Die neueste Version des spezialisierten Browsers Tor Browser 11.0.2 wurde veröffentlicht, mit dem Fokus auf Anonymität, Sicherheit und Datenschutz. Bei der Verwendung von Tor Browser wird der gesamte Datenverkehr ausschließlich über das Tor-Netzwerk geleitet, wodurch eine direkte Verbindung über die aktuelle Netzwerkanbindung des Systems unmöglich ist. Dies verhindert die Rückverfolgbarkeit der echten IP-Adresse des Nutzers. Im Falle eines Browserangriffs könnten Angreifer auf die Netzwerkeinstellungen des Systems zugreifen, weshalb zur vollständigen Vermeidung möglicher Datenlecks Produkte wie Whonix eingesetzt werden sollten. Die Tor Browser-Bundles sind für Linux, Windows und macOS verfügbar.
Um zusätzlichen Schutz zu gewährleisten, enthält der Tor Browser die Erweiterung HTTPS Everywhere, die die Verschlüsselung des Datenverkehrs auf allen Websites ermöglicht, wo dies möglich ist. Um die Bedrohung durch Angriffe unter Verwendung von JavaScript zu verringern, wird standardmäßig die Erweiterung NoScript mitgeliefert, die Plugins blockiert. Alternativ werden Transportmethoden eingesetzt, um gegen Zensur und Verkehrsinspizierung vorzugehen. Um die Identifizierung spezifischer Merkmale einzelner Besucher zu verhindern, sind die APIs WebGL, WebGL2, WebAudio, Social, SpeechSynthesis, Touch, AudioContext, HTMLMediaElement, Mediastream, Canvas, SharedWorker, WebAudio, Permissions, MediaDevices.enumerateDevices und screen.orientation deaktiviert oder eingeschränkt. Zudem wurden Telemetrie-Übertragungen, Pocket, Reader View, HTTP Alternative-Services, MozTCPSocket, „link rel=preconnect“ und das modifizierte libmdns deaktiviert.
In der neuen Version wurde die Synchronisation mit dem Code-Release Firefox 91.4.0 umgesetzt, in dem 15 Sicherheitsanfälligkeiten behoben wurden, von denen 10 als kritisch eingestuft sind. 7 dieser Anfälligkeiten resultieren aus Speicherproblemen wie Pufferüberläufen und dem Zugriff auf bereits freigegebene Speicherbereiche und könnten potenziell zur Ausführung von Angreifer-Code führen, wenn speziell gestaltete Seiten geöffnet werden. Einige ttf-Schriftarten wurden aus der Linux-Version entfernt, da ihre Verwendung zu einer fehlerhaften Textdarstellung in Benutzeroberflächenelementen unter Fedora Linux führte. Die Einstellung „network.proxy.allow_bypass“, die die Aktivität des Schutzes gegen fehlerhafte Proxy-API-Nutzung in Erweiterungen steuert, wurde deaktiviert. Für den obfs4-Transport wird standardmäßig ein neuer Gateway „deusexmachina“ verwendet.
In der Zwischenzeit setzt sich die Geschichte um die Blockierung von Tor in der RF fort. Roskomnadzor hat die Maske der gesperrten Webseiten im Register geändert. Domänen Die Domain „www.torproject.org“ wurde auf „*.torproject.org“ ausgeweitet und die Liste der zu blockierenden IP-Adressen wurde erweitert. Aufgrund dieser Änderungen sind die meisten Subdomains des Tor-Projekts, einschließlich blog.torproject.org, gettor.torproject.org und support.torproject.org, blockiert. Der Zugang zu forum.torproject.net, das in der Discourse-Infrastruktur gehostet wird, bleibt bestehen. Teilweise sind gitlab.torproject.org und lists.torproject.org zugänglich, auf die zunächst kein Zugriff mehr möglich war, der jedoch vermutlich nach einer IP-Adressänderung wiederhergestellt wurde (gitlab ist jetzt auf den Host gitlab-02.torproject.org geroutet).
Gleichzeitig wurden die Blockierungen von Tor-Gateways und -Knoten sowie des Hosts ajax.aspnetcdn.com (Microsoft CDN), der im Transport von meek-asure verwendet wird, nicht mehr festgestellt. Anscheinend wurden die Experimente zur Blockierung von Tor-Knoten nach der Blockierung der Tor-Website eingestellt. Eine komplexe Situation besteht mit dem Mirror tor.eff.org, der weiterhin funktioniert. Der Grund dafür ist, dass der Mirror tor.eff.org an die gleiche Domain gebunden ist, die IP-Adresse gebunden sind, die für die Domain eff.org der Organisation EFF (Electronic Frontier Foundation) verwendet wird. Daher würde eine Blockierung von tor.eff.org zu einer teilweisen Blockierung der Website dieser bekannten Menschenrechtsorganisation führen.
Zudem kann die Veröffentlichung eines neuen Berichts über mögliche Angriffe zur De-Anonymisierung von Tor-Nutzern erwähnt werden, die mit der Gruppe KAX17 in Verbindung gebracht werden. Diese Gruppe zeichnet sich durch spezifische falsche Kontakt-E-Mails in den Knoteneinstellungen aus. Im Verlauf von September und Oktober wurden durch das Tor-Projekt 570 potenziell schädliche Knoten blockiert. Zu einem Höhepunkt gelang es der Gruppe KAX17, die Anzahl der kontrollierten Knoten im Tor-Netzwerk auf 900 zu erhöhen, die bei 50 verschiedenen Anbietern gehostet waren, was etwa 14 % der Gesamtzahl der Relais entspricht (zum Vergleich: 2014 gelang es Angreifern, die Kontrolle über fast die Hälfte der Tor-Relais zu erlangen, und 2020 über 23,95 % der Ausgangsknoten).
Die Platzierung einer großen Anzahl von Knoten, die unter der Kontrolle eines einzigen Betreibers stehen, ermöglicht es, Benutzer durch einen Sybil-Angriff zu de-anonymisieren, der durchgeführt werden kann, wenn Angreifer die Kontrolle über den ersten und letzten Knoten in der Anonymisierungskette haben. Der erste Knoten in der Tor-Kette kennt die IP-Adresse des Benutzers, während der letzte die IP-Adresse der angeforderten Ressource kennt, was es ermöglicht, die Anfrage durch das Hinzufügen eines bestimmten versteckten Tags in die Pakethauptinformationen auf der Eingangsseite zu de-anonymisieren. Diese Tags bleiben während der gesamten Anonymisierungskette unverändert und können am Ausgangsknoten analysiert werden. Wenn Angreifer auch Kontrolle über die Ausgangsknoten haben, können sie Änderungen am unverschlüsselten Verkehr vornehmen, beispielsweise Umleitungen zu den HTTPS-Versionen von Websites entfernen und unverschlüsselte Inhalte abfangen.
Laut Vertretern des Tor-Netzwerks wurden die meisten der im Herbst entfernten Knoten nur als Zwischenknoten genutzt und waren nicht für die Verarbeitung eingehender und ausgehender Anfragen vorgesehen. Einzelne Forscher weisen darauf hin, dass die Knoten allen Kategorien zugeordnet waren und die Wahrscheinlichkeit, auf einen von der Gruppe KAX17 kontrollierten Eingabeknoten zu treffen, bei 16 % lag, während es bei einem Ausgangsknoten 5 % waren. Selbst wenn dies der Fall ist, wird die Gesamtwahrscheinlichkeit, dass ein Benutzer gleichzeitig mit einem Eingangs- und einem Ausgangsknoten der Gruppe von 900 kontrollierten Knoten von KAX17 verbunden ist, auf 0,8 % geschätzt. Es gibt keine direkten Beweise für die Nutzung der Knoten von KAX17 für Angriffe, aber potenziell ähnliche Angriffe sind nicht ausgeschlossen.
Quelle: opennet.ru
