ysdkang

[ysdkang]

Something Awesome - Reflection

When I initially started the project, I wanted to write a keylogger for Windows (since most people are running Windows, I wanted my project to have a real world use case). I ended up writing a keylogger using a module called pyHook, but I didn't feel like I learned anything. I had written some lines of code implementing pyHook, but I had no idea what was happening under the hood. So, I scrapped the keylogger and started again but this time in C, and for my own system, linux.

Making this keylogger was probably the most fun I’ve at uni so far. I’ve always been fascinated by security and it was awesome to learn what is happening low level with all the various event drivers, how to access them and to record them in readable data. 

I learned a lot technical skills for sure, but I also learned some important lessons:

1. Don’t mess around with system start up scripts as you may be locked out of your machine if you make a mistake. 

2. Creating a keylogger for an OS does not means it works on machines that run that OS. It would take quite a bit of work to write a keylogger that works for all Linux machines. 

3. It would take even longer to come up with a method for remote injections, which was what I had proposed in the beginning, and thought I could do it in the time that I had. I was a fool. Even if I could remotely inject a program and get it to run with root privileges, every system is different so I would need cat and grep a bunch of variable names around the system before it would work. Also, depending on the language it is written in, the target machine would have to have certain libraries or modules installed for it to work. For example, the keylogger written in Python would need the module pyHook installed on the target machine. 

Overall, I enjoyed the project immensely and I plan on working on the remote injection capabilities over the summer. 

[ysdkang]

Week 6 - Case Study - Ravens FTW?

Scenario: If world war 3 was to occur, a big component of the war would be fought in cyberspace. As a committee in the ASD, what are some recommendations you propose to the government? 

1. I think our primary focus should be on the military. Yes we can have backup power systems, etc for civilians but as soon as our military is made redundant, we will lose the war and the steps we’ve taken for the civilians will be all for nothing. I believe our number one focus should be to have a set of backup communication system for the military. As a former Air Combat Officer, I can confirm that cutting out comms will make the armed forces almost useless. A modern military cannot function without communication. Events occur in real time in rapid pace and majority decision making is dependent of information coming from other units. 

2. We should expect even the backup communication systems to eventually fail. We need to have procedures in place for each individual unit so that once we do go ‘dark,’ individual units can continue to operate, with the knowledge of what other units are doing. 

3. We need to have backup power, food/medical supplies for civilians and a evacuation point, where they can safely wait out the attack. As a society we’ve come to depend on our infrastructures, and these aren’t trivial matters. Without electricity we can’t operate our trains, traffic lights no longer work, alarm systems may fail, and life support in hospitals will cut out. 

. 

.

.

10. (This was our worst recommendation) - We could train ravens to deliver our messages for our military communications, because ravens can’t be hacked. Although this is true, our military no longer moves on foot/horses. We can deploy a jet and have it within the required location within minutes. The ravens wouldn’t serve much of a purpose when we need almost instantaneous comms..

[ysdkang]

Week 5 - Case Study - AI vs the World

Scenario - you work in a company that develops many things, but among them also self driving cars. As a consultant for the company, what are the major risks of going to market (we will be selling to other companies) with self driving cars? How will we mitigate these risks? And what is your final recommendation? 

Company Assets 

1. PR/Reputations - this will be the biggest issue. We will potentially put millions of drivers (truckers, taxi drivers, delivery, etc). Not only that, accidents will occur and when they do, we may receive some of the blame. 

2. The technology itself. This is proprietary tech. After we hit the market, expect to have copy cats flooding the market (yes this will be harder to copy since it isn’t as simple as copying the external shell of something) - whether it be through stealing company secrets or innovation of other companies catching up. 

3. The cars themselves (although this is not our company’s assets). If a fault were to occur, cars will be left in the middle of the road. How will we mitigate this? 

4. Remote cyber attacks? What if malicious attackers can take control of the vehicles remotely? 

How will we address these risks? 

1. In terms of PR issues, we will need to manipulate (or somehow persuade) the media report on the emergence of self driving cars as mostly a positive thing. Yes, jobs will be lost - there’s no doubt about that. As a company, we need to admit this and show the public that we are aware of the consequences. However, self driving cars will also create more jobs and more importantly, it will take out human error out of driving and significantly decrease the number of accidents on the road. 

In terms of getting the blame for accidents (because previously, if I sold a car to Jason and Jason hit a pedestrian, the fault was with Jason. Now that drivers are out of the picture, it is not as straightforward), there’s a few things we could do. Have 24/7 monitoring of systems and a 360 degree camera to determine if the accident was due to external forces, or perhaps the driver was messing around with the controls, etc. There are other methods such as having the companies we sell the technology to accept that they have final responsibility of accidents if they are to happen. However, if there was an accident and it was our fault, beyond a reasonable doubt, we should own up to it and pay for the damages. This will create a trusting relationship with the public and help with the success of the company long term. 

