quinta-feira, 23 de junho de 2016

Exploiting SQL Injection by Bypassing WAF (Mod_Security)

Since years, SQL Injections have been the most dreadful and frightening of all vulnerabilities discovered till date. The power of a single quote (') is beyond comparison. SQL injection attacks were first discovered in 1998, with one of the first live attacks taking place in 2002 on the fashion retailer Guess and the rest is History. Billions of Dollars and reputations have been lost. In spite of implementing multiple forms of fixes, it’s a never ending war between developers and hackers. If the former comes up with a way to prevent it, the latter comes up with a way to bypass it.
The blog focuses on providing in-depth insights into the discussion of the techniques used to bypass one of such prevention methods. This blog will not help you to learn the basics of SQL Injection; so I would recommend you to go through OWASP before even thinking about jumping into advanced techniques. This blog is more focused on bypassing Mod_Security (Web Application Firewall) and eventually exploiting SQL Injection vulnerability. 
The Attack:
First and foremost, we need to find our target website. In this case I am using:

Looks perfect! Right? Now let's try to insert a single quote at the end of the URL and observe what happens:

Hmmm!! Different response!
The page appears but no data. So something did happen but still we don’t have a confirmation whether SQL Injection exists or not. Let's modify our query a bit to see how the application responds.
http://targetsite.com/demo/exams.php?sort=8' or 1=1--

Normally in a vulnerable website the above query would return values from the entire table since the Boolean condition is always true. Let's see how this website responds:

It seems like our target website has a WAF implemented to prevent itself from being targeted. So, if I am not wrong, any attacks directed towards the database will be blocked by Mod_Security.
Well in some cases, it is possible to block such attacks if you have the implementation done correctly with an up-to-date version of WAF being used and regular update of security patches being rolled out.
But then again, aren't we hackers? We don't give up, do we? Let's try to get around it. Sounds intriguing? Let's play.
First we need to make some queries work just to be sure that SQL Injection indeed exists.
Finding the Number of Columns:
Till now I would say that we are kinda hacking in the dark. No real MySQL errors which actually proved the presence of SQL Injection. The only success we had was when we used a single quote in the above mentioned URL and received a blank page in response…no rows…no data. This can however mean that we somehow managed to change the structure of the underlying query and the page might be vulnerable to SQL Injection. Let's try and get some confirmation.
Finding the number of columns present in the current database might actually prove its presence. This can be achieved by using a simple "ORDER BY" clause.
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 1-- 

No Error! Expected Response! Cool…there's Hope after all….
Let's proceed further…
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 2--           No Error
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 3--           No Error
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 4--           No Error
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 5--           No Error
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 6--           No Error
http://targetsite.com/demo/exams.php?sort=8 ORDER BY 7--           No Error but a Blank Page

As seen above, ORDER BY 7-- query generated a different response thereby proving the existence of 6 columns in the current database. We were lucky though since the WAF did not block the 'ORDER' keyword. We need that sometimes!
However, since now we know the number of columns in use; let’s see which columns get displayed in the response.

OOPS! Mod_Security again!
So I guess the filter has been set on 'UNION' and 'SELECT' keywords. So now it's time to actually bypass the WAF (since we've had enough of it) by modifying the query and force the backend database to exfiltrate data as we desire.
Bypassing WAF:
Let's try the modified query below:

It seems like the 3rd, 4th and 6th columns are being displayed. Now we can use SQL Injection to extract data and display them on the above displayed columns
Let's extract our first GOLDEN PRIZED data by finding out the MySQL version and the current database user.
http://targetsite.com/demo/exams.php?sort=8+/*!50000union*/+/*!50000select*/+1,2, current_user(),@@version,5,6--+

Extracting Data from Database:
Since we know it’s a MYSQL database, we also know that there are some globally defined database tables, columns and schema. The names and hierarchies are as follows:
·         information_schema - name of the meta-database in MYSQL which has the following table
Ø columns - is the table name in the information_schema which in turn has the following columns inside
ü       table_name - all tables in all databases
ü       column_name - all columns in all the tables of all the databases
ü       table_schema - all databases in server
Now let’s use this to get some data.

Anything interesting? 'users' table seems to be interesting!
Let's query it further to see what kind of columns it has.

I guess we reached the 'orgasmic' point where the next step could lead you to a complete different level. Imagine having a list of all the usernames and passwords at your disposal and especially if you have the ADMIN creds. Well I am not saying anything but you are intelligent enough to make use of it. So ready for your final attempt? Here we GO

The data that I am most interested in is:
Looks like a SHA-1 Hash which finally resolves to 'pass' once reversed. So the final value:

Username: admin
Password: pass

Do I need to tell you what to do next!! Just go find the GOD DAMN admin console and do whatever you wanna do. My Job here is done. See you again. Till then
Hasta la vista

segunda-feira, 23 de maio de 2016

Secret Life of Hashes Divulged – Length Extension Attack Explained

