crackeverythingyouget

[crackeverythingyouget]

Week 8 Tutorial

This tutorial was just dedicated to presenting our Something Awesome projects to the class. Instead of presenting one at a time to the whole class, we split into stations and presented which was great if you ask me. I thought it was better than just presenting to the whole class. We got to walk around, talk to others and learn about all the other Something Awesome projects in the class.

Case Study:

We didn’t have enough time to do the case study so I just read it after coming back home. Just a brief introduction: The major M can see the alien but cannot see the invisible man X but wants to communicate. The questions were is the alien trusted, or Is there anything urgent we should do based on the information you obtained in your trip to the alien planet?

Basically the issue here is the same as our Houdini case study. We want to verify the Authenticity of the message and integrity to check whether the message has been altered or not. We can use a secret that only the major and the man knows to communicate, which would mean one time pads, or MACs or all the other methods we’ve learned in lectures for Authentication. For integrity, we can use sending MACs and hashes to check if the message has been altered or not. We also need to keep in mind of the issues with replay attacks so something like a timestamp would prevent replay attacks.

[crackeverythingyouget]

Community/Professionalism Evidence

This post will be dedicated to providing evidence for the community/professionalism portion of my job application. I intend to get some feedback from fellow classmates. I have helped others by engaging in discussions during the tutorial case studies and lecture content whenever someone needed help as well. 

[crackeverythingyouget]

Week 8 Lectures

Root cause analysis: When something goes wrong, find out the root cause.

Root Cause Analysis (most frequent answers):

Human Error: People like blaming others, Last person to touch something that goes wrong is generally blamed

Honesty: Honesty leads to most human errors (Conduct code for Students)

Misdirection and Limited focus of humans (social engineers take advantage of this)

Similarity Matching: Finding some event similar and take notes from that, people do not like to think too much

Frequency Gambling: Physics postgrad students can answer questions from textbooks but for real life physics questions they answer just like someone who knows nothing about physics.

Attack is when someone wants things to go wrong but accidents are when they don’t and it still ends up going wrong. Building towers game: building everything first and then testing at the end makes everything collapse

2. System Error

Defense in depth

Hindsight bias - knowledge of outcome of previous event increases perceived likelihood of that outcome

3. Culture

Reflection: Mention of DuckDuckGo in the lectures also made me think of personal security and the password manager that was shown in the tutorial. I decided to improve my personal security as a result. I’ve downloaded the Brave browser, and a password manager. I’ll use it for almost all of my accounts. I’ll take advantage of the Onion Routing network in Brave as well. I’ve already started using Linux Mint on my pc!

Homework:

Chernobyl Disaster:

Trying to test the backup cooling of reactor 4

Uranium steel rods react to produce massive amounts of heat

Converts water to steam to rotate turbines

Control rods are inserted in between for cooling to prevent overheating

All control rods were removed during the test

Technicians lost control of the coolants

Temp rised

Extreme heat melted the core

1:23 AM, reactor exploded, 8 tons of radioactive debris

Radioactivity equal to 400 Hiroshima nuclear bombs

[crackeverythingyouget]

Week 7 Homework

I’ve done most of the weekly homework but since I’m doing COMP2511 and the assignment was due last week (pretty bad this term because of the trimesters and also they compressed a four people’s project into two) so I couldn’t do the homework for last week and also some of the module exercises from week 6. I’ve prioritised the lectures, case studies and something awesome projects, but I prioritised the assignment over the homework and module exercises so I’m catching up this week.

Vulnerabilities

Simple Vanilla Cake:

How much of every ingredient to add isn’t given, temperature might be a bit too low.

Caramel Slice:

Again, missing quantities for the ingredients to add

Cheese Souffle:

The time mentioned isn’t maintained properly

Codes:

Length is signed value which means a very large negative number will be smaller than max

Size of isn’t used properly. It will return the sizeof the pointer

Comparing f and sizeof(mybuff), f of type short which is 2 bytes while sizeof returns a long.

OWASP Top 10: Sensitive Data Exposure

