z5209760-blog

[z5209760-blog]

Ghost: Post-Tutorial Analysis

This week we discussed the Stargate Ghost Problem. 

Our task was:

Suppose you are the friendly Major M from the base who can see the alien A but who cannot see the invisible man X. 

What would you M do to get from X his report on the Alien's (A's) planet?

Our Solution (not really):

Here’s how my group approached the question:

When we first read the question, we though that the invisible man was tangible and could communicate with us through other means aside from going through the alien. However Andrew said that this would defeat the purpose of the question. He said that the invisible man can’t speak or communicate with us directly.

For some reason we interpreted that as “you can’t communicate with the invisible man AT ALL” and that made us have a number of questionable solutions to the problem, which are probably too bad to say anyway.

It wasn’t until the other groups started giving their answers that we realised that we didn’t understand the question properly.

So now that I understand the question properly here’s a possible solution.

Assuming the alien has no supernatural powers like super hearing, the ability to see through walls etc, you and the invisible man enter an isolated room where you will discuss as secret with them. The secret will be of the form “if the enemy incorrectly conveys your message your next message should contain the keyword/message X, otherwise continue sending messages”. X is our secret and should be long enough such that it will not randomly appear in a message.

Thoughts:

A major problem for my group in this case study was our lack of understanding of the question. This led us to make assumptions that made the problem difficult for us to solve it. I hope that next I see a question like this I’ll approach with a more open mind that is not very rigid in forming restrictions in the problem

[z5209760-blog]

Lecture Reflect-ure: Week 8

This week we focused on errors.

Whenever something goes wrong, we often try to find the root cause of the accident. There are three things we can allocate blame to:

humans - we like to blame the last person to last touch the system as the cause of its disaster

the culture - the culture of a company was not suited to running the system safely. This itself is something very vague and does not tell you specifically how to fix the problem. It’s very easy to throw money at this problem and pretend that the culture has been changed because money was invested in it

the system - if the system is too complex, too tightly coupled, not very cohesive, it is a disaster waiting to happen.

Human Weaknesses

Bringing back what was untouched since week 3, it’s time for human weaknesses!

dishonesty - humans are prone to lying and in general we are not very good at telling the truth. In fact most people get away with lying because they thoroughly believe that what they are lying about is the absolute truth *ahemTrumpahem*

limited focus and misdirection - as humans, we aren’t able to focus on many things. Instead we have a series of heuristics that we follow to find the most important things to focus on. Because of our lack of focus, we are easily subject to misdirection (especially when they distract us with gestures, eye contact, sounds, etc). To simplify, we focus on what grabs our attention.

heuristics

- similarity matching - match whatever is happening now to what has happened in the past and you are very likely to act similarly to how you did before

- frequency gambling - if many patterns match, you will pick the one that was most used in the past

Why do we do the above? Because our brain likes to act in a way that requires minimal thought and the easiest way to do that is by doing what you’ve done before.

confirmation bias - we ignore what we don’t like and only focus on evidence that support our claims

satisficing - instead of maxmising something, we only do was is good enough or satisfactory

group-think - when you value your membership in a group, you are more likely to follow the consensus of the group even if you do not personally agree with it just so that you will not lose your value in the group

Systems

We like to believe that an event has only one significant cause, and this is greatly emphasised through our retelling of the events. We will simplify them to what we thought was important and will probably exaggerate what we have left in. This provides us the illusion of control; that we can control the outcome.

The true cause of an event is in fact a series of event all resulting from the design of a system. In a system there can be direct errors, errors which give you direct feedback or latent errors, errors, whose consequences do not appear until much later. Combined together these errors are a disaster waiting to happen.

So how can we design better systems?

reduce complexity

have high coherence

have low coupling

have visibility of actions and the system itself

don’t make data lakes!! get rid of something as soon as you don’t need it. Don’t let the data pile up and become a target

[z5209760-blog]

Lecture Reflect-ure: Week 7

This week we covered Diffie-Helman, vulnerabilities, assets, PKI and a few more things. Let’s quickly go over them

Diffie Hellman

Diffie Hellman is a way of generating a shared secret between two communicators. 

