CVE-2018-5559 my first CVE

TLDR

CVE-2018-5559 is a information disclosure security vulnerability in Komand Security Orchestrator (v0.40.2) that has been disclosed responsibly to Rapid 7 and has been mitigated and patched within days (version >0.42.0). The vulnerability itself is not worth to have a logo.

Introduction

Being a security professional I happen to hear a lot of people complaining about companies handling responsible disclosure in a way that is not appreciated by customers (by sitting on patches to long) or by the disclosure (by not reacting etc). The following blog post is report about a very positive case that I happen to have by disclosing my very first security vulnerability. I really hope this one is being shared and that companies adopt some of the positive aspects. At the very end of the post I will also try to lead to further points where either researchers or companies can read further about the topic.

The stage

Being interested in various APIs that are interesting to security people (eventually turning into dedicated list of APIs on Github) I stumbled across Komand Security Orchestrator. As there was no documentation available (heads up Rapid 7, that fact needs some love!) I spent some time to reverse engineer and discover APIs with Google Chrome developer tools and Python and actively sharing my results on github.

One of the API endpoints was /connections:

https://komandurl/v2/connections 

Connections

Komand Security Orchestrator is made to interact with various (security related) tools to interact and create so called workflows. To achieve that goal, Komand needs credentials to those tools. Every set of credentials is stored in a central keychain that is accessible for workflows. Most connections store some kind of URL, Username and password.

Given this nature, credentials stored in this keychain have either higher Privileges to accomplish tasks or are able to see more than the regular user.

Every Plugin can have it’s own set of credentials, so let’s say you have the LDAP plugin to connect to Active directory, there could be a dedicated set of credentials for prod and qual active directory.

Surprise

After my first GET request to the connection API endpoint something got my attention. While most of the connections have the password field *****ed out, some did not – WTH?
Most look like the following:

"name":"VT Private API","type":"plugin","parameters":{"api_key":"********","url":"https://www.virustotal.com/vtapi/v2/"} 

But OTRS looks like the following:

{"connection_id":36,"plugin_id":75,"name":"OTRS Dev User:komand_test","type":"plugin","parameters":{"server":"https://`EDUCTED","credentials":{"password":"REDUCTED","username":"komand_test"}},"created_at":"2018-08-08T10:56:54Z","updated_at":"2018-08-08T10:56:54Z","deleted_at":null,"deleted_by_id":null} 

And LDAP:

{"connection_id":39,"plugin_id":72,"name":"ÀD","type":"plugin","parameters":{"host":"ldaps://LDAPURL","port":636,"use_ssl":true,"username_password":{"password":"CLEARTEXTPASSWORD","username":"AD\\USER"}},"created_at":"2018-10-05T11:53:47Z","updated_at":"2018-10-05T11:53:47Z","deleted_at":null,"deleted_by_id":null} 

Scope – pre-requisite

To get the above mentioned list of connections you need to have a to be an authenticated admin, so it is not open to everyone.

Scope – affected plugins

As not every password was visible, several plugins have been tested (not every plugin!) and thus two Plugins seem to be affected:

LDAP plugin and OTRS plugin

Impact

To score the vulnerability, the best way to go for is leverage CVSS, and the rating for this vulnerability is a CVSS Score:3.1

CVSS Base Score:3.4
Impact Subscore:1.4
Exploitability Subscore:1.7
CVSS Temporal Score:3.1
CVSS Environmental Score:3.1
Modified Impact Subscore:1.4
Overall CVSS Score:3.1

Responsible disclosure process

October 25, 2018 14:42 created issue with Rapid 7 online portal / Mail to Circl.lu

So I found the issue and wanted to get it fixed as soon as possible and have a CVE assigned, my first reaction was to reach out to my friends from CIRCL.lu to assist and assign a CVE, so I sent them a pgp encrypted mail to info@circl.lu.

Side-note: By accident I had a local mail rule, filtering out all mails from info@circl.lu to a sub folder and marked them as read, that is a stupid thing to do if you expect an answer from them and caused some confusion afterwards, so for clarification, they were very responsive and their reaction time is in hours, so if you do not know who to disclosure with a 3rd party, CIRCL is a great way to get it started and they have a profound network of contact points.

Then I looked on rapid 7 webpage and found that they have a responsible disclosure statement and procedure in place as well so I gave it a shot with opening an issue there.

The portal is very well done and requesting information that are good for engineers to assess the impact as fast as possible, it is even possible to propose a CVSS rating (more to that later)

October 26, 2018 First reaction of Rapid7

Rapid7 gave a SYN / ACK to have received the issue and that Engineering and Support is working on scoping and verifying the issue.

October 26, 2018 Rapid7 verifies it is an issue

On the same day the designated person made a note in the online portal to verify it is an issue and that they are working on fixing it.

October 30,2018 Rapid7 case update

Note on the online portal, Rapid 7 team is working on a fix and providing a rough timeline that a patch should be available the same week and that assigning an CVE is in progress as well.

November 1,2018 Rapid 7 case update

Another note that fix is on the horizon

November 1,2018 Komand Release Notes

On that day a Mail was sent out announcing a new version „Komand Release Notes“. In the Bug fixes area this was mentioned:

v0.42.0: Certain endpoints that are able to list the always encrypted-at-rest connection data could return some configurations of connection data without obscuring sensitive data from the API response. We fixed this issue, and all configurations of connection data are now correctly obscured.

November 1,2018 Komand slack

Via Slack, Komand engineers are asking for my feedback if the patch is indeed fixing the issue I reported, after updating I was able to confirm that.

November 2,2018 pro assigned CVE

Rapid7 reached out to me and CIRCL (who seems to have reported the issue in parallel but I had no SYN ACK from them but told them that they did not need to further disclose as soon as I discovered the Rapid 7 portal.
In this mail I was told the pre assigned CVE for the issue and the CVSS rating their engineering team came up with. They also asked if I plan to write a blog post or other coverage (which you can read at the moment).

Affected?

All versions below 0.42.0 is affected. Afaik it is only the OTRS and the LDAP plugin.

Mitigation

Patch to Komand version 0.42.0 or later. I would recommend to reset the password to all accounts stored for LDAP and OTRS plugins.

Exploited?

Most people might ask – alright, so how can i find out if someone with bad intention has used this vulnerability. The only way to tell is to check the web logs of Komand and look for GET requests to /v2/connections from unusual source IPs.

Feedback

The way this issue was handled was straight forward, at any point I had the impression that my issue was treated on the right level, no over hyping and no „we don’t care“ just the right balance.
It is notably that the online form used by Rapid7 is supporting this process a lot, I assume it makes it easy to scope issues on engineering site as well as easy for the researcher who wants to know what the current status of the reported issue is.

It is also good to see that the work from the FIRST CVSS sig is adding value in such issues as it helps both sides to rate the vulnerability.

Links

https://nvd.nist.gov/vuln/detail/CVE-2018-5559

https://github.com/CVEProject/cvelist/pull/1303

Further reading

To lean more about best practices in responsible disclosure I would recommend:

https://titanous.com/posts/security-disclosure-policy-best-practices