Saturday, January 21, 2012

This post will be about stealing data from a database one bit at a time. Most of the time pulling data from a database a bit at a time would not be ideal or desirable, but in certain cases it will work just fine. For instance when dealing with a blind time based sql injection. To bring anyone who is not aware of what a "blind time based" sql injection is up to speed - this is a condition where it is possible to inject into a sql statement that is executed by the database, but the application gives no indication about the result of the query. This is normally exploited by injecting boolean statements into a query and making the database pause for a determined about of time before returning a response. Think of it as playing a game "guess who" with the database.

Now that we have the basic idea out of the way we can move onto how this is normally done and then onto the target of this post. Normally a sensitive item in the database is targeted, such as a username and password. Once we know where this item lives in the database we would first determine the length of the item, so for example an administrator's username. All examples below are being executed on an mysql database hosting a Joomla install. Since the example database is a Joomla web application database, we would want to execute a query like the following on the database:

We would keep incrementing the number we compare the length of the username to until the database paused (benchmark function hit). In this case it would be 5 requests until our statement was true and the benchmark was hit.

Now in the instance of the password, the field is 65 characters long, so it would require 65 requests to discover the length of the password using this same technique. This is where we get to the topic of the post, we can actually determine the length of any field in only 8 requests (up to 255). By querying the value bit by bit we can determine if a bit is set or not by using a boolean statement again. We will use the following to test each bit of our value:

Start with checking the most significant bit and continue to the least significant bit, value is '65':

value & 128 0100000110000000-----------00000000

value & 640100000101000000-----------01000000

value & 320100000100100000-----------00000000

value & 160100000100010000--------00000000

value & 80100000100001000--------00000000

value & 40100000100000100-----------00000000

value & 20100000100000010-----------00000000

value & 10100000100000001-----------00000001

The items that have been highlighted in red identify where we would have a bit set (1), this is also the what we will use to satisfy our boolean statement to identify a 'true' statement. The following example shows the previous example being executed on the database, we identify set bits by running a benchmark to make the database pause:

As you can see, whenever we satisfy the boolean statement we get a delay in our response, we can mark that bit as being set (1) and all others as being unset (0). This gives us 01000001 or 65. Now that we have figured out how long our target value is we can move onto extracting its value from the database. Normally this is done using a substring function to move through the value character by character. At each offset we would test its value against a list of characters until our boolean statement was satisfied, indicating we have found the correct character. Example of this:

select if(substring(password,1,1)='a',benchmark(50000000,md5('cc')),0) as query from jos_users;

This works but depending on how your character set that you are searching with is setup can effect how many requests it will take to find a character, especially when considering case sensitive values. Consider the following password hash:

da798ac6e482b14021625d3fad853337skxuqNW1GkeWWldHw6j1bFDHR4Av5SfL

If you searched for this string a character at a time using the following character scheme [0-9A-Za-z] it would take about 1400 requests. If we apply our previous method of extracting a bit at a time we will only make 520 requests (65*8). The following example shows the extraction of the first character in this password:

Again I have highlighted the requests where the bit was set in red. According to these queries the value is 01100100 (100) which is equal to 'd'. The offset of the substring would be incremented and the next character would be found until we reached the length of the value that we found earlier.

Now that the brief lesson is over we can move on to actually exploiting something using this technique. Our target is Virtuemart. Virtuemart is a free shopping cart module for the Joomla platform. Awhile back I had found an unauthenticated sql injection vulnerability in version 1.1.7a. This issue was fixed promptly by the vendor (...I was amazed) in version 1.1.8. The offending code was located in "$JOOMLA/administrator/components/com_virtuemart/notify.php" :

Tuesday, January 10, 2012

Now that we got that out of the way... I have been seeing posts on sites with people having fun with embedded systems/devices and I was feeling left out. I didn't really want to go out and buy a device so I looked at what was laying around.

First order of business was to update the camera with the most recent firmware:

Device info page confirming firmware version

Now that the device was using the same version of firmware as I was going to dive into, lets get to work. I will be using binwalk to fingerprint file headers that exist inside the firmware file. Binwalk can be downloaded from the following url: http://code.google.com/p/binwalk/

There is all sorts of interesting stuff in the "/server" directory but we are going to zero in on a specific directory "/server/cgi-bin/anony/"

#cd server/cgi-bin/anony/#lsjpgview.htm mjpeg.cgi mjpg.cgi view2.cgi

The "cgi-bin" directory is mapped to the root directory of http server of the camera, knowing this we can make a request to http://192.168.1.17/anony/mjpg.cgi and surprisingly we get a live stream from the camera.

video stream. giving no fucks.

Now at first I am thinking, well the directory is named "anony" that means anonymous so this must be something that is enabled in the settings that we can disable.... Looking at the configuration screen you can see where users can be configured to access the camera. The following screen shows the users I have configured (user, guest)

Users configured with passwords.

Still after setting up users with passwords the camera is more than happy to let me view its video stream by making our previous request. There does not appear to be a way to disable access to the video stream, I can't really believe this is something that is intended by the manufacturer. Lets see who is out there :)

Because the web server requires authentication to access it (normally) we can use this information to fingerprint the camera easily. We can use the realm of 'netcam' to conduct our searches

HTTP Auth with 'netcam' realm

Hopping on over to Shodan (http://www.shodanhq.com) we can search for 'netcam' and see if there is anyone out there for us to watch

9,500 results

If we check a few we can see this is limited to only those results with the realm of 'netcam' and not 'Netcam'

This python script requires the shodan api libs http://docs.shodanhq.com/ and an API key. It will crawl the shodan results and check if the device is vulnerable and log it. The only caveat here is that the shodan api.py file needs to be edited to allow for including result page offsets. I have highlighted the required changes below.

Monday, January 9, 2012

Awhile back when doing a pentest I ran into an interesting web application on a server that was acting as a gateway into a juicy environment *cough*pci*cough*, the application was “Ganglia Monitoring System” http://ganglia.sourceforge.net

The scope of the test was extremely limited and it wasn't looking good....the host that was in scope had a ton of little stuff but nothing that looked like it would give me a solid foothold into the target network. After spending some time looking for obvious ways into the system I figured it would be worth looking at the Ganglia application, especially since I could find no public exploits for the app in the usual places....

First step was to build a lab up on a VM (ubuntu)

apt-get install ganglia-webfrontend

After apt was done doing its thing I went ahead and started poking around in the web front end files (/usr/share/ganglia-webfrontend). I looked to see if the application had any sort of admin functionality that I could abuse or some sort of insecure direct object reference issues. Nothing looked good. I moved on to auditing the php.

Started out with a simple grep looking for php includes that used a variable....bingo.

We can see here that our $graph value is inserted into the target string $graph_file with a directory on the front and a php extension on the end. The script then checks to make sure it can read the file that has been specified and finally includes it, looks good to me :).

The start of our string is defined in conf.php as "$graphdir='./graph.d'", this poses no issue as we can traverse back to the root of the file system using "../../../../../../../../". The part that does pose some annoyance is that our target file must end with ".php". So on my lab box I put a php file (phpinfo) in "/tmp" and tried including it...

Going back to the real environment with this it was possible to leverage this seemingly limited vulnerability by putting a file (php shell) on the nfs server that was being used by the target server, this information was gathered from a seemingly low vuln - "public" snmp string. Once the file was placed on nfs it was only a matter of making the include call. All in a hard days work.

I have also briefly looked at the latest version of the Ganglia web front end code and it appears that this vuln still exists (graph.php)