TAG | web application
0 Comments | Posted by Sven Nobis
The HITBSecConf or “Hack In The Box” in Amsterdam is a well known security conference in Europe. We also attended this year too, and there were quite some interesting talks at the HITBSecConf16 conference. One of the talks was about “New Methods for Exploiting ORM Injections in Java Applications” by the security researchers Mikhail Egorov and Sergey Soldatov.
1 Comment | Posted by Timo Schmid
I’ve recently found some sort of classic web vulnerabilities in the Google Search Appliance (GSA) and as they are now fixed , I’d like to share them with you.
First of all, some infrastructure details about the GSA itself. The GSA is used by companies to apply the Google search algorithms to their internal documents without publishing them to cloud providers. To accomplish this task, the GSA provides multiple interfaces including a search interface, an administrative interface and multiple interfaces to index the organization’s data. (more…)
0 Comments | Posted by Simon Rich
First of all: This is not an in-depth Kerberos how-to, nor is this tutorial about the different aspects of web application testing. This tutorial is just to give support in testing Kerberos authenticated web applications. The goal is to hand over the right tools and steps to be able to perform the configuration and be able to test the application.
1 Comment | Posted by Kevin Schaller
In the context of an internal evaluation, we recently had a look at most of the burp plugins available from the BApp store. The following overview represents our personal top 9 plugins, categorized in “Scanner Extensions”, “Manual Testing” and “Misc” in alphabetic order:
0 Comments | Posted by Kevin Schaller
During one of our last projects in a large environment we encountered an interesting flaw. Although it was not possible to exploit it in this particular context, it’s worth to be mentioned here. The finding was about Cross-Site Request Forgery, a quite well-known attack that forces a user to execute unintended actions within the authenticated context of a web application. With a little help of social engineering (like sending a link via email, chat, embedded code in documents, etc…) an attacker may force the user to execute actions of the attacker’s choice.
Some days ago another advisory related to a web application firewall (WAF) product was published. This time the product Airlock by Ergon was affected by a vulnerability that combines Encoding and NULL Byte attacks to circumvent the pattern based detection engine. We have described these attacks in detail in our newsletter “Web Application Firewall Security and The Swiss Army Knife for Web Application Firewalls” because they belong to a well known category of attacks against WAFs.
The product is commonly used in the swiss banking industry to ensure PCI DSS compliance and serves as another proof that WAFs can’t protect web applications from skilled attackers as already stated by me in an earlier post that you can find here. Beside these “5 myths of web application firewalls” we can also look at WAFs based on the typical attack vectors against web applications:
These attack vectors are described in detail in the famous “Web Application Hackers Handbook” and if you’re doing web application assessments they belong to the mandatory test methodology. Based on our WAF research we have compiled a little nice diagram that reflects the technical capabilities of WAFs to protect against these attack vectors:
As you can see especially authorization (user A can access data of user B) attacks and also logic flaws can not be addressed by WAFs because they can not be detected by pattern matching and even by whitelisting approaches. By the way when testing banking web applications one of the most relevant questions to answer is “can customer A see account information of customer B” :-). This raises the question “Why is the banking industry using WAFs to protect their customers data instead of fixing vulnerabilities in their applications or in general ensuring the quality?”. And again, finally we end up realizing that implementing a Security Development Lifecycle (SDL) would fulfill our “security needs” in a more effective way, but this time just from an attackers point of view.
Have a great day
0 Comments | Posted by Michael Thumann
Take Care of the Database
There are some database specifics, every pentester should be aware of, when testing for and exploiting SQLi vulnerabilities. Besides the different string concatenation variants already covered above, there are some other specifics that have to be considered and might turn out useful in some circumstances. For example with Oracle Databases, every SELECT statement needs a following FROM statement even if the desired data is not stored within a database. So when trying to extract e.g. the DB username using a UNION SELECT statement, the DUAL table may be utilized, which should always be available. Another point, if dealing with MySQL, is the possibility to simplify the classic payload
' or 1=1 --
' or 1 --
One important difference regarding totally-blind SQLi are the different ways for an equivalent MS-SQL “
waitfor delay” in other database management systems. For MySQL (before 5.0.42), the benchmark function may be used. E.g.:
For later versions:
Respectively, Oracle supports an HTTP request function, which is expected to generate a delay if pointed to a non existing URL:
utl_http.request('http://192.168.66.77/'). Alternatively, the following function may be useful:
Using database specific test and exploit signatures will also help to identify the used database, which makes all further tests much easier.
Another important difference is the missing MS-SQL “
xp_cmdshell” on other DBMSs. However, there were some talks in the past (e.g. at Black Hat Europe 2009 by Bernardo Damele A. G. the author of sqlmap) about the possibility to execute code with MySQL respectively PostgreSQL under certain circumstances (sqlmap supports upload and execution of Metasploit shellcode for MySQL and PostgreSQL). This table summarizes useful SQL functions.
How to Exploit SQL Injection
After identifying vulnerable parameters it is time for exploitation. There are some basic techniques for this task, which will be explained in the context of an Oracle DB. As for data extraction one of the most useful statements is
UNION SELECT. However, the
UNION SELECT approach doesn’t work in all situations. If,for example, injecting right after the select statement (e.g. “
SELECT $INPUT_COLUMN_NAME FROM tablename;” ) and not after a
WHERE clause, trying to extract data with
UNION SELECT leads most likely to an SQL error if you are unaware of the exact query. In this simple but sometimes occurring scenario, one solution would be the use of subselects. The advantage of subselects are the fact, that in many cases it is not necessary to know anything about the surrounding query. So supplying
(SELECT user FROM DUAL)
the SQL query doesn’t get broken and ideally prints the desired information. However if the payload is injected into a string, the previously covered string concatenation gets useful. So with a similar query, the attack string could look like:
'|| (SELECT user FROM DUAL) ||'
The previous examples depend on any form of results from the application. In case the application doesn’t print any results of the SQL query, it may still be possible to gather database information if the application behavior can be influenced.Given a registration form, where the supplied username gets checked for existence in the database, the used SQL query might look like:
SELECT username FROM users WHERE username = '$NEW_USERNAME';
This kind of vulnerability is a boolean-based blind SQLi. It is not possible to print any SQL query results, but the application logic can be exploited. So the payload in this case might be:
'|| (SELECT CASE WHEN (SELECT 'abcd' FROM DUAL) = 'abcd' THEN 'new_username' else 'EXISTING_USERNAME' END FROM DUAL)||'
Or in pseudo code:
If abcd equals abcd
Obviously this payload does not provide any useful information by now, but it illustrates the possibility to make boolean checks on strings which will be helpful later on during/for extracting real data from the database.
How to get around Web Application Firewalls
In some situations, the application might filter specific attack strings or a Web Application Firewall (WAF) is deployed in front of the web servers/applications. In these cases, being creative is essential. For example, instead of injecting
' or 'a'='a
we already circumvented a WAF by supplying a slightly modified version of this payload:
' or 'a='='a=
If dealing with a MySQL database, using the previously mentioned attack string might also (and did already in practice) help to deceive some filters:
' or 1 --
It is also very likely, that one single quote doesn’t cause any reaction, as of false positive prevention. If it does, the following variation could also help to get through the WAF:
In general, using short test strings (and some brainpower) might help to not trigger any filtering rules.
If unsure whether a WAF is in place or not, it is advisable to first verify its existence with some fingerprinting tools. One of them is wafw00f which supports many different vendors. Another tool is tsakwaf, which supports less vendors but includes additional features for WAF circumvention like encoding capabilities for test signatures, that might be useful for SQL injection testing, when a WAF is in place.
… to be continued …
Have a great day and enjoy trying 🙂
Michael, Timo and Frank from the Appsec Team