Zusammenfassung
- Unsere Analyse hat ergeben, dass am 25. Oktober 2023 etwa 28.910 Hosts Anzeichen einer Gefährdung aufweisen.
- Die Angreifer haben sich angepasst, und unsere bisherigen Methoden zur Identifizierung sind nicht mehr wirksam
- Forscher haben einen neuen (wenn auch nicht ganz so präzisen) Weg gefunden, um festzustellen, ob die Hintertüren auf diesen Geräten noch aktiv sind
Letzte Woche informierten wir über ein laufendes Ereignis mit Cisco-Geräten und einer auf Zehntausenden von Cisco-Hosts installierten Backdoor. In unserem letzten Update haben wir einen deutlichen Rückgang der Zahl der Infektionen festgestellt. Und würden Sie glauben, dass diese Zahl auf Null gesunken ist? Nun ja, irgendwie schon...
Seitdem hat die Gruppe (oder Einzelperson), die hinter dieser Massenkompromittierung steht, den Fehler erkannt und versucht, seine öffentliche Sichtbarkeit zu verschleiern, indem sie die Konfiguration entfernt hat, mit der Forscher feststellen konnten, ob das Gerät kompromittiert wurde. Auf diese Weise wurden die Methoden zum Auffinden dieser Kompromittierungen sofort veraltet.
Im Kern läuft auf diesen Cisco-Geräten der Nginx-Webserver, und (eine) der Konfigurationen, die von den Angreifern geändert wurden, ist die Nginx-Konfigurationsdatei des Hosts. Einem aufmerksamen Leser bei Fox-IT ist aufgefallen, dass der Angreifer in dem von Talos zur Verfügung gestellten Screenshot eine weitere Konfigurationsanweisung für den Standort hinzugefügt hat, die uns Aufschluss darüber geben kann, ob die Backdoors auf dem Gerät installiert sind.
Eine Standortdirektive in Nginx ermöglicht es einem Administrator, auf der Ebene des HTTP-URL-Pfads anders zu agieren, und diese hinzugefügte Direktive war ein von Groß- und Kleinschreibung unabhängiger regulärer Ausdruck für jeden Pfad, der das Prozentzeichen (%) enthielt, und wenn dieses Prozentzeichen im Pfad gefunden wird, setzt es einfach ein paar Header und gibt einen 404 zurück.
Leider werden die in dieser Direktive hinzugefügten Header aufgrund der Art und Weise, wie Nginx mit 404-Fehlerrückgaben umgeht, nie an den Client ausgegeben. Da diese Cisco-Geräte jedoch einen benutzerdefinierten 404-Handler zu haben scheinen und diese neue Konfigurationsdirektive diesen Handler außer Kraft setzt, erhalten wir eine andere 404-Statusmeldung (die Standardversion von Openresty/Nginx), wenn diese Konfiguration in Kraft ist.
Wir begeben uns auf unsicheres Terrain, wenn es darum geht, den Status dieser Hintertür zu bestimmen, und wir sind uns nicht zu 100 % sicher, ob dies der beste Weg ist, um diese Art von Tests durchzuführen, aber es ist der einzige Weg, den wir im Moment haben.
Welche Bedeutung hat nun dieses Prozentzeichen? Wir können die Antwort nur vermuten, denn in den meisten Fällen kann ein Prozentzeichen in einer URL nicht druckbare Zeichen in etwas übersetzen, das ein Server sehen kann (z. B. %41 == "A"). Die Angreifer versuchen also, etwas zu verbergen, aber wir haben keine Möglichkeit, das mit Sicherheit festzustellen. Leider geben die meisten Sicherheitsorganisationen wie Talos nicht mehr preis als das, was sie veröffentlichen, daher ist dies alles, was wir wissen.
Am 25. Oktober führten wir einen weiteren sekundären Scan gegen jede IP-Adresse durch, die in den letzten sieben Tagen mit Cisco-ähnlichen Merkmalen beobachtet wurde (dies kann auch Geräte umfassen, die nicht speziell Cisco XE sind, da wir vorsichtshalber einen allgemeineren Blick auf alle Cisco-ähnlichen Geräte werfen), und suchten nach jedem Gerät, das mit der Standard-Nginx/Openresty 404-Meldung antwortet, wenn der URI "/%25" angefordert wird. Unsere Eingabeliste enthielt über 135.000 potenzielle Geräte, und nur 28.910 Hosts antworteten mit einem Standard-Openresty/Nginx-404-Handler auf die Anfrage "/%25", was darauf hindeutet, dass die Backdoor installiert ist.
Auch hier können wir nicht mit 100-prozentiger Sicherheit sagen, ob dies tatsächlich ein Indikator für eine Kompromittierung ist, aber diese Cisco-Geräte reagieren anders, wenn sie eine Ressource anfordern, die auf diesen Hosts nicht existieren sollte. Zum Beispiel:
Abfrage von /%25 auf einem zuvor kompromittierten Host.
Anfordern einer zufälligen Datei, die auf einem zuvor kompromittierten Host nicht existieren sollte.
Das Faszinierende an diesem Vorfall ist, wie spezifisch und gezielt alles war. Cisco verwendet Openresty, einen auf Nginx basierenden Webserver mit der Möglichkeit, Lua direkt in den Konfigurationsdateien zu entwickeln und einzubetten - dies ist im Grunde so, als würde man die Anwendungsentwicklung in den Webserver selbst verlagern; dies ist nichts Ungewöhnliches, da derzeit rund 800.000 Openresty-Server online sind, was nicht viel ist, aber im Vergleich zu anderen Servertechnologien als mäßig populär angesehen werden kann.
Auf den ersten Blick sieht es so aus, als hätten die Angreifer ihre Zero-Day-Schwachstelle ausgenutzt, aber es ist offensichtlich, dass es sich um einen koordinierten, gut geplanten und gut durchgeführten Angriff handelt. Sie haben nicht nur die Schwachstelle in diesen Geräten gefunden (falls die Schwachstelle nicht gekauft wurde), sondern auch die zugrunde liegenden Technologien auf diesen Geräten genutzt, um eine Backdoor zu implementieren. Das bedeutet, dass ein angemessener Aufwand betrieben wurde, um die Technik zu erlernen und die systemspezifischen Hintertüren zu implementieren.
Und obwohl es keine perfekte Ausführung war, haben sie aus ihren Fehlern gelernt und sie schnell behoben. Wir haben dieses Muster schon ein paar Mal gesehen(Deadbolt, ESXiArgs):
- Ein Vorfall ereignet sich, Informationen werden veröffentlicht
- Verbreitung von Nachrichten und Forschungsergebnissen
- Angreifer überwachen und passen ihre Techniken an, um die Identifizierung und Analyse zu unterlaufen
- Wiederholen Sie
In diesem Fall erhielten wir genügend Informationen, um die ersten Kompromittierungen zu finden, wurden aber schnell ausgesperrt, als die Angreifer ihre Methoden und Techniken änderten. Wenn diese neue Methode zum Auffinden von Kompromittierungen genau ist, dann hat sich die Zahl der Geräte drastisch verringert.
