Bei der Überprüfung der Sicherheit der Webressourcen der Bank haben wir kürzlich eine Sicherheitsanfälligkeit im Exim 4.89-Mailserver festgestellt, die zur Ausführung von Remotecode führen kann. Die Sicherheitsanfälligkeit wird als CVE-2018-6789 bezeichnet. Mit dem PoC-Exploit haben wir die Reverse Shell auf dem Remote-Computer abgerufen und dann auf die Website der Bank zugegriffen.
Natürlich haben wir uns gefragt, warum eine solche Ausnutzung der Sicherheitsanfälligkeit möglich wurde.
Woher kam CVE-2018-6789?
Kurz gesagt, die Sicherheitsanfälligkeit ist auf einen Fehler bei der Berechnung der Pufferlänge in der von Exim verwendeten Funktion base64.c: b64decode zurückzuführen. Mehr dazu lesen Sie hier (auf Englisch).
Wenn Sie eine Zeichenfolge mit besonderer Länge eingeben, können Sie ein Informationsbyte überschreiben und mit einfachen Aktionen die Serverbefehle ändern, um beliebigen Code (RCE) auszuführen.
Exim weist einen Puffer von 3 * (len / 4) +1 Bytes zu, um die decodierten Daten zu speichern. Wenn dem Funktionseingang jedoch eine falsche base64-Zeichenfolge zugeführt wird, z. B. 4n + 3 lang, weist Exim dem Puffer 3n + 1 Byte zu. Es werden jedoch 3n + 2 Datenbytes in den Puffer geschrieben. Dadurch wird ein Byte im Heap überschrieben.
Exim bietet store_malloc_3 und store_free_3, Wrapper für die malloc- und kostenlosen Funktionen von Glibc. Glibc ordnet einen großen Datenblock zu, speichert dann seine Metadaten in den ersten 0x10 Bytes und gibt einen Zeiger auf den Speicher zurück, in den der Benutzer seine Daten schreiben kann. So sieht es aus: Die
Metadaten enthalten die Größe des vorherigen Blocks (der im Speicher oben), die Größe des aktuellen Blocks und einige Flags. Die ersten drei Bits der Größe werden zum Speichern von Flags verwendet. In diesem Beispiel bedeutet Größe 0x81, dass der aktuelle Block 0x80 Byte beträgt und der vorherige Block bereits verwendet wird.
Freigegebene Blöcke, die einmal von Exim verwendet wurden, werden in eine doppelt verknüpfte Liste gestellt. Glibc verwaltet es durch Flags und führt zusammenhängende freigegebene Blöcke zu einem größeren Block zusammen, um eine Fragmentierung zu vermeiden. Für jede Speicherzuweisungsanforderung untersucht Glibc diese Blöcke in FIFO-Reihenfolge und verwendet sie erneut.
Um die Leistung zu verbessern, verwendet Exim ein eigenes Speicherverwaltungs-Add-On. Es basiert auf der Storeblock-Struktur. Das Hauptmerkmal von Storeblock ist, dass jedes von ihnen mindestens 0x2000 Bytes groß ist, was eine Einschränkung für die Ausnutzung darstellt. Beachten Sie, dass Storeblock auch Blockdaten sind. So sieht es im Speicher aus:
Vom Mailserver unterstützte Befehle zum Organisieren von Daten auf dem Heap:
- EHLO hostname. EHLO hostname sender_host_name. , store_free store_malloc .
- . , , Exim .
- AUTH. Exim base64 . , store_get (). store_get().
- Reset EHLO/HELO, MAIL, RCPT. , Exim smtp_reset. store_reset , « ». , storeblock- store_get .
Um einen Ein-Byte-Überlauf im Heap verwenden zu können, müssen wir in der Lage sein, den Datenblock freizugeben, der sich unter der decodierten Zeichenfolge base64 befindet. Hierfür ist Sender_host_name geeignet.
Der Heap muss so gebildet werden, dass der Datenblock über dem Block mit sender_host_name frei bleibt.
Dazu müssen Sie:
1. Einen großen Block in einen unsortierten Behälter legen. Zunächst senden wir eine EHLO-Nachricht mit einem übergroßen Hostnamen, damit ein Teil der Länge 0x6060 in einem unsortierten Bin zugeordnet und freigegeben wird.
2. Wählen Sie den ersten Storeblock aus. Dann senden wir einen nicht erkannten Befehl, um store_get () aufzurufen und den Storeblock innerhalb des freigegebenen Chunks zuzuweisen.
3. Wählen Sie den zweiten Block aus und lassen Sie den ersten los. Wir senden EHLO, um den zweiten Block zu erhalten. Der erste Block wird nacheinander freigegeben, da smtp_reset nach Abschluss von EHLO aufgerufen wird.
Sobald der Heap vorbereitet ist, können wir ihn verwenden, um die ursprüngliche Blockgröße zu überschreiben. Wir ändern 0x2021 in 0x20f1, wodurch der Block leicht erweitert wird.
4. Senden Sie base64-Daten und überlaufen Sie 1 Byte auf dem Heap. Führen Sie den Befehl AUTH aus, um base64-Daten zu senden.
5. Erstellen und senden Sie eine Zeichenfolge geeigneter Größe. Da wir den Datenblock erweitert haben, liegt der Anfang des nächsten Blocks jetzt irgendwo im Inneren. Jetzt müssen wir das Problem beheben, um die Glibc-Integritätsprüfung zu bestehen. Wir senden hier einen weiteren base64-String.
6. Befreien Sie den erweiterten Block. Um den Inhalt des erweiterten Blocks zu steuern, müssen wir zuerst den Block freigeben, da wir ihn nicht direkt bearbeiten können. Das heißt, wir müssen eine neue EHLO-Nachricht senden, um den alten Hostnamen freizugeben. Bei der Verarbeitung des EHLO-Befehls wird jedoch bei erfolgreicher Ausführung smtp_reset aufgerufen. Dies kann zu einer Programmunterbrechung oder einer abnormalen Beendigung führen. Um dies zu vermeiden, senden wir einen ungültigen Hostnamen wie ein +.
7. Überschreiben Sie den nächsten Zeiger des überlappenden Storeblocks.
Nachdem der Block freigegeben wurde, können wir ihn mit AUTH abrufen und einen Teil des überlappenden Storeblocks überschreiben. Hier verwenden wir eine Technik namens "Teilaufzeichnung". Dies ermöglicht es uns, den Zeiger zu ändern, ohne die ASLR zu beschädigen. Wir haben den folgenden Zeiger teilweise auf einen Block geändert, der ACL-Zeilen enthält. ACL-Zeilen werden durch eine Reihe von Globals angegeben, z. B. uschar * acl_smtp_helo;
Diese Zeiger werden zu Beginn des Exim-Prozesses initialisiert und entsprechend der Konfiguration festgelegt. Wenn die Konfiguration beispielsweise die Zeile acl_smtp_mail = acl_check_mail enthält, zeigt der Zeiger acl_smtp_mail auf die Zeile acl_check_mail.
Jedes Mal, wenn der Server einen MAIL FROM-Befehl empfängt, führt Exim eine ACL-Prüfung durch, die zuerst acl_check_mail erweitert. Wenn Exim bei der Erweiterung auf die Zeile $ {run {cmd}} stößt, versucht es, den Befehl cmd auszuführen, damit ein entfernter Angreifer den Code zur Ausführung erhalten kann.
8. Setzen Sie den Storeblock zurück und rufen Sie den Storeblock mit der ACL ab. Der ACL-Block befindet sich jetzt in der Blockchain. Es wird freigegeben, nachdem smtp_reset () fertig ist, und dann können wir es wieder abrufen, indem wir einige Blöcke zuweisen.
9. Überschreiben Sie die ACL-Zeilen und führen Sie die ACL-Prüfung aus. Schließlich schreiben wir den gesamten Block mit den ACL-Zeilen neu. Jetzt senden wir Befehle wie EHLO, MAIL, RCPT, um die ACL-Prüfung auszuführen.
Übrigens wurde die Ausnutzung der Sicherheitsanfälligkeit durch die aus einem uns unbekannten Grund deaktivierte ASLR erleichtert.
Welche Probleme hatte der Kunde?
Das erste ist das Fehlen eines Update-Managements. Aufgrund der Tatsache, dass die alte Version von Exim verwendet wurde, war es möglich, einen Kompromiss des Systems zu organisieren. Um dies zu vermeiden, empfehlen wir, die regelmäßige Überprüfung und Installation von Sicherheitsupdates für die Komponenten der Informationsinfrastruktur zu organisieren.
Wir empfehlen, mindestens einmal im Monat nach neuen Sicherheits- und kritischen Updates zu suchen. Es ist besser, die Websites / Mailinglisten der Gerätehersteller oder Informationen aus Repositorys zu verwenden, um nach Updates zu suchen.
Der Bank fehlte auch ein Schwachstellenmanagementprozess, weshalb die Schwachstelle nicht rechtzeitig erkannt wurde. Die Verwendung spezialisierter Schwachstellenscanner - zum Beispiel OpenVAS, Nessus, xSpider usw. - würde helfen, die Situation zu korrigieren. Regelmäßige Penetrationstests und die Überwachung des Zeitpunkts der Beseitigung von Schwachstellen würden ebenfalls helfen.
Zuguterletzt. Der Bank fehlte ein Change-Management-Prozess. Alle Änderungen wurden von Administratoren in der Produktionsumgebung vorgenommen. Folglich hat niemand dies kontrolliert oder überwacht. Dies führte dazu, dass ASLR auf dem Server deaktiviert war.
Ausgabe
Mehrere scheinbar nicht zusammenhängende Verstöße führten dazu, dass die Website der Bank kompromittiert wurde. Dies könnte von Angreifern verwendet werden, um beispielsweise die Bankdaten in ihre eigenen zu ändern.
Die Geschichte endete gut. Nach dem Kompromiss haben wir den Kunden sofort über die Situation informiert. Die Bank hat den Exim-Server dringend auf die aktuelle Version aktualisiert, für die die Sicherheitsanfälligkeit nicht mehr relevant ist. Wenn die Sicherheitsanfälligkeit jedoch nicht während des Penetrationstests, sondern von echten Angreifern identifiziert worden wäre, hätte das Ergebnis möglicherweise anders ausfallen können.