LogRhythm Web Console Vulnerabilities

Scope

High-risk vulnerabilities have been identified in the LogRhythm Web Console.

Risk

The risk of these vulnerabilities is high. However, “real-world” exploitation of the vulnerabilities does require certain pieces of information about the target organization’s LogRhythm NextGen SIEM and Web Console infrastructure that are not readily available to an outsider¹.

Affected Product(s) and Software Version(s)

• LogRhythm SIEM: All version 7.x.x releases prior to (but not including) version 7.6 
• LogRhythm Cloud

Vulnerability Status

• The vulnerabilities disclosed in this report were made public four weeks after the release of LogRhythm 7.6 to provide our customers the time necessary to upgrade. Version 7.6 was release on Nov. 18, 2020.

Remediation Status

• The vulnerabilities have been remediated in LogRhythm SIEM version 7.6 (release date of Nov. 18, 2020).
• All LogRhythm Cloud deployments have been be upgraded on Dec. 3, 2020.
• We recommend you use the compensating controls (outlined below) to mitigate the vulnerabilities. Additional monitoring controls will be made available on the Community post titled, .

Summary of Vulnerabilities

External researchers from CyberCX, an Australian-based cybersecurity services company, discovered three high-risk vulnerabilities in the LogRhythm Web Console. They quickly engaged with LogRhythm, through a responsible disclosure process, to determine the cause of the vulnerability, available compensating controls, and what needed to be done to remediate it. The three vulnerabilities consist of the following:

CVE-2020-25094: Command Injection

• LogRhythm Platform ManagerDeployment 7.x.x (prior to but not including 7.6) allows Command Injection. To exploit this, an attacker can inject arbitrary program names and arguments into a WebSocket. These are forwarded to any remote server with a LogRhythm SmartResponse agent installed. Commands are run with the privileges of the LogRhythm System Monitor Agent, by default “LocalSystem.”

CVE-2020-25095: Cross Site Request Forgery

• LogRhythm Platform ManagerDeployment 7.x.x (prior to but not including 7.6) allows CSRF. The Web interface is vulnerable to Cross-site WebSocket Hijacking (CSWH). If a logged-in PM user visits a malicious site in the same browser session, that site can perform a CSRF attack to create a WebSocket from the victim client to the vulnerable PM server. Once the socket is created, the malicious site can interact with the vulnerable web server in the context of the logged-in user. This can include WebSocket payloads that result in command execution.

CVE-2020-25096: Incorrect Access Control

• LogRhythm Deployment 7.x.x (prior to but not including 7.6) has Incorrect Access Control. Users within the LogRhythm SIEM can be delegated different roles and privileges, intended to limit what data and services they can interact with. However, no access control is enforced for WebSocket-based communication to the PM application server, which will forward requests to any configured back-end server, regardless of whether the user’s access rights should permit this. As a result, even the most low-privileged user can interact with any back-end component that has a LogRhythm agent installed.

How to Exploit the Vulnerability

While the three vulnerabilities could be used in many ways (either in combination or alone), we believe that most exploitation sequences would follow a pattern similar to the following:

In our view, initiation of the chain via the cross-site-request-forgery vulnerability is likely the highest-risk scenario² because it potentially allows for “drive-by” exploitation of an existing session. In most scenarios, an attacker must already know the hostname and port used by the LogRhythm Web Console in order to leverage the above chain via the CSRF exploit (CVE-2020-25094). It should be noted that this is not the case if the end-user is utilizing the LogRhythm Web Console directly from the Platform Manager (PM). LogRhythm views this scenario as the highest-risk scenario involving the vulnerabilities³.

Compensating Controls

LogRhythm software version 7.6, scheduled for release on Nov. 18, 2020, has addressed and remediated all three of the vulnerabilities. At a minimum, we strongly recommend implementing the “Browser Security” compensating control listed below. This control is the easiest to implement, is the least intrusive, and prevents the entry point of the exploit chain (CSRF, CVE-2020-25094) from occurring. These compensating controls can be implemented now, prior to the LogRhythm version 7.6 release, and they can mitigate risk as our customers upgrade to the latest version of our software. As additional compensating controls are developed, we will release subsequent notices as they are available.

Browser Security

• In our opinion, preventing the CSRF portion of the exploit chain (CVE-2020-25095) is the most critical vulnerability to mitigate⁴. We recommend only using up-to-date versions of Google Chrome and Microsoft Edge to access the LogRhythm Web Console (until updating to LogRhythm version 7.6). The default security settings in Google Chrome 86.0.4240.111 (or later) and Microsoft Edge 86.0.622.51 (or later) prevent the CSRF portion of the exploit from occurring and make it much more difficult for an attacker to leverage the other two CVEs. It should be noted that your organization may use a custom Chrome/Edge policy that may contain non-default settings. Please verify your Chrome/Edge settings as detailed in the “Browser Security (Detailed Information)” section below.
• Do not access the LogRhythm Web Console from the PM host using any web browser (until updating to LogRhythm version 7.6). Accessing the LogRhythm Web Console directly from the PM removes the need for an attacker to know the PM’s hostname when performing an attack as they can simply specify “localhost” as the target to exploit.

Browser Security (Detailed Information)

• If using Google Chrome, verify that Chrome flag “SameSite by default cookies” is set to either “Default” or “Enabled”. If this flag is set to “Disabled”, the existing session can be hijacked via CVE-2020-25095. As of Google Chrome version 86.0.4240.111 the “Default” setting for this flag prevents CVE-2020-25095 from occurring.
  • The Chrome flag can be found by navigating to chrome://flags in your Chrome browser, then typing “SameSite by default cookies” in the search bar.
• If using Microsoft Edge, verify that Edge flag “SameSite by default cookies” is set to either “Default” or “Enabled”. If this flag is set to “Disabled”, the existing session can be hijacked via CVE-2020-25095. As of Microsoft Edge version 86.0.622.51 the “Default” setting for this flag prevents CVE-2020-25095 from occurring.
  • The Edge flag can be found by navigating to edge://flags in your Edge browser, then typing “SameSite by default cookies” in the search bar.
• If using Mozilla Firefox, be aware that “Private Browsing” mode does NOT prevent CVE-2020-25095 from occurring (in contrast to the above similar workarounds for Google Chrome and Microsoft Edge).
• Microsoft Internet Explorer 11 and Mozilla Firefox (as of version 82.0) are both vulnerable to CVE-2020-25095 with their default settings in place, in contrast to the Google Chrome and Microsoft Edge (versions listed above). Consequently, we would recommend using Google Chrome or Microsoft Edge for all LogRhythm Web Console access until your deployment is upgraded to software version 7.6.

Best Practice: Configuration/Architecture

• Using a jump box infrastructure, configured to not allow outside browsing (only to the web console or internal systems), to access your LogRhythm deployment is another recommended control.
  • Other dedicated systems, used in the same capacity with the same limitations, can also mitigate risks presented by these vulnerabilities.

Additional guidance on best practices for SIEM configurations will be published as they become available on this community post.

Monitoring and Detection Strategies

While we have not identified a singular technique for monitoring and detecting usage of the above vulnerabilities, we believe using one or more of the following strategies will help reduce risk and increase the likelihood of detecting malicious behavior:

Monitor LogRhythm SysMon Agent and Alarming and Response Manager Logs

• A monitoring solution has been developed that allows monitoring of the SysMon Agent and Alarming and Response Manager logs for rogue behavior related to the Web Console vulnerabilities. This monitoring solution will be made available as development is finalized on the LogRhythm Community.

This topic explains the steps required to collect logs generated by the LogRhythm System Monitor Agent (Windows Only) for the purpose of troubleshooting or monitoring of SRP execution actions with relation to CVE-2020-25094, CVE-2020-25095, and CVE-2020-25096. These CVEs do not impact non-Windows LogRhythm System Monitor agents as they do not have Smart Response (SRP) functionality.

Impact

Collection of LogRhythm System Monitor (SCSM) logs will increase the incoming log ingestion rate of your LogRhythm deployment. Volume generated by the SCSM process depends heavily on its function in the environment and the configured logging level of the agent. These can range from >1mps average per agent up to potentially 100mps+ for an agent with thousands of pull-based log sources (APIs, Windows, etc). GLPRs or Log Source Virtualization can be used to reduce the incoming volume and deployment impact if needed.

Prerequisites

• LogRhythm Enterprise 7.1.x or higher.
• LogRhythm Knowledge Base 7.1.572.2 or higher.
• LogRhythm System Monitor Agent log path should be recorded, in most scenarios this will be the default of “C:\Program Files\LogRhythm\LogRhythm System Monitor\logs\scsm.log”
• LogRhythm System Monitor Agents must be at Logging Level of Info or higher

Higher logging levels (Verbose/Debug) generate significantly higher log volume and are not recommended except during short troubleshooting sessions

Configure LogRhythm System Monitor Log Collection

Only Global Admins or Restricted Admins with elevated View and Manage privileges can take this action.

1. Access Deployment Manager, System Monitors Tab
2. Filter Type Column for “Windows”
3. Right Click, Check All Displayed
4. Right Click, Actions > Add Flat File Log Source
5. Select Type “Flat File – LogRhythm System Monitor”
6. Select Log Message Processing Policy “LogRhythm Default”
7. Under Flat File Settings tab fill in the following fields:
   1. File Path – Enter File Path (default “C:\Program Files\LogRhythm\LogRhythm System Monitor\logs\scsm.log”)
   2. Date Parsing Format – Select LogRhythm System Monitor (// ::\.)
   3. Log Message Start Regex – \d{2}\/\d{2}\/\d{4}\s\d{2}:\d{2}:\d{2}\.\d+

(Optional) Import AIE Alarm for Agent SRP Action Executions

This will allow automated detection and alerting of SRP actions performed on LogRhythm Agents. Depending on the environment these actions may be normal/expected and therefor alarm configuration would not be necessary as a recurring report/review of SRP actions can be performed manually. We’ve pre-built the AI Engine rule/alarm, which is attached to this post (filename “AIEngineRule_1000000015_20201117.airx”). To import the AI Engine rule/alarm:

• Download the AI Engine rule/alarm file attached to this post (“AIEngineRule_1000000015_20201117.airx”)
• Open the LogRhythm Console, select “Deployment Manager” > “AI Engine” tab
• Right-click in the “AI Engine” rule grid, select “Actions” > “Import”
• In the “Import” window that appears, navigate to the downloaded AIE rule/alarm file, select it, then click “Open”
• After a brief pause the AI Engine rule/alarm (“LogRhythm Agent SRP Executed”) will now appear in the “AI Engine” rule grid
• The LogRhythm Console may prompt you to “Restart AI Engine Servers”; if prompted, click the “Restart AI Engine Servers” button near the top of the window
• Select the “Action” checkbox that corresponds to the newly imported AIE rule/alarm (“LogRhythm Agent SRP Executed”), then right-click and select “Actions” > “Enable
• Once again, the LogRhythm Console may prompt you to “Restart AI Engine Servers”; if prompted, click the “Restart AI Engine Servers” button near the top of the window
• The AI Engine rule/alarm will now fire whenever SRP actions are performed by LogRhythm System Monitor Agent(s)

Monitor Process Creation on Platform Manager/SysMon Agents

• Review and monitor logging/events from your organization’s EDR deployment (if available). In particular, we recommend monitoring and alerting on atypical/unexpected child processes spawned by the LogRhythm SysMon agent’s process (scsm.exe) and Alarming and Response Manager (ARM) process (scarm.exe).
• Review and monitor process creation events on the LogRhythm PM and SysMon agents by using the “Process Monitor” endpoint monitoring feature available within the LogRhythm SysMon agent. LogRhythm is developing a monitoring setup using this solution, which will be added to the LogRhythm Community upon completion.
  • Note: Only SysMon Agents with a Pro license can utilize process monitor or other endpoint features.

Next Steps

For all custom content developed by the LogRhythm OCSO team or ask a question visit the post titled, LogRhythm Web Console Vulnerabilities 11.11.2020, on the LogRhythm Community: https://community.logrhythm.com/t5/Product-Security/LogRhythm-Web-Console-Vulnerabilities-11-11-2020/td-p/451638

SIEM Content (for Monitoring and Detection)

LogRhythm SIEM content for monitoring and detecting exploitation of the vulnerabilities will be made available on this post as the development of the content is completed.

Credit

LogRhythm would like to thank the CyberCX team for discovering and working directly with us to responsibly disclose the identified vulnerabilities, limiting unnecessary risk to our existing customers.

Footnotes

¹ Successful exploitation of the vulnerabilities (as detailed in this analysis) requires prior knowledge of the target LogRhythm Web Console’s hostname and port number.

² Versus other initiation methods (e.g., stealing or intercepting the LogRhythm Web Console session cookie value via a Man-In-The-Middle attack)

³ At this time we have not identified any method for an attacker to surmise the hostname and port of the LogRhythm Web Console via any of the above vulnerabilities, or via an existing LogRhythm Web Console session. As mentioned prior, the hostname is not required if an end user is browsing the Web Console directly from the Platform Manager. Please see “Browser Security” bullet point two for more information.

⁴ If the CSRF portion of the exploit chain (CVE-2020-25095) is blocked, an attacker cannot utilize a malicious website/”drive by” attack to exploit CVE-2020-25094. The attacker would then need to already have compromised or otherwise gained a foothold on the target organization’s network.