Sounds interesting!! Doesn’t it? Well, it sounds to me and so I want it penned down. Let’s see how this goes.
If you feel you’ve nailed it after reading through the entire blog, then I can consider diving deep into the blogging world. It’s my second post within 24 hours and I already feel I was born for it. Let’s not bore you guys with my shit, and learn something about a new form of cryptographic attack called the Hash Length Extension Attack, instead.
It all started when I was at Goa in India (an exotic place to be in for sure) a year ago for the null conference. I know, when I say Goa, the only thought that comes to your mind is the beaches – pristine blue with golden sand and perhaps a bottle of Goa’s favorite chilled beer “Kings”.  The thought of not attending the conference crossed my mind, but then my Boss gave me an intensive look and there I was, (‘Coz my employer paid for the trip). I already knew that I was going to hate it but things changed at the blink of an eye the moment I entered the conference. One of the trainings at this conference was about an attack called a Hash Length Extension Attack. This was the first time I've heard it and it kept me on my toes for the entire session.
Half way down the session, I realized that the attack is not only super awesomely cool, but also conceptually easy to understand and perform. To make your job much easier, there are various modules available over the internet such as HashPump and hash_extender. There’s another module which I like personally, is the one from Stephen Bradshaw called hlextend. This module can be found at GitHub.
As per Wikipedia, the basic definition of this attack goes by:
In cryptography and computer security, a length extension attack is a type of attack where an attacker can use Hash (message1) and the length of message1 to calculate Hash (message1 message2). This attack can be used to sign a message when a Merkle–Damgard based hash is misused as a message authentication code, allowing for inclusion of extra information.
This attack can be done on hashes with construction H (secret message) when message and the length of secret is known. Algorithms like MD5, SHA-1, and SHA-256 that are based on the Merkle–Damgard construction are susceptible to this kind of attack.”
Before we begin, a quick go-through on how Hashing works:
·         Hash functions operate on fixed block sizes
·         Input data is split into fix-sized parts equal to the block size
·         If any of these parts is smaller than block size (mostly the last part), the missing bytes are padded
ü       PKCS7
ü       Bit Padding
·         The hash value represents the internal state of the hash function
ü       You can simply continue adding data + padding and hash again using the internal state
The Attack:
Let’s assume a web application which uses a known hash generated from an unknown secret value tied to a user entered input. The basic purpose of doing so is to check the integrity of the entered value to avoid any form of manipulation. For example, let’s assume the desired SHA1 hash value generated with an unknown secret length for a valid parameter value ‘student’ is ‘204036A1EF6E7360E536300EA78C6AEB4A9333DD’. So, if we try to access the below mentioned URL, we get all the details of a student.

Cool! I guess that’s what the application was supposed to do. It’s a valid request after all. Let’s see what happens if we try to play with the ‘param’ value. Let’s try to access the ‘/etc/passwd/’ file using path traversal. What do you think will happen?

Oops!! File not found.
Of course! And did you think it was that easy? So what do you think happened? 
Well, the requested file did not match the above SHA1 hash value since it belonged to ‘student’. In order to perform this attack successfully, we would need a valid SHA1 hash value for the ‘/../../../../etc/passwd’ file, combined with an unknown length of the secret value.
And how do you think we get that? Well, the first thing we need to do is to guess the length of the secret value. Without which it won’t be possible to generate a valid hash. In such cases, brute forcing the value by trying multiple different lengths can sometimes be possible, depending on the application.
Let’s first see what all data we already have that might come in handy:
Known Data: student
Hash of known Data: 204036A1EF6E7360E536300EA78C6AEB4A9333DD
Extended Data: /../../../../etc/passwd
Hash of Extended Data: <unknown>
Length of secret: <unknown>
If I have to explain it in simple words, the application creates a sha1 hash value of '204036A1EF6E7360E536300EA78C6AEB4A9333DD', by concatenating an unknown secret of length ‘X’ and known data of 'student'. You wish to append the text '/../../../../etc/passwd' after 'student' and also provide a valid hash back to the application that it will produce when it concatenates your provided value (which will include the string 'student' followed by '/../../../../etc/passwd') with its secret.
I hope by now you already know what our ultimate goal is. Ready for some action!!! Here we go……
The goal is to read the /etc/passwd file, via bypassing the hash integrity check on the param parameter. This is what the script below will automate using the hlextend module to generate the extended hash values.
And the output:

Once we access the above displayed URL:

You may notice that the new value produced above contains a lot of additional data (in this case, a 0x80 followed by a number of 0x00s and a message length, which is the length of the key plus the original message, appended at the end) between the 'student' and the '/../../../../etc/passwd' - this is hex encoded padding data used by the hash algorithm that needs to be integrated into the hashed data in order for the attack to work - So strictly speaking you can't specify the EXACT value to append, only what comes after the padding, but under the right circumstances you can make the application ignore this extra padding.
So in short, if the hash algorithm used is vulnerable, it is possible to achieve this without knowing the secret value as long as you know (or can guess, perhaps by brute force) the length of that secret value. This is called a hash length extension attack.

Happy Hacking my Friends!!!