DcLabs - Security Team

quarta-feira, 2 de agosto de 2017

Some time ago we were testing an application and we found very limited reflected XSS vuln injecting straight into the page and we had only 22 chars to exploit that.

After some testing, the following payload worked very well:
<svg/onload=alert(1)> or <svg onload=alert(1)>

This <svg> payload has 21 chars, but we still not happy with the size.

Checking the HTML doc it was possible to find the function oncut, obviously, it has fewer chars than onload.
Well, as the function name oncut is quite clear, we need something to cut on the web page.
So, a small HTML tag that accepts text is <p>.

In this case, the payload will be the following:
<p/oncut=alert(1)>A or <p oncut=alert(1)>A

Bingo! We have a functional XSS payload with 19 chars. \o/

The problem: To trigger the payload, of course, the user must try to cut the "A". In other words, different from onload that is automatic, this payload must have user interaction.

Another super short we can use with 18 chars is:
<a/oncut=alert(1)> or <a oncut=alert(1)>

In this case, some text must preexist on page body after injecting the tag <a> and as same from the previous payload, the user must try to cut any text after <a> tag. In other words, also same as the previous example, this payload must have user interaction.

quinta-feira, 23 de junho de 2016

Since years,
SQL Injections have been the most dreadful and frightening of all
vulnerabilities discovered till date. The power of a single quote (') is beyond
comparison. SQL injection attacks were first discovered in 1998, with one of
the first live attacks taking place in 2002 on the fashion retailer Guess and
the rest is History. Billions of Dollars and reputations have been lost. In
spite of implementing multiple forms of fixes, it’s a never ending war between
developers and hackers. If the former comes up with a way to prevent it, the
latter comes up with a way to bypass it.

The blog focuses on providing in-depth insights into the discussion of the techniques used to bypass
one of such prevention methods. This blog will not help you to learn the
basics of SQL Injection; so I would recommend you to go through OWASP before even thinking about jumping into advanced techniques. This blog is more
focused on bypassing Mod_Security (Web Application Firewall) and eventually exploiting SQL Injection vulnerability.

The Attack:

First and
foremost, we need to find our target website. In this case I am using:

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

BLOCKED!

It seems like
our target website has a WAF implemented to prevent itself from being targeted.
So, if I am not wrong, any attacks directed towards the database will be
blocked by Mod_Security.

Well in some
cases, it is possible to block such attacks if you have the implementation done
correctly with an up-to-date version of WAF being used and regular update of
security patches being rolled out.

But then again,
aren't we hackers? We don't give up, do we? Let's try to get around it. Sounds
intriguing? Let's play.

First we need
to make some queries work just to be sure that SQL Injection indeed exists.

Finding the Number of Columns:

Till now I
would say that we are kinda hacking in the dark. No real MySQL errors which
actually proved the presence of SQL Injection. The only success we had was when
we used a single quote in the above mentioned URL and received a blank page in
response…no rows…no data. This can however mean that we somehow managed to
change the structure of the underlying query and the page might be vulnerable
to SQL Injection. Let's try and get some confirmation.

Finding the
number of columns present in the current database might actually prove its
presence. This can be achieved by using a simple "ORDER BY" clause.

As seen above, ORDER
BY 7-- query generated a different response thereby proving the
existence of 6 columns in the current database. We were lucky though since the
WAF did not block the 'ORDER'
keyword. We need that sometimes!

However, since
now we know the number of columns in use; let’s see which columns get
displayed in the response.

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

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