Obfuscate SQL Fuzzing for fun and profit

Introduction

Now days cyber criminals are increasingly using automated SQL injection attacks powered by botnets to hit vulnerable systems. SQL injection attacks is the prevalent way of attacking front-end Web applications and back-end databases to compromise data confidentiality. Recently published reports by the Web Hacking Incidents Database (WHID) shows SQL injections as the top attack vector, making up 19 percent of all security breaches examined by WHID.  Open Web Application Security Project (OWASP) top 10 risk categorization chart, rates SQL injection risk as number one threat along with operating system command injection and LDAP injection attack.

But why does this happen? Have you ever thought about it? Well the answer is easy, we're seeing such an increase in SQL injection incidents because we have an "industrialization of hacking". SQL injection attacks are generally carried out by typing malformed "SQL commands into front-end Web application input boxes" that are tied to database accounts in order to trick the database into offering more access to information than the developer intended. Part of the reason for such a huge rise in SQL injection attacks is that the last years criminals are increasingly using automated and manual SQL injection attacks powered by botnets  or professional hackers to hit vulnerable systems. They use the attacks to both steal information from databases and to inject malicious code into these databases as a means to perpetrate further attacks.

Why SQL injection attacks still exist

SQL injection attacks happen because of badly implemented Web Application filters, meaning that the web application will often fail to properly sanitize malicious user input.  You can usually find this type of badly implemented SQL injection filters in outsourced web applications to India, Asia or other possibly third world countries, that developers are not aware of what SQL injection proper filtering is. Most of the time well known large organizations from the financial sector will create a large team of functional and security testers and then outsource the project in order to reduce the development cost, at the same time they would try to maintain and increase the control of the web application development progress and quality assurance process. Unfortunately this is not easy to happen or even possible due to bad management procedures or lack of security awareness from the side of the developers. The main mistake the developers do is that they are looking for a quick fix, for example they might think that placing a Web Application Firewall (WAF) in-front of a web application and apply black list filtering will solve the problem.

That is wrong because SQL injection attacks can be obfuscated and relatively easy bypass these quick fixes. Obfuscating SQL injections attacks nowadays is a de facto standard for penetration testing and has been used by well known web malware such as ASPRox. The Asprox botnet (Discovered around 2008), also known by its aliases Badsrc and Aseljo, is a botnet mostly involved in phishing scams and performing SQL Injections into websites in order to spread Malware. Since its discovery in 2008 the Asprox botnet has been involved in multiple high-profile attacks on various websites in order to spread malware. The botnet itself consists of roughly 15,000 infected computers as of May, 2008 although the size of the botnet itself is highly variable as the controllers of the botnet have been known to deliberately shrink (and later regrow) their botnet in order to prevent more aggressive countermeasures from the IT Community. ASPRox used extensively automated obfuscated SQL injection attacks, in order to better understand what SQL obfuscation means, within the context of computer security, you should consider obfuscated SQL injection attacks as a similar technique to virus polymorphism.

Why obfuscate SQL injection

This article is going to talk about Obfuscated SQL Injection Fuzzing. Nowadays all high profile sites found in financial and telecommunication sector use filters to filter out all types of vulnerabilities such as SQL, XSS, XXE, Http Header Injection e.t.c. In this particular article we are going to talk only about Obfuscated SQL Fuzzing Injection attacks.

First of all what obfuscate means based on the Dictionary.com:

"Definition of obfuscate: verb (used with object), ob·fus·cat·ed, ob·fus·cat·ing.

1. To confuse, bewilder, or stupefy.
2. To make obscure or unclear: to obfuscate a problem with extraneous information.
3. To darken."

