hasan-khalil/cve-2020-6514Exploit für CVE-2020-6514, der auf WebRTC SCTP Speicherkorruption in Android-Anwendungen abzielt. Verwendet Frida, um native Funktionen zu hooken und SCTP-Pakete für die Remote-Code-Ausführung zu verändern.
Der Exploit
Als ich den Exploit schrieb, habe ich ursprünglich die SCTP-Pakete verändert, die an das Zielgerät gesendet wurden, indem ich die Quelle von WebRTC änderte und sie neu kompilierte. Dies war für Angriffe auf Closed-Source-Anwendungen nicht praktikabel, also wechselte ich schließlich zu Frida, um die Binärdatei des angreifenden Geräts zu hooken. Fridas Hooking-Funktionalität erlaubt es, Code vor und nach einem bestimmten nativen Funktionsaufruf auszuführen, was es meinem Exploit ermöglichte, ausgehende SCTP-Pakete zu verändern sowie eingehende zu inspizieren. Funktional ist es äquivalent zur Änderung der Quelle des angreifenden Clients, aber anstatt dass die Änderungen zur Kompilierzeit in der Quelle vorgenommen werden, werden sie zur Laufzeit dynamisch von Frida durchgeführt. Der Quellcode für den Exploit ist hier verfügbar.
Es gibt sieben Funktionen, die das angreifende Gerät hooken muss, wie folgt:
usrsctp_conninput // empfängt eingehende SCTP DtlsTransport::SendPacket // sendet ausgehende SCTP cricket::SctpTransport::SctpTransport // erkennt, wann der SCTP-Transport bereit ist calculate_crc32c // berechnet Prüfsumme für SCTP-Pakete sctp_hmac // führt HMAC durch, um den geheimen Schlüssel zu erraten sctp_hmac_m // signiert SCTP-Paket SrtpTransport::ProtectRtp // unterdrückt RTP, um Heap-Rauschen zu reduzieren
Diese Funktionen können als Symbole oder als Offsets in der Binärdatei gehooked werden.
Außerdem werden drei Adress-Offsets aus der Binärdatei des Zielgeräts benötigt, damit der Exploit funktioniert. Der Offset zwischen der system-Funktion und der malloc-Funktion sowie der Offset zwischen dem im vorherigen Beitrag beschriebenen Gadget und der malloc-Funktion sind zwei davon. Diese Offsets befinden sich in libc, einer Android-Systembibliothek, daher müssen sie basierend auf der Android-Version des Zielgeräts bestimmt werden. Der Offset vom Ort der cricket::SctpTransport vtable zum Ort von malloc in der Global Offset Table wird ebenfalls benötigt. Dieser muss aus der Binärdatei bestimmt werden, die WebRTC in der angegriffenen Anwendung enthält.
Beachten Sie, dass die bereitgestellten Exploit-Skripte eine schwerwiegende Einschränkung haben: Jedes Mal, wenn Speicher gelesen wird, funktioniert es nur, wenn Bit 31 des Zeigers gesetzt ist. Die Gründe dafür werden in Teil 2 erläutert. Das Exploit-Skript enthält ein Beispiel, wie dies behoben und jeder Zeiger mit FWD_TSN-Chunks gelesen werden kann, aber dies ist nicht für jede Leseoperation implementiert. Zu Testzwecken habe ich das Gerät zurückgesetzt, bis die WebRTC-Bibliothek an einer günstigen Stelle eingeblendet war.
Eine Liste beliebter Android-Anwendungen, die WebRTC integrieren, wurde durch die Suche nach einer bestimmten Zeichenkette in usrsctp in APK-Dateien im Google Play Store ermittelt. Ungefähr 200 Anwendungen mit mehr als fünf Millionen Nutzern schienen WebRTC zu verwenden. Ich habe diese Anwendungen bewertet, um festzustellen, ob sie plausibel von den Schwachstellen des Exploits betroffen sein könnten und welche Auswirkungen dies hätte.
Es stellte sich heraus, dass die Arten, wie Anwendungen WebRTC nutzen, recht unterschiedlich sind, aber in vier Hauptkategorien unterteilt werden können.
Die Auswirkungen der im Exploit verwendeten Schwachstellen sind für jede dieser Kategorien unterschiedlich. Projektion ist ein geringes Risiko, da viel Benutzerinteraktion erforderlich ist, um die WebRTC-Verbindung herzustellen, und der Benutzer ohnehin Zugriff auf beide Seiten der Verbindung hat, sodass es wenig zu gewinnen gibt, wenn man die andere Seite kompromittiert.
Streaming ist ebenfalls ein relativ geringes Risiko. Obwohl es möglich ist, dass einige Anwendungen Peer-to-Peer-Verbindungen nutzen, wenn ein Stream eine geringe Zuschauerzahl hat, verwenden sie normalerweise einen Zwischenserver, der die WebRTC-Verbindung vom sendenden Peer beendet und neue Verbindungen zu den empfangenden Peers startet. Das bedeutet, dass der Angreifer normalerweise keine fehlerhaften Pakete direkt an einen Peer senden kann. Selbst bei einer Peer-to-Peer-Streaming-Konfiguration ist Benutzerinteraktion erforderlich, damit das Ziel den Stream ansehen kann, und oft gibt es keine Möglichkeit, den Zugriff auf einen Stream einzuschränken. Aus diesem Grund sind Streaming-Anwendungen, die WebRTC verwenden, wahrscheinlich nicht für gezielte Angriffe geeignet. Natürlich ist es möglich, dass diese Schwachstellen die von Streaming-Diensten verwendeten Server betreffen, aber dies wurde in dieser Untersuchung nicht betrachtet.
Browser sind mit ziemlicher Sicherheit anfällig für die meisten Fehler in WebRTC, da sie eine große Kontrolle über die Konfiguration ermöglichen. Um einen solchen Fehler in einem Browser auszunutzen, müsste ein Angreifer einen Host einrichten, der wie der andere Peer in der Peer-to-Peer-Verbindung agiert, und das Ziel davon überzeugen, eine Webseite zu besuchen, die einen Anruf zu diesem Host startet. In diesem Fall hätte die Schwachstelle eine ähnliche Auswirkung wie andere Speicherkorruptions-Schwachstellen in JavaScript.
Konferenzen sind die risikoreichste Nutzung von WebRTC, aber die tatsächliche Auswirkung einer Schwachstelle hängt stark davon ab, wie Benutzer einer Anwendung miteinander Kontakt aufnehmen. Das höchste Risiko stellt ein Design dar, bei dem jeder Benutzer jeden anderen Benutzer basierend auf einer Kennung kontaktieren kann. Einige Anwendungen erfordern, dass der Angerufene auf eine bestimmte Weise mit dem Anrufer interagiert hat, bevor ein Anruf getätigt werden kann, was es schwieriger macht, ein Ziel zu kontaktieren, und das Risiko im Allgemeinen verringert. Einige Anwendungen verlangen, dass Benutzer einen Code eingeben oder einen Link besuchen, um einen Anruf zu starten, was einen ähnlichen Effekt hat. Es gibt auch eine große Gruppe von Anwendungen, bei denen es schwierig oder unmöglich ist, einen bestimmten Benutzer anzurufen, z. B. Chat-Roulette-Anwendungen und Anwendungen, die Funktionen bieten, mit denen ein Benutzer einen Anruf beim Kundensupport starten kann.
Für diese Untersuchung konzentrierte ich mich auf Konferenzanwendungen, die es Benutzern ermöglichen, bestimmte andere Benutzer zu kontaktieren. Dies reduzierte meine Liste von 200 Anwendungen auf 14 Anwendungen, wie folgt.