The simplest way to describe the protocol is like this: 1. Pick two number p and g, where p is prime and g is a primitive root modulo p. We will use p as the modulus and g as our base. 2. One person chooses a secret number a and the other also chooses a secret number b 3. The (secret) key will be g^ab mod(p)=g^ba mod(p)  which is essentially (g^a mod(p))^b mod(p)=(g^b mod(p))^a mod(p)

A great analogy commonly used the paint analogy where two people have a common paint and mix it with their secret colors. The secret mixture become their common secret.

Diffie Hellman does not provide authentication. It only confirms that they person you are communicating with has not changed since you started communicating

Krak des Chevaliers

Richard briefly went over the fall of his favourite castle, the Krak des Chevaliers. The castle was known for being impenetrable and no one had ever reached its inner walls. The only reason the Castle fell was because its beseigers forged a letter telling the crusaders, who had fortified themselves in the inner walls of the castle, to surrender. So the Castle fell not because its defences weren’t strong enough but because the crusaders we socially engineered!

Vulnerabilities

A vulnerability is essentially a weakness. It is something that can be exploited and with regards to programming, software bugs are usually a vulnerability. The most common types of software bugs include memory corruption, buffer overflows and format strings. A good example of format string bugs would be printf’s %x format, which lets you write to memory and is obviously a very bad idea. 

During the lecture we went over a few snippets of code and the biggest takeaways were:

don’t use gets(). EVER.

don’t optimistically indent unless you’re certain it works

always check return values

Facets of Assets

