Exploit code published for dangerous Apache Solr remote code execution flaw

Confusion still surrounds a security bug that the Apache Solr team patched over the summer, which turns out it’s actually much more dangerous than anyone thought.

Apache Solr is a Java-based open-source search engine, initially developed to add search functionality to the CNET website.

The project was donated to the Apache Software Foundation in 2006, from where it gained worldwide usage due to its speed and expanded feature-set.

Issue reported months ago

Over the summer, a user named “jnyryan” reported to the Solr project that the default solr.in.sh configuration file that is included with all new Solr instances contained an insecure option.

The default config shipped with the ENABLE_REMOTE_JMX_OPTS option set to enabled, which, in turn, exposed port 8983 to remote connections.

At the time it was reported, the Apache Solr team didn’t see the issue as a big deal, and developers thought an attacker could only access (useless) Solr monitoring data, and nothing else.

Things turned out to be much worse when, on October 30, a user published proof-of-concept code on GitHub showing how an attacker could abuse the very same issue for “remote code execution” (RCE) attacks. The proof-of-concept code used the exposed 8983 port to enable support for Apache Velocity templates on the Solr server and then used this second feature to upload and run malicious code.

A second, more refined proof-of-concept code was published online two days later, making attacks even easier to execute.

It was only after the publication of this code that the Solr team realized how dangerous this bug really was. On November 15, they issued an updated security advisory. In its updated alert, the Solr team recommended that Solr admins set the ENABLE_REMOTE_JMX_OPTS option in the solr.in.sh config file to “false” on every Solr node and then restart Solr.

They also recommend that users keep Solr servers behind firewalls, as these systems were never designed to sit exposed on the internet, but only part of closed and tightly monitored internal networks.

The Solr team said that only Solr versions running on Linux are impacted.

However, there is still some mystery about what versions are impacted. In its security advisory, the Solr team said that only v8.1.1 and v8.2.0 are vulnerable, but, in a blog post last week, the Tenable research team said that the impact is much greater, with the vulnerability affecting all Solr versions from v7.7.2 to v8.3, the latest version.

No attacks detected, but are expected

The good news is that at the time of writing, no attacks have been detected in the wild. However, this is only a matter of time.

Apache Solr instances usually have access to large computational resources and, historically, have been highly sought after targets by malware gangs.

For example, CVE-2017-12629 and CVE-2019-0193 were targeted by hackers within weeks after details and exploit code became public. In both instances, attackers used the two vulnerabilities to gain access to Solr servers and plant cryptocurrency-mining malware on unpatched servers.

Because we already know this new Solr bug can lead to remote code execution and we have readily-available public exploit code, experts expect this security flaw to come under active attacks within days or weeks.

This new Solr bug is tracked as CVE-2019-12409.

READ MORE HERE