Atak Sybil w sieci Tor: jak masowe relay’e mogą zagrozić anonimowości użytkowników

Sieć Tor została zaprojektowana tak, aby żaden pojedynczy węzeł nie posiadał pełnej wiedzy o komunikacji użytkownika. Adres IP jest widoczny po stronie wejścia, cel komunikacji może być widoczny po stronie wyjścia, natomiast pomiędzy nimi znajduje się dodatkowa warstwa relayów.

Na pierwszy rzut oka wydaje się więc, że wystarczy odpowiednio duża liczba niezależnych węzłów, aby zapewnić bezpieczeństwo.

Problem zaczyna się wtedy, gdy wiele pozornie niezależnych węzłów jest w rzeczywistości kontrolowanych przez jednego operatora.

To właśnie jest istota ataku Sybil.

W przypadku Tora nie chodzi jednak wyłącznie o samo uruchomienie dużej liczby serwerów. Znacznie ciekawsze pytanie brzmi:

Czy operator kontrolujący odpowiednio dużą część infrastruktury może zwiększyć prawdopodobieństwo przejęcia strategicznych pozycji w obwodach Tor?

Odpowiedź wymaga zrozumienia sposobu wyboru relayów, wag przepustowości, roli Guardów, separacji pozycji w obwodzie oraz możliwości prowadzenia korelacji ruchu.

Sybil to nie „dużo serwerów”

Najprostszy model ataku Sybil wygląda następująco:

              Jeden operator
                    |
       +------------+------------+
       |            |            |
    Relay A      Relay B      Relay C
       |            |            |
    Relay D      Relay E      Relay F

Dla systemu mogą to być różne tożsamości.

Z punktu widzenia operatora:

A = B = C = D = E = F

Wszystkie należą do jednego przeciwnika.

To fundamentalny problem systemów rozproszonych:

liczba identyfikatorów nie musi odpowiadać liczbie niezależnych uczestników.

W przypadku Tora ma to szczególne znaczenie, ponieważ relay’e uczestniczą w budowaniu obwodów komunikacyjnych.

Netbe opisywał już mechanizmy ochrony przed tym zagrożeniem w artykule Jak działa obrona przed atakami Sybil w sieci Tor?.

Dlaczego Sybil jest szczególnie interesujący w Torze?

W klasycznym systemie peer-to-peer atak Sybil może polegać na stworzeniu ogromnej liczby fałszywych uczestników.

W Torze sytuacja jest bardziej skomplikowana.

Nie wystarczy:

1000 relayów

jeżeli każdy z nich ma minimalną przepustowość i niewielkie znaczenie dla wyboru ścieżki.

Tor uwzględnia właściwości infrastruktury.

Można więc przyjąć uproszczony model:

Wpływ relay'a
    ↓
przepustowość
+
stabilność
+
rola
+
wagi w consensusie
+
zasady wyboru ścieżki

Dlatego liczba relayów i realny wpływ na sieć to dwie różne rzeczy.

Consensus jest ważniejszy niż sama liczba węzłów

Tor potrzebuje mechanizmu opisującego aktualny stan sieci.

Relay’e nie są po prostu przypadkowymi komputerami, które klient wybiera na podstawie adresu IP.

Sieć wykorzystuje informacje o relayach i ich właściwościach.

W uproszczeniu klient potrzebuje wiedzieć:

Które relay'e istnieją?
        ↓
Które są dostępne?
        ↓
Jaką pełnią rolę?
        ↓
Jaką mają przepustowość?
        ↓
Które spełniają wymagania obwodu?

To właśnie sprawia, że atak Sybil jest przede wszystkim problemem wpływu na mechanizm wyboru, a nie prostym problemem liczby serwerów.

Node count ≠ network influence

Załóżmy dwa scenariusze.

Scenariusz A

Atakujący posiada:

500 małych relayów

Scenariusz B

Atakujący posiada:

20 bardzo wydajnych relayów

Nie można automatycznie powiedzieć, że pierwszy wariant daje większą kontrolę.

W Torze znaczenie ma bowiem również efektywna waga infrastruktury.

Dlatego istotniejsze pytanie brzmi:

Jaki procent zasobów istotnych z punktu widzenia wyboru ścieżki kontroluje przeciwnik?

To znacznie bardziej interesująca metryka niż zwykłe:

Ile ma serwerów?

Najważniejszy cel ataku: strategiczna pozycja

Atakujący nie musi kontrolować całego obwodu.

Wystarczy, że zwiększy prawdopodobieństwo znalezienia się w strategicznym miejscu.

Przykładowo:

Użytkownik
    ↓
[Attacker Guard]
    ↓
Legal Relay
    ↓
Legal Relay

albo:

Użytkownik
    ↓
Legal Guard
    ↓
Legal Relay
    ↓
[Attacker Exit]

Jeszcze ciekawszy jest scenariusz:

Użytkownik
    ↓
[Attacker Guard]
    ↓
Legal Relay
    ↓
[Attacker Exit]
    ↓
Internet

Wtedy przeciwnik może potencjalnie uzyskać obserwacje z obu stron komunikacji.

I właśnie tutaj zaczyna się problem Traffic Correlation.

Jeden złośliwy relay nie oznacza złamania Tora

To bardzo ważne.

Jeżeli użytkownik ma:

Client
 ↓
[Malicious Guard]
 ↓
Honest Middle
 ↓
Honest Exit

złośliwy Guard może obserwować pewne informacje związane z wejściem ruchu do sieci.

Nie oznacza to jednak automatycznie, że zna jego cel.

Analogicznie:

Client
 ↓
Honest Guard
 ↓
Honest Middle
 ↓
[Malicious Exit]
 ↓
Destination

Exit może zobaczyć określone informacje dotyczące ruchu wychodzącego, ale nie posiada automatycznie adresu IP klienta.

To jest właśnie sens rozdzielenia informacji pomiędzy różne elementy obwodu.

Szerszy opis architektury znajduje się w Jak działa sieć Tor – anonimowość, routing cebulowy i zagrożenia.

Prawdziwe zagrożenie zaczyna się przy korelacji

Wyobraźmy sobie:

Client
  ↓
[Attacker]
  ↓
Tor Network
  ↓
[Attacker]
  ↓
Destination

Oba punkty mogą obserwować pewne charakterystyki ruchu.

Nie muszą znać jego treści.

Mogą interesować ich:

• czas wysłania danych,
• czas odebrania danych,
• wielkość transmisji,
• kierunek ruchu,
• długość sesji,
• charakterystyczne bursty,
• częstotliwość transmisji.

Następnie można próbować dopasować:

INPUT PATTERN
      ↓
    MATCH
      ↑
OUTPUT PATTERN

To właśnie end-to-end traffic correlation.

Netbe omawia ten problem również w materiale Ryzyka wycieku tożsamości (deanonymization) w sieci Tor.

Dlaczego timing jest tak istotny?

Szyfrowanie zmienia treść komunikacji.

Nie musi jednak całkowicie wyeliminować informacji o czasie.

Przykładowo:

t=10.001  → packet
t=10.015  → packet
t=10.031  → packet
t=10.048  → packet

Podobny wzorzec może być widoczny po drugiej stronie sieci.

Jeżeli przeciwnik ma wystarczająco dobre dane, może próbować odpowiedzieć na pytanie:

Czy te dwa strumienie są tym samym połączeniem?

To nie jest klasyczne „odszyfrowanie”.

To analiza metadanych.

Więcej o tym mechanizmie można przeczytać w Jak działa ukrywanie metadanych w ruchu sieciowym – Traffic Obfuscation.

Sybil + Traffic Correlation

To właśnie połączenie tych dwóch zagadnień jest najbardziej interesujące.

Sam Sybil:

Many attacker relays

nie musi wystarczyć.

Sam monitoring:

Traffic observation

również nie musi wystarczyć.

Ale:

Many controlled relays
        +
Strategic placement
        +
Traffic observation
        +
Correlation

tworzy znacznie poważniejszy model zagrożenia.

Dlaczego Guard jest tak ważny?

Wracamy tutaj do poprzedniego artykułu serii.

Guard jest szczególnym relay’em, ponieważ znajduje się na wejściu do sieci Tor.

W uproszczeniu:

Client
  ↓
Guard
  ↓
Middle
  ↓
Exit

Guard może znać adres IP klienta.

Dlatego uzyskanie kontroli nad dużą częścią Guardów byłoby znacznie bardziej interesujące dla przeciwnika niż kontrolowanie przypadkowych relayów.

Guard Persistence jako mechanizm obronny

Tor nie powinien ciągle losować nowego pierwszego relay’a.

Gdyby tak było:

Circuit 1 → Guard A
Circuit 2 → Guard B
Circuit 3 → Guard C
Circuit 4 → Guard D
Circuit 5 → Guard E

atakujący posiadający dużą liczbę relayów otrzymywałby wiele kolejnych okazji do znalezienia się na wejściu.

Stabilniejszy model wygląda bardziej jak:

             → Circuit 1
Guard A ─────→ Circuit 2
             → Circuit 3
             → Circuit 4

To ogranicza ekspozycję użytkownika na ogromną liczbę potencjalnie złośliwych Guardów.

Sybil przeciwko Guardom

Załóżmy hipotetyczną sytuację:

Legitimate Guards
████████████████████████

Attacker Guards
████

Atakujący chce zwiększyć prawdopodobieństwo:

User
 ↓
Attacker Guard

Nie musi zdobyć wszystkich Guardów.

Wystarczy zwiększenie udziału w przestrzeni wyboru.

To dlatego waga relayów i mechanizmy selekcji są tak ważne.

Dlaczego nie wystarczy uruchomić tysiąca VPS?

To częsty błąd w rozumowaniu.

Można wyobrazić sobie:

1000 VPS

ale jeżeli wszystkie:

• mają małą przepustowość,
• działają w tych samych zakresach adresów,
• pochodzą od jednego dostawcy,
• mają podobne fingerprinty,
• wykazują identyczne zachowanie,

mogą być znacznie łatwiejsze do wykrycia.

W praktyce analiza infrastruktury może obejmować korelację takich cech jak:

IP ranges
ASN
Geolocation
Uptime
Bandwidth
Software configuration
Timing
Behavior

Właśnie dlatego infrastrukturalny fingerprinting jest ważnym elementem obrony przed Sybil.

ASN może zdradzać wspólne pochodzenie

Wyobraźmy sobie:

Relay A → ASN X
Relay B → ASN X
Relay C → ASN X
Relay D → ASN X
Relay E → ASN X

Nie oznacza to automatycznie:

Same owner

ale jest sygnałem, który może być interesujący dla analizy.

Jeszcze ciekawsza sytuacja pojawia się, gdy wiele relayów ma:

same provider
same subnet patterns
same configuration
same timing behavior

Wtedy niezależność tych węzłów może być kwestionowana.

Geografia też ma znaczenie

Jeżeli kilkadziesiąt relayów deklaruje różne lokalizacje, ale infrastruktura wskazuje na wspólnego dostawcę lub podobne charakterystyki sieciowe, może pojawić się kolejny sygnał.

Nie można jednak po prostu powiedzieć:

„Dwa relay’e są w tym samym kraju, więc są jednym Sybilem”.

To byłoby zbyt daleko idące.

Analiza Sybil opiera się raczej na zestawie wielu cech.

Fingerprinting relayów

Można analizować:

• wersje oprogramowania,
• charakterystykę działania,
• dostępność,
• zmiany przepustowości,
• konfigurację,
• zachowanie w czasie.

Jeżeli wiele relayów zachowuje się niemal identycznie, może to być interesujący sygnał.

Warto jednak pamiętać:

podobieństwo nie jest dowodem wspólnej kontroli.

Wielu operatorów może korzystać z tych samych dostawców VPS, systemów i konfiguracji.

Sybil i czas uruchomienia relayów

Kolejny interesujący sygnał:

09:00 → Relay A
09:02 → Relay B
09:04 → Relay C
09:06 → Relay D
09:08 → Relay E

Jeżeli wiele relayów pojawia się w bardzo podobnym czasie, może to wzbudzić zainteresowanie systemów monitorujących.

Szczególnie jeśli jednocześnie mają podobne:

ASN
configuration
bandwidth
software
uptime

Wtedy pojawia się znacznie silniejszy sygnał.

Dlaczego detekcja Sybil jest trudna?

Bo normalna sieć również generuje podobieństwa.

Wyobraźmy sobie:

20 relayów
↓
ten sam VPS provider
↓
ten sam Linux
↓
ta sama wersja Tor

To może być:

jeden operator

albo:

20 niezależnych administratorów korzystających z tego samego dostawcy.

System detekcyjny musi więc minimalizować dwa błędy:

False Positive

czyli uznanie legalnych relayów za Sybil,

oraz:

False Negative

czyli przepuszczenie złośliwej infrastruktury.

Sybil to gra między atakującym i detektorem

Możemy potraktować to jak ciągły wyścig:

Attacker
   ↓
Creates relay infrastructure
   ↓
Changes fingerprints
   ↓
Changes providers
   ↓
Changes bandwidth
   ↓
Attempts to look independent

Po drugiej stronie:

Network
   ↓
Collects relay metadata
   ↓
Finds correlations
   ↓
Detects anomalies
   ↓
Limits influence

To oznacza, że Sybil nie jest pojedynczym wydarzeniem.

To ciągła gra operacyjna.

Dlaczego stabilność Guardów jest tak ważna?

Wróćmy do prawdopodobieństwa.

Jeżeli użytkownik często zmienia Guard:

P(attacker Guard)

może być rozpatrywane przy wielu kolejnych wyborach.

Jeżeli natomiast Guard pozostaje stabilniejszy:

P(attacker Guard)

nie jest losowane od nowa przy każdej aktywności.

To bardzo ważny mechanizm ograniczający skuteczność części ataków Sybil.

Ale Guard Persistence nie rozwiązuje wszystkiego

Jeżeli użytkownik już otrzymał złośliwego Guard’a, stabilność może mieć również drugą stronę.

Przeciwnik może potencjalnie obserwować aktywność tego użytkownika przez dłuższy okres.

Dlatego mamy klasyczny kompromis:

More rotation
    ↓
More exposure to different relays

Less rotation
    ↓
Less exposure
but
greater persistence of a compromised Guard

Bezpieczeństwo nie polega więc na maksymalizacji jednego parametru.

Sybil i Onion Services

Ataki infrastrukturalne są szczególnie interesujące również w przypadku usług .onion.

Połączenie z Onion Service nie wykorzystuje klasycznego modelu:

Client → Guard → Middle → Exit → Website

Występują dodatkowe elementy architektury, w tym rendezvous point.

Uproszczony model:

Client
  ↓
Tor
  ↓
Rendezvous Point
  ↑
Tor
  ↑
Onion Service

Netbe szczegółowo opisuje tę architekturę w Jak działa mechanizm Onion Services – usługi .onion od strony technicznej.

To pokazuje, że wpływanie na infrastrukturę Tor może mieć znaczenie nie tylko dla zwykłego dostępu do Internetu, ale również dla komunikacji pomiędzy użytkownikiem a ukrytą usługą.

Czy Sybil może złamać Onion Service?

Nie należy tego przedstawiać jako prostego:

Sybil → onion service deanonymized

To byłoby nieprawidłowe uproszczenie.

Anonimowość zależy od wielu elementów:

Tor architecture
+
Circuit selection
+
Guard selection
+
Service configuration
+
Application behavior
+
Traffic analysis
+
Operational security

Sama obecność złośliwych relayów nie oznacza automatycznie poznania prawdziwego IP serwera.

Sybil + błędy OPSEC

Najbardziej interesujące scenariusze często powstają wtedy, gdy atak infrastrukturalny łączy się z błędem użytkownika lub administratora.

Przykład:

Sybil infrastructure
        +
Traffic metadata
        +
Bad OPSEC
        ↓
Higher attribution probability

Dlatego Tor nie powinien być traktowany jako rozwiązanie wszystkich problemów anonimowości.

Netbe omawia ten aspekt w Zasadach bezpiecznego korzystania z sieci Tor – poradniku dla zaawansowanych użytkowników.

Sybil a Traffic Isolation

Kolejną warstwą obrony jest izolowanie różnych aktywności.

Jeżeli różne zadania użytkownika są odpowiednio rozdzielone:

Activity A → Circuit A
Activity B → Circuit B
Activity C → Circuit C

trudniej traktować całą aktywność jako jeden łatwy do skorelowania strumień.

Więcej na ten temat znajduje się w Jak działa separacja ruchu (Traffic Isolation) w sieciach anonimowych i VPN vs Tor.

Czy szyfrowanie rozwiązuje problem Sybil?

Nie.

Szyfrowanie chroni przede wszystkim:

CONTENT

Sybil dotyczy natomiast:

INFRASTRUCTURE
+
SELECTION
+
OBSERVATION

To zupełnie inna warstwa.

Możemy mieć bardzo dobre szyfrowanie:

AES / TLS / Onion Encryption

a jednocześnie problem:

Who controls which relays?

To jedna z najważniejszych rzeczy do zrozumienia w bezpieczeństwie sieci anonimowych.

Sybil nie musi odszyfrować danych

Zaawansowany przeciwnik może być zainteresowany przede wszystkim metadanymi.

Na przykład:

09:14:01 → traffic starts
09:14:03 → burst
09:14:07 → burst
09:14:12 → response

Jeżeli podobny wzorzec pojawi się po drugiej stronie infrastruktury, można próbować szukać korelacji.

Dlatego ukrywanie metadanych jest równie ważne jak szyfrowanie treści.

Machine Learning i Sybil

W przyszłości analiza Sybil może coraz częściej wykorzystywać modele statystyczne i machine learning.

Model może analizować jednocześnie:

ASN
IP ranges
Uptime
Bandwidth
Geography
Relay behavior
Software characteristics
Timing
Lifecycle

i próbować wykrywać grupy relayów zachowujące się podobnie.

Problem polega na tym, że złośliwy operator może próbować generować infrastrukturę wyglądającą bardziej naturalnie.

To prowadzi do klasycznego:

Detection
      ↕
Evasion

Czy duży przeciwnik może całkowicie kontrolować Tor?

Teoretycznie im większa część infrastruktury znajduje się pod kontrolą jednego podmiotu, tym większe są możliwości manipulowania prawdopodobieństwami wyboru.

Ale:

Control of some relays
        ≠
Control of Tor

Nawet bardzo duży operator musi jeszcze uwzględnić:

• zasady wyboru ścieżek,
• role relayów,
• Guard selection,
• ograniczenia dotyczące pozycji w obwodzie,
• czas działania infrastruktury,
• wykrywanie anomalii,
• możliwość uzyskania odpowiednich pozycji jednocześnie.

Dlatego pełna kontrola jest znacznie trudniejszym problemem niż samo zwiększenie udziału w sieci.

Najbardziej niebezpieczny jest przeciwnik globalny

Dla użytkownika szczególnie interesujący jest model globalnego przeciwnika.

Taki przeciwnik może mieć możliwość obserwowania dużych fragmentów Internetu:

ISP
 ↓
Internet backbone
 ↓
Data centers
 ↓
Tor infrastructure

W takim modelu nawet bez kontrolowania wszystkich relayów można próbować wykonywać szeroką korelację czasową.

Sybil może wtedy stać się jednym z elementów większego systemu obserwacji.

Sybil jako element większego łańcucha ataku

Najbardziej realistyczny zaawansowany model nie wygląda:

Create relay
      ↓
Deanonymize user

ale raczej:

Create many relay identities
            ↓
Gain network share
            ↓
Increase strategic placement probability
            ↓
Observe traffic
            ↓
Collect metadata
            ↓
Correlate observations
            ↓
Combine with external intelligence
            ↓
Potential attribution

To znacznie lepiej pokazuje rzeczywisty charakter zagrożenia.

Co użytkownik może zrobić?

Najważniejsze jest zrozumienie ograniczeń Tora.

Użytkownik powinien:

• korzystać z oficjalnego Tor Browser,
• nie modyfikować bez potrzeby jego konfiguracji,
• unikać logowania do kont związanych z prawdziwą tożsamością,
• nie otwierać pobranych plików poza bezpiecznym środowiskiem,
• stosować odpowiednią izolację aktywności,
• pamiętać o fingerprintingu,
• rozumieć ryzyko Traffic Analysis.

Szczegółowe zasady opisuje poradnik bezpiecznego korzystania z sieci Tor.

Najważniejszy wniosek: Tor nie musi być „złamany”

Atak Sybil pokazuje bardzo ważną rzecz.

Anonimowość może zostać osłabiona bez:

• złamania szyfrowania,
• znalezienia exploita w Tor Browser,
• przejęcia komputera użytkownika,
• odczytania treści komunikacji.

Wystarczy odpowiednio duży wpływ na infrastrukturę i możliwość obserwacji ruchu.

Dlatego bezpieczeństwo Tora należy analizować na kilku poziomach:

Cryptography
      ↓
Protocol
      ↓
Relay selection
      ↓
Infrastructure
      ↓
Traffic metadata
      ↓
User OPSEC

Atak Sybil dotyka przede wszystkim środkowej części tego łańcucha.

Podsumowanie

Atak Sybil w Torze nie polega po prostu na uruchomieniu dużej liczby serwerów.

Jego istota polega na stworzeniu wielu pozornie niezależnych uczestników kontrolowanych przez jednego przeciwnika, a następnie próbie uzyskania przez nich nieproporcjonalnego wpływu na wybór ścieżek.

Najważniejsze elementy tego problemu to:

1. liczba relayów nie jest równoznaczna z ich wpływem,
2. przepustowość i waga relayów mają ogromne znaczenie,
3. Guard jest strategicznie ważniejszy niż przypadkowy relay,
4. stabilność Guardów ogranicza część możliwości ataków Sybil,
5. jeden złośliwy relay nie oznacza automatycznej deanonymizacji,
6. największe ryzyko pojawia się przy połączeniu obserwacji wielu punktów,
7. Traffic Correlation może być ważniejszym zagrożeniem niż samo przejęcie relay’a,
8. infrastrukturalny fingerprinting pomaga wykrywać potencjalne grupy Sybil,
9. błędy OPSEC mogą znacząco zwiększyć skuteczność ataku,
10. Sybil jest przede wszystkim problemem probabilistycznym i infrastrukturalnym.

Najciekawsze jest to, że anonimowość Tora nie zależy wyłącznie od tego, czy dane są zaszyfrowane.

Zależy również od tego, kto uczestniczy w budowaniu ścieżki, jakie ma możliwości obserwacyjne i jak duży fragment infrastruktury znajduje się pod kontrolą jednego przeciwnika.

Dlatego właśnie ataki Sybil są jednym z najważniejszych tematów, gdy przechodzimy od podstawowego „jak działa Darknet” do rzeczywistej analizy bezpieczeństwa sieci anonimowych.

Powiązane materiały Netbe

• Jak działa obrona przed atakami Sybil w sieci Tor?
• Jak działa sieć Tor – anonimowość, routing cebulowy i zagrożenia
• Ryzyka wycieku tożsamości (deanonymization) w sieci Tor
• Monitoring ruchu w sieci Tor
• Jak działa ukrywanie metadanych w ruchu sieciowym
• Jak działa separacja ruchu w sieciach anonimowych
• Jak działa mechanizm Onion Services
• Zasady bezpiecznego korzystania z sieci Tor
• Tor i wirtualne maszyny

Polecane wpisy

Techniki Anti-Forensics – Jak Atakujący Ukrywają Ślady Po Włamaniu

🔐 Techniki Anti-Forensics – Jak Atakujący Ukrywają Ślady Po Włamaniu W erze zaawansowanych narzędzi analizy cyfrowej i monitorowania bezpieczeństwa cyberprzestępcy Czytaj dalej

Jak stworzyć silne hasło i je zapamiętać – poradnik krok po kroku

Jak stworzyć silne hasło i je zapamiętać – poradnik krok po kroku Bezpieczeństwo w sieci to dziś priorytet. Silne hasło Czytaj dalej