2. This is inevitable. Expect other companies to eventually catch up. Have a plan on how we will stay ahead of the competition. 

3. Have the cars being monitored 24/7. If something is at fault, or about the go wrong (perhaps this prediction can get better with machine learning), have it pull over to the side of the road and wait for a technician, just as you normally would. 

4. This is a tricky one, because there is no way to prevent these type of attacks 100%. As we are under the assumption that there are still people monitoring the cars (much like train safety officers that have a birds eye view of all the trains), we could implement a remote shut down capability. If they suspect foul play, the can pull the vehicle over and force a shutdown.

Final recommendation: yes, I believe we should go forward. Yes there are risks and jobs will be lost and accidents will occur, but it will be much safer than human drivers and it will make us a lot of money, and at the end of the day that’s our primary goal. Also, self driving cars are inevitable. We may as well be first. 

[ysdkang]

Week 6 - Feistel Cypher

[ysdkang]

Week 6 - How would you encrypt a hard-drive?

First of all, encrypting an entire hard drive is a lot of work. If something goes wrong, the chances of recovering lost files drop considerably. Then should you backup the data? But what’s the point of encrypting a hard drive, and backing up the data and not encrypting that backed up data? For me, I would be satisfied with a single encrypted folder. There are a few different methods such as USB hard-drive encryption - whenever a file is written and stored on the drive, it is automatically encrypted by software and decrypted when the data is read, while the rest of the data remains encrypted. 

However, if I was to encrypt a hard drive I would go with a full hard drive encryption. This method will protect me from making mistakes such as forgetting to encrypt a particular file. This can slow down the drive, but this shouldn’t be an issue with the processing power today. 

[ysdkang]

Week 6 - Moore’s Law

Moore’s Law is the observation made in 1965 by Gordon Moore (co-founder of Intel), that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented. Moore predicted that this trend would continue for the foreseeable future. This law is expected hold true until 2020-2025. 

So, what does this mean for encryption? 

I think the first thing to realise is in recent years, Moore’s Law has slowed down a little and that the number of transistors increasing only helps with brute forcing a encryption. According to ‘eetimes,’ it will take 1.02 x 10^18 years to brute force a 128-bit key and 3.31 x 10^56 years to brute force a 256-bit key. 

If you assume that:

1. Everyone on the planet owns 10 computers. 

2. There are 7 billion people on the planet. 

3. Each of these computers can test 1 billion key combinations per second. 

4. You will crack a key after trying 50% of possible combinations. 

It will still take the entire earth’s population 77,000,000,000,000,000,000,000,000 years to crack ONE 256-bit key!!

With this in mind, let’s think about the ROI for a hacker to break an encryption - because it will cost a significant amount of resources (money) to break a 256-bit key, let alone a 128-bit key. How much is the encrypted data worth? Also keeping in mind that we can encrypt a file with more than one key - it probably is not worth it for the attacker. 

You should be weary of other attack vectors such as social engineering and phishing. Moore’s Law has a long way to go before our keys can be realistically cracked with a brute force attack. 

[ysdkang]

Week 6 - Stack Smashing

A buffer overflow, or stack smashing occurs when a program writes to a memory address on the program’s call stack outside of the intended data structure, which is usually a fixed length buffer. A buffer overflow is caused when a program writes more data to a buffer located on the stack than what is allocated for that buffer. This results in corruption of adjacent data on the stack, and in cases where the overflow is triggered by a mistake, it will often cause the program to crash or operate incorrectly. 

A stack buffer overflow can be caused deliberately as part of an attack known as stack smashing. If the affected program is running with root privileges, or accepts data from untrusted network hosts then the bug is a potential security vulnerability. 

A function like below works fine for arguments smaller than 12 characters, however any arguments larger than 11 characters long will result in corruption of the stack. 

void foo (char *bar) {

    char c[12];

    strcpy(c, bar); //Doesn’t check for size of bar

}

So how can we prevent this?

The most obvious technique is to prevent the problem from even happening. Buffer overflows occur when a program tries to write outside the bounds of a data structure. Using a language like Java will manage the memory for you. If you must use C, ensure that you perform proper checks before writing to a buffer. 

The second technique is to mitigate the damage a buffer overflow can cause. Techniques like stack canaries fall into this category. They work to limit the damage a buffer overflow can cause by making it more difficult for an attacker to execute arbitrary code after an overflow. 

[ysdkang]

Week 5 - How to Choose a Password

According to an article in the “Science of Password Selection,” nearly one third of passwords fall into one or more of the following categories:

Name/nickname of a loved one, name of a pet, street/city/location of significance, a birthday or special date, a password incorporating the website’s name, any combination of the above. 

Also, even if a password may take 100 trillion years to crack, if you use the same password for every site, your password will be useless - because you should assume one of the sites will eventually get hacked and your password will be leaked...meaning the password to all the sites will be leaked...

Passwords are a inherently bad choice for authentication, because the longer and more complicated a password is, it is harder to remember and easier to remember passwords are easily guessed by computers.  

Here are some rules of thumb:

1. Up to 8 character passwords are too short. 

2. Use a different password for each app/site. 

3. Don’t use easy to guess passwords like the examples above. A random mix of letters, symbols and characters or words is best. 

4. Use a password manager if you can. This way, all your passwords are completely random and you only have to remember one master password. 

[ysdkang]

Security Everywhere

I received an email (I won’t say from what organisation) with an encrypted file, but they had the password for the encryption in plaintext in the same email as the encrypted file...

[ysdkang]

Week 5 - Salt

A common way to store passwords in databases is to hash the passwords. When a user logs in with their plaintext password, the password is hashed and compared to the hashed password in the database. In theory, this should be enough to stop an attacker getting a hash and figuring out the password, since a hash can only go one way. 

But, there are tools like Rainbow Tables where you can input a hash, and the table will lookup pairs of common passwords and its hashes, and try to match the hash with the input hash. 

You can also do a dictionary attack, where you attempt to find the plaintext password by hashing common passwords and comparing them to the target hash. A bruteforce method would be to try every combination of characters against the hashed password to see if you get a match. However, this will take a very long time. 

As you can see, hashing a password alone is not secure enough. We can further protect passwords with the use of salts. Salts are random set of characters that are appended to the end of a users password before they are hashed. Salts are generally stored in plaintext next to the password. This will prevent most rainbow table look ups, as the password “password!” is most likely in the table, but the password “password!@^$&#&GHdjkdh” probably is not. However, since the attacker knows what salt to try, the password is still vulnerable to dictionary attacks and bruteforce attacks especially if the attacker knows where to place the salt. 

This brings us to peppers, a pepper is a short string or character appended to the end of a password. Peppers are random and different for each password. For example, capital ‘M’ may be a pepper. So, the hash stored will be hash (”password+m”). During password validation, the website will cycle through every combination of possible peppers with the user password, until a match is found - e.g. website hashes password + a, password + A....until password +M and thus a match is found. Peppers are not stored. So, if an attacker wanted to bruteforce a password, it will take:

time taken with out pepper * number of different pepper combinations. 

This increases the login time for the legit user only slightly, but increases the time for an attacker to crack the password significantly. 

[ysdkang]

Week 5 - Hashing

Preimage Resistance: given the hash, it should be hard to find the original message. 

Second Preimage Resistance: give the hash and the original message, it should be hard to come up with a second message that has the same hash. 

Collision resistance: When allowed to control both messages, it should be hard to choose two messages that result in the same hash. Similar to second preimage resistance, but you control both messages. 

Hash algorithms generally have 3 principles. 

1. Speed: it should be fairly quick, but not too quick. If it’s too slow, no one will  want to use it. If it’s too fast, it will be easy to create documents with the same hash as others. 

2. A small change in the original message should change the hash. 

3. Avoid hash collision. 

#Hashes should always have the same output string length. 

[ysdkang]

Week 5 - OWASP #1 Vulnerability - Injection

An injection of code happens when an attacker sends invalid data to the web application with the intention to make it do something different from what the application was designed to do. One of the most common example of this is the SQL query consuming untrusted data. 

The core of a code injection vulnerability is the lack of validation and sanitisation of the data consumed by the web application, which means that this vulnerability can be present almost anywhere. 

How can we prevent code injection vulnerabilities? 

Here are some OWASP’s technical recommendations to prevent SQL injections:

1. Use safe APIs which avoid the use of the interpreter entirely. 

2. Use server side input validation. This is not a complete defence as many applications require special characters, such as text areas or APIs for mobile applications. 

We won’t ever reach perfect security, but we can at least implement something like ‘best security practices’ that developers can follow, much like design patterns.  

[ysdkang]

Sidenote - Calculating mod on a regular calculator

E.g. 10,000 % 886

10,000 / 886 = 11.2866

11.2866 - 11 = 0.2866

0.2866 * 886 = 254 = 10,000 % 886 

[ysdkang]

Week 4 - MACs

Hashes can be used to detect changes, but the concern with a hash alone to provide integrity is that the attacker can change the original message and alter the hash as well. To overcome this, MACs combine the message with a key and hash the result. The MAC is then sent with the message, and the receiver performs a MAC on the message, with the shared secret key and confirms that it matches the MAC that was sent. 

However, this isn’t completely ‘hack proof.’ Attackers can still perform length extension attacks, where they can append to the message, and calculate a new has that matches the key. They don’t need need to know the key itself to do this, just the length of they key. 

hash (key | msg) --> vulnerable to length extension attacks. 

hash (msg | key) --> vulnerable to collisions. Messages can be forged still. 

hash (key | message | key) --> still problematic. 

This brings us to the HMAC - hashed message authentication code. 

1. We create 2 subkeys from our primary key - k1, k2. 

2. We calculate the hash of k1 + message, then append the result to k2, then hash it again. 

3. The result looks like: hash(k2 | hash (k1 | message)). 

Length extension attacks are not possbile because the attacker would have to know what the ‘internal state’ was after has (k1 | message). 

[ysdkang]

Week 4 - Bits of Penguin

The possible combinations are: 

Right foot: yellow, purple, blue, green, red, brown

Left foot: green, blue, yellow, brown, red

Left wing: blue

Right wing: yellow, brown

A penguin may have all or none of the unique colours. According to the answer, there are 7 x 6 x 2 x 3 (they must have added +1 for the ‘no colours’ option).  However, shouldn’t the total number of permutations be 2^6 * 2^5 * 2^1 * 2^2?

Since order doesn’t matter, each colour has the option to be either ‘in’ or ‘out.’ Hence, each body part can have be calculated like below:

Left foot: 2 (green yes or no) * 2 (blue yes or no) * 2 (yellow yes or no) * 2 (brown yes or no) * 2 (red yes or no) 

aka -> 2^5. 

So, for all body parts it would be 2^6 * 2^5 * 2^1 * 2^2 = 2^14 = 16k combinations, which seems to high as a gut feeling. So, I may be wrong. 

But, manually calculating just the left wing with right wing gives a total of 8 combinations, which is 

2^1 * 2^2, not 3 * 2

[ysdkang]

Week 4 - Bits of Security

To calculate bits of security, essentially you find the total number of permutations for the password, key etc and estimate the closest number that is a power of base 2, to the number of permutations. 

So, bits of security  = log2(number of permutations). 

On the calculator we can do this quite easily. 

log2(num) = ln(num) / ln(2). 

Often when we’re asked to calculate bits of security (especially from the defenders point of view), we take into account the average case. So, if there are 100 possible permutations, we assume the attacker will be able to break the system with 50 guesses, or attacks. 

[ysdkang]

Week 3 - Lock picking

Raking - the most basic form of picking a lock. A tension tool is inserted into the lock, followed by a rake. Then, the rake is moved about a bit. It is a crude, simple technique that beginners can learn quite easily. Despite it’s simplicity, there are many benefits of raking:

Speed: a lock can often be raked in seconds. 

Ease: anyone can learn to rake and have success early on. 

Practical: one rake, or a set of rakes will fit literally millions of locks. 

Effective: it may not be an effective technique on the more security conscious locks, but it works in most everyday locks we see today. 

Bumping - a lock picking technique that refers to the repeated striking motion used to dislodge the pins inside a lock. Doing this requires a specially cut key, known as a bump key. 

1. Find a key that fits into the lock you’re attempting to bump. The keys won’t be the right size or dimension to move the pins, so they key won’t turn. 

2. Identify the position of the valleys in the teeth - at the bottom of each tooth is a flat area known as the ‘valley’ that separates the teeth. To disengage the lock, these valleys need to be filed down all the way to the main shaft of the key. 

3. File the valleys down to their lowest position. 

4. Make sure the teeth are level. If the valleys of the key at the front are deeper than those in the back, they won’t be able to slide into the lock. If the valleys at the back are deeper, you may have difficulty pulling the key out of the lock after bumping it. 

5. Insert key into lock and push it until it stops, the pull back slightly until you hear or feel the last pin click. This puts the pins in the right position to be manipulated by the teeth of the modified key. 

6. At this point, keep wriggling and turning the key. If it doesn’t work right away, hitting the back of the key with a blunt object while you turn it may help. This is what is known as the ‘bump.’ You’ll need to hit the key quite hard, as the technique requires the force to be transferred through the lock. If successful, the pins inside the lock jump momentarily, creating enough space for the key to turn the rest of the way.