Skocz do zawartości

Zmień kolory
Primary: Sky Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Secondary: Sky Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Squares Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to Uploaduj.com - Forum Zarabianie przez Internet - Zarabianie na Uploadzie / Uploadingu
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account

Nawet 10 PLN za pobranie jednego pliku w Polsce? Sprawdź narzędzia w Lead.Network

Sieć afiliacyjna System płatności online


Możesz nas wesprzeć!


Zdjęcie

Anomalia w sieci μTorrent


  • Zaloguj się, aby dodać odpowiedź
1 odpowiedź w tym temacie

#1
Karczu

Karczu

    Administrator

  • Administrator
  • 5471 postów
[align=center]

Anomalia w sieci μTorrent[/align]


1. Wstęp

1. Wstęp

W ostatnich tygodniach obserwowalismy znaczny wzrost aktywności w sieci uTorrent (opartej na protokole uTP). Niektóre z rejestrowanych pakietów wywoływały fałszywe alarmy systemu ARAKIS wysokiego poziomu informujące o możliwej infekcji chronionych węzłów. Co więcej, z danych dotyczących ruchu wynikało między innymi, że występowała komunikacja pomiędzy dwiema sondami systemu ARAKIS, co było bardzo mało prawdopodobne. Oznacza to, że adresy zawarte w pakietach IP składających się na ten ruch były błędne (lub podrobione). W niniejszym raporcie zebrane zostały wyniki badania tej aktwyności.


Za metodyką wykonywania testów bezpieczeństwa OSSTMM 3:
Anomalia

nieidentyfikowalny lub nieznany element, którego działania nie mogą zostać wyjaśnione na gruncie standardowych operacji. Zazwyczaj pochodzenie (przyczyna) i przeznaczenie (cel) tego elementu nie mogą być wytłumaczone [przy wykorzystaniu dostępnej o nim wiedzy - tłum.]. Anomalia może być wczesną oznaką problemu bezpieczeństwa. Ponieważ “nieznane” (unknowns) to elementy, które nie mogą być w odpowiedni sposób kontrolowane (weryfikowane), w trakcie audytu właściwym jest zarejestrowanie każdej napotkanej anomalii.

[...]

Przykłady anomalii:

W kanale PHYSSEC (PHSYSEC oznacza “fizyczny” kanał interakcji z chronionymi zasobami) anomalią mogą być martwe ptaki znalezione na dachu budynku w pobliżu sprzętu komunikacyjnego.

W kanale telekomunikacyjnym COMSEC anomalią może być zgłoszenie modemu z numeru, który nie posiada modemu.

W kanale SPECSEC (kanał spektrum elektromagnetycznego) za anomalię można uznać lokalny sygnał, którego źródła nie można ustalić, ale który nie wpływa w zauważalny sposób na chronione zasoby.


2. Co to jest uTP?



Protokół uTP wykorzystuje do transportu protokół UDP i uzupełnia go o funkcje protokołów połączeniowych. Obudowuje on (lub: enkapsuluje) zwykłe pakiety BitTorrent. Oznacza to, że zwykły ruch BitTorrentowy znajduje się wewnątrz kanału komunikacyjnego utworzonego w warstwie uTP. Kanał ten posiada niektóre z właściwości kanału TCP, takie, jak na przykład zorientowanie na połączenie i jego kontrolę. Zwykłe pakiety BitTorrentowe korzystają z cech protokołu TCP, takich, jak na przykład potwierdzanie odbioru danych, regulowanie wielkości okna etc., natomiast w tym przypadku własności te zapewnia uTP. Po co więc kolejny protokół, skoro można korzystać z TCP? Otóż, stos UDP/uTP/BT ma za zadanie m.in. zwiększenie kontroli nad obciążeniem. Prędkość ściągania danych z Internetu przez klienta BitTorrent nie podlega takim ograniczeniom, jak na przykład transmisja z serwerów FTP i HTTP (czyli ograniczeniu pasma po stronie serwera). Dlatego przy pobieraniu dużych ilości danych może zdarzyć się, że w sieci klienta wystąpi obciążenie wysycające większość lub całe dostępne pasmo, uniemożliwiając jej poprawne funkcjonowanie. Jednym z rozwiązań jest zastosowanie ograniczeń transferu na poziomie aplikacji klienta. Nie są to bardzo rozbudowane funkcje, poza tym wielu użytkowników po prostu o nich nie pamięta. uTP natomiast pozwala na dynamiczne regulowanie przepustowości w sieci BT na poziomie protokołu i dodatkowo posiada inne możliwości, jak wspomaganie transferu u klientów o wąskim paśmie czy dzielenie linii ADSL z przeglądarką interetową.


3. Nasze obserwacje uTP (statystyki)



Z posiadanych przez nas danych wynika, że aktywność sieci uTP, a co za tym idzie – również BT – znacznie wzrosła w ostatnich miesiącach w porównaniu na przykład do roku 2011. Wybraliśmy do analizy próbkę ruchu z 1. kwietnia roku 2011 i tego samego dnia roku 2012 w tej samej lokalizacji. Oto zestawienie statystycznych parametrów analizowanego ruchu:

2011.04.01:
-----------
pakietów:       103546 (8.7MB)
UDP:              183 (~0.2% ruchu)
anomalia         0

2012.04.01:
-----------
pakietów:       2142296, (201MB)
UDP:             957047 (~45% ruchu)
anomalia:       393862 (~18% całego ruchu i ~41% ruchu UDP)


Przy tworzeniu powyższego zestawienia przyjęto następujące założenia:

Analizowany ruch (pakiety składające się na anomalię) to ruch złożony z pakietów o charakterystyce podobnej do pakietów, które wywołały fałszywe alarmy w systemie ARAKIS. Wyznaczona charakterystyka jest następująca:

Pakiet wywołujący anomalię jest pakietem uTP z ustawioną flagą DATA.
Pakiet ten zawiera pakiet BT, który zawiera następujące informacje:
Hash protokołu BitTorrent: 057a315b89b54e53e2ee583dd5cd9ef60648805e
Peer protokołu BitTorrent: 0000000000000000000000000000000000000000

Można trochę osłabić te założenia i przyjąć, że na ruch-anomalię składają się także pakiety uTP SYN, które poprzedzają pakiety DATA, o takim samym gnieździe źródłowym i docelowym, jak pakiety DATA. Wtedy podsumowanie z 1. kwietnia 2012 roku wygląda następująco:

anomalia:           787724 (~37% całego ruchu i ~82% ruchu UDP)

Sonda na każdy pakiet tego typu odpowiadała pakietem ICMP informującym o zamkniętym gnieździe UDP. Jeśli dodać te pakiety do ruchu składającego się na anomalię, statystyka staje się już bardzo wymowna:

anomalia:           1575448 (~73% całego ruchu)

Można łatwo zauważyć, że udział ruchu uTP jest nieproporcjonalnie duży w stosunku do reszty protokołów, jeśli porównać go do próbki z 2011 roku, którą wybraliśmy do porównania. Jest to także ponad 20-krotny przyrost całości ruchu. Podobne symptomy anomalii obserwowaliśmy w różnych lokalizacjach (alarmy wysokiego poziomu, statystyczne odchylenia ruchu sieciowego).


4. Analiza pakietów



Poniżej przedstawiamy poglądową ilustrację porównawczą klasycznego stosu BitTorrent i stosu uTP. Stopniowo przeanalizujemy informacje zawarte w poszczególnych warstwach.

Dołączona grafika

4.1. Warstwa IP/UDP
Zacznijmy od warstwy IP/UDP. Poniżej znajduje się zestawienie źródłowych i docelowych adresów i portów analizowanych transmisji (ruch przychodzący uTP).

Hosty źródłowe (top 20):
ilość adres
  -----+-------------
    613 xxx.xxx.192.40
    463 xxx.xxx.67.237
    463 xxx.xxx.17.54
    459 xxx.xxx.115.38
    373 xxx.xxx.40.233
    367 xxx.xxx.158.104
    362 xxx.xxx.183.36
    360 xxx.xxx.177.102
    360 xxx.xxx.102.55
    347 xxx.xxx.221.41
    347 xxx.xxx.176.105
    344 xxx.xxx.122.46
    342 xxx.xxx.208.110
    338 xxx.xxx.233.116
    335 xxx.xxx.231.118
    330 xxx.xxx.180.245
    328 xxx.xxx.68.104
    318 xxx.xxx.132.178
    315 xxx.xxx.142.110
    310 xxx.xxx.64.228

Hosty docelowe:
ilość adres
 ------+--------------
 393850 xxx.xxx.xxx.34
      4 xxx.xxx.xxx.27

Porty źródłowe (top 20):
ilość port
 ------+-----
 133014 45571
  79677 62100
  39658 60598
  35461 55025
  30830 47013
  29605 45770
  11555 36610
   9697 57902
   5996 20995
   4989 32692
   3436 21512
   3084 46957
   2715 17632
   2334 28328
    575 1119
    228 1926
     10 6974
      4 9425
      4 9405
      4 9159

Porty docelowe (top 20):
ilość port
 ------+-----
 133007 45571
  79672 62100
  39657 60598
  35461 55025
  30829 47013
  29604 45770
  11554 36610
   9697 57902
   5996 20995
   4989 32692
   3436 21512
   3084 46957
   2715 17632
   2334 28328
    575 1119
    228 1926
      4 9425
      4 9405
      4 9159
      4 8786

Adresy źródłowe posiadają dość równomierny rozkład, jeśli pominąć wyróżniające się adresy znajdujące się na szczycie listy. Adresy te pochodzą z różnych systemów AS i różnych lokalizacji geograficznych (w tym: z Rosji, Kanady, Chin, Australii, USA). Rozkład tych adresów posiada cechy sumy rozkładu równomiernego i pewnego rozkładu nierównomiernego. Może to oznaczać, że część tych adresów jest wykorzystywana w równomierny sposób (np. po kolei) lub są losowane (tj. podrabiane).

