New Apache Solr Injection Vulnerability

By August 15, 2019 Alerts

In a new research paper that was presented in this year’s Def Con, Veracode Security Researcher Michael Stepankin, released information about a new vulnerability that affects Apache Solr. The vulnerability could also allow Remote Code Execution and affects Solr instances regardless of their architecture (e.g. Internet-facing, behind a reverse proxy, or used only by internal web applications).

The new attack vector, which is also known as Apache Solr Injection, allows malicious users to perform a plethora of attacks, including:

  • Disclosure of sensitive data
  • Data tampering
  • JSON response rewriting
  • XML response poisoning
  • XSS via response poisoning
  • XXE
  • Path traversal
  • Arbitrary file read
  • RCE via Java deserialization

The Def Con 27 presentation is already available online and provides more technical information on this new attack vector. The paper is also available on GitHub.

Immediate Action is Necessary

Proof-of-concept exploits are already publicly available online for anyone to use.

In the environments where RCE is possible, the severity of this vulnerability could be critical, which could result in a full compromise of the server. Remote code execution vulnerabilities can be exploited by cryptomining malware and ransomware.

It is important to highlight that most of these attacks affect older, unpatched, releases of Apache Solr. Users of Apache Solr v7.1 and below should immediately patch their Solr instances. According to the current information, users of Apache Solr v8.2 are safe as long as DataImportHandler is disabled, which is the default setting.

Network security administrators should also make sure that all unused ports are blocked by firewalls and should monitor their systems for random port creation and connections as well as monitor their networks for suspicious network traffic, such as RMI and JMX.

Finally, security administrators should monitor for the presence of the sequence “%26” in the value part of the parameter “q” of GET HTTP requests.

Waratek fully protects against this new risk

Waratek solutions provide protection against deserialization attacks without the use of blacklisting of gadgets and therefore it is immune against any kind of payload variants, alternative exploits, zero-days etc., and it is entry point agnostic. Therefore, once you have implemented Waratek, you are protected against deserialization vulnerabilities – full stop.

With Waratek Secure and Enterprise, users are also protected against all the other attacks that are possible via Apache Solr Injection, including XSS, XXE, path traversal, Arbitrary file read, etc.

Waratek’s Customers Are Already Protected

  • Existing Waratek Secure and Waratek Enterprise customers who have enabled the deserial zero-day (CWE-502) rule in protect mode, are already protected against RCE attacks. No further action is required.
  • Existing Waratek Patch customers who have enabled the Process Forking ARMR rule in protection mode, are already protected against RCE attacks.
  • Waratek’s ARMR platform provides complete remediation to this zero-day critical vulnerability and therefore, Waratek customers do not have to upgrade their Solr instances with urgency.

Non-Waratek customers who are affected by the Apache Solr Injection vulnerability and are interested in learning more about how Waratek secures against this threat as well as other deserialization and zero day attacks, please contact Waratek at info@waratek.com.

About Waratek

Waratek is an award-winning pioneer in the next generation of application security solutions. Using patented runtime protection technology, Waratek makes it easy for teams to secure business critical applications and securely extend the life of their legacy applications. We provide some of the world’s largest brands with:

  • Instant patching of known software flaws with Runtime Virtual Patches
  • Protecting applications from known and unknown attack vectors such as the OWASP Top Ten and SANS Top 25
  • Virtually upgrading out-of-support Java applications and platforms to the most current version without rewriting the app
Apostolos Giannakidis

Author Apostolos Giannakidis

Apostolos drives the research and the design of the security features of Waratek’s RASP container. Before starting his journey in Waratek in 2014, Apostolos worked in Oracle for 2 years focusing on Destructive Testing on the whole technology stack of Oracle and on Security Testing of the Solaris operating system. Apostolos has more than 10 years of experience in the software industry and holds an MSc in Computer Science from the University of Birmingham.Apostolos is acknowledged by Oracle for submitting two Java Deserialization vulnerabilities that were fixed in the Oracle January 2018 CPU and is featured on Google’s Vulnerability Reward Program Hall of Fame.

More posts by Apostolos Giannakidis
X