hash-include-sec-blog

[hash-include-sec-blog]

Week 8 Recap

This week focused on error, specifically human error.

All cyber issues are due to human error.

Analysis of the Root Cause

We blame the last person in contact with the system

Eg an airline company blaming the last engineer to sign off

Culture

Organisations like to place the blame on someone

Difficult to change

Easy to throw money at for the appearance of something being done - saves face but does not fix the root cause.

The system itself - likely too complex and something going wrong was inevitable

Human Weaknesses 

Honesty

Humans lie, usually to protect ourselves or someone we love

We even lie to ourselves about our own honestly

We always like to believe that we are good people, but even white lies and omission of information are still forms of lying, ones we might not actively think about when we (don’ t) say them.

Misdirection and limited focus

Chekhov's gun

People are bad at picking the right features to focus on (going back to identifying assets to protect from a few weeks back)

Logically important vs psychologically salient

People should focus on what is logically important

People usually focus on what is evident

Similarity matching

When people look for similar situations from their past and apply them to the current situation.

Kind of like with risk analysis and learning not to do something from past negative experience.

Frequency gambling

If many patterns (situations) match, we tend to choose the one which we have the most experience with

eg if gravity works 100 times, surely it will work the 101st time

Basically the idea that “if it worked before it should work again”

Not guaranteed to be the best solution, especially in security

Satisficing and bounded rationality

Satisficing: doing good enough, rather than doing perfect

Bounded rationality: since we have a limited amount of information, our ability to make decisions is bounded by that information

People prefer positive statements

We ignore what we don’t like - see no evil, hear no evil, speak no evil

Also known as ignorance is bliss?

I strongly disagree with this approach, because then you live in your own delusional rose-tinted world without becoming aware of a) the suffering of others, b) your own privilege and c) how you can work to make the world a better place in your own way.

Humanity is all about teamwork, yo.

People convince themselves that they are right even when the evidence doesn’t exactly line up.

Group-think syndrome

How people think when they’re in groups rather than as individuals

A kind of example of this is the bystander effect, or how we tend to mimic the behaviour of people in our environment to fit in

We prefer to keep the peace in a group rather than fight against collective ideas

Result: groups become homogeneous

E.g someone makes a joke in a group and everyone laughs even if it isn’t funny

Confirmation bias

We prefer the evidence that confirms what we believe

An example of cognitive bias; describes that people gather and recall information selectively/interpret in a selective manner

Accidents vs Attacks

The intent makes the main difference.

Error

Error Proofing Systems

Luck does not cut it when building systems - be purposeful

Always assume that the person using the system is going to do whatever they can to attack it.

Always assume that the environment of a system will be the worst-case scenario

Don’t just punish the person who made an error - It’s about learning from the mistakes and not repeating them in future

Basic OOP design

Complexity is bad

Low coupling

High cohesion

Systems that follow these rules are easier to maintain and are more resilient to attacks.

[hash-include-sec-blog]

Trump Phishing

Hi Donald,

Someone just used your password to try to sign in to your account. Google blocked them, but you should check what happened.

CHECK ACTIVITY

[hash-include-sec-blog]

Hackers vs 7.5TB of Russian Data

SyTech, a Russian contractor working for the Russian FSB (their version of NASA, also known as the incorrect FSB I referenced in my fsb ctf blog post) recently suffered a massive data breach by hackers. 7.5TB of data was stolen, including various sensitive spy projects, most notably “ Nautilus-S”, a program designed the deanonymise Tor traffic. This information was sent to BBC Russia and is now in the public domain. 

This was the hackers’ parting gift:

The article does not specify how the breach occurred, as SyTech has allegedly taken their website down and is ignoring media enquiries. However, it just goes to show that no one is above being hacked.

Although this story is based in Russia, it makes me wonder if NASA or other country equivalents are also working on similar projects, but have just yet to be hacked and exposed?

[hash-include-sec-blog]

Case Study: Snoop

Also known as the Great Privacy Debate.

Honestly I got a little overwhelmed looking at my notes from the tute but here are what I thought to be the main points of argument from both sides. (What I do know is that I was most definitely triggered by my debating days 😔)

MOOT: The government or government agencies collect and have access to your data for good purposes.

AFFIRMATIVE:

Trust the government

We need a higher authority to regulate us

More surveillance = less crime

The more information the government has, the more informed their decisions that can best benefit the citizens

Eg health records, future investments, etc

Can be audited

As technology improves, so do the tactics of malicious people who want to access your data. Since normal people won’t be able to defend against that, we would want the government + professionals to do it for us instead.

NEGATIVE:

Can’t trust the government

Giving them too much power - who is watching the watchers?

Even if the current government is benevolent, the next government could be bad.

Privacy is connected with social standing - if the government knows everything, your record will be permanently tainted by past actions

May restrict your access to certain services, similar to that one Black Mirror episode and what’s happening in China currently

Privacy is a basic human right

We lack the resources to protect our data - everything is hackable

[hash-include-sec-blog]

Week 7 Recap

There was a lot covered in this week’s lecture so I’ll try to give a TL;DR (with pictures! Because I looked through my blog the other day and god did my eyes bleed from the pages of text 😩).

--------------------

The only way to authenticate someone is with a shared secret – but how can we establish a secret that no one else knows?

Diffie Hellman Key Exchange

Exploits the discrete log problem

Steps:

Over public communication, share a base number

Raise that base number to an unknown power (each person has their own power that they do not share with anyone)

Take base raised by secret number and raise it again with your own secret number.

The resulting number is supposed to be the same – that is the secret key.

Public has seen Ab and Ac but has not seen Abc– and they can’t work it out.

Vulnerabilities

Vulnerability = weakness

Exploit = taking advantage of vulnerabilities

Software bug = sometimes vulnerable, sometimes not

Common Bugs

Memory corruption

Buffer overflow – occurs in stack

Integer overflow

If the user has control over an integer in memory, the integer is stored with a fixed amount of space. If you keep adding to that integer, eventually it will overflow and flips around to different values (signed/unsigned, large/small)

eg if there is a counter for a password, you can use a longer password than counter and then counter will mess up, might pass some tests etc

Bugs related to the stack and heap

Bugs related to how functions are called in C

Format string

printf – it expects a number of arguments passed into it. First is a format string – if this string is not a code specific, it would just print the string

Eg instead of printf(“%s\n”, “hello world”), lazy programmers wrote printf(“hello world”)

Eg printf(“Richard%s”)

C will see %s and think it has to print the next string variable but there is none, so it will print the next string in the stack.

If %x was entered, it will print out the next byte in the stack

Someone can just %x a whole bunch and print out the whole stack – information gathering attack

In this way, you can also write to memory – what and where you write is essentially under your control (using %n)

Swiss cheese analogy: If you hold up slices of cheese, theoretically each hole is covered by the layer of cheese underneath. But every now and then the holes in the slices line up – like bugs in your code.

Shell Code

If you're attacking a system, the easiest thing is to use a terminal – back in the day, “popping the shell” was the easiest and most ideal way to hack

When you're doing a memory corruption attack, the goal is to get the system to run your code - use shell code to do this

But even if u get your code into the stack, you won't know where it is (hence information gathering attack) – best to target areas with memory leaks

Nop Sled

There’s an operation that tells the OS not to do anything – attackers would just put a few “do nothings” in a row before their actual code so they don’t have to know where their code is in the stack. As long as instruction pointer landed on one do nothing, the rest acted as a runway to your code. This is called a nop sled.

Responsible Disclosure

Still debated as to what it actually means/what the procedure is but the general idea is to let the person in charge of the vulnerability that you find know so that they have time to take care of it. If they don’t, then you slowly escalate the situation, but the idea is you don’t blurt it out for the bad guys to know.

Security Engineering – Assets

Security is here to protect assets

Sometimes we protect the wrong assets

You can’t protect everything

Strategies for Identifying the Assets

Ask people

Everyone has different priorities/POVs

Ask as many people as possible, in different positions etc

Do this regularly to keep evaluation current

Use standards in place but don’t take it as gospel – that once you do it you’re completely done (but don’t ignore them either)

There’s going to be something (probably more than one) you don’t see (blindspot) – this is a weakness

Act of looking at assets = act of humbleness

Valuing Assets

Tangible assets

Intangible assets

Just because an asset is hard to defend, does not mean do not defend it. So long as it's important!

[hash-include-sec-blog]

Google: Auto-delete mobile location history and activity data

One of the issues with privacy that most people don’t seem to be aware of is the metadata that is collected by your phone and browser, specifically location history and activity data. This could give a potential hacker (or just, people on the internet who know where to dig) more than enough information as a starting point to look into your browsing habits, daily routine, etc.

Google has recently given some power back to the people’s hands, wherein they allow users to be able to set timers to delete this information automatically. More information in this article.

[hash-include-sec-blog]

Case Study: Safer

Possible Cyberwarfare Tactics (Tutorial prep):

Power grid

Affects hospitals, traffic lights, communications, etc

Malware in government computers (files, information)/air traffic control

DDOS/Man in the middle/messing with election voting or census results

Military (in general, like obtain information/give false information)

Hacking media/tv - Like reverse propaganda? IDK what this would be called lmao

Interestingly, the only defence against propaganda is propaganda (ideology)

Nuclear facilities/missile launch

Phishing emails of high ranking officials

Recommendations for actions to be taken:

Decentralising the power grid from the internet

Fragile in Australia - there are only 2 power plants (Sydney, Newcastle)

(Pls read the above bullet with caution, I typed that in my notes during the tute but I can’t remember if that’s what I rly mean and I can’t find anything to verify so,,,,)

Invest in renewable energy - can be used as a fail-safe instead of grid power.

Higher encryption on government drives????? Protect government confidential information

Backup communication channels

Early warning systems for attacks (this was mentioned briefly, we did no really discuss how to implement this because early detection of anything cyber can be very difficult)

Upgrade Satellite defence systems (not, like, weapons, but the code)

Apparently, it’s not that hard to hack satellites because who would think to do so, right? But everything is fair game when you think about a cyberattack from one government to another

Educating people

If they are more aware, they are less susceptible to attacks

Honourable mention: DeVeLoP a NuClEaR pRoGrAm

[hash-include-sec-blog]

Week 6 Recap

Richard was sick this week I hope we gets well soon :(

Points of Interest from this week:

Modern Symmetric Ciphers

DES

NASA fiddled with a submitted Standard, causing alarm (lmao) which prompted academic interest in cryptography for the first time which I find hilarious but also v interesting

Quickly found to be broke as heck but it was years before the next gen of encryption standard came around

AES

There is an ongoing competition to make a gen 3 standard (for 20 years now!)

Buffer Overflow

Can exploit the nature of the stack by overflowing a buffer to write into the previous stack element

Can be used to alter return addresses, values of variables, etc

The fact that we feel comfy/confident until we discover a bug when in fast that bug had existed long before we knew about it - when we discover something new, we talk about it as if it hasn’t already existed all this time.

Authentication

Million dollar challenge: how can a computer authenticate someone’s identity?

The computer is akin to sitting in an isolated room and only being given a few pieces of data from the outside world

Someone’s identity is tied closely to how they look (no 2 people look the same) but although humans are very good at recognising faces, computers are not.

If you can’t authenticate, there is no point for the rest of our protocols

No point for voting systems, for example, if anyone can turn up and vote without prior authentication

How do we solve the problem? Defense in depth

Something you know

Something you have

Something you are

(mentioned previously in Houdini case study yayeet)

[hash-include-sec-blog]

Seminar: OpSec

This week was my group’s week to present a seminar on Operational Security. Overall I think it went well - we were well prepared and everyone was clear on their roles/responsibilities.

I hope people learnt a thing or two about OpSec, or at the very least laughed at some of our jokes. 

The only thing I would not recommend is having your Kahoot be bot hacked by 300 richards 🙄

[hash-include-sec-blog]

Homework: Drop the Bomb

The podcast: https://www.thisamericanlife.org/634/human-error-in-volatile-situations/act-one-1

For the United States government in the podcast above, what were the most important assets that required protecting?

The people

The missile (only because if denotated, would wreak mass destruction).

The Secret (of the existence of nuclear warheads)

State your reasoning and recommended approach for ensuring that the asset is adequately protected.

The People

In a situation with nuclear weapons, the safest place for people to take cover would be bunkers specifically built to withstand such a blast. In the podcast, it was mentioned that such a bunker existed however at the time of the blast, the integrity of the surrounding structure was not able to fully withstand an explosion, but this could be due to the age and thus, the wear and tear of the building. In other words, one recommendation would be to make sure that the materials used in building such a base has been tested and is more likely to hold rather than to collapse. 

It was also mentioned that the order from the higher chain of command was to evacuate, even though the crew on the ground disagreed. The fact that higher command had power to even deliberate what to do in such a situation and make a choice (which took several hours) means that the protocols in place are not clear enough to advise on what to do in such a situation. Thus, another recommendation would be to be more explicit in terms of emergency and evacuation procedures so that action can be taken quicker.

The Missile

Similar to above, the warhead in question was built in the 60s, which technology available at the time. This is fine, if not for the fact that it does not seem that the equipment was ever updated or maintained (e.g. the rubber band around the missile that had loosened to allow the socket to fall in the gap). The same goes for the tools the missile team have available to them e.g. platforms.

The Secret

Honestly one of the few things the military ever gets right is their secrets so idk what else I could recommend ¯\_(ツ)_/¯

The only action that would need to be taken would be in the face of disaster (like the one we are currently talking about) wherein the secret is no longer a secret. Then it just becomes a question of cover-up (that I don’t condone) and pointing fingers (which someone will always be unhappy about, regardless of the result, but it’s not like the military are very good at admitting their own faults either, so we might just be wasting our breath).

[hash-include-sec-blog]

Case Study: Assets

Context: You are to advise the CEO/some important people (I’m writing this the weekend after my tute I can’t remember the details sorry) in giant tech company Giggle on whether or not to pursue the project on self-driving cars.

Assets of the company

Reputation/trust

A big company like Giggle has billions of users that choose to use its services rather than those of its competitors. When an accident occurs (especially involving human life) it won’t reflect well.

Time/Money

Need to make sure this project is worth investing in, but also needs to be done well

IP

If the project goes through, need to make sure information and backend is securely protected so that people cannot tamper/easily build malware/steal information

I cringe at how shallow these assets sounds, but I guess it just be like that sometimes for corporations.

Top 3 Risks

Code failure

Machines can have bugs/errors, and are too methodical. 

Cannot trust them to account for quickly changing environment on the road/unmarked road work/detours on the map, someone running across the street, etc. 

Also software crashes are a thing.

Can be hacked

Any machine can be hacked and used for malicious intent, especially if these machines are running with the same code. Hack one, hack them all - a terrible opening for terrorist or criminal activity.

Death and/or destruction of property

Can result of the above 2 points

Reason why this is bad speaks for itself

How to address each risk

Cars cannot be completely driverless. Can consider it to be 90% autopilot but still needs a human to “supervise” just in case.

Can have a manual override for passengers in the car itself in case someone tries to remotely control the car or car veers off course

Emergency stop/eject procedures

Safety standards/standards within the code so that there is a minimum bar of safety that all self-driving cars meet

Alter road infrastructure for better conditions suited for self-driving cars

Engineer the car so that the risk of machine error is less than human error

Specialised education for writing code for self-driving cars

Recommendation to proceed and brief reason

Personal recommendation: Yes - although not recommended to fully automate everything, it can make travel more convenient in the long term. 

Team recommendation: No, with all the risks not currently feasible. Either all cars have to be automated or all with drivers but not both.

Conclusion

It turns out different groups in the tutorial were given different questions - some groups were placed as the Minister of Security discussing legislation. This explains the confusion as to why some were more focused on citizens and others were more focused on company brand lol - It just shows that discussions over similar issues comes back to bias and POV.

In general, self-driving cars are statistically proven to be safer than normal cars - some would say that it is “actively evil” to not put them out there right now because you’re essentially killing people. Ethical issues like trolley problem might be over-diagnosing the problem

Interesting question: in case of death/accident with self-driving cars, who is at fault?

[hash-include-sec-blog]

Week 5 Recap

Don’t roll your own

Don’t try to make your own cryptographic function

WEP

Some people still use it which is Worrying

Captain Crunch

Phones back in the day mixed data and control. Users should have access to data but not control

Phone tones were exploited used the whistle that came with Captain Crunch cereal

(More) Hashes

MD5, SHA0, SHA1 broken

SHA2, SHA3 unbroken

Merkle-damgard construction

Builds collision-resistant cryptographic functions

How it works:

Break up message into blocks

Start with initialisation vector (IV)

Use hash function with IV and block one, then use output with block 2, block 3, ..., block n 

Once finished, that is final hash

Also that one puzzle at the end of the lecture notes

EDIT: This is me from the future to say I never figured out what the code says and I am Annoyed

Guest Lecturer: Dr Lisa Parker

Main topic: Unconcious bias

When wanting to affect change, attack the weakest link - target the one with the power of influence/decision (the root) making rather than spending effort/time/resources on the branches of the proverbial tree

In security, this might mean bribing someone for the needed password instead of cracking a hash function to obtain it

Changing culture/mindset is a key part in bringing change rather than implementing more rules

It is about modelling its affects rather than just talking about them

[hash-include-sec-blog]

Blogging for Weeks 4 & 5

Just a note to say that I will not be able to blog much for this week and the next due to midterms (I have 3 in week 5 and another 2 in week 6 (yes I’m aware that adds up to more than 3 midterms for 3 courses but it’s kind of a long story) + an assignment).

I will try to make up for it at a later date!

[hash-include-sec-blog]

Case Study: Secret

This week’s case study was based on developing the physical security of a Google Office which would house a top-secret project. Please note that this was carried out in exam conditions and I arrived LATE so this is more of a brain dump but

The main things that I determined would need to be protected:

Entryways (including parking, specifics floors and rooms of the facility, etc)

Employee identities

The Project

Information

There might be a single point of failure depending on how the information is stored

Key features of my security design:

(2 factor) Biometric authentication + employee RFID card

Harder to falsify than a written password

Restricted access to different parts of the building

Keep information on a need to know basis based on security clearance of employees.

Less sources wherein a leak could occur

Back up servers in remote location

If attackers get on site and compromise the data, all is not lost

Mitigates single point of failure

Since the case study was completed in 20 minutes under exam conditions, we then gathered into groups to provide feedback on each other’s thoughts. It was here that we were able to discuss/further explain our reasoning, as well as the clarity in which we conveyed our ideas with the time that we had. 

My feedback mostly consisted of suggestions to elaborate on my points in terms of justification and specific implementation. Overall I was awarded a B-.

Similarly I graded what my peers had written and gave them feedback. I tried to approach it from a holistic view so that they can apply my suggestions in other case studies as well, but inevitably we dissolved into discussions about this week’s scenario in particular.

Other ideas from the tutorial group included an underground bunker that housed the project (and the rest of the building above ground would operate as normal) and keeping the building itself inconspicuous to not draw attention to it from the beginning (including not labelling it as a Google property).

[hash-include-sec-blog]

Week 4 Recap

This week we started learning about hashing and different hashing attacks.

First, hashing is not encryption. Encryption can do both ways (eg can encrypt and decrypt something to return to original text) but hashes only go one way - once you hash something, you cannot de-hash it since some information is lost from the original file.

There are 3 types of hash attacks:

Pre Image Attack

Given a hash, find the original word/file/thing

Second Pre Image

Given a word, find another word that has the same hash

Collision Attack

Find any 2 things that have the same hash

[hash-include-sec-blog]

Case Study: Doors

 This week’s case study was an example of type I/type II errors - we couldn’t improve security in one area without worsening it in another area.

There were a few issues with the current design, namely:

Too much power in the cockpit

People in the cockpit had the ability to override door opening/locking/closing procedures, which meant that if an adversary was inside, there was little the people outside could do.

Negligence

(Position of) Perpetrators

Different issues arose depending on if the perpetrators were inside (see first bullet point) or outside the cockpit (let’s just say even an axe wouldn’t help you break-in).

Some solutions discussed by the tutorial group:

Control of the cockpit door should be given to a third party who is not on the plane so that they can perform a manual override in case of emergency.

This led to problems with authentication for the third party when determining whether or not to take action.

Also signal jamming is a thing

Having the plan be remotely controlled completely, to remove any need for pilots and doors at all lmao

Problem was that unexpected circumstances with weather/turbulence/winds can occur without notice, which is hard to program for from a technical standpoint. Would still probably need human intervention.

Have 2 people in the cockpit at all times so that there is no single point of failure. In a lot of the readings, a rouge pilot took control of the plane whilst the other pilot was out of the cockpit (for whatever reason). If there was another person there (who doesn’t necessarily need to know how to fly the plane, just how to control the door), this mitigates the risk of locking out the other pilot/allowing the rouge pilot to take full control of the plane.

What if both people in the cockpit are corrupt? Discussed possibility of “overriding the override” where once a stewardess from the outside uses the keypad to ask for access (and is overridden by the people inside the cockpit), then another stewardess can override that override to prevent the pilots from locking themselves inside.

Stricter regulations on door testing (sometimes the door jams which is Inconvenient)

Have a hidden pilot on the plane that no one knows about, who has different access codes to the cockpit

[hash-include-sec-blog]

How to Steal a Penguin

I apologise to the hypothetical penguin I would steal, but I would most likely bind its beak so that it couldn't squawk loudly in distress (or maybe tranquillizing it would be more humane) and then carry it out in a chilly bin. It wouldn’t be too far-fetched for someone to walk out and around near the penguin enclosure with something ice related, right?

Alternatively: