In this post, I am going to talk about a tool I came across while trying to crack a pre-MySQL 4.1 password hash. As my goto hash cracker did not support this type of depreciated hash, I had to look for other methods of doing this and I came across the MySQL323 password cracker/collider located here
I found this tool to be just what I was looking for so I downloaded it and ran it. It is very easy to use and the flags for the command are very straight forward.
"mysql323 32.exe" [number of threads] [hash] [keyspace-file]
Once the program finished it gave me these statistics
Total time: 455.626 seconds (7.5 mins)
Average speed: 10.96 Tp/s
Very fast! And yes, the tp/s does stand for trillion passwords per second. The machine I ran this on has an i7 processor with 8 gigs of memory.
This will definitely be my new goto tool for these specific types of MySQL hashes.
Tuesday, January 17, 2012
Friday, January 13, 2012
Attacking Hackademic RTB1
As I am always looking for new machines that are vulnerable by design, Boot to Root, whatever you want to call them, I came across one called Hackademic Boot to Root 1 located here : https://ghostinthelab.wordpress.com/2011/09/06/hackademic-rtb1-root-this-box/
Once I set it up as a VM, booted it, and fired up Backtrack 5 I began to poke around on this machine to see what I could find out about it. First I started with a basic netdiscover which yielded its IP at 192.168.2.104. Next I went on to scan it with nmap.
nmap -sV -p 1-65535 -v 192.168.2.104
After this scan finished, it reported a closed port 22 and an open port 80 running apache. Lets browse to the site to see what we can find out.
After a little clicking around we find out that this site is a Wordpress 1.5.11 installation. After playing with all the links and parameters I could find, we definitely have a sql error message thrown in the ?cat=1' parameter.
Now lets try to inject commands to get database output to the screen and see what the database will tell us using methods I discussed in previous posts here
/*Sidenote: If you are using Backtrack 5 and firefox, you will need to disable No-Script in the firefox browser. It will not allow you to type in the special characters to do other sql injection enumeration of the database.*/
Bingo! We were successfully able to get the database output to display on the page. Now lets mine the database for as many usernames and hashes as we can. Since we know this is a Wordpress installation, a little recon from our friend google will tell us the default table and field names so if the user has not changed the defaults it will make our job much easier.
Now that we have all the usernames and hashes from the Wordpress table, lets crack them so that we can log into the application. There are many password cracking tools, but since I have a new found love for hashcat and OCLhashcat I will use that to do the cracking. OCLhashcat utilizes your GPU for pretty much the fastest password cracking I have ever seen. With my new HD 6770 this should take no time at all :).
As you can see, I was able to recover ALL the hashes in about 3 seconds. OCLhashcat really is an amazing tool.
So now for our newly owned users we have this:
GeorgeMiller:q1w2e3
MaxBucky:kernel
TonyBlack:napoleon
JohnSmith:PUPPIES
JasonKonners:maxwell
NickJames:admin
Now what can we learn from this attack:
Mistake #1: Obviously the user had an unpatched version of Wordpress (1.5.11) that allowed for the initial sql injection.
Mistake #2: The user left the Wordpress tables inside the MySql database at their default configuration. These table names are easy to find on the internet. Changing them probably would not have stopped the attacker, but would have atleast made his job a little tougher.
Mistake #3: These users DEFINITELY did not have a good password policy implemented. The administrator (NickJames) had a password of 'admin' which is awfully easy to guess. Using longer password lengths, such as 13 characters, as well as using special characters and passwords that are not english words would have made this password attack harder to do.
In the next post I will try to get underlying access to the operating system of this machine.
Once I set it up as a VM, booted it, and fired up Backtrack 5 I began to poke around on this machine to see what I could find out about it. First I started with a basic netdiscover which yielded its IP at 192.168.2.104. Next I went on to scan it with nmap.
nmap -sV -p 1-65535 -v 192.168.2.104
After this scan finished, it reported a closed port 22 and an open port 80 running apache. Lets browse to the site to see what we can find out.
After a little clicking around we find out that this site is a Wordpress 1.5.11 installation. After playing with all the links and parameters I could find, we definitely have a sql error message thrown in the ?cat=1' parameter.
Now lets try to inject commands to get database output to the screen and see what the database will tell us using methods I discussed in previous posts here
/*Sidenote: If you are using Backtrack 5 and firefox, you will need to disable No-Script in the firefox browser. It will not allow you to type in the special characters to do other sql injection enumeration of the database.*/
Bingo! We were successfully able to get the database output to display on the page. Now lets mine the database for as many usernames and hashes as we can. Since we know this is a Wordpress installation, a little recon from our friend google will tell us the default table and field names so if the user has not changed the defaults it will make our job much easier.
Now that we have all the usernames and hashes from the Wordpress table, lets crack them so that we can log into the application. There are many password cracking tools, but since I have a new found love for hashcat and OCLhashcat I will use that to do the cracking. OCLhashcat utilizes your GPU for pretty much the fastest password cracking I have ever seen. With my new HD 6770 this should take no time at all :).
As you can see, I was able to recover ALL the hashes in about 3 seconds. OCLhashcat really is an amazing tool.
So now for our newly owned users we have this:
GeorgeMiller:q1w2e3
MaxBucky:kernel
TonyBlack:napoleon
JohnSmith:PUPPIES
JasonKonners:maxwell
NickJames:admin
Now what can we learn from this attack:
Mistake #1: Obviously the user had an unpatched version of Wordpress (1.5.11) that allowed for the initial sql injection.
Mistake #2: The user left the Wordpress tables inside the MySql database at their default configuration. These table names are easy to find on the internet. Changing them probably would not have stopped the attacker, but would have atleast made his job a little tougher.
Mistake #3: These users DEFINITELY did not have a good password policy implemented. The administrator (NickJames) had a password of 'admin' which is awfully easy to guess. Using longer password lengths, such as 13 characters, as well as using special characters and passwords that are not english words would have made this password attack harder to do.
In the next post I will try to get underlying access to the operating system of this machine.
Wednesday, December 14, 2011
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.
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.
Subscribe to:
Posts (Atom)