Die Entwickler des anonymen Tor-Netzwerks veröffentlichten die Ergebnisse des zweiten Audits, das von der Firma Radically Open Security von April bis August 2023 durchgeführt wurde (zuvor fand von November 2022 bis April 2023 das erste Audit durch Cure53 statt). Die Überprüfung betraf den Code zur Gewährleistung des Betriebs von Exit-Knoten, den Tor-Browser, Infrastrukturkomponenten (Metriksammlung, SWBS, API Onionoo) und Testwerkzeuge. Hauptziel der Wiederprüfung war die Bewertung der Änderungen, die zur Verbesserung der Geschwindigkeit und Zuverlässigkeit des Tor-Netzwerks vorgenommen wurden, wie das im Release Tor 0.4.8 eingeführte Protokoll zur Traffic-Trennung Conflux und Methoden zum Schutz von Onion-Diensten vor DoS-Angriffen basierend auf Arbeitsnachweis.
Im Rahmen des Audits wurden 17 Sicherheitsanfälligkeiten festgestellt, von denen nur eine als kritisch eingestuft wurde. Vier Sicherheitsanfälligkeiten erhielten ein mittleres Gefährdungspotential, 12 wurden als geringfügige Probleme eingestuft. Die gefährlichste Anfälligkeit wurde in der Anwendung onbasca (Onion Bandwidth Scanner), die zur Bandbreitenscanning von Knoten des Netzwerks verwendet wird, identifiziert.
Die Schwachstelle entsteht durch die Möglichkeit, Anfragen über die HTTP-Methode GET zu senden, die es ermöglichen, intersite-Anfragen im Namen eines anderen Benutzers auszuführen (CSRF, Cross-Site Request Forgery). Dies gibt dem Angreifer die Möglichkeit, seine Brückenpunkte in die Datenbank einzufügen, indem er den Parameter „bridge_lines“ manipuliert. Zum Beispiel kann der Angreifer eine Webseite mit JavaScript-Code bereitstellen, der fetch(„http://127.0.0.1:8000/bridge-state/?bridge_lines=obfs4+0.0.0.000000+AAA+cert0+iat-mode0“), und wenn ein Benutzer mit einer aktiven Sitzung im Onion Bandwidth Scanner diese Seite öffnet, wird unter seinem Namen die IP „0.0.0.0“ in die Datenbank eingefügt.
Probleme mit mittlerem Gefährdungspotential:
- Denial of Service in metrics-lib durch die Übermittlung einer großen komprimierten Datei – da die Datei im Arbeitsspeicher entpackt wird, kann eine Art Zip-Bombe gesendet werden (z. B. können 600 MB Nullen in 0.0006 MB verpackt werden), was zu einem Ausschöpfen des verfügbaren Speichers führt.
- Die Verwendung des Drittanbieter-Moduls tun2socks im tor-android-service (verwendet im Tor-Browser für Android), dessen Unterstützungen eingestellt wurde.
- Das Schreiben von Null-Bytes außerhalb des zugewiesenen Puffers im Tor-Client aufgrund der Verwendung der Funktion read_file_to_str_until_eof, die die Größe ohne Berücksichtigung des Nullcharakters zurückgibt.
- Eine Sicherheitsanfälligkeit in sbws (Simple Bandwidth Scanner), die es ermöglicht, eine HTTPS-Verbindung auf HTTP zurückzusetzen, indem eine Weiterleitung zu HTTP verwendet wird. Ein von einem Angreifer kontrollierter Ausgangsknoten von Tor könnte diese Schwachstelle nutzen, um API-Token zu leaken.
Quelle: opennet.ru
