2 AFFECTED PRODUCTS
The following Products have been tested as vulnerable so far:
Cisco Unified Meetingplace with the following modules:
• MeetingPlace Agent 7.1.1.9
• MeetingPlace Audio Service 7.1.1.8
• MeetingPlace Gateway SIM 7.1.1.2
• MeetingPlace Replication Service 7.1.1.9
• MeetingPlace Master Service 7.1.1.8
• MeetingPlace Extension 7.1.1.8
• MeetingPlace Authentication Filter 7.1.1.8
3 DETAILS
The following parameters are affected:
http://$IP/mpweb/scripts/mpx.dll [POST Parameter wcRecurMtgID]
4 VULNERABILITY SCORING
The severity rating based on CVSS Version 2:
Base Vector: (AV:N / AC:L / Au:S / C:P / I:P / A:P)
CVSS Version 2 Score: 6.5
Severity: Low
As we are at the topic of Cisco’s Unified Communications Solution, there is a lot more in the queue to come up, just be patient a little longer, it’ll be worth it (-;
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 ASCII and SUBSTR.
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:
[ … ] ++++++++++++++++SQL Command++++++++++++++++
if ascii(substring((select system_user),1,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”:
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.)
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.
Final Conclusion
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
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 --
to
' 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.:
benchmark(3000000,MD5(1))
For later versions:
sleep(5)
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:
DBMS_LOCK.SLEEP(5)
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
return new_username
else
return EXISTING_USERNAME
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:
abc'def
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
SQL injection attacks have been well known for a long time and many people think that developers should have fixed these issues years ago, but doing web application pentests almost all the time, we have a slightly different view. Many SQL injection problems potentially remain undetecteddue to a lack of proper test methodology, so we would like to share our approach and experience and help others in identifying these issues.
