shensecuritylectures6841

[shensecuritylectures6841]

COMP6841 Lecture Week 8

This week we talk about errors, more human weaknesses and privacy.

When something goes wrong, what is the root cause? We usually pin it down to three parties, the first being the last person who touched the system (i.e. the last engineer who maintained an aircraft before it crashes, even though the fault might not necessarily lie with him/her), the second being culture, the culture of a company is to be blamed, this could be quite fundamental and a deep underlying problem, rather hard to fix. The third being the whole system, something was always going to go wrong, it just unfortunately happened on this particular instance, it was always doomed to fail from the start.

Building on what we have done in the course so far, more human weaknesses were discussed. First being discussed is honesty, people always lie, we love lying and we are good at it, people lie to other people and they certainly to themselves. 

Then it’s misdirection and limited focus, we should focus on what is logically the most important, but usually end up focusing on what is evident. 

Then there is the issue of frequency gambling, that occurs when we want to pick something that we want, we usually go with what hasn’t gone wrong in the past; we are also sheep, we have a herd mentality, we look for evidences that support what we believe in and we choose to selectively ignore evidences that contradict our world views. We also love following rules, in fact, the whole foundation of modern society is propped up by our tendency to believe in authority, to follow rules set out by men and deviations from this pre-established “rules” will result in public shunning.

So that was a whole lot about human flaws and inevitable human errors that result from it, how do we fight it? By making better and more error proof systems. We should aim for a system that has low complexity, low coupling (able to change components without having to rewrite everything), high cohesion (components thoroughly utilise each other) and of course, defence in depth.

Then we talked about privacy and digital forensics.

In 2019, we don’t have much privacy left, we sacrifice privacy for convenience and fun, but we can always use a few good privacy practices to increase what little privacy we have left. Examples being Incognito, VPN and Onion.

Digital forensics is “a branch of forensic science encompassing the recovery and investigation of material found in digital devices, often in relation to computer crime.”[1] COMP6445 let’s go

[1]  https://en.wikipedia.org/wiki/Digital_forensics

[shensecuritylectures6841]

COMP6841 Lecture Week 7

This week we talk about Diffie-Hellman key exchange, even more buffer overflows, assets, fuzzing and even more security protocols.

Diffie-Hellman exchange is basically a method of exchange keys over a public channel, 

The two parties first publicly agree to use a modulus p and a base g

Party A chooses a secret integer a, then sends Party B: A = g^a mod p

Party B chooses a secret integer b, then send Party A: B = g^b mod p

Party A computes s = B^a mod p

Party B computes s = A^b mod p

Alice and Bob now have a key in common which they could now use to communicate between the two parties securely.

Diffie-Hellman is secure because of this problem called the discrete logarithm problem, which means we cannot efficiently calculate modular exponentiation. So a lot of work needs to be done in order to crack Diffie-Hellman.

Then we talked about buffer overflows and how C program call/store functions (building stack frames, pushing registers, popping registers, etc.), I have now blogged about this extensively in both Week 6′s lecture summary and also in 2 of my Something Awesome blog writeups (bof and passcode). So I will not further write up on this.

Then we talked a bit on assets, security is usually made to protect our assets, but sometimes we focus on the wrong assets (such as making a door 100% force-entry proof but thieves could just crack open one of the windows and gain entry into the house without even touching the door). So it’s important that we need to be able to identify assets. Now how do we protect assets? We could use a multiparty review system, using standards and protocols, never think it is 100% secure and constantly reevaluate the assets you have.

We then moved on to this security testing concept called fuzzing, which is essentially an automated testing sequence. A fuzzer (according to Wikipedia) could be categorized into three categories:

A fuzzer can be generation-based depending on whether inputs are generated from scratch or by modifying existing inputs[1]

A fuzzer could be smart or dumb depending on whether it is aware of input instructures[1]

A fuzzer can be white, grey or black box, depending on the fact if it is aware of program structure.[1]

Essentially, fuzzing involves providing invalid, unexpected, or random data as inputs to a computer program in the hopes that it will either crash, expose bugs or reveal vulnerabilities within a system. Most of the production level software that’s in serious circulation uses fuzzing, an example being Google Chrome, it is continuously fuzzed by the Chrome Security Team with 15,000 machine cores.[2]

[1] https://en.wikipedia.org/wiki/Fuzzing#Browser_security

[2] https://browser-security.x41-dsec.de/X41-Browser-Security-White-Paper.pdf

[shensecuritylectures6841]

COMP6841 Lecture Week 6

This week we talk about IV, buffer overflow attacks and encryptions.

