Archive for June 2012
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
As we are receiving a lot of questions about our VMDK has left the building post, we’re compiling this FAQ post — which will be updated as our research goes on.
How does the attack essentially work?
By bringing a specially crafted VMDK file into a VMware ESXi based virtualization environment. The specific attack path is described here.
What is a VMDK file?
A combination of two different types of VMDK files, the plain-text descriptor file containing meta data and the actual binary disk file, describes a VMware virtual hard disk. A detailed description can be found here.
Are the other similar file formats used in virtualization environments?
Yes, for example the following ones:
- VDI (used by e.g. Xen, VirtualBox)
- VHD (used by e.g. HyperV, VirtualBox)
- QCOW (used by e.g. KVM)
Are those vulnerable too?
We don’t know yet and are working on it.
Which part of VMDKs files is responsible for the attack/exposure?
The so-called descriptor file, describing attributes and structure of the virtual disk (See here for a detailed description).
How is this to be modified for a successful attack?
The descriptor file contains paths to filenames which, combined, resemble the actual disk. This path must be modified so that a file on the hypervisor is included (See here for a detailed description).
How would you call this type of attack?
In reference to web hacking vulnerabilities, we would call it a local file inclusion attack.
What is, in your opinion, the root cause for this vulnerability?
Insufficient input validation at both cloud providers and the ESXi hypervisor, and a, from our point of view, misunderstanding of trust boundaries, such as that one should “not import virtual machines from untrusted sources”.
Does this type of attack work in all VMware ESX/vSphere environments?
Basically, the ESXi5 and ESXi4 hypervisor are vulnerable to the described attack as of June 2012. Still, the actual exploitability depends on several additional factors described here.
Can this type of attack be performed if there’s no VMDK upload capability?
Which are typical methods of uploading VMDK files in (public) cloud environments?
E.g. Web-Interface, FTP, API, …
Which are typical methods of uploading VMDK files in corporate environments?
In addition to the mentioned ones, direct deployment to storage, vCloudDirector, …
Will sanitizing the VMDK (descriptor file) mitigate the vulnerability?
From our perspective this should not be too difficult to implement. There are basically two steps:
- Striping leading directory paths/relative paths from the path to be included
- Restricting included files to customer-owned directories
However a certain knowledge about the specific storage/deployment architecture is necessary in order to sanitize the VMDK descriptor file and not break functionality.
Will VMware patch this vulnerability?
Probably yes. They might do so “silently” though (that is without explicitly mentioning it in an associated VMSA) as they have done in the past for other severe vulnerabilities (e.g. for this one).
Could you please describe the full attack path?
All steps are described here.
More details can be found in a whitepaper to be published soon. Furthermore we will provide a demo with a simplified cloud provider like lab (including, amongst others, an FTP interface to upload files and a web interface to start machines) at upcoming conferences.
Do you need system/root access to the hypervisor in order to successfully carry out the attack?
No. All necessary information can be gathered during the attack.
What is the potential impact of a successful attack?
Read access to the physical hard drives of the hypervisor and thus access to all data/virtual machines on the hypervisor. We’re still researching on the write access.
Which platforms are vulnerable?
As of our current state of research, we can perform the complete attack path exclusively against the ESXi5 and ESXi4 hypervisors.
In case vCloud Director is used for customer access, are these platforms still vulnerable?
To our current knowledge, no. But our research on that is still in progress.
Are OVF uploads/other virtual disk formats vulnerable?
Our research on OVF is still in progress. At the moment, we cannot make a substantiated statement about that.
Is AWS/$MAJOR_CLOUD_PROVIDER vulnerable?
Since we did not perform any in the wild testing, we don’t know this yet. However, we have been contacted by cloud providers in order to discuss the described attack.
Given AWS does not run VMware anyways they will most probably not be vulnerable.
Is it necessary to start the virtual machine in a special way/using a special/uncommon API?
Which VMware products are affected?
At the moment, we can only confirm the vulnerability for the ESXi5 and ESXi4 hypervisors. Still, our research is going on
Matthias and Pascal
0 Comments | Posted by Michael Thumann
Extract the data
If you want to extract some data from a database you first need to gather knowledge about the internal structure of the database.
One of the first steps (after determining the database type) is enumerating the available tables and the corresponding columns. Most database systems have a meta database called information_schema. By querying this database it is possible to get information about the internal structure of the installed databases. For example you could get the tables and their corresponding columns in MS SQL and MySQL by injecting “
SELECT table_name, column_name FROM information_schema.columns“. Oracle databases have their own meta tables, so you have to handle them differently. For getting the same output in Oracle, you have to query the all_tab_columns table (or user_tab_columns if you only want to search in the currently selected database). If the found vulnerability only allows to receive a single column (or if it is too complicated to identify two columns in the server response) you could concatenate the columns to one single string, e.g. in Oracle: “
SELECT table_name||':'||column_name FROM all_tab_columns“.
A much more frequent problem you have to deal with is that only the first row of a result-set is returned. To get all table and column names you have to iterate over the results. It is helpful to determine the expected row count first by injecting a “
SELECT COUNT(column_name) FROM all_tab_columns“. Iterating over the results in MySQL is simple: “
SELECT table_name, column_name FROM information_schema.columns LIMIT $start,1” (where $start denotes the current offset in the result-set). MS SQL doesn’t support to specify ranges for the results. This is why you have to combine several select statements to get the same result:
SELECT TOP 1 table_name, column_name FROM (SELECT TOP $start table_name, column_name FROM information_schema.columns ORDER BY table_name DESC) ORDER BY table_name ASC
(where $start denotes the row number you want to extract).
If you are confronted with a large database, it is always easier to search for interesting column names instead of tables. So you can combine the mentioned query statements with where clauses to search for columns which contain ‘pass’ or ‘user’.
If the found vulnerability is a blind or totally blind SQL injection, you have to use boolean expressions to extract some data. One approach is getting the database username (or any other data) by doing a binary search with the procedures
For example on Oracle databases you would get the first character of an username by injecting “
ASCII(SUBSTR(username, 1,1))” into the where clause. To do a binary search on ‘Admin’ you would do “
ASCII(SUBSTR(username, 1, 1)) < 128” which results in true. The next value to compare with is 64 (which is right in the middle of 0 and 128). This time the query would fail because the ascii value of ‘A’ is 65. Now you compare with 96 (the middle of 64 and 128) and so on, until you reach 65. After that you will treat the remaining characters in the same way.The following excerpt is an output from sqlninja (which will be covered again later on), which uses this technique in an automated way on a totally-blind SQLi vulnerability:
[ … ]
if ascii(substring((select system_user),1,1)) < 79 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 55 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 67 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 73 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 76 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 77 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 78 waitfor delay '0:0:5';
if ascii(substring((select system_user),1,1)) < 78 waitfor delay '0:0:5';
Here he found the first character: N
and now continues with the second:
if ascii(substring((select system_user),2,1)) < 79 waitfor delay '0:0:5';
[ … ]
As the manual extraction of data can be quite time consuming, the usage of automated tools becomes essential. There are various tools that may help identifying and exploiting SQLi vulnerabilities. One of them is sqlmap, which concentrates on blind SQL injection, it comes with many options and supports a lot of different Database Servers (amongst them MS-SQL, MySQL, Oracle and PostgreSQL) which is one of the reasons why it is covered in this article. The extraction process is very intuitive and sqlmap tries to identify automatically the sort of SQLi (Blind, totally blind …) if not specified, so it is easy to get it up and running in a few minutes. We are not going into great detail, as this would go beyond the scope, but are showing a few commands which may already suffice to let sqlmap extract all available data from the database. Prerequisite for the following scenario is an already identified SQLi Vulnerability:
The first command tries to enumerate all available databases using the vulnerable parameter “txtUserName”:
sqlmap -u "http://172.16.141.128/vulnweb/SQLInjection/Login.aspx" --data=__VIEWSTATE=dDwtNjI1NzM1OTs7Pv6HhHTCvfGeXKasVQXuFgQtgqym\& txtUserName=\&txtPassword=\&Button1=OK --dbms=mssql --dbs -p txtUserName
The next command enumerates all available table names of the found databases without the need to specify the database names as all gathered information are stored in a local progress file and automatically used for all further attacks:(This feature becomes important as soon as the amount of already collected data gets vastly large.)
sqlmap -u "http://172.16.141.128/vulnweb/SQLInjection/Login.aspx" --data=__VIEWSTATE=dDwtNjI1NzM1OTs7Pv6HhHTCvfGeXKasVQXuFgQtgqym\& txtUserName=\&txtPassword=\&Button1=OK --dbms=mssql --tables -p txtUserName
After using the same command but with the –columns option instead of –tables, enough necessary information were gathered to identify potential interesting tables of which now data can be extracted from. As this process might sometimes last too long, it is also possible to search for specific column names like “password” with the –search option. If however time doesn’t matter or the content is expected to be not very large, the –dump-all option may be used to extract all data contained in all databases.
As SQLi vulnerabilities enable an attacker not only to extract data, but sometimes also to execute system level commands, it is possible, and most tools offer such an option, to upload and execute binary files like e.g. netcat, resulting in an interactive shell with the same rights of the SQL server process (in the worst case root/administrative rights).Going one step further, sqlmap respectively sqlninja (a handy and in some cases less buggier than some others, but MS-SQL only SQLi tool) are able to use the exploitation framework Metasploit, which offers various attack payloads like “Creation of an administrative user” or a “Reverse-TCP shell”.In that way it is for example possible, to upload the powerful Meterpreter payload using an existing SQL injection vulnerability within a web application. Once started, Meterpreter enables system level access and can be used (depending on the rights of the database server process respectively the patch status of the underlying system) to extract system level data and utilize the database server as a jump host to an internal network or to exploit a local privilege escalation vulnerability to gain administrative rights.
An attacker uses an existing SQL injection vulnerability to upload and execute the meterpreter payload, then added a route entry within metasploit, making the internal network of the SQL server accessible through the meterpreter session and is now able to scan and attack systems behind the server, which would normally be not reachable from the attacker side.
Rating of the findings
After doing all the testing stuff, there’s one important step missing, at least if we are talking about a professional pentest. The criticality rating of findings is a mandatory task in the course of a pentest. On the one hand, the comparative value of the rating must be guaranteed, on the other hand, the rating must be appropriate for the environment which is in scope of the pentest. Based on these requirements, we propose the Common Weakness Scoring System as an appropriate metric for the rating of web application related security findings like SQL injection.The design considerations of CWSS include the applicability for scoring processes as well as the integration of stakeholder concerns or environmental requirements. These considerations result in the definition of three different metric groups which each contain different factors:
Different entities may evaluate separate factors at different points in time. As such, every CWSS factor effectively has “environmental” or “temporal” characteristics. Different pre-defined values can be assigned to each factor and each factor also has a default value. The different values for the single factors are explained in detail here:
CWSS uses also a reliability factor, so the factor Finding Confidence is explained as an example above.
All factors will be combined using a formula, which results in a value between 0 and 100. The higher a weakness is scored, the higher is the associated criticality. Regarding the formula and the used factors and weights, the CWSS allows a precise, comparable, and reproducible rating of vulnerabilities in the context of web application pentests. The rating will also help the application owner to prioritize the findings and use the always limited resources for the most critical issues.
Bringing the mentioned steps of the methodology together, you can follow a small checklist to identify all SQL injection issues in an application and help the application owner to mitigate the most severe problems. But every shortening of the test steps will have a negative influence on your success rate and the acceptance of the results:
1. Identify all input vectors
2. Test all input vector with a set of test signatures
3. Identify the database
4. Exploit the SQL injection vulnerability to proof the existence and avoid any discussions
5. Rate the criticality of the findings based on a metric
… the end
Thanks for following us and staying tuned to wait for all the parts of this article. If you missed one or both of the earlier posts, don’t forget to read “SQL Injection Testing for Business Purposes Part 1” and “SQL Injection Testing for Business Purposes Part 2” to get it all.
Michael, Timo and Frank from the Appsec Team