Let us consider ourselves as executives at a bank as an example. We have a bunch of users and we need to protect user information to make sure we don’t incur losses if revealed. We do it by hiding information that only we know how to retrieve, kind of like how we hide our personal documents. We need to alter the data and only we should be able to get back the data. We need to do something called encryption. Lets take an account for user ‘Bob’. We can encrypt his name to ‘cpc’ (we shifted each letter by one alphabet called a Caesar cipher). Although this can hide his name, if anyone figures out the pattern he/she will be able to decrypt and find the data which is why we need something stronger. If we do not properly hide or encrypt our user information we might end up revealing sensitive data which is one of the top 10 biggest security vulnerability according to OWASP.

One-Time Pads:

I’ve replicated the Cribb Dragging method using a python script (check out hex()) and XOR the letters each (C1⊕C2=(P1⊕K)⊕(P2⊕K)=P1⊕(K⊕K)⊕P2=P1⊕0⊕P2=P1⊕P2) and obtain the messages

The secret to winning Eurovision is excellent hair

Everyone deserves a hippopotamus when they’re sad

Can you please help Oliver find the flux capacitor

The most important person in the world is me myself

The price of bitcoin is too damn high given the data

[crackeverythingyouget]

Week 7 Case Study

What the government stores about you:

Address: I was the only one in class who wasn’t really okay with the government knowing where I live. I understand it helps catching criminals as well but I’ve thought about it after class and it doesn’t make much sense anymore. Criminals don’t live in their homes they generally stay outside cause they’re always on the run. For mortgages, a bank can seize property that you own by law, they do not have to find you. Addresses work because we think it’s secured (we assume criminals will stay home)

Name: With names I really don’t have much of an issue. There may be a lot of people with the same name so it doesn’t contain much unique information anyway. They probably need it to store records.

Family: I personally don’t have an issue with them knowing my family but I don’t see any good reason why. Separating power will be tougher if they hold more information so they should only have information that they absolutely need. 

Medical Records: Absolutely not with this. They will contain too much information and information that probably wouldn’t be of any use for them anyway. 

Criminal Record: Jazz convince me on this that criminal records affect people’s future work. So even though I initially thought criminal records might be okay for storing, I personally think they’re no good as they’re publicly available

Internet: Most government generally only allow their bandwidth to pass. They won’t allow people from outside to bring internet cables in and this poses a huge problem, Single point of failure. A single attack from the inside will disrupt everything

Passport: I guess this is needed for verification

Finances: I would not mind sharing financial records as well. Guess it’s okay for them to catch tax frauds

Transport: Tracking transport to find location is scary to be honest. They should never be able to track people’s locations from the inside.

Appearance: Okay with my appearance as well. I feel like appearance is better for storing than residence since people around criminals who they’ve met for a couple of times might want to identify criminals but housing will provide no identity.

Education: Okay with education storing as well.

Communication: Totally not. Invading privacy is beyond security. Eavesdropping on conversation will also probably not provide a good evidence in court since it was taken out of consent.

Relationships: I understand these last two topics were probably important. I personally think relationships are important for storing. Building a link around a criminal to catch them might be helpful. It would not hurt me if the government knew the people that I know if it helps them build a network and catch someone.

Race: Probably not. Race plays a big part in a lot of things. Race definitely affects how the government judges certain race. This also affects jobs as well. People have a lot of important information about them, race should not affect the judgement, treating everyone equally regardless of their race should be the norm.

Reflection: These case studies and other exercises have helped me develop quite a lot on my Analytical Skills. Looking back on my previous tutorials, for example, the week 2 Houdini case study I only managed to barely come with a solution but I could’ve written more about how there was a shared secret between Houdini and his wife that needed to be established. It was great that I mentioned the eavesdropping issue but I also probably should’ve mentioned a small solution to it to make the analysis more comprehensive. Looking back at my previous posts, I’ve realised I’ve learned a lot of practical skills that are very useful.

[crackeverythingyouget]

SecSoc Term 2 CTF

