Apache Solr RCEs with public PoCs could soon be exploited
Two remote code execution (RCE) vulnerabilities in Apache Solr could be exploited by attackers to compromise the underlying server.
One – CVE-2019-12409 – has already been patched, while the other – currently without a CVE number – seems to still be unpatched. Proof of concept exploit code for both is available on GitHub.
In the past, attackers have been known to exploit vulnerabilities in Apache Solr to compromise servers and saddle them with crypto-mining malware.
About Apache Solr
Initially an in-house project at CNET Networks, Apache Solr has been open-sourced and donated to the Apache Software Foundation in 2006. A thriving community of users and contributors (both individuals and companies) has since sprung up around it.
Solr is widely used for enterprise search and analytics, and is bundled with many applications and supported in various data processing and integration frameworks.
CVE-2019-12409
CVE-2019-12409 was first reported in July 2019 by John Ryan and was believed to be of low severity. Nevertheless, it was patched a month later.
A week ago, researcher Matei Badanoiu demonstrated that the flaw could be exploited to achieve RCE, and Apache Solr maintainers escalated its severity to “High”. PoC exploit code is available on GitHub.
The flaw arose due to an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr.
“An unauthenticated attacker with the ability to reach the RMI port could leverage the vulnerability to upload malicious code to the server and then install a shell to further compromise the machine. While the vulnerability is limited to two versions of Apache Solr based on a default configuration setting, there is the potential for others to be affected if their configuration (solr.in.sh) sets ‘ENABLE_REMOTE_JMX_OPTS’ to ‘TRUE,” Scott Caveza, Research Engineering Manager at Tenable, told Help Net Security.
CVE-2019-12409 affects Solr 8.1.1 and 8.2.0 for Linux and has been fixed in version 8.3.
Administrators can implement the update or, alternatively, make sure their 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,” the project team pointed out.
The unnumbered Apache Solr RCE flaw
According to Tenable researchers, the other RCE issue affects the Velocity template in Apache Solr versions 7.7.2 and 8.3. “We suspect older versions that include the Config API are potentially vulnerable,” researcher Satnam Narang noted.
PoC code was published in late October, and was followed by an exploit script a few days later.
“According to the PoC, an attacker could target a vulnerable Apache Solr instance by first identifying a list of Solr core names. 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,” Narang explained.
“Enabling this parameter would allow an attacker to use the velocity template parameter in a specially crafted Solr request, leading to RCE.”
Since the issue is yet to be fixed, admins would do well to mitigated it by adding authentication to their Apache Solr instances.
“Also, review the VelocityResponseWriter class in the solrconfig.xml configuration file and ensure the params resource loader value is set to false. Be advised that unless the Config API is locked down, an attacker could modify the solrconfig.xml file,” he added.