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 [email protected].

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