LogRhythm Zero Days

by Liam-OShannessyby Liam O’Shannessy

Background

While undertaking penetration testing of a customer’s security operations centre (SOC), a number of vulnerabilities were identified in the LogRhythm application suite.

As part of the engagement scope, CyberCX performed web application penetration testing of a number of “as deployed” SOC applications, including the LogRhythm Security Information and Event Management (SIEM) solution. LogRhythm is a popular SIEM solution, so we were not expecting to find any major vulnerabilities. Often tests of this type uncover integration or deployment issues, but it is usually rare to find critical vulnerabilities in mature software platforms. This test, however, was going to prove an exception.

Solution Architecture

As a result of our team’s penetration testing and exploitation activities, we uncovered a series of high-risk vulnerabilities that could be chained together.

The description that follows greatly simplifies the LogRhythm solution architecture, however it should prove sufficient to understand the vulnerabilities being discussed.

LogRhythm users log into a web application interface (the “Web Console”) that provides a dashboard view of data and tasks that the user can perform. Data is gathered from “back-end” hosts that have a LogRhythm “Smart Response” agent installed on them. These back-end hosts are typically servers that reside within enterprise networks.

Users within LogRhythm have fine-grained access controls applied to them. Depending on their role membership, they may have access to some data and functionality, but not others. This includes being able to access the data of, and interact with, some back-end hosts, but not others. For higher privileged users, this includes the ability to run certain commands on the back-end hosts. This execution of commands on the remote servers is known as “SmartResponse” in the LogRhythm world and is used to allow SIEM users to perform custom actions such as uploading suspicious files to VirusTotal. An example is shown below.

Naturally, this functionality caught our eye (in particular the greyed-out “Command to Execute”), as any time a user can run remote commands, there is the possibility that a malicious user could inject and execute arbitrary commands other than the commands intended by the system designer unless the solution is built appropriately.

But first… an aside on WebSockets

HTTP(S) has long been the hidden hero of the web – it’s the protocol over which (nearly) all web traffic is sent. However, after a quarter-century of employment, HTTP has some well-known shortcomings from an engineering standpoint. To address some of these shortcomings, a new standard known as WebSockets was proposed and is now beginning to be found in a number of places.

WebSockets are a distinct protocol from HTTP, but are designed to build on the huge amount of legacy HTTP infrastructure present on the Internet. Like HTTP, WebSockets work over TCP ports 80 and 443, and work with existing HTTP proxies and intermediaries. WebSockets rely on legacy HTTP for the initial connection between client and server, after which the client and server agree to switch protocols to WebSocket via an “HTTP Upgrade request”.

The important thing to bear in mind when thinking about WebSockets is that it’s a relatively new technology, which means it’s currently not as well understood by developers OR hackers.

And now, on with the CVE show

1. CVE-2020-25094: Command Injection

Initial interaction between the client’s browser and the Web Console such as logging in and viewing site data is performed via HTTPS, however it was noted that certain activities, including the execution of SmartResponse requests, was performed by a WebSocket connection that was initiated between the client browser and the Web Console.

By intercepting and manipulating SmartResponse WebSocket traffic, it was determined that the commands being forwarded by the Web Console to the back-end agents, were being performed by Windows PowerShell commands that were being sent inside the WebSocket. By manipulating the WebSocket request, it was relatively simple to rewrite the PowerShell command sent to the back-end agent to any arbitrary payload.

This is a fairly common “Command Injection” vulnerability. While the impact of these vulnerabilities is high, allowing for arbitrary Remote Code Execution (RCE), the commands can only be injected by a user-account that is already relatively highly privileged (i.e., they already have the ability to run SmartResponse commands on the remote servers). This changes “Remote Code Execution” (as intended) to “Arbitrary Remote Code Execution”.

1.5 (No CVE): The agent runs as WHAT?!?

Of course, the first thing you do when you have arbitrary RCE is to ask: What account context are my commands running in? If the RCE is running in an extremely locked-down sandbox, it may not be so bad.

OK, in this case it is bad.

The LogRhythm Smart Response agent installer gives users the ability to specify an account that the agent should run as, but the default behaviour is to run as “NT AUTHORITY\SYSTEM”. This account is a built-in Windows account that is the most highly privileged account on the system, equivalent to “root” on Unix/Linux.

2. CVE-2020-25096 Incorrect Access Control

When further analysing WebSocket traffic being sent by the client, another strange condition was noted. While the HTTP traffic between the client and the Web Console was authenticated using HTTP Cookies, no equivalent token was present when the protocol switched to WebSockets.

Remember back several paragraphs ago when I said “Users within LogRhythm have fine-grained access controls applied to them. Depending on their role membership, they may have access to some data and functionality, but not others. This includes being able to access the data of and interact with some back-end hosts, but not others” ?

This access-control model was simply not being enforced on WebSocket traffic. In fact, the WebSocket requests that sent Smart Response PowerShell commands contained very little in the way of unique information. Which back-end agent the Smart Response command was sent to was determined by a simple 4-digit parameter. If the parameter was altered to correspond to an agent that the current user should not be able to interact with, the command was still successfully sent through and executed on that agent. As the parameter is only 4 digits, it would be feasible for an attacker to brute-force all possible digits, resulting in code execution on any connected system with an agent installed without any regard for the user’s intended access rights.

The combination of CVEs 2020-25094 and 2020-25096 mean that even the most lowly-privileged Web Console user could execute arbitrary code with System privileges on all connected agent hosts. This is obviously an extremely high-impact scenario, but still relies on the initial compromise of a legitimate Web Console user account (or a rogue insider) to kick off the kill-chain.

The particular customer environment being pentested also had one further security control up its sleeve – the entire LogRhythm deployment, including the Web Console, was only accessible from a network segment that required Multi-Factor Authentication to access. As the Web Console could not be accessed from the Internet, these vulnerabilities could not be exploited due to the “Defence in depth” security architecture employed by the customer… or could it?

3. CVE 2020-25095 Cross Site WebSocket Hijacking (CSWH)

The HTTP part of the Web Console relied on a traditional cookie-based authentication control. Cookies are a well-understood and widely adopted approach to authentication of HTTP sessions, however they can suffer from a vulnerability known as Cross-Site Request Forgery (CSRF).

CSRF is an attack whereby a user, who is logged in to a vulnerable web application, subsequently opens another browser tab and unknowingly visits a malicious third-party site.

Without the user’s knowledge, the malicious third-party site sends requests to perform actions on the vulnerable web application using the user’s existing session. This is made possible by the victim’s browser helpfully attaching their session cookie to the cross-domain request made from the malicious site to the vulnerable web application. Due to a browser security control (Same-origin policy) that is applied to cross-domain requests, the malicious third-party site can’t see the response to these cross-domain requests, and so the exploitation of CSRF is normally only useful to an attacker if the cross-domain request can be used to make a change in the vulnerable site (a classic example being updating the victim user’s password to a value the attacker knows).

CSRF attacks can occur when the vulnerable web application does not adequately validate incoming requests to ensure they come from a trusted source.

If CSRF, normally a high-impact vulnerability by itself, can be combined with the request issued by the client to change protocols from HTTP to WebSockets, the impact can be significantly higher.

Unlike normal cross-domain requests, WebSockets are not restricted by Same-origin policy. This means that if a malicious site can send a cross-domain request to initiate a WebSocket connection to a webserver that is vulnerable to CSRF, a WebSocket will be created that allows unrestricted, bi-directional communication between the malicious site and the vulnerable site. This dangerous sub-type of CSRF is known as Cross-Site WebSocket Hijacking (CSWH).

The Web Console was noted to not be validating the “Origin” header in cross-domain WebSocket initiation requests, nor did it implement any other controls designed to prevent CSRF attacks such as unique CSRF tokens, leaving it vulnerable to CSWH.

Exploitation

The particularly scary thing about CSRF in general, and CSWH in particular, is its ability to “jump” over security boundaries. Even though in this case the vulnerable Web Console was not Internet-accessible, if it was accessed by a user who then visited a malicious Internet site, that site could still exploit the CSWH vulnerability, effectively using the victim’s browser as a “pivot” into the otherwise protected network segment.

By chaining the three vulnerabilities (and one insecure default configuration), it would be theoretically possible for a malicious website to gain arbitrary remote code execution with the highest privileges on all systems with an agent installed connected to the solution, regardless of the victim user’s configured level of access or role.

A summary of the most likely exploitation chain (created by LogRhythm) is below:

Conclusion

WebSockets, as a relatively new technology, are not yet as widely or as deeply understood as some more mature technologies. This lack of understanding can result in security controls or considerations not being taken into account when deploying this new technology. This lack of understanding is not unique to developers – offensive security practitioners (whether pentesters or cybercriminals) often overlook these same considerations. Both developers and pentesters currently have vastly fewer tools available to assess the security of WebSocket deployments as they do for traditional HTTP.

The vulnerabilities discussed in this piece are not particularly complex, and yet there is very little in the way of automated tooling that would detect them. This speaks volumes for the benefits of including penetration testing as part of any security regime.

CyberCX would like to acknowledge the actions and response of LogRhythm, who were at all times receptive to the vulnerability information being disclosed and worked closely with CyberCX staff to limit the risk to LogRhythm customers

Affected Products and Software Versions

• LogRhythm SIEM: All version 7.x.x releases prior to version 7.6 (released November 18th, 2020)
• LogRhythm Cloud

As well as releasing the patch, LogRhythm have also provided a hardening guide for Browser Security that can act as a compensating control. Further information is available for their customers HERE (requires LogRhythm customer authentication).

Disclosure Timeline

• 27 Aug 2020: Initial findings forwarded to LogRhythm by CyberCX’s customer
• 4 Sep 2020: Discussion between CyberCX and LogRhythm. LogRhythm confirms vulnerabilities
• 18 Sep 2020: LogRhythm provided updates on remediation progress and release planning
• 29 Sep 2020: Further technical detail provided by CyberCX to LogRhythm Security Engineering team to understand full impact of some conditions
• 13 Oct 2020: LogRhythm finalises code fixes and begins release planning. LogRhythm requests and CyberCX agrees to extended “customer notification period” via private channels between LogRhythm and customers prior to public vulnerability disclosure
• 11 Nov 2020: LogRhythm releases initial communications with their customers regarding vulnerability details
• 18 Nov 2020: LogRhythm releases fixed versions of software
• 16 Dec 2020: Public disclosure of vulnerabilities

About CyberCX

The CyberCX group unites our country’s most trusted cyber security companies to deliver a comprehensive cyber security capability for enterprises and governments.

With a workforce of 700+ cyber security professionals, a footprint of more than 20 offices across Australia and New Zealand, and a global presence in Europe and the US, CyberCX offers the ultimate end-to-end cyber security service.

CyberCX’s Security Testing and Assurance team has the scale to ensure we have specialist expertise in every aspect of penetration testing to safeguard your application layer from hidden vulnerabilities.

Contact CyberCX today to learn how your organisation can benefit from our unrivalled web application penetration testing capabilities.