By Samuel Erb & Phil Bertuglia
At Akamai, the Enterprise Security Red Team (ESRT) continuously strives to evaluate the security of both our external and internal services. We look at the security of the services we build and purchase for security vulnerabilities that could negatively impact our business and our customers. During a scheduled sorti, the ESRT investigated how to pivot access from a local package management system used to support our endpoints. While that system didn't yield a direct finding, we did find a transitive relationship with a Quest Kace 1200 system, also used to manage corporate devices. So, we decided to take a closer look at our KACE Management Appliance.
When reviewing this appliance, we tested to see if there were any vulnerabilities that could be used to escalate an average user's permission to impact other users. We were able to identify one vulnerable endpoint that we could leverage for a [SQL injection attack](https://owasp.org/www-community/attacks/SQL_Injection).
SQL injection attacks are not always obvious. Rarely will you see a SQL error rendered to an end user. Instead, SQL injection attacks are often "blind" with no visible output. One way to detect this without access to the source code of an application is to use "blind" payloads, that contain SQL sleep/delay functions (such as MySQL "SLEEP()" ). When executed they will delay rendering of the page, waiting for a response from the database. The amount of time spent sleeping/delaying the page rendering can also be used to slowly exfiltrate data.
In order to identify this blind SQLi, we used a SQLi "sleep" wordlist in combination with the burp request timer plugin:https://github.com/1N3/IntruderPayloads/blob/master/FuzzLists/sqli-time-based.txt (for example) https://portswigger.net/bappstore/56675bcf2a804d3096465b2868ec1d65
As you can see in the image above, requests taking longer than 5 seconds become obvious, highlighting the time-based SQL injection.
Once this was discovered, other automated testing revealed that this same injection point is also vulnerable to error based, or Boolean, SQLi. For example, the following request will result in a server side SQL error causing a different HTTP response being returned compared to a normal page error (400 vs 500 for example).
http://XXXX/common/user_profile.php?ID=46086&table_id=up_assigned_devices_table&sort_column=IS_PRIMARY_DEVICE&sort_direction= AND 3514=(SELECT (CASE WHEN (3514=3514) THEN 3514 ELSE (SELECT 1249 UNION SELECT 6766) END))-- Ixbp&records_per_page=5&page_number=1
Boolean operators can be used within injected SQL statements in combination with this vulnerability, such as '>' and '<'. This allowed a binary search algorithm to be used that had significantly faster read-only access to the database than the time-based approach. Using this method, we were able to read all tables in the database, including endpoint management information and user details.
Unfortunately, this does not appear to be the only blind SQLi observed recently in this product. In 2018, a similar defect was reported (CVE-2018-5404).
Impact:
Using this exploit, we observed that older KACE accounts on our system had fixed-salt sha1 passwords. Recently-used accounts used a more modern password hashing scheme. With that in mind, we recommend upgrading and rotating passwords for all privileged users.
Timeline:
7/23/2020: vulnerability identified & reported
11/02/2020: KACE version 11.0 released
Article Link: https://blogs.akamai.com/sitr/2021/03/cve-2020-15915----quest-for-kace-blind-sqli.html