So I attended my first ever CTF today and it was an absolutely enjoyable experience. As a beginner I was expecting to be lost but working in a team was one of the best experiences as we kept on helping out each other. We had 4 people in our team and all of us are beginners (first time CTF) so we learned and taught each other as we completed the challenges. As beginners I wasn’t really expecting to end up anywhere near the top of the table considering this was all of our first CTF, but ending up in 15th position (only short of 100 points to get top 10 :( ) wasn’t really bad. Enjoyed the challenges it really pushed us all into learning new things, especially Crypto!

I put my web exploitation experience for the web component but couldn’t finish a couple of the challenges on time so I came back home and did them after the event. We did a couple of forensics and miscellaneous challenges as well. I’m really looking forward to CTFs in the future!

[crackeverythingyouget]

UNSW Change Passwords

Richard mentioned how changing passwords are no good because people will run out of good passwords and just use weak passwords for the new ones. It always annoys me that I have to change password every single time. So for last year I used two passwords and alternated between both of them every time they sent me an email. However, this time it did not let me do it. 

This is very concerning that UNSW stores the previous 12 password hashes (I assume they’re hashes). This means if the system ever gets compromised all the previous 12 password hashes are revealed. There is no point in changing passwords every 6 months if all previous passwords are stored as the security vulnerability still exists.

[crackeverythingyouget]

Week 7 Lectures

Diffie-Hellman Key Exchange: The key exchange relies on the discrete log problem. a^b^c = a^(b*c). Alice has key b, Bob has key c, and they both choose their base as a. Alice sends a^b and bob sends a^c. Alice will then raise the a^c sent to the power of b and bob does the same with c. They both will have the same key without revealing the key itself. Any man in the middle attack will have to do a tremendous amount of work to find out the key.

Memory Corruption: Memory corruption occurs in a computer program when the contents of a memory location are modified due to programmatic behavior that exceeds the intention of the original programmer or program/language constructs; this is termed violating memory safety. The most likely cause of memory corruption is programming error. - Wikipedia

Buffer Overflow: take inputs beyond the bounds of memory and causes other allocated memory to be corrupted.

Format Strings: When the program is inputted command from the user and the program executes it. %n is used to write into memory.

The stack and heap: Stack collects memory one on top of another. Heap is used for dynamically allocating memory

Functions in C are called in stack. The return goes to the previous function in stack

Shell Code: Running an exploit to get a shell code to get access to the computer

Nop Sled: A bunch of no instruction commands followed by exploit. If the program executes anything inside the sled, it will keep on doing nothing and at the end execute the program. This increases the chances of executing as the nop sled covers a bigger part of memory

Assets: Work out what all the things you should be protecting and their relative value to you

Strategies to identify assets:

1) Regularly surveying the values of people of the involved in what you are protecting

2) Develop a sensible plan - well designed to tease this information out of them.

3) Periodically revise current list of assets

Strategies to find the value of the assets:

1) Tangible Assets: Those that are easily given a value

2) intangible Assets: These cannot be easily and objectively be valued

PGP: Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. - Wikipedia

Source: https://www.freecodecamp.org/news/how-does-pretty-good-privacy-work-3f5f75ecea97/

PKI (Public Key Infrastructure): CA is used to verify authenticity of a website

Source: https://www.thesecuritybuddy.com/blockchain/public-key-infrastructure-and-blockchain/

Reflection: This was a big day for reflection. Talking about authentication and walking through my door using my key card reminded me of how I’d get into other buildings if study space was full by just tailgating as mentioned by Richard earlier this semester. I also remembered the mention of how you’re as strong as your weakest link and also how the key reader doesn’t really protect as it was made by thinking like a defender and focusing on the strengths instead of weaknesses. It all started to be so related to each other. 

[crackeverythingyouget]

Something Awesome: Cyber

Last week, I executed all of the exploits on my Flask application so I worked on fixing some of the vulnerabilities this week. 

SQL Injection

The application was using an SQLite server to login users and add posts. The problem here was formatting the strings. Almost every single Flask tutorial or lectures will use %s as the string formatter to add SQL queries. However, all this does is take the raw input and replace it with the string. We do not want this as we can always assume that the user will always pass in malicious data. We want to detect SQL Queries. The SQL engine in Flask (also in other frameworks as well) has a parameterised queries option in the execute option. This checks if any of the sql queries are inside the query itself and prevents the user from inputting it. 

The one above was how everyone does it but the one below is how everyone should do it. Almost every framework or language has parameterised queries that prevent user from inputting queries.

Although SQL-Alchemy does not have all the features that raw SQL has but for things that can be done using SQL-Alchemy ALWAYS use it. It has built in parameterised query so there is a higher chance of not making mistakes. If more complex and powerful queries are required then use parameterised queries.

Cross-Site Scripting (XSS)

For the XSS vulnerability, the problem was that we were returning the data raw from our server. What we need to do is we need to sanitise the data. We’re long past the stage where people output as raw, most people use a sanitiser for their output but the problem is that they do it in the client side. Google has their own Javascript library to sanitise inputs and that hasn’t worked out well for them (https://www.securityweek.com/javascript-library-introduced-xss-flaw-google-search). There is another library as well (https://github.com/jitbit/HtmlSanitizer) which looks much better but the problem is trusting the client side. You can never assume client will input non-malicious code. We should always be doing all our escape strings from the backend. For this project, I am trying to sanitise the characters &, <, >, ‘, and ” from the backend and Flask already has a library called escape.

This prevents the XSS injection from the posts.

I’ve taken a different route to fixing the vulnerabilities. I did not just want to fix it as it would have been thinking like a defender, instead I fixed it first, then tries exploiting again, fixing again, and keep on doing until I could not exploit anymore. I’ve learned how to find vulnerabilities and exploit them from this project but I wasn’t expecting to develop ‘security eyes’ just from fixing the bugs. I was thinking that it would just be to fix the vulnerabilities but I went as far as researching and fixing everything from the server end and not the front end because the user can always run malicious code. I also remember my basic starter security of ‘avoiding script tags’ for XSS and all the others that I built to make things harder. I’m proud of coming this far due to this project and also my time management has improved so much more because of the project. I planned on completing earlier so I allocated some time off in the weekends to complete project earlier. This project was an amazing learning experience for me!

[crackeverythingyouget]

Video Conferencing Apps Vulnerability

Most people generally have some sort of video conferencing app installed on their laptop, but these video conferencing apps generally take it too far with the calling features and ultimately ends up having vulnerabilities all across the platform. Recently, this happened to a very popular app (should remain unnamed since it hasn’t been patched and they haven’t taken things seriously as well), let’s call it abc video calls. What’s worse is it still remains even if you uninstall abc video calls. 

Vulnerability:

The vulnerability can force the user to join in on any abc call with the user’s camera activated without the user’s permission. For Mac users, this is even worse as it can DOS any webpage on safari as well. There is a reinstall feature on this app which forces installation of the software. So even if you uninstall it, they can reinstall without user permission. It’s basically like a malware. 

ABC Video Calls not taking this seriously:

They took 10 days to address this issue and even then they were given 90 days to fix the issue and disclose publicly. Only 18 days before the end of the 90 days period was when they had a ‘quick fix’ and as soon as this was reported publicly, attackers started exploiting their quick fix. They have since taken this seriously which is a good thing.

The 90 days public disclosure is really good for fix and even though bugs are not made ‘too’ public, they might get away with it for some time but if given some malicious websites are really popular, like torrent sites, if they end up exploiting this, they could end up with a lot of user data. The time given is not to be taken lightly and the disclosure should also not allow such quick fixes as this is even worse than just not fixing it, cause now more people know public vulnerabilities that can be exploited. 

[crackeverythingyouget]

Digital Signatures

Last week, Richard mentioned a bit about Digital Signatures. I got the gist of the concept but it wasn’t clear in the call. I decided to research a bit more on digital signatures and learn more about them.

Digital Signatures are used to verify if the contents of a message (or a file) have been altered or not. 

Let us consider Alice and Bob trying to send each other files

Alice selects the file to send and hashes the file.

The hash is encrypted using Alice’s private key.

Original file is sent along with the digital signature.

Bob receives the file and signature, decrypts the signature, compares hash with by hashing the file received and checking them. If the hashes are same, the file has not been tampered with. 

This ensures integrity of the message, however, the authenticity problem still remains. The message could be from someone else. There could be a middle man attack and the digital signature would provide no such prevention for this event. This means only use Digital Signatures when authentication is not really required and integrity is very important. So places like software, or files to be sent from you, do not use digital signatures as these things require proper authentication of the source.

[crackeverythingyouget]

Week 6 Lecture

Initialisation Vector: Used to operate the first object using a function that requires two inputs. The next input will use the output and the second part of the message. IV is used to start the process.

Context Switching: Computers do a lot of processes simultaneously, context switch is the process of storing the state of a process or of a thread, so that it can be restored and execution resumed from the same point (Generally done on Stacks)

Moore’s law: Predicted by Moore in 1965 that compute power will double every 18 months, which means attackers gain 1 bit every 18 months

Disk Encryption: Use password to encrypt the key and store the key which is used to encrypt files on disk

Cold Boot Attacks: RAM loses data slowly, turn the computer off and quickly apply cold spray on the chip to reduce the speed of losing data and retrieve information

Cryptographic Methods generally don’t have flaws, the flaws are mostly at the OS level or the Protocol of using it

2FA: Using something they have and something they know to log them in

Threat Modelling Module Exercise:

I think the biggest risk here is the damage to power lines which can be natural disaster, totally unpredictable, or maybe an insider attack as well

Reflection:

Moore’s Law: I remember researching about CPUs and GPUs a couple of years ago when I was planning on buying a computer. There was a mention of how we are reaching the limits of the Moore’s law. There was mention of how we cannot design chips to be smaller exponentially so Moore’s Law might near an end. Took a bit of time to find the article (https://www.eetimes.com/document.asp?doc_id=1323507#). This would mean we were losing security by 1 bit every 18 months but we might theoretically end up losing security slower than this in the near future.

[crackeverythingyouget]

Week 6 Tutorial

*Week 5 Tutorial:

*I’ve had assignments on week 5 so didn’t get enough time to get blog about the tutorial on week 5. So basically for the case study we did split the class into two groups. One group discussed the assets, risks and mitigations from the government’s point of view of getting more self-driven cars and another discussed with the point of view of the company employees. I was in the second group and we came up with pretty good ideas.

Assets: Reputation of the company, Reputation of the overall market which might mean if the reputation is affected something similar could not be done in a later stage, Software and Hardware assets in company and user data

Risks: Correctness of the implementation, Strong standards body and testing, Corporate Espionage, Hackers

Mitigation: Encrypt data, Keep software closed source

Overall, a pretty engaging case study and an interesting tutorial

Week 6 Tute:

The class discussed about Shellcode and went through an impressive demo as well which showcased how powerful shellcode is.

Buffer Overflow:The class went through regular buffer overflow examples. They were pretty simple basic examples to get started and learn the concepts behind it. The discussion about memory in buffer overflow was very interesting.

Case Study:

This week’s case study was one of the best case studies we’ve done so far. It was basically on cyberwar attacks and defence.

Attacks:

Attack any critical infrastructure that uses internet

Potentially water source

Power grids

Offer bounties to kill

DDOS

Espionage

0 Days

Research

Recon

Ransonware

Frame others

Defence:

Educate on cyber

Educate on phishing

Track progress stats

Security measures like stronger password

Make new allies

Remove infrastructure from internet

Rely less on internet

Pen testing

Wargames

[crackeverythingyouget]

Something Awesome Update: Cyber

Last week I almost finished building the website so I moved on to attacks this week:

SQL Injection:

For login, I tried a lot of the SQL injections practices online and pretty much guessed that the string was inputted between quotes. So I used an OR statement between the strings to login without actual authentication!

Cross-Site Scripting (XSS)

I tried adding script tags but I intentionally made sure script tags did not execute (Just so I’m challenged). This post really isn’t fun anymore since they pretty much covered this in the web lectures but it was a great exercise on Natas (Highly recommend doing this)

Denial of Service Attack:

I basically wrote a script to open a socket connection on my localhost on 5000. It just keeps on opening and at one point it stops returning the opened connections. However, It takes so much time since the previous connections are not still active.

Slow Loris Attack

This is a very interesting kind of a denial of a service (My favourite!). It’s not covered in lectures and totally not popular amongst everyone. The way this works is how apache servers are configured. This does not work on all servers, but some (MOST) are. This way this works is apache servers will wait for some time to receive the full request. So how this works is that you send a small unfulfilled request byte and let the server open a socket and let the server wait for the next byte. Before the server turns terminates the server, you send another byte and keep the socket open. A server can only handle a specific number of concurrent users. My server stopped working after around 200 concurrent users. It started crashing applications after some time so I turned it off after some time.

I’ll be working on fixing SQL Injection and XSS vulnerabilities over the next week.

[crackeverythingyouget]

Length Extension Attacks

Richard mentioned a bit about length extension attacks, but I found an even better example for Wikipedia which might be very helpful. For Merkle Damgard Construction based hashes, they are all susceptible to length extension attacks. 

In order to hash the new data, ideally we would like the attacker to give us the key but since we are breaking the message into parts, hashing them and then hashing the hashes and so on, the attacker only has to do is just attach the extension at the end of the generated hash and would generate a new MAC (as long as the message has no padding at the end OR we know what the padding is) without knowing the key!

[crackeverythingyouget]

WEP Security Flaws

I researched a bit on some of the security flaws in WEP and they were massive!

The IV is too small and in cleartext: The IV used is too small to brute force in length and is also not encrypted.

The IV does not change: Ideally we want the IV to change every time we use it but in this case the IV remained the same

The IV is part of the RC4 encryption: The fact that an eavesdropper knows 24-bits of every packet key, combined with a weakness in the RC4 key schedule, leads to a successful analytic attack

WEP provides no cryptographic integrity protection

Richard mentioned a brilliant security flaw with WEP that allows us to exploit WEP vulnerabilities. The TCP/IP packets are publicly known which means we only need to change the same number of return addresses on the same network and the Access Point will just decode everything for us! This was security by obscurity at its best. Once we know what makes it cryptic, we can work a way out!

[crackeverythingyouget]

Bitcoin Security Flaw

Bitcoin can be compared to a ledger, except its digital, decentralised and global; Bitcoin transactions are its bank checks. The blockchain is stored online and anyone who wants to transact can do it by downloading an entire copy of the blockchain. This means that the checks are not private. All the transactions are publicly available.

This ledger can be upgraded (hard forked). A hard fork creates a new ledger while keeping all the legacy ledger data intact. Once a hard fork is created, the legacy network users have two options: to stay on the old ledger or move onto the new one. If everyone moves, the new ledger becomes global as the old one is pushed aside. If only a portion of users move, we get two ledgers, the legacy ledger and the forked ledger. After the fork happens, new blocks will be found for each blockchain and the chains will start differing from one another.

Let’s say you own some crypto on the legacy ledger and said ledger was split by a hard fork. You will now, post-split, own the same amount of resources on both ledgers, meaning that your balance in legacy coin stays the same while your balance in the new coin will be equal to your legacy holdings. This can potentially be a problem; if you send a transaction order through one ledger, a malicious player can theoretically intercept your hash function and use it to copy the transaction order and present it on the other ledger.

This was a classic example of a replay attack. It’s not common to see attacks taking place when money matters. This might be a big issue with publicly available blockchains. However, we must implement challenge responses on pretty much anything that requires prevention from replay attacks. A timestamp here would be useless as the key has to be sniffed, so we must make sure that anything that goes public cannot be replicated in any way whatsoever.