Pierluigi Paganini November 25, 2019

Over the summer, the Apache Solr team addressed a remote code execution flaw, not a working exploit code was published online.

The bug addressed by the Apache Solr team fixed over the summer is more dangerous than initially thought.

Apache Solr is a highly reliable, scalable and fault-tolerant, open-source search engine written in Java.

Solr is highly reliable, scalable and fault-tolerant, providing distributed indexing, replication and load-balanced querying, automated failover and recovery, centralized configuration and more.

The vulnerability was reported to maintainers by a user named “jnyryan” and resides in the default solr.in.sh configuration. jnyryan The vulnerability was reported to maintainers by a user named “jnyryan” and resides in the default solr.in.sh configuration.

“This issue originally had the title “default solr.in.sh contains uncommented lines” and told users to check their solr.in.sh file.” reads the security advisory. “Later we upgraded the severity of this due to risk of remote code execution, acquired a CVE number and issued the public annoucement quoted below.”

The issue affects 8.1.1 and 8.2.0 releases of Apache Solr for Linux (Windows is not affected) that contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file.

“If you use the default solr.in.sh file from the affected releases, then JMX monitoring will be enabled and exposed on RMI_PORT (default=18983), without any authentication.” continues the advisory” If this port is opened for inbound traffic in your firewall, then anyone with network access to your Solr nodes will be able to access JMX, which may in turn allow them to upload malicious code for execution on the Solr server.”

According to an analysis published by Tenable, all Solr versions from v7.7.2 to v8.3 are affected by the flaw.

“Tenable Research has confirmed that Apache Solr versions 7.7.2 through 8.3 (the most current release) are vulnerable, and we suspect older versions that include the Config API are potentially vulnerable.” reads the analysis published by Tenable.

When the flaw was reported, the Apache Solr team acknowledged it but did not recognize its severity because the experts thought it could be exploited by an attacker to only access Solr monitoring data.

On October 30, the user “s00py” published a proof-of-concept exploit code on GitHub that leverage the issue to get remote code execution of vulnerable systems. The exploit code used the exposed 8983 port to enable support for Apache Velocity templates then used it to upload and run malicious code.

According to ZDNet, two days later the user “jas502n” published a second PoC code that allows to exploit the flaw very simply.

The availability of the two PoC exploits forced the Solr team to publish an updated security advisory on November 15. The vulnerability received the CVE-2019-12409 identifier.

“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.” reads the updated advisory. “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.”

Experts also recommend blocking inbound traffic on JMX_PORT.

At the time of writing, experts are not aware of attacks exploiting the issue in the wild, but they pointed out that it is only a matter of time.

Pierluigi Paganini

(SecurityAffairs – Apache Solr, hacking)

[adrotate banner=”5″]

[adrotate banner=”13″]