secdino

[secdino]

Wk 9 Lecture: Main Points

Just Culture

In contrast to last week’s blame-game in the ‘Root Cause Analysis’ section, this week’s ‘Just Culture’ follows the idea that instead of blaming one individual as an approximate cause of a problem, the whole system is analysed and discussion is held to find what changes need to be introduced.

Simply put, this culture is an application of ‘don’t shoot the messenger’, as no one wants to be the focus of bad news. With a ‘Just Culture’, people who discover problems are more likely to come forward earlier (as they don’t need to be concerned with being blamed), and issues can be addressed in a more timely manner. E.g. Qantas adopted a ‘Just Culture’ and there was a correlation with a 50% reduction in aviation incidents.

Security Engineering (A Review of Sorts)

In the first week, we were asked “what does it mean to be secure in an engineering sense”, or in other words, “what is security engineering?”. At the drawing of the course to a close, we’ve experienced enough to answer it somewhat. To summarise the main roles and considerations when being a security engineer:

Learn from the Past - learn what went wrong from reflecting on past failures, as well as the failures of others.

Following Methodologies - checklists are a baseline to satisfy, but we use ‘Best Practice’, so whenever someone has a good idea, everyone can contribute and build upon it.

Redundancy and Testing - we constantly test things to make sure things don’t go wrong, and aim to break things so we can keep the logs and adapt from the results.

Pride in Work - despite pressure to meet time-sensitive demands, good engineers will stand their ground to produce a good quality product.

Focus on Process - understand the process rather than the product being made.

Review - constantly reviewing our tests and processes, as well as having a second pair of eyes provides other perspectives so less likely to miss the same things we do (reviewing it ourselves may result in missing the same things).

Professionalism - duty to profession > duty to position.

Conflicts of Interest - plan for them and address them by having systems in place to deal with such situations.

In order for us to “close the loop”, we need to apply changes to systems which simply ‘feed forward’ without collecting feedback. One of the most important concepts is to check that we are actually correct. After all we don’t want wishful thinking, but wise thinking.

System Properties

This section could be likened to a mix of assorted system property or design features which are somewhat relevant to a shared topic.

When an individual makes a mistake and the system fails as a result, it’s not the fault of the individual, but the system for allowing the mistake to occur and have such consequences.

Coherence is when everything related comes together and does the right thing for their part.

Coupling is not desired as it increases complexity and a change in one component will have a ripple effect through other components.

Humans need to remain ‘in the loop’ as ASDs (automated system designs) don’t always work. They have their own vulnerabilities as humans designed those systems.

We need to understand both systems and humans. Society itself is one large system.

Security is end-to-end, we need to secure the system all the way, not just in the middle.

Security is built on trust, yet there is no such thing as a trusted third party, so we set up systems such that if they do fail, there is a minimal impact.

Reversing and Cracking (seminar)

Reverse engineering (reversing) involves taking an executable program and analysing its ‘insides’ to understand how it is made/how it works. Static reversing is performed by looking through the code (usually assembly code), whilst dynamic reversing requires walking through the program during runtime (e.g. GDB is useful for this) and is mostly used for obfuscated programs.

The main procedure for reversing is:

Run the program first (unless it’s malware).

Put the program into a disassembler (e.g. BinaryNinja).

Look at what the program is actually doing.

Find an exploit.

Possibly profit from such exploit.

Tips:

Look at the big picture, avoid being caught up in details.

Use tools which let you modify/patch the code to test ideas.

Run beforehand where possible and work your way up.

Focus on areas of interest only.

Cracking, or patching, is an illegal (unless validated permission) step after reversing which involves changing the binary to make the software perform actions which we desire (such as removing password authentication).

In order to prevent reversing, there are two main options:

Don’t release the Debug Build

Remove the symbol table from the binary (using gcc -s [prog_name].c)

Dump symbols

Disable assert statments (using gcc -DNDEBUG [prog_name].c)

Trick the Disassembler

Make the program as convoluted as possible

Provide dummy and/or overlapping instructions

Have self-modifying code (e.g. Runtime encryption)

Embedded instructions i.e. jump halfway into an add instruction (to hide return call)

Reflection

This was the final week we had Prof. Buckland as lecturer for this course. As such it seemed the content this week appeared to bring everything full circle, by revisiting what it meant to be a security engineer from week 1, as well as providing us all with tips and advice for a future in this field.

Learning about ‘just culture’ provided a fresh new perspective on the root cause analysis from last week’s lectures, while system properties felt like a review on a variety of lessons throughout the term. The nighttime seminar on reversing and cracking reminded me greatly of my ‘Something Awesome’ CTFs, and it would’ve been a great help to have had knowledge from this seminar before that project. Only one more week of lectures to go!!

[secdino]

Wk 9 Tutorial: Final Exam Past Paper

As with most tutorials so far, we discussed the case study in small groups before sharing ideas with the class at the start of the lesson - latecomers just join the smallest group. For more detail on the case study please refer to Wk 9 Case Study: Preventing School Shootings.

After that was out of the way, it was time to start revising content for the upcoming final exam. In order to get a feel of the exam format, Andrew decided to go through the 2016 Final Paper with us as a class. Skipping questions containing not-yet-covered content or that were too difficult to go through in the time remaining, we reviewed bits of security, ECB block ciphers, replay attacks, and even transposition ciphers. Hopefully there will be time for more next week!! :D

