SecureWorks Red Cloak Local Bypass (CVE-2019–19620)
At the time of discovery, my (then) employer was using a suite of SecureWorks services, with a product called Red Cloak being a core component. In short, Red Cloak is used to outsource the huge task of endpoint detection to a 24x7, high standard of quality Security Operations Center.
In August of 2019, after going some time without any alerts from Red Cloak, we wanted to double check that it was actually doing anything. I downloaded the Mimikatz binary without any modifications to a unique folder on the local C:\ drive of a testing endpoint. I allow-listed this folder in the other security products in the environment and removed all permissions to the folder except for my testing account, to ensure that a potential attacker could not use my tools against me. Then, I ran Mimikatz successfully — and did not receive any alerts from Red Cloak. Uh oh, what happened?
I opened a support ticket to review and we started looking at various log files. When we execute the standard ‘Red Cloak Test’ methodology, alerts were fired off no problem. We found the following screenshots in the log files that explained what was happening.
Above shows a specific module in the Red Cloak agent saying that it sees the event created for launching Chrome, and successfully ends up writing some sort of log file in the folder directory for the image launched.
Above shows the error that happened when I had removed all permissions except for my own user account. Creating the log file in the folder structure failed because the system account Red Cloak was using couldn’t write to that folder. This caused a logical bypass to happen; since this little step of the overall telemetry process failed, no alerts were made and no record of Mimikatz being executed appeared in the Red Cloak portal, only in the local log file. Which, of course, an attacker than can already modify a malicious file permission would be able to modify as well. After putting system permissions back to default, this is what happened next, and an alert was fired off:
An additional issue was discovered that to see the above log files you must have enabled verbose logging, which required a system restart to take affect. In short there, if you did not have verbose logging enabled in advance, even the local log files would not indicate an attempt to execute malicious files — or really any file with system permissions removed!
Secure Works immediately acknowledged the bug and agreed to a 90-day target fix, and requested a delay in publication until customers could update. As I understand the fix, modules are now independent of each other — if this module fails, the other modules still report and alert on activity. Essentially, this was a logic flaw in the agent’s workflow. They were mostly good about communication in regards to the fix process, but have seemed to downplay the potential severity of this bug. I do agree with the Secure Works stance that because local access is required, the potential for exploit is low. However, if you’re using Red Cloak in an environment that may be targeted by true advanced, persistent threats this could cause a high impact in those more specific situations. Considering the portrayed client base of Secure Works, this downplaying of impact is worrisome to me. (Edit: for full disclosure, the SecureWorks Counter Threat Unit sent me a numbered challenge coin as a thank you. While that is cool and appreciated, there was no bug bounty awarded, etc.)
It is not currently known what version this logic bug was introduce in, or if it existed from the start of the Red Cloak product line. However, as of Windows Agent 2.0.7.9 it is confirmed to be corrected. This agent version also allowed logging level changes without restarting. Agent 2.0.7.9 was released October 29th, in advance of the industry-accepted 90 day window. I requested a CVE for this issue to help push public awareness, in addition to this blog post, but I am frankly not sure if this meets the criteria for a CVE. *Update: CVE-2019–19620 was assigned for this issue.*
So now for the tl;dr
Trivial local bypass of Secure Works Red Cloak telemetry discovered August 2019. Impact is not considered high, due to local access requirement.
Bypass occurred whenever SYSTEM permission is removed from a file or directory.
Fixed agent version released October 29th, 2019.
Blog publication and CVE request December 5th, 2019.
UPDATE: CVE-2019–19620 is assigned for this issue.
UPDATE 2: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19620 released December 6th, 2019.
