Exploit-Code für Apache Solr Remote-Code-Lücke veröffentlicht

Verwirrung herrscht immer noch um einen Sicherheitsfehler, den das Apache Solr-Team im Laufe des Sommers gepatcht hat, was sich herausstellt, dass es eigentlich viel gefährlicher ist, als man dachte. Das Projekt wurde 2006 an die Apache Software Foundation gespendet, von der es aufgrund seiner Schnelligkeit und seines erweiterten Funktionsumfangs weltweiten Einsatz fand.

Problem, das vor Monaten gemeldet wurde.

Im Laufe des Sommers berichtete ein Benutzer namens "jnyryan" dem Solr-Projekt, dass die standardmäßige Konfigurationsdatei solr.in.sh, die bei allen neuen Solr-Instanzen enthalten ist, eine unsichere Option enthielt.

Die Standardkonfiguration, die mit der Option ENABLE_REMOTE_JMX_OPTS ausgeliefert wird, ist auf aktiviert gesetzt, was wiederum den Port 8983 für Remote-Verbindungen freigibt.

Zum Zeitpunkt der Meldung sah das Apache Solr-Team das Problem nicht als große Sache an, und die Entwickler dachten, ein Angreifer könne nur auf (nutzlose) Solr-Monitoring-Daten zugreifen und sonst nichts.

Viel schlimmer war es, als ein Benutzer am 30. Oktober einen Proof-of-Concept-Code auf GitHub veröffentlichte, der zeigte, wie ein Angreifer das gleiche Problem für "Remote Code Execution"-Angriffe (RCE) missbrauchen konnte. Der Proof-of-Concept-Code verwendete den exponierten Port 8983, um die Unterstützung für Apache Velocity-Templates auf dem Solr-Server zu ermöglichen, und nutzte dann diese zweite Funktion, um bösartigen Code hochzuladen und auszuführen.

Zwei Tage später wurde ein zweiter, verfeinerter Proof-of-Concept-Code online veröffentlicht, der die Ausführung von Angriffen noch einfacher macht.

Erst nach der Veröffentlichung dieses Codes erkannte das Solr-Team, wie gefährlich dieser Fehler wirklich ist. Am 15. November veröffentlichten sie einen aktualisierten Sicherheitshinweis. In seiner aktualisierten Warnung empfahl das Solr-Team, dass Solr-Administratoren die Option ENABLE_REMOTE_JMX_OPTS in der Konfigurationsdatei solr.in.sh auf "false" für jeden Solr-Knoten setzen und dann Solr neu starten.

Sie empfehlen den Benutzern auch, die Solr-Server hinter Firewalls zu halten, da diese Systeme nie so konzipiert wurden, dass sie im Internet erreichbar sind, sondern nur ein Teil der geschlossenen und streng überwachten internen Netzwerke.

Allerdings gibt es immer noch einige Unklarheiten darüber, welche Versionen betroffen sind. In seinem Sicherheitshinweis sagte das Solr-Team, dass nur v8.1.1 und v8.2.0 anfällig sind, aber in einem Blogbeitrag letzte Woche sagte das Tenable Research Team, dass die Auswirkungen viel größer sind, wobei die Schwachstelle alle Solr-Versionen von v7.7.2 bis v8.3, der neuesten Version, betrifft.

Es wurden keine Angriffe erkannt, aber es wird erwartet.

Die gute Nachricht ist, dass zum Zeitpunkt des Schreibens keine Angriffe in der Wildnis festgestellt wurden. Dies ist jedoch nur eine Frage der Zeit. Apache Solr-Instanzen haben in der Regel Zugang zu großen Rechenressourcen und waren in der Vergangenheit von Malware-Gruppen sehr begehrte Ziele.

So wurden beispielsweise CVE-2017-12629 und CVE-2019-0193 innerhalb weniger Wochen nach Bekanntwerden von Details und Exploit-Code von Hackern angegriffen. In beiden Fällen nutzten Angreifer die beiden Schwachstellen, um Zugriff auf Solr-Server zu erhalten und Kryptowährungsmining- Malware auf ungepatchten Servern zu installieren.

Da wir bereits wissen, dass dieser neue Solr-Bug zur Remotecodeausführung führen kann und wir über einen sofort verfügbaren öffentlichen Exploit-Code verfügen, erwarten Experten, dass diese Sicherheitslücke innerhalb von Tagen oder Wochen in den aktiven Angriff kommt.