During a security assessment for one of our clients we discovered an authenticated SQL injection vulnerability in the intelligent Workload Distribution (iWD) system developed by Genesys.

The iWD-Manager had a filter function which enabled us to execute arbitrary SQL queries. In this case it was possible to dump the database via time-based blind SQL injection.

iWD 9.0.012.08 - time- and boolean-based blind SQLi (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:H)

At the time of the testing the company used a slightly outdated version (9.0.012.08) of the iWD. As previously stated to enable efficient work with the large amount of data iWD has a filter function. As the following screenshot shows the user can define different matchers for different columns. The result of the search is returned as JSON.

These matchers allowed not only binary matching, like "column1 = 'text'" or "column2 < 200" but complex ones as well, like the SQL operator "LIKE". The user defined filter was transmitted via the GET parameter ql_expression.

At this point we got suspicious that this parameter might be taken as is and inserted into an SQL query without any kind of sanitization thus allowing SQL injection. After some trial and error it was clear, that we can access SQL functions like "CONCAT". It was time to take out the big guns and let sqlmap do its magic.

After a few minutes our suspicion was proven right. Sqlmap identified both a boolean-based and a time-based blind SQL injection vulnerability with the aforementioned ql_expression parameter.

Parameter: ql_expression (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: entity_dbid=6497&entity_type=solution&release_snapshot=4_23&ql_expression=column_1 LIKE CONCAT('%','value') ) AND 8894=8894 AND (8067=8067

    Type: time-based blind
    Title: Oracle AND time-based blind (heavy query)
    Payload: entity_dbid=6497&entity_type=solution&release_snapshot=4_23&ql_expression=column_1 LIKE CONCAT('%','value') ) AND 6204=(SELECT COUNT(*) FROM ALL_USERS T1,ALL_USERS T2,ALL_USERS T3,ALL_USERS T4,ALL_USERS T5) AND (6962=6962

By exploiting this vulnerability we ware able to access the following information:

  • name of the current user
  • hostname of the database
  • DB users
  • list of databases
  • list of tables
  • list of columns
  • content of tables (limited to the ones our user had access to)

Due to the nature of the underlying database engine (in our case Oracle) and its configuration it was not possible to insert, update or delete any data or execute OS commands.

iWD 9.0.017.07 - time-based blind SQLi (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:H)

Due to the criticality of the issue it was reported to the customer immediately. As there were several newer versions of the software the customer decided to update to the - at the time - most current version (9.0.017.07) with the hopes that this issue was already fixed in an intermediate update.

The newer version indeed introduced some changes regarding the filtering function. For one it no longer used a GET request but a post one. The user defined filter was transmitted via the JSON object in the request body. Following screenshot shows an example request.

As it can be seen the filter expression was split up into three parts:

  1. operator (LIKE, <, >, =, etc)
  2. value (to which we compare the content of a column)
  3. attribute (name of the column we are searching in)

We did not find any information in the release notes that this change was induced by a security issue thus we were confident the SQL injection vulnerability is still present but the payload has to be adapted. As manual experimentation was not successful we spun up sqlmap to find out if SQLi was still possible.

Lo and behold after a few minutes sqlmap identified a new payload which could be used to perform a time-based blind SQL injection:

Parameter: JSON value ((custom) POST)
    Type: time-based blind
    Title: Oracle time-based blind - Parameter replace (heavy queries)
    Payload: [{"operator":"LIKE","value":"(SELECT (CASE WHEN (8522=8522) THEN (SELECT COUNT(*) FROM ALL_USERS T1,ALL_USERS T2,ALL_USERS T3,ALL_USERS T4,ALL_USERS T5) ELSE 8522 END) FROM DUAL)","attribute":"column1"}]

The impact of this "new" vulnerability is the same as for the version 9.0.012.08, we ware able to access internal information like hostname or the current user or dump the whole database.

Both issues were disclosed privately to the vendor (Genesys) in the form of a responsible disclosure. After some internal analysis they confirmed the existence of the vulnerability and released a hotfix (9.0.018.05) on 21.10.2021 which resolves this issue. Although an attacker has to have access to the software to exploit this vulnerability we would recommend to update to the newest version nevertheless.

The following two CVE numbers were requested:

  • CVE-2021-40860: Authetnicated SQLi in Genesys iWD < 9.0.013.11
  • CVE-2021-40861: Authenticated SQLi in Genesys iWD between 9.0.013.11 and 9.0.017.07