Threat Signal Report

Remote Code Execution Vulnerability in Default Configuration of Apache Solr (CVE-2019-12409)

Description

Latest Update 12/28/19

Please note that this update contains additional information that was not available during the time of writing.

FortiGuard Labs has developed an IPS signature for the proof of concepts mentioned in this Threat Signal as:

Apache.Solr.Velocity.Template.Remote.Code.Execution

which has been officially released in IPS definitions version 15.735.

Also, after further analysis, FortiGuard Labs has confirmed that the following existing signature addresses CVE-2019-12409:

Java.JMX.Server.Insecure.Configuration.Java.Code.Execution

We will continue to monitor this event for any further developments and will update this Threat Signal if relevant.


The FortiGuard SE team is aware of recent events affecting Apache Solr (CVE-2019-12409). Apache Solr is a scalable search platform that incorporates the Java framework to provided distributed indexing, replication and load balanced queries. Back in July, multiple researchers disclosed to the Apache Software Foundation that a new vulnerability exists in Solr, which allows access to the monitoring of data over JMX, which later turned out to be more serious than first thought. Later, it was discovered that remote code execution (RCE) was possible in Apache Solr, due to a bad default configuration. During the initial assessment, the initial severity was not regarded as high due to the fact that RCE was unknown at the time. Because of the possibility of RCE, the team upgraded the severity and obtained a CVE number.

Analysis by FortiGuard Labs is currently ongoing, specifically the vulnerability along with the published proof of concept code for coverage, and we will update this document once we have relevant information to share.


What is the vulnerability specifically?

Apache Solr 8.11 and 8.20 is affected by an insecure setting within the "ENABLE_REMOTE_JMX_OPTS" configuration option, which is located within the default solr.in.sh configuration file. The default solr.in.sh file in affected versions has JMX monitoring enabled and exposed on RMI_PORT (18983) which does not require authentication. If the port is open for inbound traffic within a firewall of the host, anyone with network access to Solr nodes can access JMX, which will then allow for the upload of malicious code for execution on the Solr server.

Two proof of concepts were published in October to GitHub and these highlight the usage of the known exploit to access port 8983, to enable support of Apache Velocity templates on the Solr server, which can then be used for remote code execution.


It appears that Solr 8.3.0 was released in November, does this address the vulnerability completely?

No, there is no patch released at this time. According to Apache, there is no need to update or upgrade code. Please refer to the mitigation steps below for further details. According to Apache, Solr 8.3.0, released in November, mitigates this vulnerability. However, there has been some rebukes to this claim from Tenable, please see below for further details.

Although Apache Solr states in its release notes that this vulnerability has been addressed with version 8.3.0, security researchers at Tenable state otherwise. We have not validated or substantiated these claims at this time.


Are there any mitigations available?

According to the advisory, Apache recommends the following:

Make sure your effective solr.in.sh file has ENABLE_REMOTE_JMX_OPTS set to 'false' on every Solr node and then restart Solr. Note that the effective solr.in.sh file may reside in /etc/defaults/ or another location depending on the install. You can then validate that the 'com.sun.management.jmxremote*' family of properties are not listed in the "Java Properties" section of the Solr Admin UI, or configured in a secure way.


Also, the FortiGuard SE team recommends that system administrators perform an audit of their network to ensure that machines running Apache Solr and any other services that were not meant to be exposed externally, be firewalled as soon as time permits and that authentication be enabled to ensure additional mitigation from external access.


What platforms are affected?

Linux machines running Apache Solr are affected. Windows operating systems are unaffected by this advisory.


Are there any known proof of concepts?

Yes, there are two known proof of concepts published on October 29 and 30. Please refer to the appendix for further details.


Has there been any observed in the wild attacks?

We have not seen any in the wild attacks at this time. Due to the update of this latest disclosure and the proof of concepts already written there is a reasonable expectation that in the wild attacks may be forthcoming within a short amount of time.


What is the status of AV and IPS coverage?

IPS coverage is currently under investigation. Once a signature is deemed feasible for release, this document will be updated with relevant coverage information.

AV coverage is not feasible for this event.


MITRE ATT&CK

Exploitation for Client Execution

ID: T1203

Tactic: Execution

Platform: Linux, Windows, macOS

System Requirements: Remote exploitation for execution requires a remotely accessible service reachable over the network or other vector of access such as spearphishing or drive-by compromise.

Data Sources: Anti-virus, System calls, Process monitoring

Supports Remote: Yes

Version: 1.0


Definitions

Traffic Light Protocol

Color When Should it Be used? How may it be shared?

TLP: RED

Not for disclosure, restricted to participants only.
Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused. Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting. In most circumstances, TLP:RED should be exchanged verbally or in person.

TLP: AMBER

Limited disclosure, restricted to participants’ organizations.
Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved. Recipients may only share TLP:AMBER information with members of their own organization, and with clients or customers who need to know the information to protect themselves or prevent further harm. Sources are at liberty to specify additional intended limits of the sharing: these must be adhered to.

TLP: GREEN

Limited disclosure, restricted to the community.
Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector. Recipients may share TLP:GREEN information with peers and partner organizations within their sector or community, but not via publicly accessible channels. Information in this category can be circulated widely within a particular community. TLP:GREEN information may not be released outside of the community.

TLP: WHITE

Disclosure is not limited.
Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction.