Wprowadzono wersję specjalizowanej przeglądarki Tor Browser 11.0.2, skoncentrowanej na zapewnieniu anonimowości, bezpieczeństwa i prywatności. Korzystając z Tor Browser, cały ruch jest kierowany wyłącznie przez sieć Tor, a dostęp bezpośredni przez standardowe połączenie sieciowe aktualnego systemu jest niemożliwy, co uniemożliwia śledzenie rzeczywistego adresu IP użytkownika (w przypadku kompromitacji przeglądarki, atakujący mogą uzyskać dostęp do parametrów sieciowych systemu, dlatego w celu całkowitego zablokowania możliwych wycieków należy używać produktów takich jak Whonix). Wersje Tor Browser przygotowane są dla systemów Linux, Windows i macOS.
Aby zapewnić dodatkową ochronę, Tor Browser zawiera dodatek HTTPS Everywhere, który umożliwia korzystanie z szyfrowania ruchu na wszystkich stronach, gdzie jest to możliwe. W celu zminimalizowania zagrożeń związanych z atakami wykorzystującymi JavaScript oraz domyślnym blokowaniem wtyczek w zestawie znajduje się dodatek NoScript. W walce z blokowaniem i inspekcją ruchu stosowane są alternatywne transporty. W celu ochrony przed identyfikacją charakterystyk specyficznych dla danego użytkownika, wyłączono lub ograniczono API WebGL, WebGL2, WebAudio, Social, SpeechSynthesis, Touch, AudioContext, HTMLMediaElement, Mediastream, Canvas, SharedWorker, WebAudio, Permissions, MediaDevices.enumerateDevices oraz screen.orientation, a także wyłączono środki do wysyłania telemetry, Pocket, Reader View, HTTP Alternative-Services, MozTCPSocket, „link rel=preconnect”, zmodyfikowano libmdns.
W nowej wersji zsynchronizowano kod z bazą wydania Firefox 91.4.0, w którym naprawiono 15 podatności, z czego 10 uznano za niebezpieczne. 7 podatności wynika z problemów z pamięcią, takich jak przepełnienia buforów i odwołania do już zwolnionych obszarów pamięci, co potencjalnie może prowadzić do wykonania kodu przez złośliwego użytkownika przy otwieraniu specjalnie przygotowanych stron. Z wersji platformy Linux wykluczono niektóre czcionki ttf, których użycie prowadziło do zakłóceń w renderowaniu tekstu w elementach interfejsu w Fedora Linux. Wyłączono ustawienie „network.proxy.allow_bypass”, które kontroluje aktywność ochrony przed nieprawidłowym używaniem API Proxy w dodatkach. Dla transportu obfs4 domyślnie zastosowano nową bramę „deusexmachina”.
Tymczasem trwa historia blokady Tora w Rosji. Roskomnadzor zmienił w rejestrze zakazanych stron maskę blokowanych domenów z „www.torproject.org” na „*.torproject.org” i rozszerzył listę adresów IP, które mają być blokowane. W wyniku zmiany zablokowane zostały większość subdomen projektu Tor, w tym blog.torproject.org, gettor.torproject.org i support.torproject.org. Dostępny pozostaje forum.torproject.net, umieszczony w infrastrukturze Discourse. Częściowo dostępne są gitlab.torproject.org i lists.torproject.org, do których początkowo nie było dostępu, ale później został on przywrócony, prawdopodobnie po zmianie adresów IP (gitlab teraz kieruje na host gitlab-02.torproject.org).
Jednakże przestały być zauważane blokady bramek i węzłów sieci Tor, a także hosta ajax.aspnetcdn.com (CDN Microsoft), używanego w transporcie meek-asure. Zdaje się, że eksperymenty z blokowaniem węzłów sieci Tor po zablokowaniu strony Tor ustały. Sytuacja jest skomplikowana z lustrzanym odbiciem tor.eff.org, które nadal działa. Faktem jest, że lustro tor.eff.org jest powiązane z tym samym adresem IP, co jest używane dla domeny eff.org organizacji EFF (Electronic Frontier Foundation), dlatego blokada tor.eff.org doprowadzi do częściowej blokady znanej strony rzecznika praw.
Dodatkowo można odnotować publikację nowego raportu o możliwych próbach przeprowadzania ataków deanonimizacyjnych na użytkowników Tora, związanych z grupą KAX17, identyfikowaną przez specyficzne fikcyjne adresy e-mail w parametrach węzłów. W ciągu września i października projekt Tor zablokował 570 potencjalnie szkodliwych węzłów. W szczytowym momencie grupie KAX17 udało się doprowadzić liczbę kontrolowanych węzłów w sieci Tor do 900, rozmieszczonych u 50 różnych dostawców, co odpowiada około 14% wszystkich relacji (dla porównania, w 2014 roku atakującym udało się uzyskać kontrolę nad prawie połową relacji Tora, a w 2020 roku nad 23,95% węzłów wyjściowych).
Umieszczenie dużej liczby węzłów kontrolowanych przez jednego operatora pozwala na deanonimizację użytkowników za pomocą ataku klasy Sybil, który może być przeprowadzony, gdy przestępcy kontrolują pierwszy i ostatni węzeł w łańcuchu anonimizacji. Pierwszy węzeł w łańcuchu Tor zna adres IP użytkownika, a ostatni zna adres IP żądanego zasobu, co umożliwia deanonimizację zapytania przez dodanie po stronie węzła wejściowego określonego ukrytego znacznika do nagłówków pakietów, które pozostają niezmienione przez cały czas trwania łańcucha anonimizacji, oraz analizę tego znacznika po stronie węzła wyjściowego. W przypadku kontroli nad węzłami wyjściowymi atakujący mogą również wprowadzać zmiany w niezaszyfrowanym ruchu, na przykład usuwać przekierowania na wersje HTTPS stron i przechwytywać niezaszyfrowane treści.
Według przedstawicieli sieci Tor większość usuniętych węzłów tej jesieni była wykorzystywana tylko jako węzły pośrednie, nieużywane do obsługi przychodzących i wychodzących zapytań. Niektórzy badacze zauważają, że węzły należały do wszystkich kategorii, a prawdopodobieństwo napotkania kontrolowanego przez grupę KAX17 węzła wejściowego wynosiło 16%, a wyjściowego — 5%. Nawet jeśli tak jest, to całkowite prawdopodobieństwo, że użytkownik jednocześnie trafi na wejściowy i wyjściowy węzeł grupy 900 kontrolowanych węzłów KAX17, szacowane jest na 0,8%. Nie ma bezpośrednich dowodów na wykorzystanie węzłów KAX17 do przeprowadzania ataków, ale potencjalne takie ataki nie są wykluczone.
Źródło: opennet.ru
