{"id":113257,"date":"2024-01-31T01:41:06","date_gmt":"2024-01-30T23:41:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/rezultaty-vtorogo-audita-bezopasnosti-razrabotok-proekta-tor"},"modified":"2024-01-31T01:41:06","modified_gmt":"2024-01-30T23:41:06","slug":"rezultaty-vtorogo-audita-bezopasnosti-razrabotok-proekta-tor","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/rezultaty-vtorogo-audita-bezopasnosti-razrabotok-proekta-tor","title":{"rendered":"Ergebnisse des zweiten Sicherheitsaudits der Tor-Projektentwicklungen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler des anonymen Tor-Netzwerks ver\u00f6ffentlichten die Ergebnisse des zweiten Audits, das von der Firma Radically Open Security von April bis August 2023 durchgef\u00fchrt wurde (zuvor fand von November 2022 bis April 2023 das erste Audit durch Cure53 statt). Die \u00dcberpr\u00fcfung betraf den Code zur Gew\u00e4hrleistung des Betriebs von Exit-Knoten, den Tor-Browser, Infrastrukturkomponenten (Metriksammlung, SWBS, API Onionoo) und Testwerkzeuge. Hauptziel der Wiederpr\u00fcfung war die Bewertung der \u00c4nderungen, die zur Verbesserung der Geschwindigkeit und Zuverl\u00e4ssigkeit des Tor-Netzwerks vorgenommen wurden, wie das im Release Tor 0.4.8 eingef\u00fchrte Protokoll zur Traffic-Trennung Conflux und Methoden zum Schutz von Onion-Diensten vor DoS-Angriffen basierend auf Arbeitsnachweis. <\/p>\n
Im Rahmen des Audits wurden 17 Sicherheitsanf\u00e4lligkeiten festgestellt, von denen nur eine als kritisch eingestuft wurde. Vier Sicherheitsanf\u00e4lligkeiten erhielten ein mittleres Gef\u00e4hrdungspotential, 12 wurden als geringf\u00fcgige Probleme eingestuft. Die gef\u00e4hrlichste Anf\u00e4lligkeit wurde in der Anwendung onbasca (Onion Bandwidth Scanner), die zur Bandbreitenscanning von Knoten des Netzwerks verwendet wird, identifiziert. <\/p>\n
Die Schwachstelle wird durch die M\u00f6glichkeit verursacht, Anfragen \u00fcber die HTTP-Methode GET zu senden, die es erm\u00f6glichen, Cross-Site-Anfragen im Namen eines anderen Benutzers (CSRF, Cross-Site Request Forgery) auszuf\u00fchren. Dies gibt dem Angreifer die M\u00f6glichkeit, seine eigenen Br\u00fcckenpunkte durch Manipulation des Parameters «bridge_lines» in die Datenbank einzuf\u00fcgen. Zum Beispiel k\u00f6nnte der Angreifer eine Web-Seite mit JavaScript-Code platzieren: 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 beim Onion Bandwidth Scanner diese Seite \u00f6ffnet, wird die IP «0.0.0.0» in die Datenbank im Namen des Benutzers hinzugef\u00fcgt. <\/p>\n
Probleme mit mittlerem Gef\u00e4hrdungspotential: <\/p>\n
\n
Denial-of-Service in der metrics-lib durch das Senden einer gro\u00dfen komprimierten Datei \u2014 da die Datei im RAM extrahiert wird, kann eine Art Zip-Bombe \u00fcbergeben werden (zum Beispiel, man kann 600 MB Nullen in 0,0006 MB packen) und so den verf\u00fcgbaren Speicher aussch\u00f6pfen.\n
Die Verwendung des Drittanbieter-Moduls tun2socks im tor-android-service (verwendet im Tor-Browser f\u00fcr Android), dessen Unterst\u00fctzungen eingestellt wurde.\n
Das Schreiben von Null-Bytes au\u00dferhalb des zugewiesenen Puffers im Tor-Client aufgrund der Verwendung der Funktion read_file_to_str_until_eof, die die Gr\u00f6\u00dfe ohne Ber\u00fccksichtigung des Nullcharakters zur\u00fcckgibt.\n
Eine Sicherheitsanf\u00e4lligkeit in sbws (Simple Bandwidth Scanner), die es erm\u00f6glicht, eine HTTPS-Verbindung auf HTTP zur\u00fcckzusetzen, indem eine Weiterleitung zu HTTP verwendet wird. Ein von einem Angreifer kontrollierter Ausgangsknoten von Tor k\u00f6nnte diese Schwachstelle nutzen, um API-Token zu leaken. <\/ul>\n