[secdino]

Wk 9 Case Study: Preventing School Shootings

Context:

America has always had a problem with the number of school shootings occurring on a regular basis. As usual, most deaths resulting from these are preventable. Today’s case study was to discuss possible methods of prevention, and list the best 5 recommendations in order.

Group Discussion:

Our recommendations were ranked based on the most likely impact in reducing lives, followed by any positive impacts on the wider community.

Gun Control Regulation

Make it harder in general to obtain gun licenses.

Mandatory background checks for all potential buyers.

Crackdown on illegal arms trade.

Raise the age requirement to 25 or so (average age for human brain to mature, above age of most school/university students).

Banning high-capacity magazines and assault weapons

If shooters can’t ‘pray and spray’, hopefully less motivated to go on shooting rampages.

If a mass shooting event were to occur, assailants can kill less people in a given time.

More in-depth monitoring of social media with a focus on possible signs of pre-meditation or extremism

Educating the general public about gun violence, raise awareness about mental health

Free anonymous mental health counselling at school/readily accessible.

Make sure everyone understands the impacts of gun violence.

Gun owners (such as parents) secure their own firearms such that children don’t get their hands on them.

Boost school security in general

Metal detectors for all students and staff at every school.

Will cost money but effective in preventing guns from entering the school.

On-site security (security guard) as a first responder and to deter attacks.

Class Threat Modelling (Brief):

Assets

People

Life in general

Threats

People coming into school with a gun and the intent to shoot in order to cause harm.

Why do these Threats Exist?

Poor gun control

‘The Constitution’

Gun ownership culture

Political aspects e.g. NRA lobbying (deters gun control)

Easy access to firearms in general

Greater wealth disparity (compared to other first world nations)

Hunting culture

Cultural divisions, racism, etc.

Class Discussion:

Instead of going through every group’s recommendations as usual, we instead compiled a ‘class list’ by discussing recommendations from each.

Increased regulations for Gun Purchase

Mandatory background checks

Renewed checking every few years

Valid reasons needed for buying e.g. ‘protection’ is not valid

Limit who can Sell Guns

Gradual culture change, it shouldn’t be seen as an everyday item

Awareness Campaigns

Mental Health

Victims sharing their experiences

Firearm safe usage

Emotional Health Services

Limit ammunition per person

Make ammunition more expensive in general

Security at Schools (not as practical as some of the other suggestions)

Check for ID

A guard at every school equipped with full SWAT protection gear

Armed with a non-lethal weapon

Reflection:

While the topic for this week doesn’t seem quite related to security engineering directly, it still required threat modelling and discussion to formulate recommendations to patch vulnerabilities in a system. It was also quite important in that this is a currently active and growing issue which multiple governments have failed to remediate in the past.

Many of the proposed recommendations were able to address major components of the existing problem, however we were unable to come up with a solution to the political and cultural aspects. Although we can do our best through legislation, culture and beliefs are something which can’t simply be change by a few rules, rather, it will require years of understanding and a willingness from the community to adopt a more progressive perspective on this issue.

[secdino]

Index Page: Lectures

To save you the time you might waste clicking through similar posts or sifting through the archive, below is a compiled, ordered list of links to the weekly lecture summaries and reflections.

Please click on a link below to read about the relevant week’s content:

Week 1 Lectures

Week 2 Lectures

Week 3 Lectures

Week 4 Lectures

Week 5 Lectures

Week 6 Lectures

Week 7 Lectures

Week 8 Lectures

Week 9 Lectures

Week 10 Lectures coming soon...

See also: 

Index Page: Case Studies & Tutorials

Job Application Main Menu (OpenLearning)

[secdino]

Index Page: Case Studies & Tutorials

To save you the time you might waste clicking through similar posts or sifting through the archive, below is a compiled, ordered list of links to the weekly case study analyses, and tutorial summaries.

Note: Some weeks have the case study and tutorial merged into one post if the tutorial content wasn’t enough to warrant a post of its own.

Please click on a link below to read about the relevant week’s content:

Week 1 Tutorial & Case Study: Deepwater Horizon

Week 2 Case Study: Houdini vs The Medium “Margery”

Week 2 Tutorial: Houdini Code

Week 3 Case Study: Doors

Week 3 Tutorial: Cockpit Secured

Week 4 Case Study: Google’s Physical Security

Week 4 Tutorial: Revision

Week 5 Case Study: Self-Driving Electric Vehicles

Week 5 Tutorial: Midsem Prep

Week 6 Case Study: International Cyber Warfare

Week 6 Tutorial: Reverse Engineering

Week 7 Case Study: Snoop

Week 7 Tutorial: Buffer Overflows

Week 8 Tutorial & Case Study: Stargate Ghost

Week 9 Case Study: Preventing School Shootings

Week 9 Tutorial: Final Exam Past Paper

Week 10 content coming soon...

See also: 

Index Page: Lectures

Job Application Main Menu (OpenLearning)

[secdino]

Wk 8 Lecture: Main Points

Root Cause

When something bad happens we perform a root cause analysis to identify the source of a fault or problem. As humans, we like to place blame on one cause only, being ignorant to the presence of multiple factors. The most common root causes people like to ‘identify’ are:

Human/Operator Error - it’s easy to blame the last person to interact with the system as the ‘problem’ can simply be removed by firing them.

Culture - there’s no real way to fix culture and as a result there’s no direct consequences either.

System - blaming an external factor (the creators of the system) can redirect scrutiny away from the true cause of the problem. Complex systems are difficult for others to understand.

Human Weaknesses

If we didn’t know enough human weaknesses before, here’s more!

Honesty - humans can’t possibly be honest all the time, we’ll often lie without knowing it. When we create a lie and follow through with it, we often end up believing that lie to be the truth.

Misdirection and Limited Focus - our inability to focus on multiple things at once makes us highly susceptible to misdirection, so we end up looking at the wrong things.

Logically Important vs Psychologically Salient - in a nutshell, what we should be looking at vs what seems to be most interesting. This weakness is exploited by magicians and social engineers (and more).

Similarity Matching - if people feel whatever is currently happening to them has happened before, they are very likely to react in a same or similar way (predictable behaviour is easy to exploit). 

Frequency Gambling - if there are any recurring patterns detected, people will most likely respond in the way that has worked most in the past. Just because something worked in the past does NOT mean it will work in a current situation.

Satisficing - only doing the bare minimum or to meet the lower bound of expectations leaves much room for error.

Bounded Rationality - having a limited amount of information sets a boundary on our ability to make decisions based on that information.

Confirmation Bias - humans will tend to focus only on evidence which supports their views or claims (blindsiding to other perspectives).

Group-Think Syndrome - people will likely behave differently when they’re an individual as opposed to when they’re part of a group. One is less likely to speak against the majority in a group if they value their membership in it.

Systems

Often there can be many issues with an existing system we are not aware of. Most of these problems arise from the system’s design. There are some key things to keep in mind when designing a system:

Assume the system’s environment will be the worst case scenario, and whoever is using it will be trying their best to attack it.

Reduce complexity such that no one component is too complex or too empty.

Have a good level of cohesion such that components close to one another can make use of one another and those far apart do not.

Minimise coupling such that a change to one component doesn’t require changing other things - same goes for failures.

Note: Also don’t retain data which is no longer necessary - large data collections incentivise attackers!

The above all together create a system with defence in depth. Even good systems will fail at one point or another but so long as the one failure doesn’t bring down the entire system, the system itself is not broken (yet).

Privacy (seminar)

There are a variety of definitions for privacy but the presenting group chose to define it as ‘the right to be free from undue surveillance’. Since our privacy is often always under attack, some ways to try and maintain our privacy:

Incognito Browsing - doesn’t store browser history, forms or cookies, but doesn’t do anything effective in any other way.

When sending requests to websites, any data sent with the request is not private.

ISPs can still see data used on their networks and owners of shared networks have similar permissions.

Change Browser - Some such as DuckDuckGo don’t store IP addresses and other data.

More Cautious Behaviour - user behaviour is often one of the greatest risks to their own privacy.

Don’t stay logged in to accounts we don’t need to be.

Don’t link accounts to other accounts (such as Spotify to FB), as data aggregation is the main threat, not individual pieces of data.

Just Lie - there’s no harmful consequences and (theoretically) no one will know.

Set up a VPN - virtual private networks hide your IP so requests and connections are made from the VPN.

ISPs only see users request a connection to the VPN but not what the VPN is actually requesting.

Requires trust in the VPN - what makes one safer than another?

E.g. nordvpn, openvpn, expressvpn.

Onion Routing - redireting requests through a series of intermediate nodes with a layer of encryption at each node.

Only the client (you) know the symmetric key for every layer.

Client sends an n-layered encrypted request and one layer is decrypted at each node using their own key but it is still encrypted up until the exit node which receives the fully decrypted request. Vice versa when returning results.

Fails when doing something like logging into FB as FB still knows our email and password.

Digital Forensics (seminar)

This is the branch of forensics science involving the recovery or investigation of material found on digital devices. The main stages of recovering material are:

Imaging - capture an ‘image’ of the drive, chain of custody (protecting forensic evidence from being changed while it’s being transferred), hashing.

Analysis - keyword searches, recover deleted files, specialist tools used.

Reporting - evidence used to construct events/actions and report written.

Some tools frequently used in digital forensics include: Encase, Autopsy, FTK Imager, file, strings, xxd, Foremost, Binwalk, mmls.

Reflection

The rest of the second lecture after the seminars was filled with Prof. Buckland reading out an excerpt from a book about the Three Mile Island Accident, illustrating the recount with a diagram of the nuclear power plant on the screen. Having watched the HBO Chernobyl miniseries, I couldn’t help but notice some similarities in the incidents (although there was a difference in scale and impact), notably being the series of unfortunate events alternating between human error and misdirection by instruments. No matter what we are looking at, it tends to be that history will always repeat itself.

All the content this week (except for the Forensics seminar) felt quite applicable at a personal level. It is quite true that even in everyday activities when something goes wrong, we tend to blame others or just anything which isn’t ourselves. The list of human weaknesses was also frighteningly an accurate description of our behaviour under the described circumstances, and while we actually know these to be weaknesses, being able to change our habits and the way we think is an entirely different story.

The digital forensics similar went by quite quickly due to a time shortage but it is an in-demand skill set which is likely to grow in future. Privacy was likely the more useful seminar to the average person, providing us with many helpful tips on how to better protect our browsing from spying eyes. If the content presented were to be shared to a wider audience (for example through these blog posts) and garnered enough attention, it is almost certain we could better protect the privacy of the online community.

[secdino]

Wk 8 Tutorial & Case Study: Stargate Ghost

At the start of the tutorial this week, everyone present took turns to present their Something Awesome Project to the class for a few minutes each. Overall there was an interesting range of topics which were investigated, with some particular ones such as a Morse Code Translation Arduino device, and an operational intelligence search on our tutor. :)

After getting those presentations out of the way, we moved onto a very casual case study.

Context:

Not too sure if this is actually what the problem is set up to be like but it’s what we believed to be the scenario in class. We have a General and his friend the Lieutenant. After a top secret space mission via a portal, the Lieutenant has returned with an alien from the planet he investigated, but he’s become a ghost! He is only able to communicate through the alien whom we can’t exactly trust... 

Our job is to come up with a protocol with which we can receive the Lieutenant’s report as the General, in light of the ghostly situation and the alien.

Group Discussion:

For coming up with a feasible protocol to be possible, there were some assumptions we had to make:

The General can still talk/do things which the Lieutenant can see and receive.

The alien does have malicious intent (where possible).

The lieutenant has a decent memory.

The alien is not entirely stupid, and speaks English.

The alien doesn’t have super abilities such as being able to go through walls or listen through walls.

In our very casual state, we started off by deciding the most extreme, impractical course of action: threaten the alien with a genocide of its race along with everything else it might value. As said, this really was just a fun idea for amusement purposes only.

Onto a more legitimate discussion, we decided a good way for us as the General to ensure the alien was relaying the truth to us was to decide on a shared key of sorts with the Lieutenant beforehand. This could be achieved by having the General and Lieutenant in the same room (which has no surveillance) without the alien, and the General could simply verbally or hand-write a key. 

Then, if the report the alien relayed to us through Lieutenant did not follow the rules of the key, we would know the alien was lying. I.e. we could enforce both Authentication and Integrity. Deciding on the form of this ‘key’ meant there would have to be some trade-off between security and practicality: there are no perfectly secure systems which can be practically or efficiently implemented.

An example of this was our idea of a one-time-pad being used. The General could create a one-time-pad in the room and show to the Lieutenant a list of pre-determined nonces. Assuming the Lieutenant could memorise the numbers and also calculate how the OTP in his head, he could then encrypt his message to be passed through the alien in parts to be decrypted by the General. This idea seemed to be by far the most secure - but with the most ridiculous assumptions, making it an impractical option.

A better protocol which was suggested towards the end of the discussion involved creating a sequence of different pairs of code-words representing go/no-go, to be pre-determined by the General and shown only to the Lieutenant in the safe room. (With some helpful input from Andrew, we continued...) Afterwards, the Lieutenant could break up his report into sections, and after each section was relayed by the alien, one of the codewords could be added to the end to state whether or not that section of the report was legitimate or not.

Since there are multiple codeword pairs, this protects against replay attacks, and since the alien doesn’t know the other codeword (e.g. if the Lieutenant tells the alien to say codeword for no-go, it can’t randomly guess the codeword for no). We decided this would be the best protocol - verifying section by section.

Class Discussion:

When it was time for the class discussion, it was interesting to find that including ours, 3/4 groups had mentioned genocide and threats as a ‘funny’ impractical option. We briefly went around the room with groups describing a protocol they came up with which they thought might work, and one they came up with which probably wouldn’t work.

Class’s Protocol Suggestions:

Break up the report into sections and lock each one with a Merkle Puzzle.

Assumes ability to do Merkle Puzzle calculations in one’s head.

Also assumes the alien can’t do computation mentally.

Use symmetric encryption on a shared key between the General and Lieutenant.

Also requires the same assumptions as the above suggestion.

Create a political embassy of trusted members from both sides to mediate and confirm any communication.

Assuming a trusted third party solves every problem and doesn’t happen in the real world so we should never suggest this.

Class’s Not-so-Practical Suggestions (excluding genocide):

Procreate with the alien and then use the gained level of trust. If that fails, use the baby against it as blackmail.

Assumes alien x human procreation is possible.

Assumes consent.

Take alien hostages (this one was mentioned by 2 groups).

Reflection:

This case study topic seemed quite similar to the Houdini vs Margery case we analysed back in Wk 2. However this week’s one felt a lot easier, probably because of the difference in mood in the room, as well as there not being an audience to have to prove authentication to (unlike Houdini’s wife having to prove Houdini was communicating, to the public).

In the end my group’s protocol (with help from Andrew) turned out to be the best one we could come up with. For the other protocols suggested, more often than not they assumed something that was too unreasonable, primarily the ability to do large calculations in one’s mind. While most case study recommendations are allowed with enough valid justification, there are some (e.g. some of the above) which should not be written in exam responses regardless.

Apart from that, I can’t believe the Something Awesome is finally over, and it’s time for us to move on to finalising our ‘Job Application’ Portfolios!!

[secdino]

SA Wk 8: Signing Off

Having presented the summary of this ‘Something Awesome’ in the tutorial this week, it seems this project has truly come to an end. It’s been a wild ride of learning new skills, frustration at failure, and satisfaction in success, and being able to share it all through the many many blog posts throughout the term.

Starting off not even knowing what a CTF was, I’d like to think we’ve come a long way, now able to conquer most beginner-level CTFs across Pwnables.kr as well as OverTheWire. If the term had been longer (i.e. maybe in a semester :) ), perhaps we would have been able to push past the difficulty barrier and get over the next level of Pwnables.kr which left us scratching our heads this time around.

Overall, I’m quite satisfied with the new functions and tools I have learned to use, and most importantly, the attacker’s mindset that comes with trying to break a faulty program. During the presentation it turns out my tutor had actually intended 3-4 CTFs throughout the term as a good goal for a marking criteria - NOT 3-4 per week as I had mistakenly thought. As such, I’m feeling quite proud of the time and effort put in to achieve what we did.

To finish off, hopefully you the reader, felt as if you were in my shoes when reading the CTF Write-ups, and Weekly Reviews, and that you too feel as you’ve managed to take something away from this ‘Something Awesome’. This is SecDino wishing you all the best of luck for your CTFs in the future!!

[secdino]

Something Awesome: Weekly Reviews

Hiya! You’ve reached the index page for my weekly reviews!

These reviews summaries the main things I learnt, experienced, and felt while doing the CTFs each week.

Feel free to click on any of the links below to read a weekly weekly review! :)

Wk 3 Review

Wk 4 Review

Wk 5 Review

Wk 6 Review

Wk 7 Review

Back to Something Awesome Menu

[secdino]

Something Awesome: Write-ups

Hello there! You’ve come to the index page for my CTF write-ups! 

Each write-up is intended to act as an in-depth walkthrough for any readers who attempt the same CTF challenges I did. They include detailed descriptions of my thought process, screenshots to illustrate key moments, and explain the use of any new functions or terms (after doing research).

Feel free to click on any of the links below to read a write-up. :)

Note: All Pwnable CTFs come from the Pwnable website at Pwnable.kr.

Week 3: (informal testing)

OTW - Bandit

Pwnables - fd

Week 4:

Pwnable - collision

Pwnable - cmd1

Pwnable - cmd2

Pwnable - blackjack

Week 5:

Pwnable - random

Pwnable - lotto

Week 6:

Pwnable - mistake

Pwnable - shellshock

Pwnable - leg

Pwnable - flag (catchup for Wk 5)

Week 7:

OTW Leviathan Pt 1

OTW Leviathan Pt 2

OTW Leviathan Pt 3

OTW Krypton Pt 1

OTW Krypton Pt 2

OTW Krypton Pt 3

Back to Something Awesome Menu

[secdino]

Something Awesome: CTFs

Welcome!! This is the main menu of SecDino’s Something Awesome.

For my Something Awesome project, I decided to develop my CTF tackling skills from scratch over the course of 5 weeks. After getting a proposal green light in week 2, I did some exploratory CTFs in week 3, before diving in headfirst for weeks 4-7. 

Now that entire journey has been put together, for the pleasure of readers...

Please click on one of the links below to get started:

The Proposal

CTF Write-ups

Weekly Reviews

Other links:

Various CTF Research (Wk 2)

A Final Statement (Wk 8)

Job Application Main Menu (Open Learning)

[secdino]

Wk 7 Lecture: Main Points

Brace yourselves for a substantially lengthy post - there was a lot this week! We started off with a brief review of the mid-semester exam. After some discussion it turned out we had in fact sat a draft version of the exam rather than the final version which Prof. Buckland had intended! One of the questions also turned out to be incorrect (all the options in the multiple choice were wrong). Getting over this, we dived into the content for the week.

Diffie-Hellman Exchange

I’d actually studied this before for the mid-semester exam thinking it would be assessed so I’ll give an excerpt from my notes instead:

The Diffie-Hellman Protocol is a method of generating a shared secret between two parties in a way such that the secret can’t be seen by observing the communication. It is based on the modulo property:  (ga mod p)b mod p = (gb mod p)a mod p where p and g are prime numbers agreed on by both parties.

Person A chooses a secret number a and performs ga mod p which they send to Person B, and Person B does likewise by choosing secret number b. After exchanging, they repeat the calculation they previously did, and by the modulo property above, they obtain a shared key. Note this is NOT a protocol for authentication, it simply ensures the person at the other end of a communication channel is the same as before. This exchange procedure is often summarised in a paint-mixing diagram:

Vulnerabilities

Vulnerabilities are potential weaknesses in a system, while exploits are attacks one can carry out on a vulnerability to compromise the system. Some common types include memory corruption, buffer overflows, and format strings. We went over some code samples of errors which covered using gets() (never use it), indenting illusion, and misusing format strings such as with printf().

There was some discussion of buffer overflow attacks also but last week’s lecture main points covered most of the things mentioned (refer to Wk 6 Lecture: Main Points). One new thing learnt (though slightly off topic but good to know nonetheless) was the use of NOP sleds - a technique in which a series of NOPs come before malicious code so buffer overflow attacks which try to jump to a specific target address will have a larger range of bytes to hit.

Assets

Assets are those things which we find valuable, and security exists to protect our assets. As humans however, we are often quite poor at identifying our most important assets and end up protecting the wrong ones (e.g. being stabbed with a syringe vs losing $5 wallet in a hold-up). We have both tangible and intangible assets, and here are some ways that we can better identify which assets to protect:

Multiple Pairs of Eyes - ask for different peoples’ perspectives.

Standards & Protocols - often miss more than they catch but are a good starting point and should NOT be ignored.

Think Deeper - don’t think you’ve covered everything, there’s always blind spots or forgotten categories.

Regularly Update a List of Assets - survey others every now and then as values will change, and it is important to reorganise and reallocate resources accordingly.

Note: Remember just because something is difficult, it does NOT mean it cannot be done.

Bug Bounties (seminar)

Bug bounties involve competing to find bugs and then notifying the company about them. In notifying the company, competitors make a detailed report of vulnerabilities and the level of difficulty in find them. Companies usually have a list of ‘in scope’ areas of their system where they wish bug bounty hunters to be testing, and likewise an ‘out of scope’ area where no bounties are rewarded. Some basic preparation steps include:

Learning web app principles

Look for areas of wider scope and less competition

Stay within scope and start at a comfortable difficulty

Look for publicly disclosed reports and assets which have recently changed

Improve skills and teamwork ability

Practice with training resources such as Hacker101 and EdOverflow

One common method bounty hunters use is called fuzzing, where an automated process provides varying input to a program and monitors for unexpected behaviour (like crashing). Fuzzers should keep track of which input caused the anomaly, how long it took to find the vulnerability, where it occurred, and other important information.

Penetration Testing (seminar)

Pen-testing uses authorised simulated cyber-attacks on a computer system to evaluate possible security risks as well as identify strengths, for a full risk assessment. This plays a major role in testing existing security controls as well as discovering any potential vulnerabilities before attackers do.

The main steps in pen-testing involve:

Recon - gather intel regarding possible weaknesses in the system.

Planning - formulate a strategy to attack and possible ways to multiple goals.

Exploitation - intel gathered during recon put to use and vulnerabilities exploited.

Post-Exploitation - establishing persistence.

Some pen-testing tools (a non-exhaustive list):

Nmap - open source network scanner.

Kali - a massive tool set.

Metasploit - security project providing information about vulnerabilities aiding in pen-testing and IDS signature development.

Gobuster - used to brute force URIs (directories and files) in websites and DNS subdomains.

Public Key Infrastructure (PKI)

PKI is a method of authentication used to ensure we are communicating with a website which is what we think they are (prevention against MiTM). It links a public key to a domain name which is certified by a ‘trusted’ third party (the certificate authority). Certificate authorities (CAs) are in charge of checking websites and validating them with a certificate if they are who they claim to be.

Our user browsers keep track of trusted CAs and if a website is authenticated by one of them it will automatically trust that website. The website’s public key is used by any user wishing to communicate with it, and the website will decrypt incoming messages with their private key.

While CAs can certify a website is legitimate as they claim, they do not check if the websites contain malicious content or are impersonating another website. Another weakness of this protocol is that users can easily proceed if a browser displays an SSL warning for expired or invalid certificates (at their own risk).

Reflection

What a week! Skipping over the Diffie-Hellman Protocol which I mostly knew already, the vulnerabilities section may seem to imply that we should try to make perfect code. It is true that we should do our best to reduce the number of possible vulnerabilities and easy common ones at that, but it is also important to remember that it is impossible to write perfectly secure programs.

Hopefully the section about assets got you thinking as it did for me - I’m personally not even too sure what I value at the moment. Most of us would probably think straight to tangible assets such as electronic devices and wallets/money, but I think it’s also imperative we remember relations with others such as friendships could in a way also be considered invaluable assets.

As usual, the seminar presentations were interesting and provided a strong overview into Bug Bounties and Penetration Testing. If one was to pursue either one of these paths, they should make sure they know what they are doing, as not knowing could create undesired consequences. As for public key infrastructure, its strength in preventing MitM attacks introduces its own weaknesses, as does ‘improving’ most security protocols. I do not completely understand it in detail at the moment, so I’ll probably look further into it soon. :)

[secdino]

SA Wk 7: Review

Having learnt about buffer overflows during the tutorial this week (refer to Wk 7 Tutorial), I wanted to try the Pwnables ‘bof’ (buffer overflow) CTF to start off the week, but sadly the ‘nc’ connection failed! Trying some of the other ones which I had not done yet, I found they were escalating in difficulty very fast, so unintuitively, I tried a higher grade altogether.

Pwnables in the Rookiss section were in another world, I tried to push my ‘pwning’ skills but to my dismay I really could not get anywhere with them. Even after watching walkthrough videos on Youtube for 2 of them, I couldn’t understand more than 90% of what was said - honestly my ability hasn’t developed as much as I thought over the course of this project. 

In saying that, I gave up on attempting the Rookiss challenges (and of course the higher difficulties) as it is impractical to waste time trying to do things which are clearly out of my grasp for now. My inability to progress also led me to desire a change for this final week.

As a result, I changed to my backup plan (refer to Something Awesome (SA) Wk 2: Initial Proposal) mentioned in the initial proposal where if I couldn’t find something to do (or something I wanted to do), I’d fall back on doing CTFs from other fields. From this, I decided the best course of action was to set TWO OTW challenges for myself: Leviathan and Krypton. Here’s the summary of our final week of Something Awesome:

OTW Leviathan Pt 1

Revisited grep to make educated guesses of keywords to find a password.

Learnt the purpose of setreuid and geteuid. 