Initialisation vectors are basically arbitrary numbers which get used once in the very beginning of secure hashing. They basically act like seeds and after we start feeding into the hash function chunks of messages, They serve as a good way to increase the encryption of a hash function and also ciphers.

Then we talked about buffer overflow attacks, now I have documented about buffer overflow attacks extensively, so I won’t blog too much about it here. The main gist of buffer overflow attacks is basically exploiting functions which accept inputs from STDIN without boundary checks (such as gets() and scanf()), there are a variety of different methods to utilise the buffer, we could overwrite return addresses of functions, overwriting EIP (instruction pointer) to redirect the flow of the function and overwriting the GOT (Global offset tables). More technical stuff could be found in the something awesome challenge writeups (Bof and passcode). However, most modern programming languages have safeguards in place to address buffer overflow attacks, C/C++ are the most vulnerable but the latest GCC/G++ compilers compiled executable will provide warning when detecting overflows. There are also many programming techniques we should use to deter buffer overflow attacks (such as eliminating the use gets() and specifying the exact length of strings we want when using scanf(), or just use read()). Long story short, despite being one of the most iconic exploitations techniques in the programming history, it is no longer an effective exploitation.

Then we spent a significant amount of time on encryptions, to encrypt a hard drive, we first generate a random key to encrypt the disk and then encrypt the key and store it somewhere else. 

Now, how do we exploit disks even though it’s encrypted? We could exploit the RAM (which is part of the file system, as covered in OS COMP3231), RAM despite its nature, stores some data after being powered off (not for long though), but we could freeze a RAM and then be able to retrieve the data that’s stored on there later on, as freezing the RAM will slow down the data deterioration on the RAM). 

Something Awesome’s time left is ticking down, so this blog is a rather short one.

[shensecuritylectures6841]

COMP6841 Lecture Week 5

This week’s lecture continues on from last week’s building further onto the topic of hashing.

The majority of the topics this week have already been written about by me last week (through my personal extended researches). Very first thing we covered is something called the Wired Equivalent Privacy (WEP), it is deeply flawed and is used to provide WLAN with a certain amount of security, similar to those in-place for LAN connections. What it does it a stream of bits is sent through one point to another; however, a flaw occurs when we use the same key twice, we could use something like XOR to be able to crack that layer of security and obtains the plaintext. The keys are almost certain be reused again, since there are 2^24 streams, once it exhausts itself (through 23-24 bits of work), it will return back to the very first stream.

Then we built on top of hashes, we learnt about various secure hashing algorithms (such as MD5, SHA0-3), these with the exception of SHA3 are all prone to length extension attacks, when given a MAC to work with. Recall that MAC is H (P | M). MD5, SHA0 and SHA1 are also broken, which means there is some kind of technique that allows attackers to do something like a birthday attack, which is faster than brute force. A birthday attack is type of collision attack.

Which leads us to the Merkle Damgard Construction, it is a method that allows for the constructions of collision-resistant cryptographic hash functions, given collision-resistance one-way compression algorithms. Basically we first start with an initialisation vector (a set of initial states in the hash function), then we break the message into chunks and pass them into the hash functions, we keep sending more chunks into the current hash states and when the message is finished, we will be able to get the hash. It is collision resistant, as long as the compression algorithm is collision-resistant.

Then we talked about HMAC, Length extension attacks, and signiature, which I have covered last week so I will not blog about them this week.

To finish off, we then covered a bit of key stretching. We “salt” a passcode before it gets hashed, if the salt strings are unique to the individual users, the passcodes almost always be distinct and unique before we hash it. Which makes the amount of work required for the hackers to brute force a hash to be as long as possible. Another thing we do to deter attackers from preventing brute forcing passcodes is designing a hash to be slow, such that even more work is required from the hacker to brute force a large list of passwords. We also talked a little about the separation of data and control, very much like the separation of power in politics, no one party should be able to have control to both data and control.

[shensecuritylectures6841]

COMP6841 Lecture Week 4

This week we touch on ciphers, hashing and social engineering.

The substitution ciphers have in total 26! different combinations, which is equivalent to around 90 bits of work, that is an incredible amount of work required to brute force a substitution cipher. But we don’t need to brute force it, English letters follow a very specific frequency pattern, to be exact “etaoin shrdlu” descending. We have to introduce a concept called entropy now, entropy in physics means chaos, it is the second law of thermodynamics. But in security, entropy stands for randomness. The more entropy there is, the heavier the entropy becomes. There are 2^25 different 5 letter combinations, but only 2^13 valid 5 letter words. Which equivalents to each letter adding an additional 2.5 and a bit bits. Passwords typically use words which are valid rather than nonsense (or maybe small variances on top of valid words). So we can use that to optimise our cracking, this is called a “guided bruteforce”.

Then we talked about telegrams, let’s assume we are a bank in the middle of no where, how do we make our communications with the “main branch” tamper-free? There are possible attacks called “replay” attack which basically intercepts a valid transmission and replay it again (with all the right authentications). One idea to combat this is to have the return messages be different based on each telegram we send out. So that way replaying a previous message will fail the follow up authentications.

Hashing is basically a function that makes big things into smaller things, but it also has to follow a few principles. They have to return the same hash everytime, assuming the inputs are the same. They also should be able to be “hash collision resistance” which means it will be hard to hash two different inputs to match the same hash results. It should also be preimage resistance (which means, it should be hard to reverse a hash, if we know what the hash is). It should also be second preimage resistance which means given a hash input and a hash result, it should be hard to find another input that matches the same hash. The idea of hash is that it’s easier to look at the hashcode than the original, and slight tampering with the original message and the resultant hash will be significantly different, this is called an “Avalanche effect”. Another way that Hash is used is the MAC (message authentication codes), basically it is a hash of the password appended with the message itself H(P|M), however this could be attacked by length extension attacks, so usually we use HMAC, which is double hashing, H(MAC | H(P | M)). This makes it significantly harder to crack.

Then we talked about social engineering, it is used in 95% of all cyberattacks. A social engineering attack is basically exploiting people to do your biddings. How a social engineering occur is basically at first, investigation (learn about the victim), then hook (build a connection with the victim), play (get the information you require from the victim) and then exit (leave the conversation without arousing suspicions). How do we persuade people to give us what we want? There are a few principles, first is that people can always be persuaded, people would always feel obliged to return a favour if you do them a favour at first; if people like you, it’s much easier to influence them, also people follow authorities, if you are authoritative, people will be a lot more willing to give you a benefit of the doubt.

That’s not all though, we could also fish hard drives out of the dumpsters and obtain informations which have not been wiped off of the drives. Documents which are shredded can be pieced back together and even if something is burned, information could still be obtained from the ashes.

[shensecuritylectures6841]

COMP6841 Lecture Week 3

This week we touch on risk, how to deal with risks and more cryptography.

Risks are invisible, we don’t really know when/if we took a risk until something goes wrong. Risk is everywhere and is always persistent. We are bad at analysing and assessing risks because of our tendency to overlook things that have an extremely small probability. Sometimes the risks despite their small odds, could yield catastrophic results. We call these “low probability high impact events”, such as a terrorist attack or an asteroid.

Then we talked a bit about technical aspects within security, but before that we covered “bits”, 1 bit is 2 different outcome, so when something has 4 bits, it could have 16 different outcomes. Same with information and security. There is something called the space-time tradeoff, if we want to brute force something, statistically we would be able to get there after trying half of all possibilities. There is another concept called “work factor”, which we basically increase the amount of work required for someone to break into our system so that it no longer is profitable for them to do it.

Now how do we deal with risks? There are four ways, we could try to prevent risks by removing vulnerabilities, we could try to limit the damage caused by risks by minimising the effects of such risks, we could try to shift the risk to a third party (i.e. buying a life insurance) or we could try to wear the risk (i.e. tanking it)

Then we touched on this concept of public key cryptography, in which the idea is that if we have one lock and only one key that would work for one party, if we want to give 30 people access to our locks, we have to issue 30 keys to the 30 people (otherwise they will be able to access other people’s communication to you). This could get messy very soon. So basically, a system called RSA was introduced, it has two keys, one that is public and another which is private. Public keys can be used whoever that wants to send messages, private key is kept by the receiver of the message. The two keys can be calculated using a series of calculations, as follows:

Find two large distinct primes (p, q)

Calculate n = p * q

Calculate the Euler’s quotient which is (p - 1)(q - 1)

Find an integer e such that 0 < e < p, q and gcd(e, Euler’s quotient) = 1

Now we have a public key (n , e)

Find an integer d such that e * d = 1 mod (Euler’s quotient)

There is our private key (n, d)

We can then encrypt our messages (M in this case) using the public keys:

c = m ^ e mod (n)

We can decrypt our messages using the private keys:

m = c ^ d mod (n)

RSA is hard to brute because of a mathematical property called prime factorisation.

[shensecuritylectures6841]

COMP6841 Lecture Week 2

Our second week of lectures involved talking about the very recent ANU Hack and the cybersecurity email sent out by UNSW, security by design (as opposed to obscurity), a LOT of ciphers and touched a little bit on Type I & Type II errors.

ANU hack was one of the most sophisticated attacks against an Australian education institution, 19 years worth of data was breached. What can we do, if we were to give advises to the UNSW vice chancellor? A few ideas were floated out there, first being don’t suggest hiring consultants (wink), second being penetration testing and make our security better by some means.

