Proof of concept exploit code was published online this month for two Apache Solr vulnerabilities, signaling that attacks are probably on their way as hackers will find ways to weaponize the two exploits inside their botnets.
Of the two bugs, one received a patch over the summer, while the second has yet to be addressed by the Solr team.
Attacks are bound to happen as Apache Solr is an advanced tool that is often used inside enterprise networks to support powerful data search functions, making a perfect trget for hackers looking for ways inside high-value networks or into servers with access to large computational resources.
The first bug: CVE-2019-12409
The first bug is an issue that was reported and fixed over the summer. The bug, tracked as CVE-2019-12409, refers to a default setting in the solr.in.sh configuration file that is included with all new Solr instances.
According to a report, Solr versions 8.1.1 and 8.2.0 shipped with the ENABLE_REMOTE_JMX_OPTS option set to enabled, which, in turn, exposed port 18983 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 Solr monitoring data, and nothing else.
However, proof-of-concept code was published last week showing how an attacker could abuse this bug to upload malicious code via the exposed port, and take over vulnerable Solr instances.
Fixing this issue should be as simple as switching the ENABLE_REMOTE_JMX_OPTS parameter to "false" in the solr.in.sh file, or updating Solr to version 8.3.0, released last month.
The Solr team said that only Solr versions running on Linux were impacted by this issue.
Second bug: The zero-day (no CVE yet)
But the most dangerous bugs of the two is one for which there's no official fix yet. According to an analysis by the team at Tenable, this bug impacts all Apache Solr versions between 7.7.2 and 8.3.0 -- the current version.
This bug can be exploited by placing a malformed HTTP request via a Solr server's port 8983 that uses a bug in the Config API to toggle an option in the solrconfig.xml configuration file to true.
Once this option (params.resource.loader.enabled) has been set to true, an attacker can upload Apache Velocity template files on the Solr server and run malicious code to hijack the server.
This second issue came to light at the end of October when a user published proof-of-concept code on GitHub showing how an attacker could abuse the bug.
A second, more refined proof-of-concept code was published online two days later, making attacks even easier to execute.
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 vulnerability 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 know these two 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.
Article updated on November 26 to add details about the second Solr bug. Most of the article was re-written from scratch to make it clear there are two bugs. The headline was upated accordingly.