Apache Solr, an open source enterprise search platform used by some of the biggest names in business including Adobe, Bloomberg, eBay, Goldman Sachs, Instagram and Netflix as users, remains vulnerable to a zero day weeks after proof-of-concept code became public, cybersecurity experts have warned.
The alert comes after after two remote code execution (RCE) vulnerabilities emerged. One, CVE-2019-12409 has already been patched by the Apache Solr team, while the other – without a CVE number – seems to still be unpatched. (Admins are being urged to rapidly implement the patch to avoid attack).
The first RCE was first reported in July 2019 by John Ryan and initially believed to be of low severity. It was patched a month later. But with security researcher Matei Badanoiu now having demonstrated that the flaw could be exploited to achieve RCE, Apache Solr maintainers escalated its severity to “High”.
Critics warned that the initial failure to recognise the severity of the vulnerability could put businesses at risk. With PoC exploit code available on GitHub, they warned that widespread attacks in the wild were likely imminent.
Apache Solr CVE-2019-12409
With regard to CVE-2019-12409, the Apache Solr team said: “The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr.Windows users are not affected.”
They added: “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. 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.”
The Second Vulnerability
As Columbia-based security firm Tenable noted, on October 29, a PoC for another RCE vulnerability in Apache Solr, was published as a GitHub Gist (code snippets published to GitHub). Tenable’s Satnam Narang said: “At the time this blog was published, this vulnerability did not have a CVE identifier and no confirmation or indication of a solution available from Apache. 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.”
He added: “According to the PoC, an attacker could target a vulnerable Apache Solr instance by first identifying a list of Solr core names.
See also: BlueKeep Malware Lands, Spawns, Vanishes Abruptly
“Once the core names have been identified, an attacker can send a specially crafted HTTP POST request to the Config API to toggle the params resource loader value for the Velocity Response Writer in the solrconfig.xml file to true.”
Ilia Kolochenko, founder and CEO of web security company ImmuniWeb, commented: “Modern-day cybercrime groups are super agile.
“Probably, as early as the first PoC was published, it was on their radar. On underground marketplaces, one can easily find lists of servers or websites with specific network or web software. Once a hot 0day is published, attackers buy these lists with all publicly-known servers running the vulnerable software and swiftly launch their attacks. Given that the vulnerability is exploitable in default configuration, we should expect quite large-scale and aggressive exploitation in the wild pretty soon.
“Server admins must urgently update their configuration as per vendor’s instructions, and then ascertain that their servers have not been breached before.”
With regard to the second RCE, Tenable said: “Users can mitigate attacks leveraging this vulnerability by adding authentication to the Apache Solr instance. Also, review the VelocityResponseWriter class in the solrconfig.xml configuration file and ensure the params resource loader value is set to false.
Read this: Oracle Vulnerability Gives Hackers “Untraceable” License to Print Money
