My Public Insecurities @public-insecurities - Tumblr Blog

Job Application: Overview

Dear Recruiter,

I am writing to you in response to an advertisement I found on OpenLearning regarding the Security Engineer position at GITZon.

I believe that I am the perfect person for the job, as outlined by the pages linked below.

Analytical Abilities

Time Management

Skills

Community/Professionalism

Something Awesome

Thank you for your time. I look forward to hearing from you; let's talk soon.

Kind regards,

Peppa Pig

public-insecurities.tumblr.com

Job Application: Community and Professionalism

Established Tumblr Community

Here are my community statistics.

Here are the blogs which receive most of my love.

My most liked post would have to be this one and it probably attracted a lot of attention because it was very relatable.

Tumblr Participation

I also liked and commented on some of the posts by some of the blogs I followed, where I either provided constructive criticism or disussed the post. Here are some examples:

Tsoyuzhu - Something Awesome

Tsoyuzhu - Security Everywhere

Aisforsecurity - CTF Discussion

6841blog - CTF discussion

Tsoyuzhu - CTF

Alexpanaman - Cryptocurrency

Sharing is Caring

During the course, I tried to share as many resources as possible with my Tumblr community, such as informing people of important dates,and sharing resources (links, practice ciphers, etc.)

Finals PSA

Cipher Practice

Research: Birthday ATtack

Hashing

I also took notes for my friends who were away one week, and posted them.

Week 8 Note Taking

Security Everywhere

Throughout the semester, I developed 'security eyes' and documented security issues. I blogged about these issues each week, demonstrating strong evidence of my effectiveness and time management skills.

Kyoto Animation Studio

Blogger Account Workaround

UNSW zID Anonymisation

Mascot Towers

Hoffman Murder

Hong Kong Protests

Westpac Attack

Class Participation

I attended the weekly case studies where I was able to analyse situations and provide recommendations, alongside their justifications, before brainstorming with a larger group to compile our answers and discuss the strengths and weaknesses of each point, before coming to a conclusion we can agree on.

Week 7 - Lightning Talk

Week 7 - Snoop Debate

Week 6 - Safer Case Study

Week 5 - Self Driving Cars Case Study

Week 4 - Secret Case Study

Week 3 - Doors Class Study

Week 2 - Houdini Class Study

Week 1 - Deepwater Horizon Class Study

Security Events

SecSoc CTF

Along with 3 other friends, I also participated in the SecSoc T2 CTF.

SecSoc T2 CTF Solutions Workshop

SecSoc T2 CTF - 2/2

SecSoc T2 CTF - 1/2

COMP6841 CTF

Recently, I have started participating in the COMP6841 CTF.

COMP6841 CTF

Hosting a CTF

At the end of June, I organised a CTF! I set up the server and made up the questions (though I've since killed the server...) The only proof I have is the Facebook event page and Alex Panaman's post of a picture from the CTF where I spelt Vigenere wrong...

Job Application: Skills

Activities

Each week, I aimed to improve my security skills and mindset by completing at least two of the weekly activities on OpenLearning. More analytical skills can be found in this blogpost.

Module 2

Shredding Analysis

Dumpster Diving

Cipher Intro

Coincidence Index

Module 3

Penguin-napping

RSA

Module 4

Bits of Penguin

MACs + Hashing

Module 5

Vulnerabilities

Hashing Gone Wrong

Module 6

Threat Modelling

Module 7

AES and Block Cipher Modes

Social Engineering Simulator

Research

In addition to the OpenLearning activities, I made completed some extra research on topics covered in the course such as RSA and lockpicking.

RSA

Lock Picking

MACs

Hashing and Birthday Attacks

Cryptoprocessors

Coincidence Index

Claude Shannon

Cipher Practice

In preparation for the mid-semester exam and the final exam, I practiced solving some ciphers. In particular, I solved a lot of cryptograms on the Cryptograms mobile application and managed to get my average time up from 2:04 to 0.48.

Cryptograms

Improvement to 0:48

Improvement to 2:04

Initial cryptogram struggle

Transposition Ciphers

In addition to substitution ciphers, I also practiced (which was labelled as 'miscellaneous') which I found was shared by a tutor in another lab group.

Transposition ciphers

SecSoc Term 2 CTF

I participated in the SecSoc Term 2 CTF with some friends and came eighth place to try and apply the skills we have learnt and obtain more skills.

SecSoc T2 CTF Solutions Workshop

SecSoc T2 CTF - 2/2

SecSoc T2 CTF - 1/2

Something Awesome

As part of my Something Awesome, I challenged myself to complete the project in AVR Assembly. I was able to meet most of my expectations and create a system I was proud of.

Demonstration

Job Application: Analytical Abilities

Security Everywhere

Each week, I attempted to ensure that I am always looking around and analysing the enviroment around me for security issues, as well as providing recommendations on how these issues can be addressed.

Kyoto Animation Studio

Blogger Account Workaround

UNSW zID Anonymisation

Mascot Towers

Hoffman Murder

Hong Kong Protests

Westpac Attack

Homework

In some of my homework posts, I decided to include a bit about we can learn from this activity, as well as some recommendations. So instead of just completing the activity, I thought about the issue at hand from multiple sides to reduce my bias and ensure that I am exploring all possibilities before coming up with a recommendation.

Social Engineering and Email Phishing

Threat Trees

High Impact, Low Probability

TI/TII in the News

ATM Attacks

Vulnerabilities

Case Studies

Week 7 - Snoop Debate

Week 6 - Safer Case Study

Week 5 - Self Driving Cars Case Study

Week 4 - Secret Case Study

Week 3 - Doors Class Study

Week 3 - Doors Pre-Lab

Week 2 - Houdini Class Study

Week 2 - Houdini Pre-Lab

Week 1 - Deepwater Horizon Class Study

Week 1 - Deepwater Horizon Pre-Lab

Human Weakness of the Week

Corruption

Self-Interest

Frame of Mind

Reflections

At the beginning, I had started writing weekly reflections. However, as mentioned in my Week 3 reflection post, I found that the expectations I put on myself were too high and I decided to cool things off a bit by focusing on quality over quantity to ensure that I wasn't blogging for the sake of blogging, but to ensure that I blog for the sake of learning and reflection. I picked up Weekly reflections in Week 6 where I hope to continue this to make sure that I am learning from my mistakes and getting the most I can from the course.

Week 6

Week 3

Week 2

Week 1

Something Awesome

In addition to completing regular blogposts regarding the process of my Something Awesome project, I decided to include some analysis which focused on my current thoughts towards the overall security of my piggy bank at that point in time. I also analysed the security of the entire system and blogged about it, as part of my project.

Week 2 Progress

Week 4 Progress.

Week 5 Progress #1

Week 5 Progress #2

Week 7 Progress #1

Week 7 Progress #2

Week 8 Progress

System Evaluation

Job Application: Time Management

Tumblr Posts

Overall, I attempted to post at least 2-3 times per week, whether it be for the OpenLearning activities, lab reflections, or lecture homework.

An archive of all my posts can be found here. As of Friday 26th July, I had 86 posts, which rounds to 10 posts per week.

Sometimes, unforeseen circumstances arise. To ensure that I still get some work done, I attempted to at least make a start on everything throughout the week. For example, in Week 5 I was overwhelmed by my work schedule, my procedure, and all sorts of stuff, but I was still able to get things done at the end of the week as I had already made a start.

The time stamps on the posts also provide proof.

Weekly Modules

I attempted to do at least 2 module activities per week. I could not find my posts for Week 1, and some of the other activities, as I had commented it under the activities themselves and I was unable to retrieve the comments.

Module 2

Shredding Analysis

Dumpster Diving

Cipher Intro

Coincidence Index

Module 3

Penguin-napping

RSA

Module 4

Bits of Penguin

MACs + Hashing

Module 5

Vulnerabilities

Hashing Gone Wrong

Module 6

Threat Modelling

Module 7

AES and Block Cipher Modes

Social Engineering Simulator

Case Studies

I was able to attend all the labs/case studies this term and uploaded all reflections/pre-lab thoughts by the end of the week.

Week 7 - Snoop Debate

Week 6 - Safer Case Study

Week 5 - Self Driving Cars Case Study

Week 4 - Secret Case Study

Week 3 - Doors Class Study

Week 3 - Doors Pre-Lab

Week 2 - Houdini Class Study

Week 2 - Houdini Pre-Lab

Week 1 - Deepwater Horizon Class Study

Week 1 - Deepwater Horizon Pre-Lab

Something Awesome

As part of my Something Awesome project, I aimed to do a bit of work each week in order to achieve my goal. Although some weeks are missing, due to work circumstances and work piling up from other subjects, I attempted to make up for lost time by doing more work in later weeks and catch up.

Week 2 Progress

Week 4 Progress.

Week 5 Progress #1

Week 5 Progress #2

Week 7 Progress #1

Week 7 Progress #2

Week 8 Progress

Deadlines

Something Awesome

I was also able to upload my demonstration, write up my reflection, and evaluate my performance before the due date. They were all uploaded to my blogpost before 8pm on Monday, when it was due on Tuesday 6pm.

System Evaluation

Demonstration

Marking Criteria Evaluation

Job Application

This job application was submitted before the due date on Sunday 28th July, 2019. In fact, I created these posts on Friday, before I was able to finish off my posts for the week, which is why I'm missing the Week 8 Module activities.

Mid-semerster Exam

I was able to attend the mid-semester exam and receive a mark that wasn't 0, which shows how I'm able to manage my study time and attend the exam itself such that I will hopefully not fail the course. I wish I had taken a selfie inside the lab to prove my punctual presence.

CTF Solutions Workshop

SecSoc T2 CTF Solutions

I attended the solutions workshop yesterday in the hopes of finding out how to obtain the flags I spent hours trying to find. Here are my findings (summarised because I honestly had no idea what they were talking about most of the times, someone please send help):

I only wrote up solutions to the ones I did not complete myself. For the ones I did myself, solutions can be found here.

Furious

Use Angr.

Enter binary input.

Print ouf the standard output.

Ginkou

Exploit the bug in the code where the acc value doesn't update.

Keep calling the function so that it will continually add to your account without checking the previous balance.

Run them all concurrently, not one at a time, to exploit the race condition.

Buy the flag.

Cyrptography

64seBa

Decode the string using a custom Base64 alphabet. CyberChef is quite useful for this as the alphabet used is just the usual Base64 alphabet used except backwards.

HTML Encryption

Decode the HEX string.

Decode the Base64 string.

You think you're done, but you're not. Decode each number and convert it to octal.

Forensics

YinYang

Flood fill the middle-left of the Ying Yang symbol to obtain some discoloured pixels.

Decode the pixels to obtain the flag, similar to Ying and Yang.

Big Boss

I honestly have no idea what was happening. All I know is that:

There is a QR code at the back of the image.

Use DXT1?

Something about transparency.

Pwn

Recipe

When asked for the secret sauce, put in the return address to print the flag.

bufff

Enter in 56 bytes and a few more bytes to override the return address.

Dungeon

Exploit the printf vulnerability.

Printf the maze as a string, %s address of the maze

Week 8 Morning Lecture

This morning, I became the sacrificial lamb who went to the lecture whilst others (ahemalexpanamanahemtsoyuzhuahem) slept in. I had to take one for the team and take notes, so take notes I did. Usually, I refrain from taking too many notes as I'd rather listen than try and remember two things at once (what I'm trying to write and what I'm going to write based on what's currently being said). However, since my friends weren't in the lecture, I tried to make my notes as thorough as possible.