Dołączona grafika

Zróżnicowany rozkład geograficzny adresów źródłowych skłania do przyjęcia raczej drugiego wytłumaczenia. Niewykluczone, że wykorzystywana jest również jakiegoś rodzaju rozproszona sieć anonimizująca. Wyrywkowo wybrane węzły nie przeszły testów na węzły sieci TOR, jednak pozostają jeszcze inne możliwości: inne rozproszone sieci anonimizujące, usługi VPN, botnety.

Dołączona grafika

Jeśli chodzi o źródłowe i docelowe porty transmisji, można zauważyć, że preferowane są wysokie porty. Podobne porty są wybierane jako źródło i cel transmisji.

4.2. Warstwa uTP
Pakiet uTP (szczegółowe omówienie na stronie ze specyfikacją):
0       4       8               16              24              32
+-------+-------+---------------+---------------+---------------+
| ver     | type   | extension        | connection_id                         |
+-------+-------+---------------+---------------+---------------+
| timestamp_microseconds                                                        |
+---------------+---------------+---------------+---------------+
| timestamp_difference_microseconds                                         |
+---------------+---------------+---------------+---------------+
| wnd_size                                                                             |
+---------------+---------------+---------------+---------------+
| seq_nr                                   | ack_nr                                  |
+---------------+---------------+---------------+---------------+

Ruch przychodzący składający się na anomalię można przedstawić jako serie przepływów z różnych źródeł składających się z dwóch pakietów uTP: uTP SYN i uTP DATA. Te pakiety składają się na opisywany w protokole uTP mechanizm nawiązywania połączenia (handshake), jednak pewne ich cechy są niezgodne z protokołem. Oto one:

4.2.1. Źródło transmisji ignoruje pakiety ICMP informujące o zamkniętym porcie.
W specyfikacji protokołu uTP nie jest opisana poprawna reakcja na wiadomości ICMP. Jednak klient uTP próbujący nawiązać połączenie powinien poprawnie zinterpretować tą wiadomość i uznać nawiązanie połączenia jako niemożliwe.

4.2.2. Źródło transmisji ignoruje brak pakietu uTP STATE i wysyła pakiet DATA.
Bez pakietu STATE nie posiada ono poprawnego numeru potwierdzenia, bez którego nawiązanie połączenia jest niemożliwe. Zamiast poprawnego numeru potwierdzenia umieszcza on w tym miejscu 0, co stanowi odstępstwo od protokołu. W trakcie badań wysyłaliśmy pakiety o podobnej konstrukcji do klienta uTorrent i odpowiadał on pakietem FIN i kończył konwersację. Przypuszczamy, że jest to efekt nieprzestrzegania protokołu.

4.2.3. Inne, interesujące lub niezwykłe cechy pakietów uTP:
Większość pakietów w polu timestamp difference ma wartość 0:

timestamp difference microseconds (top 10):
ilość wartość
 ------+---------
 392850 0000 0000
     10 6f63 6f6c
      4 fd7a 9ff1
      4 fb26 16d3
      4 fa5b c083
      4 f9e9 d86d
      4 f946 4a14
      4 f937 8df9
      4 f83c a31a
      4 f69a ecdf

Większość pakietów w polu window size ma wartość 0×380000 (3670016 w systemie dziesiętnym)

window size (top 10):
ilość wartość
 ------+---------
 393017 0038 0000
    738 0004 0000
     50 0000 0000
     46 0003 2000
      4 0003 9999
      4 0003 3333
      4 0000 1302
      3 0001 937c
      3 0000 0e32
      2 0002 1dfd

Wartości pól timestamp microseconds w dwóch pakietach w tych samych przepływach różni się o wielokrotność 10000 mikrosekund.

Część tych właściwości może wynikać z konkretnych implementacji protokołu, ale inne sprawiają, że stosowanie tego protokołu traci sens. Jest bardzo mało prawdopodobne, że przy tak wysokiej rozdzielczości tak schematyczne wartości w polu timestamp microseconds były zgodne z rzeczywistością. Jeśli te wartości są sfałszowane, protokół traci swoje możliwości kontroli konsumpcji pasma i jego stosowanie w tym celu nie ma sensu.