Practised more uses of ltrace and when best to use whoami.

Learnt about the access() syscall.

Learnt about ‘cat’ behaviour when filenames with two words are involved.

Learnt about symbolic links and created one.

Revisited and practised the touch command.

OTW Leviathan Pt 2

Very straightforward in general.

More uses of ltrace.

Applied binary conversion to ASCII.

OTW Leviathan Pt 3

Created my second symbolic link.

Revisited bash script syntax.

Wrote a simple brute force bash script and in doing so conducted my first ever brute force attack.

OTW Krypton Pt 1

Revisited simple decoding command line functions.

Practised more with tr command to map cipher encryption.

Performed decryption by analysing patterns on custom input.

OTW Krypton Pt 2

Analysed the results of a frequency analysis to produce a good alphabetical mapping.

Manually deciphered a short vignere cipher given the key.

Identified convenient online tools for decryption c:

OTW Krypton Pt 3

Conducted trial and error experiments to logically deduce the best parameters for solving a poly-alphabetic cipher.

Learnt about LFSRs (linear-feedback shift registers) and their weaknesses.

More practise on symbolic link creation.

Revisited knowledge of one-time pads.

[secdino]

SA Wk 7: OTW Krypton Pt 3

Level 5 -> 6

I didn’t bother with a screenshot of the starting files since they more or less look the same as all the previous levels by now. We’re dealing with a poly-alphabetic cipher once again (like Vignere) except this time we don’t know the key length.

Of course with an online Vignere decryption tool it’s only a matter of time before we input the right parameters to get the right answer.

At first, I conducted the decryption attempt using statistical analysis only. The top two ‘possible key’ results began with the letters ‘KEY’, leading me to try running the tool using it as a partial key. This turned out to be fruitless however. The next option available to try was a dictionary attack (using common English words). This also produced nothing which looked like an obvious key, but I noticed a lot of the suggested keys were either 3, 7, or 9 characters long.

From that, I went on to try running the solver using the key length parameter. Having lengths of 3 and 7 didn’t seem to produce anything useful, but a key length of 9 produced the picture above. While ‘KEYZENGTH’ isn’t exactly a word one might use, it’s not hard to see the correct key is ‘KEYLENGTH’. Using this key and the encrypted flag of ‘BELOS Z’, we can find our decrypted flag.

Flag: RANDOM

Level 6 -> 7

We’ve reached the ultimate challenge in ciphertext analyses - the one time pad!! There’s an ‘encrypt6′ executable provided to encrypt any text we provide it using the SAME key and a ‘random’ number. If the numbers were truly random, a one time pad is theoretically unbreakable, so it’s somewhat obvious the randomness of that number will have something to do with this CTF’s undoing.

The second hint regarding LFSR prompts me to do some research and learning as I have no idea what it is. It turns out LFSR stands for linear-feedback shift register. Wikipedia defines an LFSR as:

A shift register whose input bit is a linear function of its previous state.

That isn’t too important, it already reaffirms what we already know - XOR is the most commonly used LFSR function, and is in one time pads. What does pique my interest is this section:

The initial value of the LFSR is called the seed, and because the operation of the register is deterministic, the stream of values produced by the register is completely determined by its current (or previous) state. Likewise, because the register has a finite number of possible states, it must eventually enter a repeating cycle.

In other words, (assuming the hint is telling us this 8-bit LFSR is poorly designed) if we input a big enough input comprised of one letter repeating many times, we should be able to see some pattern through the ‘encrypt6′ executable. Time to try it out! 

Following the same steps as in Level 2 -> 3, we can create our own input file in a ‘/tmp’ folder of our own, then create a symbolic link to the ‘keyfile.dat’ in the original folder. I opted to go for an input of 200 ‘A’s, if we didn’t see any repeat, I’d double that and continue until a pattern was found. Of course for our sakes, OTW had made it a relatively short pattern.

Since we tested it using ‘A’s, the encrypted pattern we see is actually the key - we can now use it to decrypt the flag file. Conveniently, there exist online one-time pad solvers such as at Tools - otp. Put it into the boxes, and we get our final flag. :)

Flag: LFSRISNOTRANDOM

There was no Level 7 with a Congratulations for us :c

Regardless, we know we’ve reached the end so hurray!! We’ve done another one team!! :D

[secdino]

SA Wk 7: OTW Krypton Pt 2

Level 3 -> 4

This level is somewhat more annoying than the previous ones, in that we no longer have a cipher mechanism available to us. However, we do have 3 samples of English text which have been encrypted by the SAME KEY, allowing us to perform frequency analysis, as the helpful hints have pointed out above. Using an online frequency analysis tool such as the one at Frequency Analysis and copy pasting the text in all 3 found files, we got a table like this:

Bringing up a list of the English alphabet in frequency order, I mapped the above order of descending frequencies to the descending order of English letter frequencies, once again using tr to translate. The first output didn’t make sense, but through good guessing by utilising my knowledge of English rules, swapping enough letters in the mapping eventually got out a good enough decryption to read the flag.

Flag: BRUTE

Level 4 -> 5

This level ups the cipher sophistication by using a Vignere cipher to encrypt the flag. Once again we are given sample files - only 2 this time, and the very useful knowledge that the key is 6 characters long. If one had a lot of time on their hands and the botheration to do so, I’m sure it would be possible to solve the cipher manually. We don’t really have either of those, so using an online Vignere cipher solver such as the one at Vigenere Cipher (knowing the key length), we get this output:

Knowing that the key is ‘FREKEY’, we can now simply decrypt the file using the online decryption again, or since the flag message ‘HCIKV RJOX’ is so short, we could do it manually. Either way, we get our answer.

Flag: CLEARTEXT

More in OTW Krypton Pt 3...

[secdino]

SA Wk 7: OTW Krypton Pt 1

In the spirit of COMP6441 and also wanting to test myself against something new and possibly fun, we shall take on the OTW Krypton CTFs as our final series of CTFs for this project. Hopefully, we’ll be able to reach the end.

Level 0 -> 1

The presence of hints for this series will likely make our lives somewhat easier. Level 0 started off real slow with a simple base64 command with the --decode option to get the first key we need.

Flag: KRYPTONISGREAT

Level 1 -> 2

Remembering the notice at the bottom of Level 0 that the rest of the files are found in ‘/krypton’, the natural first step is to ‘cd /krypton’. We found our way to a README file with the introductory paragraph (which most CTFs have) followed by a very obvious hint that the flag we wanted was in ‘krypton2′ encrypted with ROT13.

Did that sound familiar? That’s right! We did exactly the same thing in OTW Bandit Wk 3! It wasn’t hard to recall how to use the tr command to create an alphabetic mapping and translate the cipher text.

Flag: ROTTEN

Level 2 -> 3

On entering the level, I followed the instructions in the example (refer to OTW - Krypton2), by creating my own folder in the ‘/tmp’ directory and creating a symbolic link to the data file. I then created my own plaintext file called ‘test’ and wrote out ‘ABCEDFGHIJKLM’. When executing the provided ‘encrypt’ executable, we were able to see the output was ‘MNOPQRSTUWXY’, meaning the text containing the key also follows the same pattern of shifting forward by 12.

To undo this, we once again look to the tr command, and map out the translation to give us the flag we need to continue.

Flag: CAESARISEASY

More in OTW Krypton Pt 2...

[secdino]

Wk 7 Case Study: Snoop

Context:

Instead of analysing a scenario as with past case studies, this week upped the ante by having a ‘class debate’ - should the government or its agencies collect and have access to your data or should citizens have a right to stop them?

Having done research before class, we were prepared when Andrew assigned us into pairs and labelled us ‘for’ and ‘against’ alternating. Any latecomers joined the smallest group. I was fortunate enough to be part of a group arguing ‘against’.

Arguing Against:

Due to there being a multitude of points supporting our argument, the following are just a brief summary of the best ones:

Breach of Privacy v Effectiveness - blanket data retention laws breach privacy under international human rights law.

Disproportionate as small percentage of population targeted but data collected from everyone.

Most terrorists/major criminals are known to authorities beforehand.

Security of Retained Data - no set of standards for agencies to ensure security of stored data.

Having all the data collected into a repository increases the reward for potential attackers and saves them the effort of having to attack individuals.

Data collection is high-value, what is in place to stop a member of an agency from selling the data out?

ISPs not required to store the data within Australia, meaning it could be leaked to foreign agents.

Use of Retained Data

Data could easily be misused or abused by government agencies.

E.g. Manipulation of voting data, targeted marketing etc.

Type I/II Trade-off - facial recognition easily misidentifies people, the benefits don’t necessarily outweigh the potential costs.

Biometrics being hacked have a lifelong consequence.

Loss of Freedom of Speech - people will be less likely to speak their mind without fearing repercussions.

Journalistic practice suffers consequences.

Whistle-blowers no longer willing to come forward.

Definition of Data Set - scope of data which may be lawfully accessed is not well defined.

No prohibition on collection and retention of browsing history.

Data set is constantly being expanded.

Poor distinction between content and metadata.

Trust in the Government - the current government may be ‘trustworthy’ but what’s to say future governments won’t exploit the collected data.

Access Threshold - set too low, at the moment 22 agencies can access data without need to authorise.

Unnecessary Duration - currently set to 2 years but most useful accesses occur within 6 months of collection.

Freedom to Choose - there is no opt-in/opt-out option, people are forced into it without say or consultation.

Class Debate:

We staged a mock debate with the ‘Against’ speaking first, followed by ‘For’, then again for each team. Each speaking part was 5 minutes max, with rebuttals included. It was quite a casual ‘debate’, with ‘Against’ arguing disproportionality and the high levels of irreversible risk involved, while ‘For’ argued its necessity in keeping crime in check and increasing system efficiencies.

After the debate, Andrew conducted a blind class survey to see where everyone’s opinion sat regarding this topic. To no one’s surprise, a majority of the class were personally ‘Against’ the data retention laws. 

Reflection:

To be able to argue a side which I agreed with personally made the task substantially easier. As demonstrated by the outcome of the blind survey, and also a short discussion after, members of the ‘For’ described the difficulty in arguing for a perspective which went against their own beliefs. 

A fellow student brought up a great point which was, “when we have to argue something, even if we don’t agree, we have to believe in it to be able to argue it well”. We all agreed on this and Andrew also added that sometimes as a result, our views change. Personally, I believe it is quite alright for everyone to have their own perspectives on a topic - but we should always look at both sides of the argument first to understand where the values of both sides lie.