Errors

Fall back attack: "Nah you gotta use this crappy version"

Film in the exam: The China Syndrome

Root-cause analysis: Trying to figure out what went wrong to stop it from being repeated (which may cause more problems). It can be useless because things can always be different (combination of factors that might not happen ever again).

Humans prefer a single cause/explanation.

Top errors in descending order:

User/human-error: How do you fix it? You sack that person. It's quick. Humans like blaming people. The person who did the "last-touch" in aviation - the person who inspected the feature/signed-off would get all the trouble.

Culture: Don't have to sack anyone. Who's responsible for a bad culture? Everyone. Consultants and education training brought in. Changing culture is hard.

Human Weakness

Honesty: maybe people aren't aware that they're not being honest. If the signing is at the top, people are more likely to be honest, than if the signing was at the bottom eg. Honour code (being EtHiCaL). Convincing yourself that you're right, despite the evidence eg. confirmation bias.

Misdirection and limited focus: Torch in dark room - some factors you don't look at, some factors you look at over and over again. Misdirection - to divert focus on something else, rather than what you should be looking at. Humans should focus on what's logically important, but we tend to focus on what's psychologically salient (most impressive, interesting). This is exploited by social engineers, magicians (tricks work because our attention is elsewhere),

Heuristics

Similarity matching: Finding what's similar and thinking that it's the same. Social engineers make the situtation seem familiar so that they're able to predict what their victim will do. You don't have to think very much.