4.3. Warstwa BitTorrent
W enkapsulowanych pakietach BT znajduje się hash: 057a315b89b54e53e2ee583dd5cd9ef60648805e. Ten hash dotyczy informacji o plikach wideo zawierających film “Avgust. Vosmogo”. Jest to rosyjski film akcji, który swoją premierę miał 21. lutego 2012 roku. Przy analizowaniu ruchu z innych lokalizacji zarejestrowaliśmy podobne pakiety (w stosie UDP/uTP/BT) zawierające hashe dotyczące informacji o innych plikach zawierających wspomniany film oraz plikach zawierających inny rosyjski film: “Shpion” (więcej o znaczeniu pola hash: http://wiki.theory.o...uest_Parameters ).

Poniżej przedstawiamy interesujące korelacje czasowe pomiędzy publikacją torrentów, a transmisjami zawierającymi odpowiadające im hashe:

hash – data publikacji torrenta – data zarejestrowanych transmisji

c11ba392ef3dd57942112641ce8f1d9b96f0ddd5 – 26.02.2012 – 17.03.2012
057a315b89b54e53e2ee583dd5cd9ef60648805e – 17.03.2012 – 01.04.2012

W badanym ruchu z 1. kwietnia 2012 roku 99.99% pakietow uTP DATA zawierało hash 057a315b89b54e53e2ee583dd5cd9ef60648805e.

Omawiane pakiety zawierały również identyfikatory peerów BT (więcej o znaczeniu tego pola: http://wiki.theory.o...ication#peer_id ).

peer IDs (top 10):
ilość wartość
 ------+-------------------------------------------------
 329755 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    399 2d54 5232 3432 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -TR2420-xxxxxxxxxxxx
    214 2d54 5232 3530 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -TR2500-xxxxxxxxxxxx
    213 2d54 5232 3432 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -TR2420-xxxxxxxxxxxx
    100 2d55 5432 3231 302d xxxx xxxx xxxx xxxx xxxx xxxx   // 2�T2210-xxxxxxxxxxxx
     97 2d55 5431 3737 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -UT1770-xxxxxxxxxxxx
     95 2d54 5231 3933 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -TR1930-xxxxxxxxxxxx
     93 2d54 5231 3933 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -TR1930-xxxxxxxxxxxx
     91 2d55 5433 3132 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -UT3120-xxxxxxxxxxxx
     90 2d4d 4732 3125 302d xxxx xxxx xxxx xxxx xxxx xxxx   // -MG21%0-xxxxxxxxxxxx

Jak widać, większość pakietów zawierała w tym polu ciąg zer.

Oto informacje dotyczące tych torrentów uzyskane od popularnych trackerów torrentowych:

tracker – seeders – peers

Dołączona grafika
- 057a315b89b54e53e2ee583dd5cd9ef60648805e – Avgust. Vosmogo

https://torrentproject.com

http://xxxxxxxxxxxx:80/announce – 17 – 0
http://xxxxxxxxxxxx/announce – 16 – 0
http://xxxxxxxxxxxx:6969/announce – 11 – 0
http://xxxxxxxxxxxx/announce – 12 – 0
http://xxxxxxxxxxxx/announce – 9 – 0
http://xxxxxxxxxxxx/announce – 4 – 1

http://torrentz.eu

http://xxxxxxxxxxxx:2710/announce – 172 – 9
udp://xxxxxxxxxxxx:80/announce – 17 – 0
udp://xxxxxxxxxxxx:80/announce – 10 – 1 hour
http://xxxxxxxxxxxx/announce.php – 3 – 0
udp://xxxxxxxxxxxx:80/announce – 3 – 0
http://xxxxxxxxxxxx/announce.php – 2 – 0

http://bitsnoop.com

http://xxxxxxxxxxxx/announce.php – 3 – 0
http://xxxxxxxxxxxx/announce.php – 0 – 1
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx:3310/announce – 0 – 1
http://xxxxxxxxxxxx:6969/announce – 0 – 0
http://xxxxxxxxxxxx/announce.php – 2 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 15 – 0
udp://xxxxxxxxxxxx:80/announce – 13 – 0


Dołączona grafika
- c11ba392ef3dd57942112641ce8f1d9b96f0ddd5 – Avgust. Vosmogo

http://torrentz.eu

udp://xxxxxxxxxxxx:80/announce – 62 – 0

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 22 – 0
http://xxxxxxxxxxxx/announce – 26 – 0
http://xxxxxxxxxxxx:6969/announce – 27 – 0
http://xxxxxxxxxxxx:80/announce – 43 – 0
http://xxxxxxxxxxxx/announce – 42 – 0
udp://xxxxxxxxxxxx/announce – 50 – 1

Można zauważyć małą liczbę peerów. Dla porównania przedstawiamy informacje o innych torrentach, bardzo popularnych (dot. serialu Lost) i mniej popularnych (Naruto, Nocznoj Dozor)


Dołączona grafika
- ab53cb0d665b34fcdf1939b271660b48297b5a74 – Lost

http://torrentz.eu

http://xxxxxxxxxxxx:6969/announce – 167 – 932
udp://xxxxxxxxxxxx:80/announce – 157 – 763
udp://xxxxxxxxxxxx:80/announce – 144 – 779
http://xxxxxxxxxxxx:8000/announce – 19 – 188
http://xxxxxxxxxxxx:8080/announce – 16 – 176
http://xxxxxxxxxxxx/announce – 16 – 194
http://xxxxxxxxxxxx/announce – 8 – 23
http://xxxxxxxxxxxx:3310/announce – 6 – 91
http://xxxxxxxxxxxx:6969/announce – 4 – 38
http://xxxxxxxxxxxx/announce.php – 1 – 0
http://xxxxxxxxxxxx/announce.php – 1 – 1
udp://xxxxxxxxxxxx:80/announce – 1 – 11
http://xxxxxxxxxxxx:6969/announce – 0 – 1
http://xxxxxxxxxxxx:9090/announce – 0 – 17
http://xxxxxxxxxxxx:6969/announce – 0 – 32
http://xxxxxxxxxxxx/announce – 0 – 1
http://xxxxxxxxxxxx/announce – 0 – 24

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 139 – 829
http://xxxxxxxxxxxx/announce – 142 – 830
http://xxxxxxxxxxxx:6969/announce – 173 – 948
http://xxxxxxxxxxxx:80/announce – 189 – 1012
http://xxxxxxxxxxxx/announce – 192 – 1016
udp://xxxxxxxxxxxx/announce – 182 – 982


Dołączona grafika
- 799db5ad3c746823a8df170bb1a717835c1dccc8 – Naruto

http://torrentz.eu

http://xxxxxxxxxxxx:3310/announce – 169 – 16
http://xxxxxxxxxxxx:6969/announce – 75 – 12
http://xxxxxxxxxxxx:2710/announce – 71 – 11
http://xxxxxxxxxxxx:8000/announce – 68 – 11
http://xxxxxxxxxxxx:8080/announce – 57 – 10
http://xxxxxxxxxxxx:6969/announce – 23 – 5
http://xxxxxxxxxxxx/announce – 6 – 0
http://xxxxxxxxxxxx/announce – 6 – 2
http://xxxxxxxxxxxx:6969/announce – 3 – 5
udp://xxxxxxxxxxxx:80/announce – 2 – 0
http://xxxxxxxxxxxx:6969/announce – 2 – 2

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 64 – 8
http://xxxxxxxxxxxx/announce – 53 – 4
http://xxxxxxxxxxxx:6969/announce – 64 – 5
http://xxxxxxxxxxxx:80/announce – 57 – 4
http://xxxxxxxxxxxx/announce – 57 – 4
udp://xxxxxxxxxxxx/announce – 60 – 5


Dołączona grafika
- db839a0773d32a8def122f5e930b2ccf4a21ead2 – Nocznoj Dozor

http://torrentz.eu

http://xxxxxxxxxxxx:3310/announce – 27 – 7
http://xxxxxxxxxxxx:6969/announce – 20 – 3
udp://xxxxxxxxxxxx:80/announce – 13 – 2
udp://xxxxxxxxxxxx:80/announce – 1 – 0

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 18 – 6
http://xxxxxxxxxxxx/announce – 14 – 7
http://xxxxxxxxxxxx:6969/announce – 13 – 4
http://xxxxxxxxxxxx:80/announce – 15 – 3
http://xxxxxxxxxxxx/announce – 13 – 3
udp://xxxxxxxxxxxx/announce – 17 – 3

Statystyki dot. badanych torrentów posiadają w większości wielu tzw. seederów i bardzo mało (najczęściej – 0) peerów. Jest to raczej niezwykły rozkład, w większości przypadków proporcje, jeśli nie są zupełnie odwrotne, to nie są aż tak wyraźne.


5. Hipotezy



W wyniku badania ruchu składającego się na anomalie występujące w naszych honeynetach nie udało się jednoznacznie ustalić jego przyczyn i skutków. Oto kilka zebranych hipotez dot. tego ruchu:

5.1 Źródła anomalii

5.1.1. Adresy źródłowe są podrobione.
Taką możliwość potwierdza równomierny charakter jednego ze składników rozkładu adresów oraz – przede wszystkim – adresy źródłowe, które należą do naszych honeynetów, w których żadne węzły nie inicjują transmisji.

5.1.2. Adresy źródłowe są prawdziwe.
W trakcie dokładniejszego badania odnaleźliśmy połączeniową sesję TCP z pakietami BT częściowo odpowiadającym charakterystyce (posiadają taki sam hash). Nawiązanie sesji TCP za pomocą podrobionych adresów źródłowych IP jest możliwe, ale bardzo trudne i praktycznie niemożliwe w sieciach WAN, dlatego można przypuszczać, że adres źródłowy tej transmisji był prawdziwy. Jest również bardzo mało prawdopodobne (głównie ze względu na korelację czasową), że wspomniana sesja była niezwiązana z anomalią. Zawierała podobny pakiet BT (ten sam hash), jednak zawierała też niezerową wartość peera. Niewyluczone, że pod adresem tym funkcjonował zwykły klient uTP lub BT.

5.1.3. Pula adresów źródłowych zawiera zarówno adresy prawdziwe, jak i podrobione.
Najbardziej prawdopodobna możliwość.

5.1.4. Porty źródłowe i docelowe to standardowe porty dla konwersacji uTP.
Tej kwestii nie zbadaliśmy jeszcze dokładnie. Z obserwacji poczynionych w trakcie badań z klientem uTorrent wynika, że ten klient domyślnie oczekuje na połączenia na porcie 12144. Może on zostać zmieniony przez użytkownika lub wylosowany. Porty transmisji mogły zostać wyznaczone na podstawie obserwacji publicznych trackerów.

5.1.5. Źródłem transmisji nie jest zwykły klient uTP, tylko inny program lub skrypt służący innemu celowi niż wymiana danych.
Wskazują na to cechy pakietów uTP – okrągłe wartości timestampów, nieprzestrzeganie protokołu uTP, ignorowanie wiadomości ICMP. Wybieranie adresów docelowych z honeynetów systemu ARAKIS przemawia za tą hipotezą.

5.2 Efekty anomalii

5.2.1. Transmisje służą zatruwaniu sieci uTP/BT
Z danych zebranych z publicznych trackerów wynika, że stosunek seederów do peerów dzielących się plikami o hashu 057a315b89b54e53e2ee583dd5cd9ef60648805e i innych hashach dot. filmu “Avgust. Vosmogo” jest niespotykany i może być wynikiem zatruwania elementów sieci uTP/BT (np. przez dystrybuowanie fałszywych danych dot. peerów – ciągów zer).

5.2.2. Transmisje służą mapowaniu sieci uTP/BT
Możliwe, że transmisje służą do wyznaczenia mapy sieci węzłów sieci uTP/BT. Automat mapujący klasyfikowałby badany węzeł jako klienta uTP na podstawie odpowiedzi:
Poprawna odpowiedź uTP – węzeł jest klientem uTP
Zła odpowiedź uTP – węzeł nie jest klientem uTP

Przeciwko tej hipotezie jednak świadczą następujące fakty:
Pomimo odpowiedzi ICMP Port unreachable źródło wysyła kolejny pakiet, chociaż klasyfikacji można dokonać na podstawie tej odpowiedzi.
Część pakietów posiada sfałszowany adres źródłowy, co praktycznie uniemożliwia automatowi odebranie odpowiedzi i dokonanie klasyfikacji.

5.2.3. Transmisje stanowią atak na systemy teleinformatyczne
Możliwe, że wysyłane pakiety wprowadzają niektóre aplikacje w nieprzewidziany przez ich autora stan – są exploitami. Z pobieżnej analizy publicznie dostępnych informacji dot. podatności klienta uTorrent nie wynika, że ta hipoteza jest prawdziwa, jednak posiadamy za mało wiedzy na temat innych klientów oraz nieopublikowanych luk, żeby stwierdzić to z pewnością. Możliwe, że niektóre cechy pakietów uTP (np. zerowa wartość numeru potwierdzenia) lub BT (zera w polu peer id) mogą wprowadzić niektóre aplikacje w nieprzewidziany stan.

Anomalia poprzez swój charakter (duża część ruchu z całego dnia) stanowi wyraźne zakłócenie pracy systemu teleinformatycznego, czego dobrym dowodem jest generowanie dużej ilości fałszywych alarmów wysokiego poziomu. W kontekście polskiego prawa, europejskiej konwencji o cyberprzestępczości i kodeksów amerykańskich (oraz pewnie wielu innych źródeł prawa w różnych krajach) można dyskutować, czy tworzenie tego ruchu jest zgodne z prawem.

Kodeks karny, rozdział XXXIII, Art. 269a.:
Kto, nie będąc do tego uprawnionym, przez transmisję, zniszczenie, usunięcie, uszkodzenie, utrudnienie dostępu lub zmianę danych informatycznych, w istotnym stopniu zakłóca pracę systemu komputerowego lub sieci teleinformatycznej,podlega karze pozbawienia wolności od 3 miesięcy do lat 5.

Convention on Cybercrime, Chapter 2, Article 5:
Each Party shall adopt such legislative and other measures as may be necessary to establish as criminal offences under its domestic law, when committed intentionally, the serious hindering without right of the functioning of a computer system by inputting, transmitting, damaging, deleting, deteriorating, altering or suppressing computer data.

[...]

Article 7:
Each Party shall adopt such legislative and other measures as may be necessary to establish as criminal offences under its domestic law, when committed intentionally and without right, the input, alteration, deletion, or suppression of computer data, resulting in inauthentic data with the intent that it be considered or acted upon for legal purposes as if it were authentic, regardless whether or not the data is directly readable and intelligible. A Party may require an intent to defraud, or similar dishonest intent, before criminal liability attaches.

5.2.4. Obserwowany przez nas ruch przynajmniej częściowo jest echem
Możliwe, że część zarejestrowanych przez nas pakietów jest echem zdarzeń (incydentów), które wystąpiły w innych sieciach.

5.3. Znaczenie anomalii

5.3.1. Zatruwanie sieci / mapowanie
Za tą tezą przemawiają dane pobrane z publicznych trakerów. Bez wnikania w szczegóły reakcji klientów torrentowych można stwierdzić, że w trackerach rejestruje się mało peerów pobierających dyskutowane zasoby. Możliwe, że jest to wynik funkcjonowania mechanizmów, których nie możemy na razie dokładnie opisać, ale które wywołują rownież opisywaną anomalię. Można bez problemu wskazać przynajmniej jedną grupę potencjalnych autorów i beneficjentów zatruwania sieci uTP: koncerny multimedialne lub ich podwykonawcy. Prowadzenie przez te instytucje tego typu kampanii nie byłoby precedensem. Niewykluczone też, że generowany ruch ma służyć mapowaniu sieci BitTorrent i zbieraniu informacji, które zostaną wykorzystane w innych projektach.

5.3.2. Błędna implementacja / eksperyment
Nieprzestrzeganie protokołu uTP może być wynikiem błędnej implementacji protokołu uTP w mało popularnym lub niedojrzałym kliencie BitTorrentowym. Niewykluczone też, że omawiana anomalia jest wynikiem jakiegoś sieciowego eksperymentu.

5.3.3. Ruch maskujący
Jeśli uznać, że ruch składający się na anomalię zawiera mieszankę prawdziwych i fałszywych źródeł, można wysunąć przypuszczenie, że część tego ruchu posiada dobrze określone przyczyny i skutki, natomiast część (większość) stanowi ruch maskujący. Ruch zawierający poprawne numery sekwencji i adresy (niepowodujący zerwania sesji), pomimo, że w mniejszej ilości, mógłby okazać się efektywny przy zatruwaniu lub mapowaniu sieci uTP.

5.3.4. Echo ataków na inne sieci
Możliwe, że część obserwowanego przez nas w honeynecie ruchu stanowi echo ataku prowadzonego w innych sieciach. Części ruchu, które czynią tą możliwość bardziej prawdopodobną to m.in.: pakiety z flagami uTP STATE (odpowiednik pakietów TCP SYN/ACK przy echach ataków DDoS) oraz transmisje połączeniowe z identyfikatorami peerów, które wyglądają na poprawne.


[size=large]

6. Podsumowanie



Po dotychczasowej analizie opisywanego ruchu nie udało się ustalić jednoznacznie jego źródła ani przeznaczenia. Dlatego w kontekście metodyki prowadzenia testów bezpieczeństwa OSSTMM, oraz uznaniu chronionych systemem ARAKIS sieci jako chronione zasoby, nadal stanowi ona anomalię. Jednak w przeciwieństwie do anomalii powstającech samoistnie (tj. bez udziału człowieka), jak na przykład (w kanale data network COMSEC) widmowe ramki w sieciach Ethernet:

Za Cisco CCNA:
Fluke Networks przyjęło termin “widmowa ramka” na ekreślenie energii (szumu) wykrytego w medium które posiada cechy ramki, ale brakuje mu poprawnego pola SFD.

Rejestrowanie pakiety są na tyle skomplikowane, że można z dużym przypuszczeniem stwierdzić, że zostały zaprojektowane. Wątpliwą kwestią jest jedynie, czy ich postać i ilość jest wynikiem celowego działania (np. zatruwanie sieci), czy też błędem w oprogramowaniu.

W punkcie 5. przedstawiliśy sformułowane przez nas hipotezy dotyczące anomalii.

Być może dokładniejsze badania pozwoliły by zrozumieć naturę opisywanego ruchu i usunąć go z kategorii anomalii.


Glosariusz:
μTP – (również: uTP) protokół transportowy wykorzystywany do przenoszenia pakietów protokołu BitTorrent
μTorrent – (również: uTorrent) klient sieci BitTorrent obsługujący protokół uTP
BitTorrent – (również: BT) rozproszona sieć P2P, także protokół zaprojektowany w celu dzielenia się plikami
ARAKIS – system analizy i agregacji incydentów sieciowych stworzony i obsługiwany przez NASK
[b]OSSTMM
– (ang. Open Source Security Testing Methodology Manual) podręcznik metodyki przeprowadzania testów bezpieczeństwa
[b]ICMP
– internetowy protokół komunikatów kontrolnych
[b]TCP
– połączeniowy protokół umożliwiający komunikację pomiędzy aplikacjami sieciowymi
[b]IP – protokół sieciowy służący do przesyłania danych pomiędzy odległymi węzłami
[b]UDP – bezpołączeniowy protokół umożliwiający komunikację pomiędzy aplikacjami sieciowymi


Źródło: http://www.cert.pl/news/5365

[i]
  • 0

Interesują Cię płatności mobilne, przykładowo przyjmowanie wpłat za pośrednictwem SMS Premium bądź Direct Billing? Sprawdź ofertę HotPay.pl

 

Masz stronę internetową, bazę mailingową, fanpage na facebooku lub inne źródło dobrego ruchu? Sieć afiliacyjna Lead.Network dostarczy Ci najlepsze Programy partnerskie do zarobienia na Twoim zapleczu!


#2
ulung

ulung

    Rozkręca sie

  • Tutor
  • 487 postów

Anomalia w sieci uTorrent efektem działań antypiratów?

[size=large]Anomalia w sieci uTorrent efektem działań antypiratów?

Znaczny wzrost aktywności w sieci uTorrent, mający charakter anomalii, zaobserwowali eksperci z CERT Polska. Ich zdaniem może być to efekt działań niezgodnych z prawem i zastanawiające jest to, że anomalia pojawia się krótko po doniesieniach na temat systemu Pirate Pay, który w tajemniczy sposób ma blokować pobrania filmów z BitTorrenta.

Pamiętacie może temat Pirate Pay? To tajemnicze antypirackie narzędzie, rozwijane m.in. przy wsparciu Microsoftu. Jego twórcy mówią jedynie, że w jakiś magiczny sposób powstrzymuje ono nielegalne pobrania filmów z BitTorrenta. Eksperci sugerują jednak, że ten magiczny sposób może być niezgodnym z prawem atakiem DoS, a poza tym zablokowanie nawet wszystkich filmów na BitTorrencie nie zmusi nikogo do płacenia za filmy, zatem nazwa Pirate Pay jest trochę nie na miejscu.

Wiemy, że trwają prace nad ulepszeniem Pirate Pay, a tymczasem CERT Polska (zespół powołany do reagowania na zdarzenia naruszające bezpieczeństwo internetu) odnotował wystąpienie ciekawej anomalii w sieci uTorrent. Z danych zebranych przez ekspertów wynika, że aktywność sieci uTP znacznie wzrosła w ostatnich miesiącach w porównaniu na przykład do roku 2011. Da się przy tym zauważyć, że udział ruchu uTP jest nieproporcjonalnie duży w stosunku do reszty protokołów.

- Anomalia poprzez swój charakter (duża część ruchu z całego dnia) stanowi wyraźne zakłócenie pracy systemu teleinformatycznego, czego dobrym dowodem jest generowanie dużej ilości fałszywych alarmów wysokiego poziomu. W kontekście polskiego prawa, europejskiej konwencji o cyberprzestępczości i kodeksów amerykańskich (oraz pewnie wielu innych źródeł prawa w różnych krajach) można dyskutować, czy tworzenie tego ruchu jest zgodne z prawem (...) Bez wnikania w szczegóły reakcji klientów torrentowych można stwierdzić, że w trackerach rejestruje się mało peerów pobierających dyskutowane zasoby. Możliwe, że jest to wynik funkcjonowania mechanizmów, których nie możemy na razie dokładnie opisać, ale które wywołują również opisywaną anomalię. Można bez problemu wskazać przynajmniej jedną grupę potencjalnych autorów i beneficjentów zatruwania sieci uTP: koncerny multimedialne lub ich podwykonawcy. Prowadzenie przez te instytucje tego typu kampanii nie byłoby precedensem. Niewykluczone też, że generowany ruch ma służyć mapowaniu sieci BitTorrent i zbieraniu informacji, które zostaną wykorzystane w innych projektach - czytamy na blogu CERT Polska (zob. Anomalia w sieci μTorrent).

Podkreślamy, że to domniemania. CERT nie ogłosił, że wykryto działających nielegalnie antypiratów. Potwierdzono natomiast, że w sieci uTorrent dzieje się coś dziwnego, może to być efekt działań nieprawnych i nie byłoby dziwne, gdyby okazało się, iż jest to działanie przemysłu praw autorskich lub innych związanych z nim podmiotów.

CERT w swoim blogowym wpisie wspomina o ruchu dotyczącym rosyjskiego filmu akcji Avgust. Vosmogo. Rozwiązanie Pirate Pay pochodzi z Rosji, zatem niewykluczone, że testują je podmioty z tego rynku. Może również być tak, że ataki nie mają nic wspólnego z Pirate Pay, ale mimo wszystko mamy do czynienia z nielegalnym działaniem jakiegoś pirackiego podmiotu. Możliwe nawet, że temu podmiotowi jest na rękę zwracanie uwagi akurat na Pirate Pay.

W tej sytuacji staje się jasne, że Pirate Pay powinno lepiej wyjaśnić, jak działają jego cudowne-acz-tajemnicze technologie. Jeśli powstaje firma rzekomo wpływająca na ruch BitTorrent i obserwowane są tego rodzaju anomalie, to nie dziwmy się, że podejrzenia padają na Pirate Pay.


Źródło: http://di.com.pl/new...ntypiratow.html
  • 0
Kazdy problem jest trudny do momentu, kiedy staje sie prosty ;)




Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych

Potrzebna Ci naprawdę dobra sieć afiliacyjna do monetyzowania ruchu bądź pozyskiwania klientów? Na Lead.Network znajdziesz tylko najlepsze programy partnerskie z sieci!
A może chciałbyś uruchomić płatności sms premium na swojej stronie internetowej? Do obsługi płatności sms premium rate, jedynym słusznym wyborem jest HotPay.pl!
Jeżeli poszukujesz wiedzy na temat zarabiania przez internet, odwiedź forum internetowe o tematyce pracy w domu pod adresem Zarabiam.com.