:fwen:

Here, my Application.

Dear Max and the Gitzon Team,

I am writing to apply for the role of security engineer at your firm.

Please find attached a copy of my job application highlighting how my skills and experiences may fit your criteria.

Best,

Seok Hyun Jung z3459079

Analytical Skills

Research

I am able to acquire required security knowledge through my own research and through completion of module activities.

Class notes

Week 1

Week 2

Week 3

Week 4

Week 5

Week 6

Week 7

Module activities

How long does a computer last?

Stealing a penguin?

Lockpicking

Hashing

OWASP pt 1

OWASP pt 2

Explaining passwords

Threat trees

I supplement my study with reflective blog posts that draw on my personal experiences.

My first blog post on my motivations, expectations and initial thoughts on the course.

Week 1 reflection post

Week 3 blog post on my progress, enjoyment of and application of material, how I manage time.

Week 3 reflection post

Applying my skills in the workplace (no disclosure)

Using security in everyday life

Security Everywhere: I apply my new skills and knowledge in my everyday life and blog about it.

Movie theatres

T1 and T2 errors

Low probability and high impact

Public WiFi dangers

Home security cameras

Security Skills

I am able to understand and use cryptographic techniques based on our class material.

Week 4

Week 5

Week 6

I am able to understand and replicate a number of web security exploits.

Something Awesome project

Project proposal

Some research

Setting up my infrastructure

Frontend progress

Token, cookies, and authentication

XSS page and logic

CSRF page and logic

I have developed good research and analytical skills to facilitate my learning of security. I have developed a decent breadth of knowledge through my independent study of class modules and background research on key concepts and historical figures.

Hashing

OWASP pt 1

OWASP pt 2

Threat trees

I can lockpick :D

Community / Professionalism

I have made some meaningful contributions to the course environment.

I am able to collaborate with others effectively to share knowledge and to further my understanding.

In Analysis sessions

Week 2: Houdini

Week 3: Doors

Week 4: Secret

Week 7: Snoop

Security collab in the workplace

In the workplace

Something Awesome

I share a lot of knowledge about web security exploits and how they work.

Token, cookies, and authentication

XSS page and logic

CSRF page and logic

Lightning talk

Presentation on how DOS and DDOS attacks work and included a live demo.

DOS Lightning talk

I made a little bit of presence online via Open Learning

Time Management Skills

I did struggle from juggling full-time work with university study, but I am happy with what I gained from this course.

I strived to create high quality work under the time constraints that I had. I adapted to my lack of time to achieve as much I could

Post SA reflection I made a post SA reflection on how I think I did and the time management challenge I had.

I tried to plan ahead, but things weren't so easy

Week 3 blog post on my progress, enjoyment of and application of material, how I manage time.

Week 3 reflection post

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

My team's argument: Should be allowed to snoop MORE so government can take all our data

From our discussion we decided that we had two main arguments.

Improve infrastructure and public goods - help make our lives easier and more convenient. Facilitate economic growth.

Safety - protect us from threats.

Economy

Administrative processes become faster as a result of collected data. Government provided services then can be made extremely efficient.

Knowing where and when you travel will help improve transport. Increase parking spaces in the right areas. Make new roads to reduce traffic. Introduce new trains (like Metro) or new train stops (Green Square). Bus routes are best when backed by data.

Healthcare benefits from data too. We need to invest in research in the areas that are most critical / lethal. Hospital

Education improves from data. Students are the future of our economy. Invest in high performers by giving them scholarships. Provide assistance for low performers that we can help improve and make them productive members of the economy.

All of these ultimately are vital to the success of our economy and wellbeing.

Safety

Terrorism protection

- Suspicious activity would be able to be detected more quickly, protecting the safety of the public.

Crimes

- Increased surveillance would allow crimes to be easily detected and disciplined.

Disease

- Taking data can help prevent diseases by identifying and vaccinating people based on geography and demography.

World peace

- One nations collection of data can help fight crime and terrorism at an international level. Should we not do our duty as a world citizen to contribute to this?

Other side

Government can be dangerous. It's risky to trust the government with our data.

Since all our data is in the hands of the government/government agencies, there is a risk that, if there is a leak, a lot of our information would be leaked.

Risk as a cost outweighs benefits of safety. A turbulent or incompetent government can leak our data to those with bad intentions. Government themselves might have bad intentions, like some of them in history.

Will future governments also be responsible with our data? Once collected, data is not going away.

A racist government can use census data to cause genocide. I personally don't think this is a strong argument.

In my opinion we won the debate. I held my ground with some objections (shouting "Objection your honour!").

So how do locks work

Cylinder locks rely on a cylinder that turns one way to pull in the bolt (to open) and the other way by default to release the bolt (to lock).

One of the most common locks is the pin-and-tumbler lock which is a type of cylinder lock that is secured by some pins that prevent the cylinder from turning and opening the lock.

So imagine there are pairs of pins that are separated by a small gap, these pin pairs are sitting inside the cylinder. Above these pin pairs are springs that allow the pin pairs to be raised. When the correct key is inserted, the shape of the key blade will raise these pins to just the right level, where the gaps between the pin pairs will align (somewhat) perfectly with the edge of the cylinder (this is called the shear line). This will allow the cylinder to turn and the bolt to pull in, unlocking the door.

How do we pick it

There are lots of ways using a variety of tools but here are just a few.

Lock bumping - a special bump key is inserted (almost to the end) and we "bump" the key inwards while applying a slight rotation, and let physics do the rest.

Rake picks - Rattle and bounce the pins around with the pointy end of a rake pick until they pins reach the shear line.

Key forging / impressioning - Get a blank key and duplicate an existing legitimate key

I made a lot of great progress and got really enthusiastic about creating this educational platform / dev box for learning about Web security.

To that end I think I definitely achieved my goal. The website is quite nice, intuitive to use and has some good educational material.

Out of my 6 pages that I planned for, I created 5. These were:

XSS

CSRF

SQLi (or an equivalent noSQL injection attack)

DOS / DDOS

Path disclosure

For this technically I sit at a Distinction on my own marking criteria. But I worked really hard and I am proud of it!

A big challenge for this project was time-management.

I barely had time to go to class but I rushed out of work on Tuesdays and Wednesdays to make the 6pm and 5pm timeslots. I really enjoyed the analysis sessions in particular, it was always insightful and meaningful, leading to some really good (and often funny) discussions with the tutor and my classmates.

Keeping up 10 blogs a week was not something I aimed for.

I will be making a presentation of DOS and DDOS with a live demo on my project.

Here I will cover the basics of what DOS and DDOS are.

Vanilla DOS

Denial of Service (DOS) refers to any attack that prevents a web service from providing its intended service to its users and hence it covers a broad range of different attacks. Most commonly DOS attacks aim to either overload the server with meaningless requests to prevent other users from using the service, or to cause the service to quit, which would have the same user impact.

Distributed is a variation on DOS (DDOS) and the difference being that the requests come from multiple places. It is harder to detect and prevent as well since simple blacklisting does not work.

RUDY attacks

RUDY stands for (R U Dead Yet). It's a variant of DOS where you send legitimate POST requests based on a form present in the website. It declares extremely long Content Length via the header, and just fills it with garbage. The server doesn't know this is all garbage and processes the request as normal, little does it know that it is being used up on processing garbage.

This is a "slow-roll" variant of DOS and is really interesting. I may include it in my SA via some form that you can RUDY on.

Logic

The url exposed for DOS was /api/v1/transactions. This endpoint is entirely unthrottled and will shut down the server from a simple barrage of HTTP requests.

Simple JS or bash will do.

const http = require('http') const p = [] for (let i = 0; i < 20000; i++) { console.log('Performing operation', i) p.push( new Promise((resolve, reject) => http.get( 'http://MY_IP:MY_PORT', withHandler(resolve, reject) ) ) .then(() => console.log('Done')) ) } Promise.all(p) `

Team america destroys the whole town to find a few criminals which is the point of the story / movie clip

Diffie Hellman exchange

Each participant has their own secret, we can come up with shared secret while not sharing own secret but sharing the result of what happens when we use them in combination.

Start with common secret

Combine with own secret

Pass solution to other

Mix received solution with own secret

Get a piece of shit

This is done with numbers (rather than colours), public modulus and base and secret integer. - Raise base to power of secret integer - Mod it by public modulus, get result - Pass result to other and receive other's result - Raise other's result by own secret integer - Final result is the shared secret

Fun exercise: figure out discrete maths proof behind it

Diffie-Hellman has Perfect Forward Secrecy (PFS).

This is a style of encryption where temporary keys are exchanged between the two parties. Every sesion has a unique key and compromising one session key does not impact any other session.

Public Key Infrastructure (PKI)

To verify the public key is legitimately from the recipient. Digital certificate is issued by a trusted CA and contains the public key of the intended recipient.

PKI is not foolproof - CAs get paid to sign and issue certificate and often attackers have gained access to variations of legitimate sites of large corporations (e.g. Google).

CA acts as a single point of failure and they often make mistakes and the barrier to entry is not high. For website, can get certificate that's authorised by a certificate authority (CA) to verify that the website being rendered is indeed owned by who they claim to be rather than someone else.

Common CAs: Sectigo, Google, Digicert, Cloudflare Can self-sign certificates but that's a bit dodgy. You probably want 3rd party CA.

When you get hacked just get the CA to revoke the certificate.

Memory corruption

Cause changes in memory, causing program to behave differently to its original intent and instead behave in the way intended by the attacker.

Buffer overflow

Program writes to memory address on program call stack outside the intended fixed length buffer - overruns the buffer in order to write to adjacent memory locations.

Buffer overflow protection

Include a canary value in the stack frame. When this is destroyed then halt / alert / indicate buffer overflow and prevent memory corruption. This canary techique is easy to get around however - you can fill an array with the canary value and the prevention mechanism will not trigger.

Asset Protection

Identifying

List all assets that are worthwhile to protect. Have many people brainstorm the asset list, not just yourself. Never be sure that you've identified every significant asset. Take enough time to consider assets carefully.

Many important assets are intangible. Reputation and brand is a good example. Emotional and psychological health is another.

Prioritising

This is the harder part. Out of the range of important assets we need to assign values to them so that they can be compared and prioritised in ranking. Surveying a lot of people can help.

Every asset needs to be assigned some numeric / monetary value. How much money will we lose if this asset is compromised?

Bug bounties

Deal offered by websites where white-hat hackers receive rewards for reporting bugs - exploits, vulnerabilities and so forth. This puts a layer of testing before the general public finds out about vulnerabilities.

The process is as follows.

Find a program. There are heaps of BB clients and crowd source websites that list them (Bugcrowd etc.)

Review scope - websites have a criteria for what to touch and what they will accept as bugs. Wider scope is better, you will get more bugs to pawn.

Find target via recon. You need to look for things like recent software updates as well as previous issues that can hint at what might arise.

Hit and find vulnerability. Do your haxx.

Report to organisation.

Penetration testing

Hacking your own system to find and patch vulnerabilities before attackers find them. Super important, as mentioned in first week, best defence is created by thinking like an attacker.

The process

Recon - gather intel, find target

Plan - execution order and payloads

Exploit - execute exploit script and watch the magic happen

SA Progress: CSRF

Nothing too fancy here either but it relies on my broken authentication logic :)

This page uses the /transactions endpoint.

This is how the page works.

Users land on /csrf page

User submits a form indicating who the recipient is, the description and amount for the transaction.

Client sends POST Request on the /api/v1/transactions endpoint to create a transaction.

This makes two changes

Sender (user) has a negative transaction on that amount

Recipient has a positive transaction on that amounnt

The two share the description

This also deliberately exposes negative amounts (for the lols)

On a different page, a Table renders list of user's transactions and calculates the user's balance. I might use that page for NoSQLi or something since it will expose user input queries.

This is how the attack is exposed.

Users are authenticated via their username and password

Users receieve a nonce token.

This token is saved into the user's cookie.

Any requests for another 5 minutes does not require a new token.

SA Progress: XSS

I have built a pretty cool page for XSS. Here is the logic!

/xss page has a table of "posts" that render rows of the title, author and creation date of user posts.

Client sends HTTP GET request to server to retrieve a list of posts

This is exposed via the /api/v1/posts endpoint/

The endpoint requires authentication. User gets their temporary token when they login (explained in previous post here) and they pass it to the endpoint.

Client retrieves list of post objects.

Client renders them in the table

To create a post, there is a Text Editor at the bottom of the page (allows title and author input).

Client sends HTTP POST request to the server with the post body containing title, author and creation date

Same authentication and endpoint as above.

The text editor supports HTML and does not sanitize it.

Users can create exploits on it as people who click into a row will render whatever was posted.

Super contrived, I know. But it illustrates the point. I will definitely revise the logic if this website goes live - the posts need to stay within someone's sandbox environment so real world users do not get pwned lol.

Disclaimer: the following is not intended to represent any real company or reveal private information. Just take it as hypotheticals. I am imaginitive.

Security practices and AWS IAM

In the past, our developers had full administrative access as we have a small startup team.

I pitched a new model to our team for better security and development lifecycle. As code gets reviewed and gets past CI, our service account handles deployment rather than manually from an administrative account.

For the most part I intended to have git for security and quality control but sometimes people do need to upload things directly like assets.

The service account also exposes various admin tasks via a CLI. This exposes deployment and code change at the level of access that employees have. Writing up to higher levels (stage or prod rather than sandbox) via CLI requires approval from two additional staff.

This also made it easier to provide the least amount of access necessary to contractors and external agencies. It would be the same interface with permissions only to relevant write ups, otherwise go through git.

No more god mode.

Web application security

We write a lot of React and vanilla for our frontend projects and while there wasn't much luck for XSS or path traversal, CSRF and DDOS were certainly possible attacks on our network. In fact we had noticed a few dodgy requests attempting path traversal on our network logs but this didn't raise much concern.

A threat tree is a model for analysing potential attacks. Each node represents how its parent node is obtained.

Threats usually and eventually become divided into either internal or external threats.

Internal / insider attacks are more difficult to prevent because trusted parties within the company often have unobstructed access.

The Belle Lapadua model may help as it prevents "write down" but with enough insiders, no company is fully secure.

Other measures against insiders include:

Having employees know and monitor each other's fulfilment of duties

Thorough and consistent background checks

External attacks are often preventable via sufficient training of staff. Provided that the system's software is fairly secure (enough to not be worthwhile via brute force), social engineering is usually the mode of attack.

AES (Advanced Encryption Standard)

The successor to DES (Data Encryption Standard) and current standard adopted by the US government and many others worldwide.

Three size variants: 128 (10 encryption rounds), 192 (12 rounds), 256 bit (14 rounds). Speed decreases but security increases from an increment in size (although 128 bit is already considered secure)

There is a general key shared between sender and recipient and round keys are derived from it.

In each round, each plaintext block is divided into sub blocks. Sub blocks are combined with the round key.

Sub blocks then either go through a subsitution (S box) or permutation process (P box). We refer to this as a substituion-permutation network.

S boxes will perform a substitution cipher. P box will shift and distribute bits to be used as input for next round of S boxes.

Confusion principle

Each bit in the ciphertext depends on many different parts of the key so their relationship is not clear. Difficult to get the key even if many ciphertexts are produced via the same key. Analysing ciphertext does not easily allow one to guess the key.

Diffusion principle

A single bit change in plain or cipher text will change half of the bits in the other.

Confusion + diffusion => makes cryptanalysis impossibly difficult (research by good old Claude Shannon)

AES satisfies both.

Block ciphers

A cipher that can only encrypt a block of limited size. Plaintext is divided into blocks first before encryption. The final block often requires padding (dataless) to match the block size.

ECB - Electronic Code Book

Each block is encrypted or decrypted separately using a key. ECB is deterministic. Not recommended.

CBC - Cipher Block Chaining

Plaintext blocked XORed with previous block. First block is XORed with IV.

Each block depends on previous result so encryption is asynchronous (a bad thing I guess)

CTR - Counter Mode

Pseudo stream cipher using block cipher.

Each plaintext block XORed with combination of key, nonce and counter. Counter incremented at every block.

Dear Grandma,

I am so touched and grateful that you always think of me so much, using my birthday as your password for everything on the internet.

But the internet is a dangerous place. A lot of people know my birthday too because you can find it on Facebook.

More than that, a lot of longer passwords are still really easy for bad people to steal.

These bad guys have entire dictionaries of passwords that look like yours or anything that would be easy to remember.

They can also guess and check a billion passwords every second and if you don't change yours to a really long and random password then it will be stolen within seconds.

You know, you can check how easy your passwords are on this website! `https://www.grc.com/haystack.htm`

I know it's a pain to remember completely random and long passwords so I've bought you something.

It's a USB fingerprint reader that will reveal your long passwords when you put your finger on it.

This isn't the best way, but it's a better way. Hope you like it - please keep it safe.

Best

I promised my SA as an example so here it is.

So, quick progress update:

I've added a really simple authentication system, along with session-saving logic, and an API endpoint for creating transactions.

Now my current authentication is TERRIBLE but it does, in its contrived way, illustrate the point.

Imagine we login with my dodgy login page.

And now look go in your devtools and check the cookies.

I've put in this logic to perform on the server when a user is authenticated.

Check for the username and password against the database collection /users

If the entry matches a DB collection, send a response code 200 along with a token (a pseudo-random number)

This token when received by the client is stored in their browser cookie.

This allows user to stay logged in after they close the site.

Other websites with better security will still have a similar logic for having users STAY authenticated. The token is usually temporary (as is mine), but it leaves a pretty good chance for CSRF attackers to exploit you.

Now imagine I open an email. This email might link me to a different page, since a lot of email clients no longer support javascript execution like they used to.

That link could look like anything though, like a nice MAKE ME RICH button...

Then the underlying url might look something like

philswebsite.com/api/v1/make-transaction?to=philjung&amount=90000000

I have already conducted a fair amount of research into a bunch of these web security flaws, but I'll go into some detail about CSRF because I think it's a pretty cool one.

Chosen vulnerability: Broken Authentication

I think this is also known as CSRF, Cross site request forgery, or SEA SURF :D

From my previous notes: what is that damn SeaSurf thing?

Attack gets executed on a web-application via the victim's authenticated use of the application while not knowing nor intending to authorise the actions.

Attacks are generally state-changing requests rather than having data returned to the attacker - the intent is not to steal data but to cause the victim to run an unintended action on their own. An example could be to getting someone to transfer funds out of their bank account to the attacker's, the victim may click a link to perform this action without the knowledge of its effect.

What does this typically look like?

I think the easiest way would be to use a phishing email of some sort really. This will require a little bit of social engineering to make it look legit.

Direct your victim to a fake replica website where they fill out a form, OR Since you already know what your API request will look like you could just straight up run some javascript that will perform the request.

As long as they have some nice session cookies you could run the exploit with very little effort on the victim's part.

Note: "Requires Wi-Fi connection"

Reference: https://www.jbhifi.com.au/ring/ring-video-doorbell-2/911444/

I think these IoT devices have become quite popular these days, just wondering how secure these things are.

As it is connected to your network, if an attacker can manage to get on the network it seems quite easy to create a replay attack!

Indeed, when I googled this there were some juicy results...

https://www.digitaltrends.com/home/ring-video-doorbell-security-flaw-hack/

Could inject some old footage, or straight up just open the door probably. I must find the time to try this (If I can be bothered buying one).

I suppose at the end of the day, there are a lot of exploits you could run if you've gained access to someone else's network.

So I decided to call my website "HackerBank", like a rip off of HackerRank and because I think something like a fake Banking web application will serve as a nice example lol

Backend is pretty much ready to go, I'll revise the logic later but I have already documented the general requirements. The following collections are necessary

/users

For general authentication. I want users to be logged in and their session data stored. This will help expose the CSRF vulnerability.

/posts

For XSS, I want users to post any HTML content into this posts collection. This will expose the stored XSS vulernability.

/transactions

I suppose they will need something to hack / manipulate other than you know, shutting down the database or something like that. In real life there are data documents that associate with some kind of value.

Users won't really need a balance or anything for the moment - they will have the sum of their transactions LOL

I have my docker container running with Mongo image. Have set up the following schemas.

user = Schema({ username: { type: String, required: true }, password: { type: String, required: true }, token: { type: Number } })

post = Schema({ title: { type: String, required: true }, content: { type: String, required: true }, author: { type: String, required: true }, uploadDate: { type: Date, required: true } })

transaction = Schema({ timestamp: { type: Date, required: true }, value: { type: Number, required: true }, description: { type: String, required: true }, user: { type: String, required: true } })

I've exposed a simple CRUD interface based on these schemas - you can make GET, POST, PATCH and DELETE requests under the HTTP protocol. When I think about releasing a live version (non-development environment) I will support HTTPS but there will be A LOT of work before that.

For frontend:

I bootstrapped my project with Gatsby, it's definitely overkill for the moment but in the future I would really prefer to have SSR and run some data logic with GraphQL.

Here is my sick first landing page