Chaining XPath injections into DOM-based XSS

The way most web apps defend themselves against DOM-based Cross-Site Scripting is by validating input that later on is written into the DOM. Sometimes, web apps request data from APIs that is trusted because it didn't come from the user, so it isn't validated. This post will show a trick for tampering with data provided by APIs that didn't come from the user by using XPath injection. Since the data is not validated you can achieve DOM-based XSS.

This attack can be useful because implementations of XPath 1.0 have a very limited attack surface. Only with XPath 2.0 and XPath 3.1 more critical attacks become a possibility. Implementations of XPath 2.0 and 3.1 are not very popular so most web apps out there use version 1.0.

Since a lot of people don't know XPath very well, I'll provide the basics to demonstrate how XPath works in order to know how to exploit it.

The first step to scan a web app against XPath injections is by using boolean based conditions such as the followings:

/vulnerable_page?id=1' and '1'='1
/vulnerable_page?id=1' and '1'='0

/vulnerable_page?id=1" and "1"="1
/vulnerable_page?id=1' and "1"="0

/vulnerable_page?id=1 and 1=1
/vulnerable_page?id=1 and 1=0

(more…)

Faster blind SQL injection exploitation: exfiltrating data without knowing the column names of the tables

(7 min read)

In the exploitation phase after finding SQL injection vulnerabilities, attackers usually exfiltrate all the information stored in the database. But first, in order to exfiltrate all of the information stored in the tables of the DB, the attacker must previously know the column names that compose those tables.

This post will show a method for extracting all the information contained in a table/view without having to know the name of any of its columns at all.

This method can significantly speed-up the exfiltration process, specially in situations where information must be extracted one character at a time as with blind injections. See the following query done in a fresh install of MySQL:

mysql> select count(*) from information_schema.columns;
+----------+
| count(*) |
+----------+
|     3542 |
+----------+
1 row in set (0.12 sec)

This means that a total of 3,542 column names must be extracted in order to be able to craft the queries that will exfiltrate the tables. Next, see the total of all the characters that must be extracted:

mysql> select sum(length(column_name)) from information_schema.columns;
+--------------------------+
| sum(length(column_name)) |
+--------------------------+
|                    47026 |
+--------------------------+
1 row in set (0.02 sec)

There is a total of 47 thousand characters that must be extracted to find all the column names in a fresh MySQL install. sqlmap performs 7 requests to extract a single character with blind SQL injections, this means that it would take a total of 329,182 requests to exfiltrate all of the column names.

A database found in a corporate or industrial environment can be extremely larger.

So now, with the method described in this post, around 188,000 requests are going to be avoided and the tables and views will be exfiltrated right away.

(more…)

High Speed Methods For Blind SQL Injections

Reading time: 50 min

I reached the conclusion that the blind SQL injection techniques we use for data exfiltration are slow, and there is huge room for improvement to make them much faster and efficient.

I spent some time designing new high-speed optimized blind SQL injections and I wrote a paper where I documented all of these techniques. The research got accepted to be presented at manysecurity conferences such as Hackfest Quebec, B-Sides Philly, BugCON Mexico, DragonJAR Colombia and Hack in Paris (which I missed because I was severely jet-lagged and I feel very ashamed to say so).

duality.py, one of these optimized attacks, uses deductive algorithms that request only certain fragments of the information and deduce the missing data through the use of decision-making trees. This method takes an average of 30% less requests than the famous tool sqlmap to exfiltrate information from a database. This and more blind SQL injection techniques are explained in this paper.

You can find the paper in .txt format here:
https://nzt-48.org/Papers/high-speed-methods-for-blind-sql-injections.txt

For a self-explanatory and condensed version of the paper, you can find the slides of the talk here (the slides are numerous but most of them are just the same slide with different highlighted values):
https://nzt-48.org/slides/high-speed-methods-for-blind-sql-injections.pdf

These are some screenshots of the slides just to make the post look cool:

Bypasses for the some of the most popular WAFs

EDIT: Most of these bypasses have already been patched. Whereas some of the tricks shown in this post can be used to find new bypasses, this will only work on very few WAFs and other types of techniques should be use to bypass most of them.

In Black Hat 2009 I had the honor of personally meeting @sirdarckcat (Eduardo Vela, leader of Google Project Zero) who gave a presentation titled "Our favorite XSS filters and how to attack them". In his presentation he managed to bypass every single popular Web Application Firewall that was in the market at that time and he said it had been ridiculously easy.

The conclusion of his talk was that all Web Application Firewalls (WAFs) were practically useless at that time due to the tremendous ease in which they could be bypassed.

Now, more than ten years later, I decided to evaluate the security of many popular WAFs to see their evolution and how robust they've become over time. The conclusion is that most of them are still extremely vulnerable. They are very easy to bypass so the degree of protection they offer is very low; I broke each WAF in around 5 minutes.

I decided to publish the bypasses because it is actually funny how bad these filters are.

The WAFs that I tested are:

  • [censored]
  • [censored]
  • [censored]
  • [censored]
  • [censored]
  • [censored]
  • [censored]
  • [censored]
  • [censored]

Click on more to see the bypasses:

(more…)

Modern XPath Exploitation

In addition to XXE vulnerabilities, XPath injections are another type of attack used to exploit XML technologies.

Following the release of XPath 2.0 and XPath 3.1 I read the specifications to see if the new features could be used to deploy new types of attacks. Turns out that these new XPath implementation did introduce new threats and new risks that expand the attack surface of XPath vulnerabilities.

Some of these new risks are:
- Arbitrary file disclosure
- Turn blind injections into visible injections
- Server Side Request Forgery
- Turn XPath injections into XSS

I wrote a .txt for your convenience and you can find it here:
https://nzt-48.org/Papers/modern-xpath-exploitation.txt

The paper also explains highly optimized algorithms for exfiltrating server files through XPath injections.

If you prefer to read the paper in this blog post, click on "more"

A tool was released as a proof of concept and you can find it here:
https://github.com/tr3w/injectX

(more…)

SQL Injection Detection Optimization

(3 minute read)

In Black Hat USA 2013, Roberto Salgado (@LightOS) came up with the idea of optimizing the detection phase of SQL injection vulnerabilities.

Usually, to test if a parameter is vulnerable to SQL injection, the following requests must be performed to find out the context of the injection. It might be between single quotes ('), double quotes (") or with no delimiters at all:

TRUE RESPONSES
-1' or '1'='1
-1" or "1"="1
-1 or 1=0

FALSE RESPONSES
-1' or '1'='0
-1" or "1"="0
-1 or 1=0

LightOS came up with the idea of fusing the three testing vectors. This is the multi-context functional polyglot that works in any of the already three mentioned contexts:

-1 OR 1#"or"'OR''='"="'OR''='

Numeric context:
-1 OR 1#"or"'OR''='"="'OR''='

Double quotation:
-1 OR 1#"or"'OR''='"="'OR''='

Single quotation:
-1 OR 1#"or"'OR''='"="'OR''='

You can find his slides in the following link: https://media.blackhat.com/us-13/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

Mirror: https://nzt-48.org/archive/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

My version of the vector is 7 characters shorter:

-1 or 1#'or"or'"!='!="

Numeric context:
-1 or 1#'or"or'"!='!="

Single quotation:
-1 or 1#'or"or'"!='!="

Double quotation:
-1 or 1#'or"or'"!='!="

I find LightOS's solution to be much more elegant because he used an equality. Can you make it even shorter?

 
You can follow me on X to stay updated: @ruben_v_pina