Then we talked about security by design, Richard used the examples of a submarine for this particular topic. Submarines have multiple compartments, if one compartment floods, the ship doesn’t sink. Likewise with security engineering, if one part fails, the whole system shouldn’t be compromised. Then we talked about the various aspects being a security engineer, first being trust (trust no one, not even oneself), second being defense in depth, avoiding single points of failures and compartmentalise our security (like a castle with outer walls and inner walls).

Then we talked about physical security, with software systems, it is sometimes incredibly difficult to identify tampering. If someone can gain access to the underlining hardware (i.e. a usb loaded with a rootkit), they can do whatever they want. We as software engineers always assume the hardware is always trustworthy and focus our main security efforts on the software, but hardware attacks are increasingly common and as we touched on earlier, could circumvent the software security safeguards in place.

Then we talked about a few ciphers, starting with Vignere cipher which is essentially a modified version of Caesar cipher. Vignere ciphers shift a plaintext message by an amount corresponding to the letter’s alphabetical order. Then we talked about the index of coincidence, which is basically a way to determine if a cipher is a mono-alphabetic substitution cipher or not. If a cipher is a substitution cipher, their coincidence index should be roughly the same as English. Then we talked about the Enigma machine, which is an encryption technique used by Germany in the second world war. It is another variation of the Caesar cipher plus an almost infinite length of password. Following that, we touched on OTP (One time pads), it is “theoretically uncrackable” but it introduces the question of key sharing.

And at last just a few things about type I/type II error, basically Type I error is false positive (i.e. allowing an unauthorised user to gain access to a system), Type II error is False Negative (i.e. not allowing an authorised user to gain access to a system). Richard said to not stress that much about which one’s which, but just aware of their presence.

[shensecuritylectures6841]

COMP6841 Lecture Week 1

Our very first week of lectures involved a series of introductory remarks and various security topics.

We talked about what exactly makes fora good security engineer, an introductory security concept called “Security through obscurity” and some cryptographic principles.

Basically, in order to become a good security engineer, we need to first understand that there would always be vulnerabilities and it is our job to be able to keep alert about potential problems and be able to provide solutions. Next, we need to be good at analysing where the problems lie. This skill of course, does not come from nothing, we need to be able to learn from the past, understand why incidents in the past happened, understand how they happened and learning what we can from these past incidents. Which leads us into the biggest vulnerability of all, humans. We are terribly good at being overconfident and overlooking mistakes and vulnerabilities. Just because we don’t think it is possible to be hacked doesn’t mean we actually are. We also touched on threat model (which is basically who we are facing), vulnerability (the flaw) and exploitation (attack based on the flaw).

Security through obscurity is this over-reliance on the complexity of our software for security. This is a poor idea simply for the fact making our code harder to understand does not mean it will be more secure or harder to crack. The people who need to maintain and provide security for your code might not even be able to identify the security exploits that could otherwise have been discovered. Then we touched on this principle called the “Kerckhoffs’s principle”, in which it basically states that a “cryptographic system should be designed to be secure, even if all of its details, except for the key, are publicly known. [1] Basically good security happens when hackers know everything we know and can’t do anything about it.

Then we touched on CIA (cryptographic principles)

C stands for Confidentiality - Only authorised users could have access to selective information

I stands for Integrity - Maintaining the “trustworthiness” of a message, making sure the message hasn’t been tampered by anyone

A stands for Authentication - Some way to show that the message is genuine, for example usernames/passwords.

Then we talked a bit about ciphers, one of the oldest ciphers in the world is the Caesar cipher, which just shifts your original message by a certain amount.

Caesar is a type of substitution cipher, which is when a/many letters is/are substituted for other letters. Then there’s the transposition ciphers, which is when the letters are maintained as their original letters but the orders of which are shifted around.

Then we looked at the Halifax Explosion, which happened in Halifax, Canada in 1917. Wha happened was a ship was carrying explosives through Halifax, then a misunderstanding happened between this ship and another which caused a collision. Sailors managed to abandon their ships prior to the explosion. This killed almost 2000 people and was the biggest man made explosion prior to the atomic bomb.

So the question beckons, how did the sailors managed to escape the explosion while 2,000 other people died? we are caught in our routines, unable to shift between our normal day to day routines to this “We are going to die in 3 minutes unless we do something” mindset in a flash. This is why we have a hard time adjusting in the face of overwhelming disasters.

[1] WhatIs.com. (2019). What is Kerckhoff’s principle? - Definition from WhatIs.com. [online] Available at: https://whatis.techtarget.com/definition/Kerckhoffs-principle [Accessed 26 Jul. 2019].