Web applications frequently employ input filters that are designed to defend against common attacks, including SQL injection. These filters may exist within the application's own code, in the form of custom input validation, or may be implemented outside the application, in the form of Web application firewalls (WAF's) or intrusion prevention systems (IPS's). Usually this types of filters are called virtual patches. After you read this article should be able to understand that virtual patching is not going to protect you from advanced attackers.

Common types of SQL filters

In the context of SQL injection attacks, the most interesting filters you are likely to encounter are those which attempt to block any input containing one or more of the following:

1. SQL keywords, such as SELECT, AND, INSERT 
2. Specific individual characters, such as quotation marks or hyphens 
3. White-spaces 

You may also encounter filters which, rather than blocking input containing the items in the preceding list, attempt to modify the input to make it safe, either by encoding or escaping problematic characters or by stripping the offending items from the input and processing what is left in a normal way, which by the way is not logical because if someone would want to harm your Web Application what for you would want to process his malicious input.

Often, the application code that these filters protect is vulnerable to SQL injection (because incompetent, ignorant or badly payed developers exist all over the world), and to exploit the vulnerability you need to find a means of evading the filter to pass your malicious input to the vulnerable code. In the next few sections, we will examine some techniques that you can use to do just that.

Bypassing SQL Injection filters 

The are numerous ways to by pass SQL injection filters, there even more ways to exploit them too. The most common way of evading SQL injection filters are:

1. Using Case Variation 
2. Using SQL Comments 
3. Using URL Encoding 
4. Using Dynamic Query Execution 
5. Using Null Bytes 
6. Nesting Stripped Expressions 
7. Exploiting Truncation 
8. Using Non-Standard Entry Points
9. Combine all techniques above 

Take notice that all the above SQL injection filter bypassing techniques are based on the black list filtering mentality, and not the white list filtering logic. This means that bad software development is based in black list filters concept.

Using Case Variation

If a keyword-blocking filter is particularly naive, you may be able to circumvent it by varying the case of the characters in your attack string, because the database handles SQL keywords in a case-insensitive manner. For example, if the following input is being blocked:

' UNION SELECT @@version --

You may be able to bypass the filter using the following alternative:

' UnIoN sElEcT @@version --

Note: Using only uppercase or only lower case might also work, but I would not suggest spending a lot of time in that type of fuzzing.

Using SQL Comments

You can use in-line comment sequences to create snippets of SQL which are syntactically unusual but perfectly valid, and which bypass various kinds of input filters. You can circumvent various simple pattern-matching filters in this way.

Of course, you can use this same technique to bypass filters which simply block any white-space whatsoever. Many developers wrongly believe that by restricting input to a single token they are preventing SQL injection attacks, forgetting that in-line comments enable an attacker to construct arbitrarily complex SQL without using any spaces.

In the case of MySQL, you can even use in-line comments within SQL keywords, enabling many common keyword-blocking filters to be circumvented. For example, the following attack will still work if the back-end database is MySQL if you only check for spaces to SQL injection strings:

' UNION/**/SELECT/**/@@version/**/-- Or ' U/**/NI/**/ON/**/SELECT/**/@@version/**/--

Note: This type of filter bypassing methodology covers gap filling and black list bad character sequence filtering.

Using URL Encoding

URL encoding is a versatile technique that you can use to defeat many kinds of input filters. In its most basic form, this involves replacing problematic characters with their ASCII code in hexadecimal form, preceded by the % character. For example, the ASCII code for a single quotation mark is 0x27, so its URL-encoded representation is %27.In this situation, you can use an attack such as the following to bypass a filter:

Original query:

' UNION SELECT @@version --

URL-encoded query:

%27%20%55%4e%49%4f%4e%20%53%45%4c%45%43%54%20%40%40%76%65%72%73%69%6f%6e%20%2d%2d

In other cases, this basic URL-encoding attack does not work, but you can nevertheless circumvent the filter by double-URL-encoding the blocked characters. In the double encoded attack, the % character in the original attack is itself URL-encoded in the normal way (as %25) so that the double-URL-encoded form of a single quotation mark is %2527.If you modify the preceding attack to use double-URL encoding, it looks like this:

%25%32%37%25%32%30%25%35%35%25%34%65%25%34%39%25%34%66%25%34%65%25
%32%30%25%35%33%25%34%35%25%34%63%25%34%35%25%34%33%25%35%34%25%32
%30%25%34%30%25%34%30%25%37%36%25%36%35%25%37%32%25%37%33%25%36%39
%25%36%66%25%36%65%25%32%30%25%32%64%25%32%64

Note: You should also take into consideration that selective URL-encoding is also a valid way to by pass SQL injection filtering.

Double-URL encoding sometimes works because Web applications sometimes decode user input more than once, and apply their input filters before the final decoding step. In the preceding example, the steps involved are as follows:

1. The attacker supplies the input ‘%252f%252a∗/UNION … 
2. The application URL decodes the input as ‘%2f%2a∗/ UNION… 
3. The application validates that the input does not contain /∗ (which it doesn't). 
4. The application URL decodes the input as ‘/∗∗/ UNION… 
5. The application processes the input within an SQL query, and the attack is successful. 

A further variation on the URL-encoding technique is to use Unicode encodes of blocked characters. As well as using the % character with a two-digit hexadecimal ASCII code, URL encoding can employ various Unicode representations of characters. There is a very good web site you can use to test various  types of encoding here. The SQL Injection query when unicode encoded looks like this:

 27 20 55 4E 49 4F 4E 20 53 45 4C 45 43 54 20 40 40 76 65 72 73 69 6F 6E 20 2D 2D

Note: I have not been experimenting a lot with unicode encoding and frankly I do not think it is going to be very useful fuzzing SQL with Unicode encoding.

Further, because of the complexity of the Unicode specification, decoders often tolerate illegal encoding and decode them on a “closest fit” basis. If an application's input validation checks for certain literal and Unicode-encoded strings, it may be possible to submit illegal encoding of blocked characters, which will be accepted by the input filter but which will decode appropriately to deliver a successful attack.

Using the CAST and CONVERT keywords

Another subcategory of encoding attacks is the CAST and CONVERT attack. The CAST and CONVERT keyword explicitly converts an expression of one data type to another more over the CAST keyword is embedded to MySQL, MSSQL and Postgre databases. It has been used by various types of malware attacks in numerous web sites and is a very interesting SQL injection filter bypass. The most infamous botnet that used this type of attack was ASPRox botnet virus. Have a look at the syntax:

• Using CAST:  
• CAST ( expression AS data_type )

• Using CONVERT: 
• CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
  

With CAST and CONVERT you have similar filtering by passing results with with the function SUBSTRING, an example can show you what I mean. The following SQL queries will return the same result back:

SELECT SUBSTRING('CAST and CONVERT', 1, 4) 

Returned result: CAST 

SELECT CAST('CAST and CONVERT' AS char(4)) 

Returned result: CAST

SELECT CONVERT(varchar,'CAST',1)

Returned result: CAST

Note: See that both SUBSTRING and CAST keywords behave the same and can also be used for blind SQL injection attacks (you can try to test this queries with sqlzoo.net).

Further expanding on CONVERT and CAST we can identify that also the following SQL queries are valid and also very interesting, see how we can extract the MSSQL database version with CAST and CONVERT:

1st Step: Identify the query to execute:

SELECT @@VERSION

2nd Step Construct the query based on keywords CAST and CONVERT:

SELECT CAST('SELECT @@VERSION' AS VARCHAR(16))

OR

SELECT CONVERT(VARCHAR,'SELECT @@VERSION',1)

3rd Step Execute the query using the keyword EXEC:

SET @sqlcommand =  SELECT CONVERT(VARCHAR,'SELECT @@VERSION',1)

EXEC(@sqlcommand) 

OR convert first the SELECT @@VERSION to Hex

SET @sqlcommand =  (SELECT CAST(0x53454C45435420404076657273696F6E00 AS VARCHAR(34))

EXEC(@sqlcommand)

Note: See how creative you can become with CAST and CONVERT. Now since the type of data that is contained in the sentence CAST is hexadecimal a varchar conversion is performed.

You can also use nested CAST and CONVERT queries to inject your malicious input. That way you can start interchanging between different encoding types and create more complicated queries. This should be a good example:

CAST(CAST(PAYLOAD IN HEX, VARCHAR(CHARACTER LENGTH OF PAYLOAD)),, VARCHAR(CHARACTER LENGTH OF TOTAL PAYLOAD)    

Note: See how simple is it.

Using Dynamic Query Execution

Many databases allow SQL queries to be executed dynamically, by passing a string containing an SQL query into a database function which executes the query. If you have discovered a valid SQL injection point, but find that the application’s input filters are blocking queries you want to inject, you may be able to use dynamic execution to circumvent the filters. Dynamic query execution works differently on different databases.

On Microsoft SQL Server, you can use the EXEC function to execute a query in string form. For example:

'EXEC xp_cmdshell ‘dir’; — Or 'UNION EXEC xp_cmdshell ‘dir’; —

Note: Using the EXEC function you can enumerate all enabled stored procedures in the back end database and also map assigned privileges to stored procedures.

In Oracle, you can use the EXECUTE IMMEDIATE command to execute a query in string form. For example:

DECLARE pw VARCHAR2(1000);
BEGIN
       EXECUTE IMMEDIATE 'SELECT password FROM tblUsers' INTO pw;
       DBMS_OUTPUT.PUT_LINE(pw);
END;

Note:  You can do that line by line or all together, of course other filter by passing methodologies can be combined with this one.

The above SQL injection attack type can be submitted to the web application attack entry point, either the way it is presented above or as a batch of commands separated by semicolons when the back end database accepts batch queries (e.g. MSSQL).

For example in MSSQL you could do something like this:

SET @MSSQLVERSION  = SELECT @@VERSION; EXEC (@MSSQLVERSION); --

Note: The same query can be submitted from different web application entry points or the same.

Databases provide various means of manipulating strings, and the key to using dynamic execution to defeat input filters is to use the string manipulation functions to convert input that is allowed by the filters into a string which contains your desired query. In the simplest case, you can use string concatenation to construct a string from smaller parts. Different databases use different syntax for string concatenation.

For example, if the SQL keyword SELECT is blocked, you can construct it as follows:  

Oracle: 'SEL'||'ECT'

MS-SQL: 'SEL'+'ECT'  

MySQL: 'SEL' 'ECT'

Further examples of this SQL obfuscation method would be:

Oracle: UN’||’ION SEL'||'ECT NU’||’LL FR’||’OM DU’||’AL--
MS-SQL: ' un’+’ion (se’+’lect @@version) --
MySQL: ' SE’’LECT user(); #
 

Note that SQL Server uses a + character for concatenation, whereas MySQL uses a space. If you are submitting these characters in an HTTP request, you will need to URLencode them as %2b and %20, respectively. Going further, you can construct individual characters using the CHAR function (CHR in Oracle) using their ASCII character code. For example, to construct the SELECT keyword on SQL Server, you can use:

CHAR(83)+CHAR(69)+CHAR(76)+CHAR(69)+CHAR(67)+CHAR(84)

Note: The Firefox plug-in tool called Hackbar is also doing that automatically (for a long time now).

You can construct strings in this way without using any quotation mark characters. If you have an SQL injection entry point where quotation marks are blocked, you can use the CHAR function to place strings (such as ‘admin’) into your exploits. Other string manipulation functions may be useful as well. For example, Oracle includes the functions REVERSE, TRANSLATE, REPLACE, and SUBSTR. Another way to construct strings for dynamic execution on the SQL Server platform is to instantiate a string from a single hexadecimal number which represents the string’s ASCII character codes. For example, the string:

SELECT password FROM tblUsers

Can be constructed and dynamically executed as follows:

DECLARE @query VARCHAR(100)
      SELECT @query = 0x53454c4543542070617373776f72642046524f4d2074626c5573657273
EXEC(@query)

Note: The mass SQL injection attacks against Web applications that started in early 2008 employed this technique to reduce the chance of their exploit code being blocked by input filters in the applications being attacked.

Using Null Bytes

Often, the input filters which you need to bypass in order to exploit an SQL injection vulnerability are implemented outside the application's own code, in intrusion detection systems (IDSs) or WAFs. For performance reasons, these components are typically written in native code languages, such as C++. In this situation, you can often use null byte attacks to circumvent input filters and smuggle your exploits into the back-end application.

Null byte attacks work due to the different ways that null bytes are handled in native and managed code. In native code, the length of a string is determined by the position of the first null byte from the start of the string—the null byte effectively terminates the string. In managed code, on the other hand, string objects comprise a character array (which may contain null bytes) and a separate record of the string's length. This difference means that when the native filter processes your input, it may stop processing the input when it encounters a null byte, because this denotes the end of the string as far as the filter is concerned. If the input prior to the null byte is benign, the filter will not block the input.

However, when the same input is processed by the application, in a managed code context, the full input following the null byte will be processed, allowing your exploit to be executed. To perform a null byte attack, you simply need to supply a URL-encoded null byte (that looks like this ) prior to any characters that the filter is blocking. In the original example, you may be able to circumvent native input filters using an attack string such as the following:

' UNION SELECT password FROM tblUsers WHERE username='admin'--

Note: When access is used as a bank end database NULL bytes can be used as SQL query delimiter.

Nesting Stripped Expressions

Some sanitizing filters strip certain characters or expressions from user input, and then process the remaining data in the usual way. If an expression that is being stripped contains two or more characters, and the filter is not applied recursively, you can normally defeat the filter by nesting the banned expression inside itself.

For example, if the SQL keyword SELECT is being stripped from your input, you can use the following input to defeat the filter:

SELSELECTECT

Note: See the simplicity of bypassing the stupid filter.

Exploiting Truncation

Sanitizing filters often perform several operations on user-supplied data, and occasionally one of the steps is to truncate the input to a maximum length, perhaps in an effort to prevent buffer overflow attacks, or accommodate data within database fields that have a predefined maximum length.Consider a login function which performs the following SQL query, incorporating two items of user-supplied input:

SELECT uid FROM tblUsers WHERE username = 'jlo' AND password = 'r1Mj06'

Suppose the application employs a sanitizing filter, which performs the following steps:

Doubles up quotation marks, replacing each instance of a single quote (‘) with two single quotes (“)
Truncates each item to 16 characters. If you supply a typical SQL injection attack vector such as:

admin'--

The following query will be executed, and your attack will fail:

SELECT uid FROM tblUsers WHERE username = 'admin''--' AND password = ''

Note: The doubled-up quotes mean that your input fails to terminate the username string, and so the query actually checks for a user with the literal username you supplied. However, if you instead supply the username aaaaaaaaaaaaaaa' which contains 15 a’s and one quotation mark, the application first doubles up the quote, resulting in a 17-character string, and then removes the additional quote by truncating to 16 characters. This enables you to smuggle an unescaped quotation mark into the query, thus interfering with its syntax:

SELECT uid FROM tblUsers WHERE username = 'aaaaaaaaaaaaaaa'' AND password = ''

Note: This initial attack results in an error, because you effectively have an unterminated string

Each pair of quotes following the a’s represents an escaped quote, and there is no final quote to delimit the user-name string. However, because you have a second insertion point, in the password field, you can restore the syntactic validity of the query, and bypass the login, by also supplying the following password:

or 1=1--

This causes the application to perform the following query:

SELECT uid FROM tblUsers WHERE username = 'aaaaaaaaaaaaaaa'' AND password = 'or 1=1--'

When the database executes this query, it checks for table entries where the literal username is 

aaaaaaaaaaaaaaa' AND password =

which is presumably always false, or where 1 = 1, which is always true. Hence, the query will return the UID of every user in the table, typically causing the application to log you in as the first user in the table. To log in as a specific user (e.g., with UID 0), you would supply a password such as the following:

or uid=0-- 

Note: This query is considered to be a very old technique used for authentication bypass or privilege escalation.

Using fuzzdb for Web Application black box testing

Fuzzdb aggregates known attack patterns, predictable resource names, server response messages, and other resources like web shells into the most comprehensive Open Source database of malicious and malformed input test cases. Using fuzzdb attack patterns to test Web Applications is a must nowadays. Importing the fuzzdb lists to Web Fuzzers should be very common if you want to get some real results. If you use fuzzdb along with Burp Scanner, Intruder and all other features you are definitely going to get better results even from any Web Application Scanner.

What's in fuzzdb?

So what is fuzzdb?

1. Fuzzdb is a collection of attack patterns: Categorized by platform, language, and attack type, malicious and malformed inputs known to cause information leakage and exploitation have been collected into sets of test cases. FuzzDB contains comprehensive lists of attack payloads known to cause issues like OS command injection, directory listings, directory traversals, source exposure, file upload bypass, authentication bypass, http header crlf injections, and more.
2. Fuzzdb is a collection of response analysis strings: Since system responses also contain predictable strings, fuzzdb contains a set of regex pattern dictionaries such as interesting error messages to aid detection software security defects, lists of common Session ID cookie names, and more.
3. Fuzzdb is a collection of other useful stuff: Webshells, common password and username lists, and some handy wordlists.
4. Fuzzdb is a collection of : Documentation - Helpful documentation and cheat sheets sourced from around the web that are relevant to the payload categories.

Mutating fuzzdb payloads using Python

With Python you can very easily mutate all interesting attack patterns concerning SQL injection, feed them to Burp Intruder as an attack list and use them to test Web Applications. There are numerous code examples for Python and even a very novice programmer can learn text manipulation with Python. The two basic modules you will have to use to perform the mutations are:

1. Standard module: string
2. Standard module: re

The string module contains several types of things, such as functions, methods, and classes; it also contains strings of common constants.The re module obsoletes the regex and regsub modules that you may see used in some older Python code. While there are still a few, limited advantages to regex , they are minor and it is not worth using in new code.

About Python regular expressions

A regular expression in Python is a concise way of describing a pattern that might occur in a text. With Python regular expressions you can answer questions such as:

1. Do certain characters occur?
2. In a particular order?
3. Are sub-patterns repeated a given number of times?
4. Do other sub-patterns exclude a match?

Conceptually, this is not unlike the way you would intuitively describe a pattern in a natural language. The trick is encoding this description in the compact syntax of regular expressions.When approaching a regular expression, treat it as its own programming problem, even though only one or two lines of code may be involved; those lines effectively form a small program.  

URL-encoding using Python

Mutating payloads is easy with Python, so when you would want to URL encode the SQL injection inputs from fuzzdb you can use the very simple Python script displayed below:



Note: In the above example you can see how easy is to URL-encode the fuzzdb list and then feed the output to Burp Intruder to test the application. It is obviously not the best Python code for URL encoding but I had no time so I did it the nasty way.

Gap filter by passing using Python

With Python you can very easily replace the gaps with the following character sequence /**/ the following code shows exactly that:

Note: See how easy and simple is SQL comment gap replacement. You can use not only SQL comment to fill the gaps but also insert within the ordinary SQL queries.

Again with Python you can very easily replace the gaps with the following character sequence %20 the following code shows exactly that:

Note: Again see how easy and simple is this (the special character sequence will be removed from the Web app).

Using Null Bytes with Python to bypass filters

With Python you can very easy concatenate the null character at the begging of the line, the following code shows exactly that:

Note: Again see how easy and simple is to add at the begging of each line the null character.

Analyzing SQL Injection counter measures

The only ways someone should defend against SQL Injection attacks are the following and only the following:

1. White list filters 
2. Black and white list hybrid filters (not only black list filters) 
3. Parametrized SQL queries 
4. Stored procedures with proper privilege assignments 

White list filters

White list filtering should be easy to understand, you just use a Web Server control that accepts only certain set of characters and rejects all other set of characters, the following concept is presented below:



Note: The white list filter accepts only ASCII characters and reject all other characters (this is an example and does not mean that SQL Injection is blocked by allowing ASCII character set).

White list filtering should be your first choice when implementing Web Application filtering mechanisms, especially when the input is very specific, such as credit card numbers. Also white list filtering has better performance when compared to black list filters with long black lists. 

Black list filters

Black list filtering should also be easy to understand, you just use a Web Server control that rejects only certain sets of characters and accept all other, the following concept is presented below:



Note: Black list filters reject only single quotes and accept all other characters (this is an example and does not mean that SQL Injection is prevented by blocking single quote characters).

Why people use black list filters? Simple because they want to find an easy solution to protect multiple Web Applications with generic SQL black list filters that apply for all their Web Applications Infra-structure. If someone would want for example to protect his/her Web Application he/she would block single quote for all Web Applications and that way add an extra layer of security (or at least that is what he/she thinks). It is also common knowledge that in order to properly configure a Web Application Firewall you would have to be a Web System Administrator and a Web Developer at the same time, which in most companies does not happen. WAF's give you the option of properly configuring white list filters if you know how the Web Application works (e.g. Http request throttling, allowed character set per html form e.t.c) but in the majority of the situations the developer of the web application to be protected is not going to do the WAF configuration.

For the reasons explained above black list filtering methodology is unfortunately adopted by many developers and vendors that develop IPS/IDS, WAF's and firewall devices. Developers and system engineers lack of imagination and are not really interested into bypassing their own filters or doing a good job on understanding hacking.

IMPORTANT NOTE: If you believe that you have an important Web Application and you need to protect it then DO NOT:

1. Think that the company WAF/IPS is going to block any advanced SQL Injection attack.
2. Use black list filtering, it is WRONG because most of the time does not provide real world protection.
3. Use automated only web security scanners to test business critical web sites.  

Note: Manual penetration testing is essential before deploying business critical Web Applications to production.

Black and white list hybrid filters

Black and White list hybrid filtering again should be also easy to understand, you just use a Web Server control that first accepts certain sets of characters and then rejects a certain character sequence of the accepted set of characters. This type of filter is the most effective and should be used as an alternative of white list filtering ONLY AND ONLY IF WHITE LIST FILTERING DOES NOT DO THE JOB.

Note: The white/black list hybrid filter displayed above accepts ASCII code and then from the accepted set of characters single quote is filtered out. This would have meaning if for example you would want to accept single quotes in a certain position, for example you might want to allow the string Mr Smith's but not Mr' Smiths. You can do that if you implement "both type of filters" into a single regular expression.

It is important to understand that when using white/black list hybrid filters to sanitize your input it means that you have excluded white list filtering because it is not going to do the job the proper way. It should also be noticed that the black list filter functionality is better to be applied after the white list filter for performance reasons (imagine having a long ugly list of character sequences to run though your input). It should also be clear by now that again when you use white/black list hybrid filtering in the black list filter part you would want to filter certain characters based on:

1. The position within the user supplied input (e.g. if you allow the + character then it should not be placed within strings such as var+iable, where variable is a critical web application variable).
2. Certain sequences of bad characters but not the characters themselves (e.g. block '-- , '# or '+' but do not block ++).

Note: Filtering user malicious input is not so difficult, you just have to have the correct mentality.

Web Application Firewall black list mentality

I talked about white list filtering, I talked about black list filtering, I even mentioned about hybrid filters. What I did not talk about is the Black list filter mentality that "lives" in big and profitable organizations. In "profitable" big organizations such as banks or big software vendors you will find something that they call information technology (IT) operation team (ITOPT). ITOPT is responsible for deploying the Web Applications, applying proper patches and making sure that everyone is happy and everything is up and running. Now what happens is that these guys will ask from information security consultants that have never performed a single decent Web Application penetration test in their life to help them deploy THE Web Application Firewall (WAF). So what happens next is for them to propose a simple low cost black list filtering approach. Why? Because it is an easy and generic solution (sounds like a smart move e?). DAAAA this is when the trouble starts, applying the same black list filter for all the custom company Web Applications is Wrong.

The following picture shows a conceptual representation of bad WAF configuration:

       
Note:  You see what is wrong here. The same filter is applied on all Web Applications, with out taking into consideration the special needs of each Web Application separately. 

Parametrized SQL queries 

With most development platforms, parametrized statements can be used and work with type fixed parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. A placeholder can only store the value of the given type and not the arbitrary SQL fragment. Hence the SQL injection would simply be treated as a strange (and probably invalid) parameter value.

Stored procedures with proper privilege assignments

Stored procedures are implemented differently in every database, so for each database we will give a different definition:

For MSSQL: Stored procedures in MSSQL means pre-compiled execution. SQL Server compiles each stored procedure once and then re-utilizes an execution plan invoking the stored procedure. This results in a tremendous performance boost when stored procedures are called repeatedly and also there is a forced type casting protection.

For MySQL: Stored procedures increases the performance of the application. Once created, a stored procedure is compiled and stored in the database catalog. It runs faster than uncompiled SQL commands which are sent from the application and of course compiled code means type casting safety.

For Oracle: Stored procedures provide a powerful way to code application logic that can be stored on the server. The language used to code stored procedures is a database-specific procedural extension of SQL (in Oracle it is PL/SQL), dynamic SQL can be used in:

1. EXECUTE IMMEDIATE statements 
2. DBMS_SQL package 
3. Cursors 

Tools that can obfuscate for you

For these type of attacks there is a tool written by Gerasimos Kassaras (this is me) that can obfuscate SQL payloads (and other payloads), it is the Teenage Mutant Ninja Turtle tool project which you can download from here.

The Teenage Mutant Ninja Turtles project is four things:

1. A Web Application payload database.
2. A Web Application error database.
3. A Web Application payload mutator.
4. A Web Application payload manager.

Nowadays all high profile sites found in financial and telecommunication sector use filters to filter out all types of vulnerabilities such as SQL, XSS, XXE, Http Header Injection e.t.c. In this particular project I am going to provide you with a tool to generate Obfuscated Fuzz strings in order to bypass badly implemented Web Application injection filters (e.t.c SQL, XSS and Path-traversal Injections e.t.c). Also with Teenage Mutant Ninja Turtles you will be able to do payload management by generating custom payload lists to test thoroughly your Web Application for all type of vulnerabilities such path traversal and SQL obfuscated payloads.

Epilogue

This article aims to become a complete guide for bypassing SQL injection filtering (meaning I am going to do regular updates) used by a wide range of web applications.

Reference:

1. The Web Application Hacker’s Handbook (Second Edition)
2. SQL Injection Attack and defence (First Edition)
3. http://en.wikipedia.org/wiki/SQL_injection
4. http://forums.mysql.com/read.php?98,358569
5. http://www.mssqltips.com/sqlservertutorial/160/sql-server-stored-procedure/
6. http://palizine.plynt.com/issues/2006Jun/injection-stored-procedures/
7. http://software-security.sans.org/developer-how-to/fix-sql-injection-in-oracle-database-code
8. http://code.google.com/p/fuzzdb/
9. http://www.ibm.com/developerworks/linux/library/l-python5/index.html
10. http://docs.python.org/library/re.html 
11. http://www.rishida.net/tools/conversion/
12. http://isc.sans.edu/diary.html?storyid=9397 
13. http://urldecoder.codeplex.com/ 
14. https://code.google.com/p/teenage-mutant-ninja-turtles/downloads/list 

Going The Same Way?

Intro

This article is about explaining the Session Fixation and Session Hijacking vulnerability impact and also do a post exploitation analysis of the methodologies used from organized crime. Many people, and by many people I mean Information Security Consultants, Security System administrators and Penetration testers tend to believe that Session Fixation/Hijacking is not so serious problem and when found in a Web Applications, when they report it they characterize it as low risk or when the Web Application is vulnerable to session fixation, they believe that when the session is not passed in the URL it cannot be used in an efficient way to attack the website.Well that is wrong, and I am sure about it because I have seen lots of my clients becoming victims from organized crime. I am also reminding you that if:

1. You become a Cross Site Script victim it might be difficult to detect the attack (especially if you allow concurrent logins).
2. You have a Session Hijacking event it is not traceable, which means that, in order to be successful the session hijacking you have to allow concurrent logins. 

Well how do you protect your session fixation? Well that is easy to answer. With properly configured the server same origin policy and by not allowing concurrent logins (it is implied that you have to use random values per page, refresh the cookie after successful login and generate truly random or pseudo random but, not predictable cookies). You should also perform web user auditing and if possible feed the web user logs to an IDS/IPS device or a web application firewall. Most of the IPS/IDS devices or Web Application firewalls can understand a syslog like input, and your web or system administrator can probably do that. 

The XSS/Phising Proxy Attack

When a Web Application is vulnerable to a) Session fixation attack (e.g. predictable cookie generation or no cookie refresh after login) or b) Session Stealing attack (e.g. XSS attack or Script Injection Attack e.t.c) the following conceptual representation attack scenarios are all feasible. See the following diagram:  
   

In the diagram above you can see that initially the attacker sends an e-mail that hides either a link that forms a GET request when passed in the browser or a hidden html form or a Java script/VBScript) that forms a POST request when passed in the browser or a link that redirects the victim to the fake proxy site. Now these types of attacks are already implemented in the Social Engineering Toolkit (SET) and you can have a look if you want. The attacker can form a POST/GET request to forward the predicted/fixed or stolen session id or can use a Phi-sing site to alter the GET request sent by the victim to a POST request with a valid session.

Then if you use a single session of authentication:

1. If the session is predictable the attacker can hijack multiple users sessions.
2. If the session is stolen, but not predictable and refreshed the attacker can hijack a single user.
3. If the session is not stolen, not predictable and not refreshed the attacker can hijack a multiple users.

The Same origin policy

The Same Origin Policy permits scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity.

History

The concept of same origin policy dates back to Netscape Navigator 2.0. Close derivatives of the original design are used in all current browsers and are often extended to define roughly compatible security boundaries for other web scripting languages, such as Adobe Flash, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.

Origin determination rules

The term "origin" is defined using the domain name, application layer protocol, and (in most browsers) port number of the HTML document running the script. Two resources are considered to be of the same origin if and only if all these values are exactly the same.To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".

Same-origin policy for DOM access

With no additional qualifiers, the term "same-origin policy" most commonly refers to a mechanism that governs the ability for JavaScript and other scripting languages to access DOM properties and methods across domains (reference). In essence, the model boils down to this three-step decision process:

1. If protocol, host name, and - for browsers other than Microsoft Internet Explorer - port number for two interacting pages match, access is granted with no further checks.
2. Any page may set document.domain parameter to a right-hand, fully-qualified fragment of its current host name (e.g., foo.bar.example.com may set it to example.com, but not ample.com). If two pages explicitly and mutually set their respective document.domain parameters to the same value, and the remaining same-origin checks are satisfied, access is granted.
3. If neither of the above conditions is satisfied, access is denied.

In theory, the model seems simple and robust enough to ensure proper separation between unrelated pages, and serve as a method for sand-boxing potentially untrusted or risky content within a particular domain; upon closer inspection, quite a few drawbacks arise, however:

1. Firstly, the document.domain mechanism functions as a security tarpit: once any two legitimate subdomains in example.com, e.g. www.example.com and payments.example.com, choose to cooperate this way, any other resource in that domain, such as user-pages.example.com, may then set own document.domain likewise, and arbitrarily mess with payments.example.com. This means that in many scenarios, document.domain may not be used safely at all.
2. Whenever document.domain cannot be used - either because pages live in completely different domains, or because of the aforementioned security problem - legitimate client-side communication between, for example, embeddable page gadgets, is completely forbidden in theory, and in practice very difficult to arrange, requiring developers to resort to the abuse of known browser bugs, or to latency-expensive server-side channels, in order to build legitimate web applications.
3. Whenever tight integration of services within a single host name is pursued to overcome these communication problems, because of the inflexibility of same-origin checks, there is no usable method to sandbox any untrusted or particularly vulnerable content to minimize the impact of security problems.

On top of this, the specification is simplistic enough to actually omit quite a few corner cases; among other things:

1. The document.domain behavior when hosts are addressed by IP addresses, as opposed to fully-qualified domain names, is not specified.
2. The document.domain behavior with extremely vague specifications (e.g., com or co.uk) is not specified.
3. The algorithms of context inheritance for pseudo-protocol windows, such as about:blank, are not specified.
4. The behavior for URLs that do not meaningfully have a host name associated with them (e.g., file://) is not defined, causing some browsers to permit locally saved files to access every document on the disk or on the web; users are generally not aware of this risk, potentially exposing themselves.
5. The behavior when a single name resolves to vastly different IP addresses (for example, one on an internal network, and another on the Internet) is not specified, permitting DNS rebinding attacks and related tricks that put certain mechanisms (captchas, ad click tracking, etc) at extra risk.
6. Many one-off exceptions to the model were historically made to permit certain types of desirable interaction, such as the ability to point own frames or script-spawned windows to new locations - and these are not well-documented.

All this ambiguity leads to a significant degree of variation between browsers, and historically, resulted in a large number of browser security flaws. A detailed analysis of DOM actions permitted across domains, as well as context inheritance rules, is given in later sections. A quick survey of several core same-origin differences between browsers is given below:

 

 

 

Note: Firefox 3 is currently the only browser that uses a directory-based scoping scheme for same-origin access within file://. This bears some risk of breaking quirky local applications, and may not offer protection for shared download directories, but is a sensible approach otherwise.
Corner cases and exceptions

The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases, such as for protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.

In addition, many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains, or submit POST forms. Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.

Workarounds

To enable developers to, in a controlled manner, circumvent the same origin policy, a number of "hacks" such as using the fragment identifier or the window.name property have been used to pass data between documents residing in different domains. With the HTML5 standard, a method was formalized for this: the postMessage interface, which is only available on recent browsers. JSONP and cross-origin resource sharing can also be used to enable ajax-like calls to other domains. easyXDM can also be used to easily work around the limitation set in place by the Same Origin Policy. It is a light weight, easy to use and self contained Javascript library that makes it easy for developers to communicate and expose javascript API's across domain boundaries.

Reference:

1. http://en.wikipedia.org/wiki/Same_origin_policy
2. http://www.w3.org/TR/html5/origin-0.html#origin-0
3. http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy
4. https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript
5. http://tools.ietf.org/html/rfc6454
6. http://www.jumperz.net/index.php?i=2&a=3&b=3