Assets are something that have value to you and they are something we want to protect. Sometimes its hard to identify you assets. Take a look at Team America. They were trying to stop terrorist from using a weapon of mass destruction in France. Naturally their asset was the lives of the civilians, but this didn’t quite align with the civilian’s nor France’s assets; it national landmarks, the Eiffel Tower and Louvre. In the end the destroyed both of them to the dismay of the French :(

So how can we better identify assets:

getting as many perspective as possible - we need to look at our threat/problem from as many perspectives to fully grasp it

develop sensible plans - critique your ideas constantly to improve them

revise your current list of assets - assets are constantly changing you want to make sure you are aware of any changes

We also have different types of assets:

tangible assets - physical items we can easily give value. e.g. jewelry

intangible assets - more conceptual ideas. These aren’t easy and objectively valued. It can be measure in terms of monetary value or even psychological and emotional costs

Public Key Infrastructure

PKI is a way of making sure that you are communicating with the website you think you are communicating with. A public key is available to any user that connect with the website. When communicating we, the clients, use that public key to encrypt and decrypt our messages while the website uses it private key to do the reverse.

PKI is authenticated using certificate authorities. They are the people who check the websites are who they claim they are and given them a certificate (usually found as a lock symbol on the url). Your browser keeps a list of trusted certificate authorities and if it sees that a website has been authenticated by one of them it trusts the website.

PKI is great for preventing man-in-the-middle attacks because it authenticates who you are talking to and once communicating via public-private keys your communication can be expected to be secure. However a whole new areas of issues arise. Certificate authorities are paid to identify your website, not to check your website is dodgy and malicious. If you are who you say you are then you are given a certificate. There are authorities that do background checks on a company but that does increase the price of getting certified.

[z5209760-blog]

Snoop-y: Post-Tutorial Analysis

This week we debated “should the government or government agencies collect and have access to your data for good purposes, or should citizens, e.g. you, have a right to privacy which stops them?”

My team was against the government and a summary of our points would be:

great risk for Type I & II errors - if you were to mitigate one, would you want innocent people being recognised as criminals or criminals being undetected

disproportionate benefits - the benefits of surveillance of a few suspicious persons out weigh the benefits of everyone else

it has been shown that such surveillance only helps them recapture already known criminals rather than new ones

re-purposing of data - the current government may have good intentions for using the data but there is no knowing what the future government will do with it. An example of this would be the Rwandan genocide, where civilians all registered their ethnic groups during a peaceful government, but from this data Hutu extremists where able to identify and slaughter about 800 000 people.

severe consequences of leaked or misused data - particularly for biometrics; once that is exposed we will have no other physical security features to rely on unless you are able to alter your fingerprints and overall identity. It is very easy to find out who and what type of person someone is based on data alone, without ever having to know or meet the person

division of people and government - citizens who don’t feel safe under their government may become compelled to hide from or lie to them. A nation without trust between its government and people is no good at all

Our opponents made a good case refuting our arguments:

data does not necessarily have to be about people but can be just general traffic to help better plan infrastructure

decisions from data are not definite but used to make informed decision and are not used a solid proof

data can be used for good purposes aside from identifying criminals. e.g. finding and returning missing people to their family

preventing crime - if people feel they are being watched they may abide the law more carefully

Overall Thoughts

This case study is another case of how bias can affect our views and arguments for a cause. Because the government has something to gain from the retention of data, there arguments actively tried to inform us of the benefits that surveillance can give. 

As a mere citizen, we don’t have much benefit from this surveillance. Instead we are placed at a greater risk of being targeted because of information is being held by an authority we are unsure whether we can trust what they are using it for or how other will use it in the future since the government in power now will not always be in power. 

[z5209760-blog]

HELLO WORLB

The Morse code is decoder is working!!!

Not so lost in translation

The only thing I needed to add to the code was just the translation logic, which was a bit more confusing than you’d expect. 

Logically speaking, the idea behind it was quite simple. After reading in the Morse code you would just compare with the available letter and number encodings and check if it matches any one of them. So if we read “--.” it would match with letters[6] meaning it should be the 6th letter after ‘A’, which is ‘G’. 

The trouble was comparing the read encrypted string with letters[i] or number[i]. Arduino was an array of chars and it also has a String which you can’t compare with each other since they aren’t the same. So I spent a good amount of time trying to compare my encrypted text with letters[i] to no avail. It turns out a simple ==  or encrypted.equals() did the trick. 

The end result was something that was not too accurate because it was easy to press a button longer or shorter than you intended.

Why six dots ......?

Another problem I faced was determining when Morse code sequence for a word had finished being read. My initial plan was to use timing, where if the buttons weren’t pressed for a certain amount of time, it assumed the word had ended. This didn’t work out so well because in between characters I had to look for the encoding of the next character I was inputting which made it think every single character was the end of a word. 

My solution ended up being press “......” to indicate the end of the word. This was the best sequence I could think of that was simple and could easily be distinguished from actual encodings (since they are typically 1 to 5 symbols). I'm not to proud of it but its the best I can think of for now.

The final sections of code ended up like this:

The End?

Now that both features of encoding and decoding are functional I believe this brings me to the end of my Something Awesome. I originally intended to have one device able to do both encode and decode text, but given the amount of work I have to do this week, I think two separate source codes for the device will do. 

Overall I’m pretty happy with the result. I achieved what I wanted to do and learning Arduino has been a great experience so I can’t wait to make more projects with what I’ve learnt or even learn more things to create even more stuff. 

[z5209760-blog]

Snoop-y: Pre-Tutorial Analysis

This week we are debating about privacy. To be specific “should the government or government agencies collect and have access to your data for good purposes, or should citizens, e.g. you, have a right to privacy which stops them?”

After reading the supplied links and articles, I ended up with the conclusion no. My main reason being their are so many risks and dangers of holding information about a large number of people despite having possibly valid reasons for doing so. An example of this would be the last article which argues that the increase of “home-grown terror” calls for the necessary collection of “US citizens’ conversations with potential overseas persons of interest”. 

Now Australia has not had as many terrorist attacks as America, which causes me to have a perspective that inclined to feel the need for surveillance to detect potential terrorism. So now I’ll go into the additional factors that I think impact my decision.

No to biometrics 

One of the articles mentioned that our digital identity will eventually be integrated with biometric recognition. As we learned last week, all factors of authentication are essentially just something we know, so it’s just a secret, and secrets aren’t very well kept or secure either. 

Richard also used a great analogy last week of a computer being a person trapped inside a black box only seeing 1s and 0s coming in. Our face, fingerprints, and other features are all just converted to those 1s and 0s. The way a computer compares and checks these binary digits are completely different to how a normal person would recognise another person leaving many holes in the accuracy of biometric recognition. This brings us to our next point.

Type I and Type II Errors

To put it simply the upcoming The Capability (what an ominous sounding name) will have to handle errors such as an innocent person being identified as a suspected criminal and a criminal being identified as an innocent person.

Re-purposing Stored Data

It is very easy for something to be used for another purpose than it initially was. I think a prime example would be the US’ social security number. What was originally intended to track individuals for Social Security purposes, it has become “a de facto national identification number for taxation and other purposes”. All it took was just a few companies to say “you know what? I think that will be useful for what I want to do” and eventually many other companies followed suit. Imagine what would happen with all the information the government has stored for you. My top bet is this data would be greatly useful to the police and insurance companies

[z5209760-blog]

Lecture Reflect-ure: Week 6

Buffer Overflows

Buffer overflows are a type of memory corruption, where when writing data to a buffer, you overflow the space available in the buffer and overwrite adjacent memory locations. Through buffer overflows, you are able to change the way someone’s code works by perhaps overflowing the return address to a (possibly) function/code you have created and making the program work for you. Other behaviour can happen such as memory access errors, incorrect results and crashes.

The simplest way to avoid buffer overflows is by checking that data that is to be written in a buffer/array is within the bounds of that buffer/array. Canaries can also be used to check for changed return addresses. A canary is a small integer, randomly chosen at program start, placed in memory just before the stack return pointer. The canary value is used to check for buffer overflows because its value would be overwritten if that were the case.

Disk Encryption

Disk encryption is just converting information into unreadable code so that it can’t be accessed or read by unauthorised people. It’s a simple idea of protecting data but strangely enough not even Windows will encrypt your hard disk properly. In fact it simply just asks the hard drive “are you able to encrypt the data you have?” and it says yes it leave that job to them instead of even trying. It won’t even know for sure if the hard disk was actually encrypted.

Authentication

Many people believe authentication can be separated in to three factors:

something you know e.g. a password

something you have e.g. your phone

something you are e.g. your face, fingerprints

But once you think about it all these factors are just something you know. They are essentially a secret which is represent by 1s and 0s to a computer.

Richard used a great analogy that a computer is basically a person who is inside a black box. They are given information and have to make decisions based on this information without much understanding of the context of their outside world. This makes it hard to distinguish things that may look similar but are actually not. Humans and computers recognise things in different ways. Consider twins; they may look the same and a computer may even think they are the same person, but humans are able to identify unique characteristics which helps them differentiate the two like how they walk, talk and act.

This went a bit off track, but all authentication is essentially just data. So whoever thinks biometrics are the future are absolute FOOLS.

Block Modes

This was something Richard told us to research since we didn’t have enough time to cover it and he wanted to move on.

Block cipher modes of operation are algorithms that use a block cipher to produce a ciphertext. Since block ciphers work in units of a fixed size, messages are divided into chunks. If a chunk if not big enough to be a block, padding is used to make it big enough. This can include adding null bytes, adding a single bit followed by enough zeros bits to fill out the block and others.

Let’s go over some block modes:

EBC (Electronic Codebook) - messages are divided into blocks and each block is encrypted separately. This has the disadvantage that if two blocks are the same they will be encrypted to the same ciphertext block. This makes them susceptible to replay attacks. CBC (Cipher Block Chaining) - each block of plaintext is XORed with the previous ciphertext block, then it is encrypted. An initialisation vector is used on the first block since it has no previous block XOR with. Since the plaintext is XORed with the ciphertext of the previous block, the decryption of a block can be correct even if the previous block was not.  CTR (Counter) - works like a stream cipher. A nonce is combined with a counter to produce a counter block for encryption. The use of a nonce, prevents the likelyhood of repetition. 

[z5209760-blog]

Saving...

Recently I’ve been seeing a lot of articles on my feed about companies saving customer recordings without them knowing or even saving recordings despite being ‘deleted’ by the customer.

Now this is nothing new, but its been strangely popping up more and more recently.

In the case of Google, they’ve had their recordings sent to language reviewers so that their devices could better understand recorded languages. Audio snippets are not associated with user accounts in the review process, however its not impossible to determine who’s speaking based on what’s talked about and how they speak.

There were also cases where the keyword ‘OK Google’ was not used yet the device was recording. Although it may not be intentional and due to a fault in the software or device, it is clearly an invasion of someone’s privacy.

A similar thing applies to Amazon’s Alexa. Previously Amazon was in the spotlight to keeping recordings indefinitely, but now we also have news of recordings still being kept despite being manually deleted by customers. Like Google, Amazon states that they remove the transcript from being related to the customer yet still maintain the recording itself “to provide the Alexa service and improve customer experience”.

What’s the take away?

Always be mindful about your devices and anything you use in general. We are living in an age where technology surrounds us and it’s very easy for that technology to observe and store information about us. Everything we do leaves a trace and it very difficult to get rid of it.

In light of the ever increasing use of voice assistants, it probably won’t be to soon that we start getting legislation/laws regarding the maintenance of information by any company.

Articles:

https://threatpost.com/amazon-admits-alexa-voice-recordings-saved-indefinitely/146225/

https://threatpost.com/google-home-recordings-domestic-violence/146424/

[z5209760-blog]

Pressing Buttons

This week I didn’t quite reach my schedule plan. Instead of getting the Morse code decoder working, I just got the microcontroller reading in Morse code! I didn’t get a lot done this week since I’ve had a barrage of assignments due this week :(. But at least some progress was made on the Morse code translator.

So the new plan of attack will be to get the microcontroller being able to translate the Morse code it has read next week and instead of making the device do both encoding and decoding with a single source code, it will be two separate source codes; one for encoding (which I already have) and another for decoding (the one currently in the works).

Here a video of the microcontroller reading in my button presses:

How long did we press the button for?

There wasn’t much new things to be learnt this week, it was more focused on finding a way of getting what you want done. In this case it was for us to figure out how to distinguish between dots and dashes when the buttons were being pressed. Needless to say short presses should represent dots and longer presses should represent dashes.

There is no timer or stopwatch function in Arduino, so I had to set up multiple variables, which stored the time since the program started at multiple places. Namely, when the button was pressed and when it wasn’t. Then I would subtract the two times to get the duration of the press.

The next problem was deciding on durations which would represent which symbol. Messing around with timings and pressing the button multiple times for different amounts of times. 

It eventually ended up being:

If the button was pressed for less than 300ms it was a dot

If the button was pressed for more than 300ms but less than 900ms it was a dash

Anything longer than 900ms was considered a space between words

I’m not sure if this is the best timing plan, but it worked out decently for most presses. There were times when it would misinterpret the press but you can’t always get it right can you. :/

[z5209760-blog]

World War III: Post-Tutorial Analysis

Our task: You are Mike Burgess. Consider the main threats we face in the cyber domain of war and produce 10 recommendations for actions to be taken. Rank and justify your recommendations.

Our Recommendations:

Since we were short on time each group shared their top 3 recommendations and their worst (10th) recommendation. Here’s what our group came up with.

Remove major infrastructure from the Internet. Isolate ourselves!!

Don’t outsource our infrastructure (although we don’t have the skills or resources at the moment so it doesn’t seem likely)

Ensure that we have shared interests with out attackers. E.g the Russians have a base in our homeland and we have something in theirs. Neither of us will want to attack each other if we have something to lose.

Our tenth and worst idea was...

Control the release of information. Yes yes, it’s not very ethical and the public probably wont trust us anymore, but this was all we could think of when preventing fake news or propaganda spreading around.

:( Yeah it’s not that great.

Overall Thoughts:

I think the most common ideas from each group can be summarised as “becoming less technologically advanced/reliant on technology” or “going full Swiss”.

Our mindset followed the logic that, the less we rely on the Internet and technology overall, the less means our attacks will have of attacking us. So this would’ve included something like eliminating autonomous system so that we can fully embrace the dark age >:).

If we go full Swiss, we won’t interfere with international events and mind our own business. But considering our shortage of skills and resources, and the globalisation of Australia, there is likely no chance Australia will be come a fully independent country.

[z5209760-blog]

Buttons Up

This week I started playing around with buttons for my something awesome. I plan to use these as a way of reading in people’s Morse Code and translating them into English.

Getting Grounded

Setting the button up was more difficult than a it was for a buzzer or LED. Since it was being used to receive input, it needed a power source and a destination so I connected, one leg of the button to the 5V pin to receive power from and the other leg to one of the digital pins of my Uno (pin 2 to be specific) to receive input. But now he had a problem of what was the pin’s state whenever the button was not being pressed? We can’t tell. This is where GND (ground) comes in. 

I’ve only just realised I haven't quite gone into the specifics about the circuits in my previous blog but I think this is pretty significant so I’ll be putting a bit of effort explaining it. But be warned, I am no expert and have only been doing this for 3 weeks D:. So if there are any mistakes or inaccuracies do not be surprised.

So I believe ground is somewhat of a negative terminal on the circuit. By wiring our button to ground, it will now have a negative pin state if the button is not pressed and a positive pin state if the button is pressed. 

Here are some diagrams to help with the explanation

Once again, I have little no experience with electronics and circuits so my diagrams will probably not be correct.

Where does it go?

Now that we’ve got the button all wired up, I want a way of telling it was pressed. So whenever the button was pressed, I made the LED light up and the buzzer sound. That step was simple as it was merely adding in an if statement.

And so we have this:

That’s all I have for this week’s something awesome :)

[z5209760-blog]

Lecture Reflect-ure: Week 5

The stars of this week’s lecture was hashes, passwords and the wonderful Dr. Lisa Parker.

WEP more like WEAK

Richard went through this wireless security algorithm which was so flawed that apparently there are competitions for finding the most ridiculous ways of cracking it.

One particular way we went through was this:

An access point sends the encrypted data to the computer. Since the access point is technically streaming everywhere, anyone can see the data but they don't accept it because its not destined for them. A hacker can sniff the packets. They can figure out the key stream by XOR-ing the plaintext and ciphertext (since the position of the bits are always the same) and change the destination address to their own address. The access point will then decrypt the packet and unknowingly send the packet to the hacker.

Hashes

We delved more into hashes once again, this time into the structure of the hash.

MD5 SHA0 SHA2 and SHA2 all use the Merkle-Damgard construction which breaks messages in to n blocks. 

Merkle? Doesn’t that name sound familiar? That’s right its the guy who created Merkle Puzzles!!

Anyway continuing on..

It starts with an initial value (the initialisation vector), which is a fixed value. For each message block, the compression function f takes the result so far, combines it with the message block, and produces an intermediate result. The last lock is padded with zeros as needed and bits representing the length of the entire message are appended.

This construction is actually vulnerable to a length extension attack, where given the hash H(X) of an unknown input X, it is easy to append another message to the already hashed message, altering the overall hash. Since the hash is technically correct, although we don't know the actual original message.

Passwords

Most of what was covered I have already mentioned in the blog on the passwords seminar so have a look at that if you want.

Free Lunches 

We had a really interesting talk/interview with Dr. Parker about bias and unconscious reciprocity, particularly in the medical industry. Parker highlighted our tendency to help someone if they helped us (if you recall from social engineering: quid pro quo). Her main example being free lunches being provided by drug companies. After being provided the lunches, doctors were more inclined to prescribe drugs from that company. Is this ethically reasonable? :/ I don’t really think so. What’s even more shocking is that Dr Parker revealed that companies like those providing free lunches spend more money on marketing than they do on pharmaceutical research. 

If anything Parker’s story highlights how we often has bias in the decisions we make. These biases tend to arise from our own experiences and perspectives. I think this week’s case study was a great way of demonstrating that.

Getting Parole

Richard mentioned something interesting during the lecture that I would just like to add:

You are more likely to get parole if your judge has just had lunch.

So in other words:

before lunch = hungry = angry = less chance of parole

after lunch = not hungry = happy = higher chance of parole

[z5209760-blog]

Giggle Motors: Post-Tutorial Analysis

Task: You are the CSO of Giggle, a company with plans to develop a driver-less car. As CSO

Identify your assets

Identify risks

Address how you will deal with these risks

Give a recommendation on whether Giggle should follow through with its plan

What we came up with?

Assets:

Customer safety

Reputation

Cars

People -> civilians, engineers, tester

Investors

The car's environment

Development documentation -> car plans, schedules, research, and results

Risks/threats:

Cars

Can be hacked/remotely access

lose power mid-way of a dive

can hurting people (both bystanders and driver) + causes a chain of events: company loses car, reputation, who is at fault?

its interactions with other cars -> will they hit each other, how does the software decide what to do

All data/information plans for the cars can be stolen by competitor companies

Accidents during testing (affecting both engineers, testers and company development plans)

If an accident does occur, who is liable if an accident happens

Surrounding environment can be damaged by the car, both the testing environment and everyday surroundings

Addressing risks:

Protecting our data - secure building with multiple authentication points, security cameras, tailgate proof gate, security guards, securing the network

Protecting our staff (engineers and testers) - train staff, have them full aware of the dangers that arise from their work and the risk they are being placed in

A manual override function which forces the car to stop and require an actual driver to get the car moving if it ever get’s hacked.

Have a large controlled environment far away from society to run tests to prevent accidents in the community

Have discussions with government regarding legislation around driver-less cars to deal with liability issues

Schedule regular checks on cars to check that all components are functional 

Recommendation:

Yes, self-driving cars should be developed, we should just be prepared and have safety precautions set up.

Why?

Driver-less cars are already in the works. The question is not whether they should happen, but when they are going to happen. Since it seems inevitable that they will happen, the best we can do is set up safety precautions so that everything works out smoothly.

Extra thoughts:

It looks like we all got bamboozled. Each group was given a different role in deciding whether or not driver-less cars should be developed. We were the CSO of the company, another group was the Minister of Security and I can’t quite remember the other roles. 

Either way it was interesting to see how this case study turned out. Every group had different assets, recommendation etc. depending on their position. Since we were an employee of Giggle, we obviously considered the company’s reputation to be an asset while the government did not. Another example of the differing perspectives would be that we were more inclined to say yes to the cars since they would progress they company and we’re more focused on issues regarding the development of the car while other groups were more focused on the safety and repercussions of any accidents.

[z5209760-blog]

My Password is password

The next seminar was passwords! I would like to give kudos to the group for their live demos. Live demos never go as planned but they did a good job. I wished we had more time for the content they didn’t get to cover though :(

Passwords suck. Why?

Well, they

are hard to remember

are hard to type

need regular renewal -> hard to remember again

have complicated generation rules (Must contain a capital letter, special char, can’t have this char etc)

tend to contain personal information -> easy to crack

and there is generally little incentive to make good passwords :( 

How to store passwords?

Not in plaintext that’s for sure and definitely not with bad hash functions (ahem MD5, SHA1)

We can make hashing more secure by salting our passwords. That is adding some extra text to our passwords so that our hash changes. If another person has the same password, but have a different salt added to it, they’re hash becomes different from ours! But there’s a catch. You shouldn’t reuse salts as that would obviously make the hashes the same again and you shouldn’t make the salts too short, or they’ll be too easy to figure out.

Better password generation

correct horse battery staple (xkcd) - choose four random words and together they should form enough entropy long enough for them to be a bit more difficult to crack

passphrases - long, wacky, nonsensical phrases, which are difficult to generate because they do not follow the patterns of normal English

intialisation of a phrase - think of a long unique phrase and choose the first letter of each word

[z5209760-blog]

OPSEC

Today’s seminar was on operations security! and something else (you’ll find out soon, it should be the next blog)

OPSEC can be simply defined as identifying and protecting information about yourself which can be used against you by adversaries.

OPSEC is a five step process with a logic resembling that of threat modeling

identifying what you want to protect

analysing threats

analysisng your vulnerabilities

assessing risks

setting up appropriate measures

When to OPSEC? 

24/7! Both in the digital and physical world.

How to OPSEC?

avoid sharing information - if you don’t need to share information don’t do it. Only give out information on a need-to-know basis. Be wary of what you share; even data has data on it (metadata)

keep your identity secret - if you do share information, make sure it can’t be traced back to you. You can use TOR, VPNs, false identites. Be careful not to contaminate your identities, making it possible to link them back to each other or even you.

be forgettable - blend in with everyone and don’t stand out. If you stand out, you’ll be remembered.

An issue was also raised over the need to balance sharing too much information and sharing no information at all. Because sharing no information is a great indicator that you have something to hide, and if you have something to hide, people are more likely to wan’t to find out what you’re hiding. So you’ve got to strike a balance between the two; share information, just not too much of it. Hence share your information only on a need-to-know basis.

[z5209760-blog]

Lecture Reflect-ure: Week 4

This week we talked more on bits, smarter approaches to brute-forcing and hashing.

Bits Again?

We did more bits! Why? Because it’s important. We mainly went through some more example for calculating bits of work. Although the modules exercises are part of the lecture, I found the Bits of a Penguin one very useful. More specifically its calculating bits of security section.

Find the total number of permutations (i.e. the total number of possible passwords, keys etc.)

Find the nearest power of 2 number (1, 2, 4, 8, 16, 32, 64, …)

Convert that number into exponential for with a base of 2 (so 2 -> 21, 4->22, 8->23 etc)

Take the exponent value. That's the number of bits of security

Note: when calculating the average bits to brute force a system, it will always be one less than the total bits of security since of average it will take half the attempts to correctly guess something Alternative: Bits of Security=log_2⁡(total # of permutations)

While we’re at it let me add my answer to the Bits of Penguin exercise following the above steps

There are (7x6x2x3)-1=251 permutations. You might be thinking but there’s only 6 colours for the right foot, 5 for the left foot etc. Yes, but we need to add the case where no colours are on the limbs. So that gives us 7x6x2x3. Since we can’t have a peguin with no bands on them we subtract 1.

The nearest power of 2 number is 256

256 = 2^8

There are 8 bits of a penguin!

Brute-Forcing

We use brute force to measure the worst-case amount of effort needed to break security.

In the case of ciphers in any languages, there are a lot of redundancies, and patterns, which let us use brute force in a more intuitive approach. e.g. there is a limited number of valid 5-letter words in English, which would be significantly less that the 265 possible words we get from brute force. Because of the patterns in language, we are able to significantly reduce the amount of work we need to do. There is also the context of words, which help us deduce what words may come next in a cipher.

Hashing

This week we also covered hashing. It takes in large and possibly varying size input and maps it to a fixed size output. Let’s give a quick run down on it:

What makes a good hash?

deterministic

difficult to reverse

small changes in input make large changes in output (avalanche effect)

unlikely to have hash collisions (I prefer hash clash)

What makes a bad hash?

clustered collisions - similar inputs having same or similar hashes

non-uniform distribution - hashes getting grouped together

Our lecture example was a good example of a bad hash. It had both of the points above. Students sitting in their friendship groups, making them of similar cohort meant they had similar hashes. We also had more undergrads than postgrads and 6441 students than 6841 students making the distribution clustered.

What else do we want our hashes to have? Resistance!

Preimage resistance: given the hash of M, h(M), you can't find M

Second preimage resistance: given M, you can't find M′ such that their hash of M and M′ are the same; h(M)=h(M^′ )

Collision resistant: you can't find any two messages, M and M′ where h(M)=h(M′)

It is interesting to note that the number of items you have to look at before finding a collision is pretty small. If there are n possible hash values, then on average you will only have to look at √n  items before finding a collision. That really was the case for our students-to-playing-card hash. We had 52 possible hashes, and after looking at 7 (or 8) students we already found a collision!

[z5209760-blog]

Operation Soft Cell

Looks like hackers have stolen phone records from more than 10 cell providers world wide, so that they could target 20-30 high profile individuals. It is said that “hundreds of gigabytes of call records were harvested over a period of years”.

How the attack worked:

According to the article, the hackers got into telecom systems by exploiting vulnerabilities in Microsoft-powered web servers. Once in, they would steal or make admin accounts and move throughout the computer network. "They would exploit one machine that was publicly accessible through the internet, dump the credentials from that machine, use the credentials stolen from the first machine and repeat the whole process several times," Amit Serper

Thoughts:

It seems that the hackers took advantage of old vulnerabilities that were overlooked by the telecom companies, which let them inside the network. Once inside they easily escalated their privileges, and mere stayed within the network to gather the information they wanted. 

It’s obvious that the cell providers are not the main targets of the hackers, instead they are merely as side door they are using to help them attack they people’s whose information they are watching. If the providers were the real targets, the hackers could have easily taken down the network. Instead, they are merely keeping metadata on call-records. This would include, when they called, who they called, where they were, even the device they called from. Although this data doesn’t contain the actual contents of the call, that information is enough to build learn about an individual’s habits and routines.

What can we do?

Honestly nothing much, unless you want to stop using your phone altogether. The attack was done towards mobile service provides and it was their security that was flawed to allow hackers in. Even if they do patch up any vulnerabilites they have, they hackers may still be able to access their networks (since they did make fake admin accounts). The providers will have to weed those fake account out as well if they want them gone for good.

Sources:

https://www.tomsguide.com/us/global-telecom-hack,news-30439.html

https://www.theverge.com/2019/6/25/18744020/operation-softcell-hack-call-detail-records-apt10-cybersecurity-cell-network-providers