CVE-2017-3164 in Solr
Summary
by MITRE
Server Side Request Forgery in Apache Solr, versions 1.3 until 7.6 (inclusive). Since the "shards" parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/29/2023
Apache Solr versions 1.3 through 7.6 suffered from a critical server side request forgery vulnerability that exposed the system to unauthorized external communications. This vulnerability specifically affected the "shards" parameter processing mechanism within the distributed search functionality of Solr. The flaw stemmed from the absence of proper input validation and whitelisting controls for the shards parameter, which allowed malicious actors to manipulate the parameter to initiate HTTP GET requests to arbitrary URLs. The vulnerability was categorized under CWE-918 as a server-side request forgery attack vector, where the application failed to validate the destination of external requests originating from its internal processing logic. This weakness enabled attackers to leverage Solr's distributed search capabilities to make unauthorized HTTP requests to internal or external systems that would otherwise be inaccessible to the attacker.
The operational impact of this vulnerability was severe as it provided attackers with the ability to perform reconnaissance activities and potentially access internal network resources that were not directly exposed to the internet. Attackers could use this vulnerability to scan internal services, access sensitive data through internal APIs, or even perform lateral movement within the network infrastructure. The vulnerability was particularly dangerous because it could be exploited through legitimate Solr functionality, making it difficult to detect and distinguish from normal operational traffic. The attack vector was classified under the ATT&CK technique T1071.004 for application layer protocol: DNS, as the malicious requests could be crafted to use various protocols including DNS queries to further exploit the system. The vulnerability also aligned with ATT&CK technique T1046 for network service scanning, as attackers could use the compromised Solr instance to enumerate services on internal networks.
Mitigation strategies for this vulnerability required immediate implementation of several security controls. Organizations needed to upgrade to Apache Solr versions 7.7 or later where the vulnerability was patched, or implement network-level restrictions to prevent unauthorized external communications from Solr instances. The recommended approach involved configuring proper input validation and whitelisting mechanisms for the shards parameter, ensuring that only explicitly allowed URLs could be accessed through the distributed search functionality. Security teams were advised to implement network segmentation to isolate Solr instances from internal network resources and deploy web application firewalls to monitor and filter requests to the shards parameter. Additionally, the principle of least privilege should have been enforced by limiting the network access capabilities of Solr instances and implementing proper authentication mechanisms to restrict access to the distributed search functionality. The vulnerability demonstrated the critical importance of validating all external inputs and implementing proper access controls in distributed systems, as highlighted in the OWASP Top Ten 2017 category A06: Security Misconfiguration.