Frequency gambling: When you have a match (the situation is happening and your brain is recalling the pattern), when pattern isn't similar, your brain will pick a pattern isn't the best matching one, but the one that you've used most often in the past. What's worked in the past will work in the future.

How is an accident different from an attack?

We can get away with accident, but we can't get away with security - someone will take advantage if it.

"Habit diminishes the conscious attention with which our actions are performed" William James 1980

The more habits we form, the less we use our torch.

Human Weakness (cont'd)

Satisficing: Instead of maximising someting, you aim for something that's good enough - good enough is good enough.

Bounded rationality: Small amount of focus fed by a tiny little trickle. The amount of focus and energy you put into someting is very small, so you take a lot of short cuts.

Overriding tendency to verify generalisations rather than falsify them: If someone's made a generalisation, it'll be hard for them to back down.

Group think: They felt important and didn't want to do anything to jeapordise it. When you value group membership and harmony/consensus. If things are going of the rails, no-one wants to say anything and be the one that no-one likes. Group pressure.

System Error

No one cause, many factors that caused the error - a normal accident, a whole system is responsible. Just culture, instead of going around punishing people, you learn about how to fix things.

Chekhov's gun: What are the points?

Case studies: Lots of irrelevant stuff so that we don't fall into the cognitive traps.

Simplification:

One significant cause

Plan for fewer contingencies can occur: focus on one contingency

Illusion of control: when you understand or can explain the problem, you feel like you can control the outcome - a sense of power.

Hindsight bias: If you know the previous outcome of the previous outcome, you are more likely to think that it'll happen again. The more things happen, the more you're likely to think that it'll occur again. THe less things happen, the less likely to think that it'll happen.

The more you tell the story, the more you simplify things and the more you exaggerate what you think is salient.

Defence in depth: You feel safe - but things may fail invisibly.

Operator deskilling due to atutomatic safety devices: By having lots of defence in depth and using humas as the last line in defence, they may lose their skills and will not be ready for an actual attack.

Latent vs active failures: Latent failures - "an accident waiting to happen".

Job Application: Something Awesome

The Idea

The idea was proposed in two early blogposts. The first mention of it was in this blogpost, right at the end. The idea was posted on my private blog as I didn't want anyone to be asking questions as to why I had a UNSW microcontroller in my possession. However, I later realised that it doesn't matter and elaborated on the idea in this post.

The Criteria

The original proposal, Marking Criteria v0.1, went into a little more depth in describing what was required of my Something Awesome Idea. It included the marks breakdown and overall marks required to obtain each of the marking tiers (P, C, D, HD).

My tutor responded to my original proposal with improvements. However, my reply e-mail was stuck on 'sending' (which I didn't realise), so the marking criteria was revised and Marking Criteria v0.2 was born. This marking criteria provided more depth and included more features to be implemented. In addition, at the end of the document, I included an intended weekly plan.

Progress

Each blogpost includes a 'What I've done so far' section which briefly explains my progress, as well as a 'In the demonstration' section which explains what is in the video. Some posts also include 'What I've changed' and 'Problems', as proof that I was attempting to do something each week. There is a gap in Week 3, as I was still trying to get my act together, and Week 6 as I was trying to catch up with things after the mid-sem. However, I attempted to make up for the gaps by doing more work at the later weeks.

Week 2 Progress

Week 4 Progress

Week 5 Progress #1

Week 5 Progress #2

Week 7 Progress #1

Week 7 Progress #2

Week 8 Progress

Final Submissions

As part of my marking criteria requirement, I made a System Evaluation post which evaluates the strengths and weaknesses of the system I created, as well as recommendations which aim to improve the overall security of the piggy bank and what I could have done better.

I also uploaded a Demonstration blogpost which shows my working system which was submitted to my tutor before I demonstrated my project in class.

In addition, there is a Marking Criteria Evaluation blogpost which is a reflection on how I performed when comparing the system I created with the marking criteria I proposed at the beginning of the semester.

Something Awesome: Final Marks

Marking Criteria

The proposal can be found here. It contains the marking criteria and the game plan.

The demonstration of the system can be found here.

System Implementation

Start Screen [5 marks]

Start screen displayed correctly.

5/5 marks

Select Screen [5 marks]

Deposit, view balance and withdraw screens implemented.

5/5 marks

Coin Input Screen [5 marks]

Coins able to be input correctly, with potentiometer input working.

5/5 marks

Coin Delivery Screen [10 marks]

PIN input implemented! However, the empty screen was scrapped and instead, the screen will return to the withdraw screen once it has finished emptying or if the piggy bank is empty. Alternative 'Empty' case handled.

10/10 marks

Failed Input [5 marks]

Waiting interval after incorrect input has been scrapped and remained unimplemented. This is because there were too many screens and not enough available lines of code to jump to, as mentioned in a previous blogpost (see Admin Mode section below).

0/5 marks

Balance Screen [5 marks]

Balance screen implemented. However, as mentioned in the Coin Delivery Screen section above, there were too many screens to be able to implement the Empty screen. Instead, viewing an emtpy balance will display nothing on the LEDs.

5/5 marks

Potentiometer Input [15 marks]

Potentiometed input works for inputting coins and it is reflected on the LED strips. Originally, an overflow of the LED strip would cause it to start from the bottom. Instead, the coins will deposit automatically. Motor functionality accompanying the coin deposit also works.

15/15 marks

Admin Mode [15 marks]

As mentioned in this blogpost last week, I have decided to scrap the admin mode as I believe that it is not really necessary for the core security elements of this project. More information can be found in the blogpost.

0/15 marks

Weekly Blogging [10 marks]

There are around 7 blogposts altogether, which can be found in the Something Awesome section of my Job Proposal.

Every time I completed something or encountered a problem, I did my best to blog about it, just in case someone had a solution and to prove that I had done something that week. However, I did not mention about what needs to be done the next week, so I will dock some points for that.

8/10 marks

Evaluation [10 marks]

The evaluation can be found [here]. It is satisfactory, but the suggestions for improvement can be lacking. However, the suggestions can be implied via the evaluated weaknesses. Most of the weaknesses of the system were due to lack of feature implementation and thus, the security is weak. This is due to the lack of time and for trying to do too many things within a short amount of time.

7/10 marks

Extensions

RFID Reader [15 bonus marks]

This remained untouched as I had trouble getting the PIN and Safe Lock implementation to work.

0/15 bonus marks

Safe Lock [10 bonus marks]

This was attempted but was not completed as the hardware was not willing to co-operate. The problem was elaborated in this blogpost, where I explain how the middle ground between MAX and MIN reading was very small and vague. It was fine for the coin input implementation, as it did not require the potentiometer to be specifically in the middle groun (neither MAX nor MIN). Thus, an attempt was made but it was unsuccessful. Pity marks for trying.

2/10 marks

Overall

System Implementation

Start Screen 5/5

Select Screen 5/5

Coin Input Screen 5/5

Coin Delivery Screen 10/10

Failed Input 0/5

Balance Screen 5/5

Potentiometer Input 15/15

Admin Mode 0/15

Evaluation 7/10

Bonus Marks

EXT: RFID Reader 0/15

EXT: Safe Lock 2/10

Total Marks:

D - 54/70 (including 2 bonus marks)

Something Awesome: The Last Part

Evaluation

The proposal can be found here. It contains the marking criteria and the game plan.

Assessment

As part of my marking criteria, I have to make a blogpost evaluating the piggy bank created.

Strengths of the System

(As mentioned in the final update blogpost...)

Numbers pressed can't be seen, so it may be a bit hard to keep track of the numbers entered once it gets long.

Keypad is sensitive so numbers may be entered twice without the user knowing.

Once an incorrect digit is pressed, the user must start again. This, combined with the previous two weaknesses may make it quite difficult to brute force the pin (and may be frustrating to the user).

Weaknesses of the System

Keypad may be prone to smudge attacks, so the attacker may be able to guess the combination.

PIN combination is stored in plaintext and can be easily read if the attacker has access to the source code.

Potentiometer combination also stored as plaintext (if it were properly implemented, this would be a weakness).

Only one layer of defence, meaning once the attacker is in, they're able to steal all the coins.

It's a simulated piggy bank. The attacker can just reset the system and the user will lose all their coins :(

Suggestions for Improvement

Another layer of security could be implemented, such as a hardware token or the safe lock that I tried implementing. That way, the attacker has to get through two defences before they are able to take the coins.

In order to counter the brute force attack which can be done to guess the PIN, there could be a delay which increases between each incorrect attempt. That way, brute force is possible, but the delay increases the time and effort required to guess the PIN.

Reflection

If I had more time, I would defintely try and wire an RFID reader to the board. I actually bought one in case I had time to do it, but alas, I didn't.

Maybe I was a aiming a bit too high by choosing to do a project in AVR assembly, but it was something I enjoyed doing (thought it was rather frustrating at times as indicated by some of my blogposts...). Maybe next time I could try using C. It may be easier to debug problems and I'll have a wide range of libraries to choose from!

Something Awesome - Demonstration

The proposal can be found here. It contains the marking criteria and the game plan.

The Demonstration

So here it is, the final demonstration before I put away my board till I feel like playing with it again.

Navigate to the deposit screen.

Insert coins using potentiometer with LEDs reflecting the number of coins input.

Deposit coins with the LEDs strips and motor reflecting the number of coins inserted.

Navigate to the balance screen.

View the balance as lights on the LED strip.

Navigate to the withdraw screen.

Incorrectly input PIN multiple times.

Input correct PIN and withdraw coins.

LED strips and motor reflect the number of coins to be output, similar to depositing.

Try and deposit more coins than the number of LED strips to try and trick it.

Coins insert automatically once the limit is reached.

The evaluation of the system (as part of my marking criteria requirements) can be found here

The assessment on how I performed according to my marking criteria can be found here

Something Awesome: The Final Push

The proposal can be found here. It contains the marking criteria and the game plan.

What I've done so far

Following on from my last Something Awesome post, I have decided to forget about the vault lock implementation because I don't like the potentiometer will co-operate with me in this case, since the middle-ground range is too small. I was about to give up when I decided to maybe try finishing of the PIN implementation.

Which now pretty much works I guess! Except it is a bit glitchy... Just like the rest of my board... But that's okay! We have something to present!

So now, I have a 5 digit PIN which needs to be entered before the user can retrieve all their coins. The keypad, just like the potentiometer is also a bit sensitive so a firm press is required. Sometimes one press will register as two, which may act like an additional layer of security as the user is unable to see what numbers have been pressed. The press required is also reset whenever the user makes an incorrect input, so this can work both in favour of, and agains the user.

In the eyes of an attacker:

Can't see what numbers have been pressed

Can't see when a number has been pressed twice

Can't see when the number has been input incorrectly

These features (not bugs) increases the effort required to break into the piggy bank. However, it is also bad luck for the user if they have to frustratingly input the same PIN over and over again because one of their pressese were registered as two inputs.

In the demonstration

Inserting 3 coins

Viewing the balance - 3 coins

Input the pin incorrectly

Input the pin correctly to retrieve coins (12345)

Bitter Sweet

I will now wrap up my Something Awesome project. I am quite sad that I wasn't able to implement as much features as I would like, but maybe I was a bit too ambitious. I'm quite happy that I was able to get the PIN implementation working so I am quite satisfied with that!

Stay tuned for my final Something Awesome post which will include the demonstration and the final reflection!

Security Everywhere: Kyoto Animation

Japanese Animation Studio Fire

On Thursday 18 July, an arsonist doused the area of Kyoto Animation studio with petrol before setting it ablaze. It's believed that he held a grudge against the animation studio and accused them of plagiarism.

The fire resulted in 33 deaths and 10 people in critical conditions.

What made the fire so deadly?

Lack of sprinklers or indoor fire hydrants: There was no way of easily putting out the fire inside the building. However, there were no legal requirements for the building to have such safety measures.

Door on the roof might have been jammed: 19 of the 33 casualties were found on the staircase leading up to the roof where the door was found to be shut. However, emergency services were able to unlock the door from the outside, indicating that the door could have been unable to be opened from the inside.

No fire escape on the outside: Following up from the previous point, a local resident made a comment saying that so many people died as a result of the lack of an external fire escape.

To summarise, the high number of casualties were the result of lack of safety features on the building such as the installation of sprinklers and the lack of a fire escape.

Recommendations

Sprinkler installation: Based off the first analysis point, there should at least be some sprinklers inside the building, even if it's just in the flight of stairs. These sprinklers may keep the occupants out of harm's way as they navigate through the flight of stairs.

Regular maintenance checks: Whether it be quarterly or bi-yearly, there should be regular maintenance checks to ensure that safety features are working as intended. These checks may have been able to identify the faulty door on the roof and it would have been fixed.

Fire escape drills: In addition, there should also be practice drills. These drills would allow people inside the building to identify areas of concern and educate them on what the best procedure is in the case of an emergency.

Escape routes: There should be at least two different escape routes in place. That way, if one route is obstructed, occupants will be able to evacuate via another escape route and will not be trapped. This will minimise the single point of failure.

Security links

In relation to security, what can we learn from this event?

Ensure that you have safety features in place in case an attacker would like to try your defences.

Check to make sure that your safety features are working to the best of their ability and that there are no identifiable bugs or faults.

Run test cases and make sure you don't neglect edge cases which may break your system.

Minimise your single point of failure. We don't like singe points of failure.

References

Japanese animation studio fire suspect reportedly alleges his work had been plagiarised by firm

Japan mourns after the worst mass killing in two decades claims 33 lives in arson attack

Something Awesome: Brokoro Like My Kokoro

The proposal can be found here. It contains the marking criteria and the game plan.

What I've done so far

So, in my previous post, I mentioned that I had a problem with the vault lock system. I've recorded a video of the problem itself.

How it's currently implemented

Here is the pseudocode... I never realised how difficult/confusing it would be to translate assembly to pseudocode haha.

if screen = incorrect_pin case(POT): MIN: if flag = 0 flag = 1 if supposed to be at MIN based on LSB of current_pot current_pot >> 1 pot_count++ else reset current_pot clear pot_count end MAX: if flag = 0 flag = 1 if supposed to be at MAX based on LSB of current_pot current_pot >> 1 pot_count++ else clear pot_count reset current_pot end default: flag = 0

What it's doing is pretty much ensuring that:

The POT must move to the middle before a MAX/MIN reading is registered so that the system won't be continually reading a MAX/MIN reading if it hadn't moved from its initial position.

The required reading is based off the LSB of current_pot which is set to the required potentiometer reading sequence in binary during setup. LSB 1 = MAX, LSB 0 = MIN. This value is shifted to the right after every correct reading. If there is an incorrect reading, the value is reset to the original.

For every consecutive, correct turn, the pot_count is increased. Once it hits the number of rotations required, it will raise a "done" flag and cause the screen to return to normal.

Incorrect readings will cause the pot_count and current_pot to be reset such that the user needs to start again.

The problem

To debug my problem, I called on the help of my trusty LED bars.

The bottom 8 reflects current_pot and should be shifted after every correct turn. The combination was set to 11, so 2 LED strips should light up.

The top 2 reflects whether the pot read MAX, MIN or neither. If it lights up, it means that the system detects a MAX or MIN reading, and the system should either reset the current_pot or shift it. If it doesn't, it detects neither a MAX or a MIN, the current_pot should remain the same.

However, as seen in the video the current_pot is being reset when it reads neither MAX nor MIN! Why! current_pot also jumps from 11 to 00 as well, no idea why!

If you focus on it, you can see that the light is flickering, which means that the POT is probably too sensitive and can't really tell the difference between MAX and MIN and it is freaking out.

SecSoc Term 2 CTF

The Results

My team, BIG BATE came seventh overall! Not bad. You can see from the graph that we were off to a very slow start, so it was quite worrying at the beginning.

My team consisted of my friends alexpanaman, tsoyuzhu and bryan (who doesn't have tumblr and isn't doing sec this semester). Each of us had different strengths, so that was very useful. Tsoyuzhu focused on the RE challenges, I focused on the forensics and crypto challenges, whilst alexpanaman and bryan focused on the web and misc challenges.

I've decided to write up the solutions on my contributions.

Forensics

Yin

For this challenge, we were given what seems to be a plain white photo. However, when you extract the RGB values of the photo which weren't pure white (0xFFFFFF), the hex values produced spelt the flag.

Yang

Similar to Yin, we were given what seems to be a plain black photo. Once again, to obtain the flag, you must extract the RGB values. However this time, you had to choose the values which weren't pure black (0x000000). The decimal values produced spelt the flag.

Reference Letter

For this one, alexpanaman actually gave me a hint and told me to modify the first chunk of hex values in the file to make it readable, as when it's first downloaded, it's corrupted. The value to change it to was found by finding out the PDF magic number. Once that was done and the file was able to be opened, it was a meme. I had no idea what I was doing but I decided to find a "PDF to JPEG" converted and convert the PDF file. To my surprise, there were two JPEF outputs produced. The first one was just the PDF in JPEG form, and the other was a JPEG of the flag! How this works?... I have no idea.

Cryptography

Rotation

All I did was go to ROT13 and try to see which rotation produced a legible output. I believe it was ROT15. Bryan actually had a crack at this at the very beginning but for some reason, there was no flag when he decoded the ciphertext...

Executive Briefing Center

All I did was look at the source code and the flag was written in plain sight. Unfortunately, I couldn't solve Executive Briefing II...

Penpal

Okay, I didn't solve this one but I do know how to solve it. I just didn't have the tools required. As soon as I saw n, e and c, I instantly knew it was RSA. However, I was unable to find an online calculator capable of finding the primes used to produce n as it was a VERY large number. Alexpanaman solved this one as he found a RSA solver (which was created for CTFs LOL).

Miscellaneous

Pikachu

I can't believe I listened to the Youtube video linked and tried to find a match between the song and the given text file which was just a variety of "pi pika pikachu". Out of curiosity I just Googled "Pikachu decoder". To my surprise, there was such a thing as "Pikalang" and I was able to decode it just by pasting the ciphertext.

Reflection

Looking back, I realised that I didn't solve that many flags, considering the fact that we had around 8 hours to do them... I hope that there will be another CTF and that my friends will want to participate again so that we can come back better prepared and with better skills!

To sum up my day:

T: Did you have fun?

M: Yes

T: Are you sure about that? There was a lot of whinging involved.

The CTF was challenging, but I do not regret attending it.

SecSoc CTF

Participated (and still currently participating) in the SecSoc CTF with alexpanaman and tsoyuzhu. I'm not sure what I was expecting but I wasn't able to do much :( Will post our overall team rank at the end. Only one hour left to go!

Something Awesome: NOT AWESOME AT ALL

The proposal can be found here. It contains the marking criteria and the game plan.

What I've done so far

I'm not even going to include what I had planned for this week because these two features are driving me crazy. I didn't even bother to rotate the video agh.

Okay so I really did try implementing a vault lock system except IT'S NOT WORKING. It can detect when I've gone from max to not-max/min to not-max.. but it's not raising the flag properly or shifting the required input for some reason! Independently they work, but when I try putting it together... it doesn't work and I have no idea why.

In the video, you can see that I just spam the keypad and, not only does it break my piggy bank, but it also causes me to release more coins than I put in! Could there be an overflow somewhere? My poor board is probably working so hard to keep up with my demands.

At this rate, not only does my piggybank have weak security... But it's also able to magically conjure up coins when you break into it!

In the demonstration

Deposit some coins

Navigate to withdraw option

Input incorrect pin (Correct PIN starts with 5, but my PIN input ain't working either so it can only detect the correct pin based on the first number...)

Mash buttons because the potentiometer doesn't work

More coins than I input get released!

Trending Blogs

Recently Viewed Blogs

My Public Insecurities