Uncommon SQL Database Alert - Informix SQL Injection

A client was looking to upgrade their Cisco UCM software and wanted assurance that their implementation was configured securely. During the assessment, we had discovered an authenticated SQL Injection issue within the Cisco UCM administrator portal. In most cases, this discovery can be followed up with using SQLMap or other tools to automatically exploit the issue.

Seeing as we were testing within the client’s development environment, we were given permission to perform more aggressive attacks against Cisco UCM. The SQLMap command I originally used was the following:

The request file contained something the following:

After letting SQLMap do what it does, a database was identified: Informix SQL. Additionally, the method of injection was Blind Boolean. From there, SQLMap can usually be used to enumerate the underlying database and potentially gain access to passwords and sensitive data. However, after using SQLMap to perform those tasks, some issues became apparent:

• SQLMap was able to enumerate the name of the current table, but was unable to enumerate other database names and other table names
• SQLMap was able to enumerate the current SQL user name but was also reporting over 1000 users for the underlying database and could not enumerate the other 999 users
• SQLMap was unable to enumerate any information relating to any user’s password within the "applicationuser" table

The following sections will be used to demonstrate how the root cause of each issue above were identified and how these issues were overcame.

Before continuing, some research was put into learning about Informix SQL.

The following is a quick lesson on the "systables" table:

• Informix keeps a record of all table information within the table "systables"
• The different columns within "systables" represent different information, such as the column "tabname" represents a specific table’s name and the column "tabid" represents a specific table’s ID number
• Other information can include the column "ncols" which is the number of columns in the table, and the column
  "nrows" which is the number of rows in the table

So as an example, let’s assume that a table was named “yaytableyay”. To retrieve the "tabid" number, the following query could be used:

To take it further, if we wanted to find the number of rows within the "yaytableyay" table, we could make the following query:

The following is a quick lesson on the "syscolumns" table:

• Informix keeps a record of all column information within each table
• The different columns within "syscolumns" represent different information, such as the column "colname" represents the specific column’s name and the column "tabid" represents which table the column is assigned to
• Other information can include the column "colno" which is the system sequentially assigned value from left to right

So as an example, if we wanted to find out the name of the first column within the table "yaytableyay":

Additionally, every table has a hidden column called "rowid". This value is assigned to each row in a table, but is not deleted when a row is deleted. For example, the following query could return no data due to the row being previously deleted:

There is also a chance that a row never even existed. This will still force the database to return the same ‘0 results’ as if the row was deleted. So when using a "rowid" as a "WHERE" clause, there is no way to differentiate between a row that was deleted and a row that never existed.

One of the best things you can do to troubleshoot any SQLMap issue (or any tool for web application testing) is to proxy the traffic from the tool. In this case, proxying SQLMap through BurpSuite helped identify that whenever SQLMap was instructed to enumerate other table names and database names, the server would always respond with one of the following errors:

• ERROR: A subquery has returned not exactly one row.
• ERROR: "NVL" cannot be used in a query
• ERROR: "RTRIM" cannot be used in a query
• ERROR: "LIMIT" cannot be used in a query
• ERROR: "LENGTH" cannot be used in a query

The first error "not exactly one row" was Googleable and could be linked back to Informix. The other errors appeared to be generic restrictions that were built into Cisco UCM itself. With those error messages in mind, it would appear that a custom script and/or tool would be required to further exploit this issue.

In order to enumerate each table, a work flow was established:

• Figure out how many valid tables were stored within the database
• Enumerate each table name letter by letter
• Enumerate how many rows and columns were in each table

To figure out how many valid tables existed, we used the "tabid" value. Specifically, we performed some "greater than" and "less than" operations based on the following payload:

The above payload would force the server to return the ASCII value for the first letter of each table name if their "tabid" value was more than 1. This of course returned multiple results since there is surely more than 1 table which forced the server to respond with another "Result is more than 1 column" error. However this was expected because the idea that *something* returned means that *something* exists. To illustrate this point further, take the following payload:

Now we are looking for tables whose tabid value is greater than 100. If a table does not exist because a tabid value over 100 does not exist, then the server will respond with no data.

So based on this behavior, we can enumerate how many tables are in the underlying database:

We have now established that the number of tabids within the current database is 75.

Next, establishing table names was required. Utilizing the ASCII value function was still an option, so we used similar logic that was used to establish the number of tables. The following payload would determine if the ASCII value of the first letter of the first table name was greater than 64:

From this behavior, we can enumerate what the first letter is:

Based on the above, the first letter of the first table must be an ASCII value of 101, or ‘e’.

Moving onto the next character in the table name, we would replace:

With:

From this point, we can enumerate what the second letter is:

Based on the above, the ASCII value of the first letter of the first table must be 110, or ‘m’.

For the sake of this blog post, the table that was enumerated in the above example is “empire”. The rest of the table names could be enumerated using this method.

After enumerating a table name and associating it with a tabid value, we can start to build some column information.

The following query could be used to help figure out how many columns are in the table “empire”:

The following query could be used to help figure out the name of the first column within the “empire” table:

When SQLMap was trying to enumerate the other SQL users, the table “sysusers” was used. And similar to the “enumerating other tables” section of this write up, the server would continue to respond with errors when SQLMap tried to enumerate other users.

In the previous section, we covered how to use the "tabid" column as a sequential number system that could be used to enumerate tables. After looking up how the “sysusers” table is organized, it was found that there was no viable sequential number system. As per IBM's official documentation, the following columns make up the "sysusers" table:

• username
• usertype
• priority
• password
• defrole

It was at this point that we used the hidden column “rowid” as part of the “WHERE” portion of our SQL query. The following example query could be used in enumerating the ASCII value of the first letter of the first username where the rowid was 1:

After enumerating the first username, we can proceed to enumerate the other usernames based on the "rowid" value:

It gets interesting when the "rowid" value reaches reaches the 5000s:

To help resolve this, the “nrows” column in the “systables” table could be used to help establish when we have found a valid user. This is because the “nrows” value is determined based on the number of non-empty rows in a table.

The following query could help determine the number of rows in the “sysusers” table:

Using this query, we can determine that the number of rows with data in the “sysusers” table was 1000:

With this in mind, we can start using ‘rowid’ and ‘ncols’ to enumerate all the usernames within the ‘sysusers’ table. By incrementing the ‘rowid’, we can cycle through queries and every time a query returns data, we reduce the ‘ncols’ value by 1:

With a set of known rowids with non-empty rows, we can now start to enumerate usernames without having to run any custom scripts indefinitely:

As previously stated, the "sysusers" table contained a row called "password". It was also found that the Cisco UCM software utilized the table "applicationuser" to store users related to the Cisco UCM software, which also contained a "password row".

Using the previously discussed techniques, it should have been possible to enumerate the entire “app_users” table…that is, until the following query:

That is a weird error message, and not very Googleable. After some testing, it was determined that the server would only respond with that error when trying to enumerate the “password” column in any table. Based on this behavior, we had assumed that it was a blacklist keyword situation at the application level.

And we were right! All I had to do was URL encode “password” to get past this issue:

SQL Map could not be used to exploit this issue, so F-Secure resorted to creating two scripts to fully exploit this issue. Since this issue requires authenticated access to the Cisco UCM administrative console, both scripts require the user to submit their session cookies.

• sql_injection_enumerate_tables.py - enumerates the name of each table on the database and stores them in a file called "cisco_tables.txt"
• sql_injection_extract_table.py - reads the entries in "cisco_tables" and enumerates the contents of each table entry

Both scripts don't automatically URL encode specific words that would trigger a security alert, such as "password". It is recommended that the scripts are proxied through BurpSuite or some other proxy tool that URL encodes words that might trigger security alerts.

The techniques described in this blog post were used to enumerate the entire database of Cisco UCM version 11.5.1.14900-11. Cisco was informed of this issue and patches are currently in development. A joint disclosure date was agreed upon for 20 November 2019.

• F-Secure's official advisory for this issue that affects certain installations of Cisco UCM can be found here: https://labs.f-secure.com/advisories/cisco-ucm-informix-sql-injection
• Scripts that were developed to fully exploit this issue can be found here: https://github.com/FSecureLABS/Cisco-UCM-SQLi-Scripts