Na stronie CERT-u opublikowany został raport, który choć dość ciężko się czyta, dostarcza informacji, które jednoznacznie kojarzą się z projektem Pirate Pay (nie Pirate Bay, choć zbieżność nazw zapewne nieprzypadkowa). W tym wpisie postaram się nieco przybliżyć i projekt i raport.
O co chodzi?
Jak zwykle – chodzi o pieniądze :) I w tym przypadku (wbrew powiedzeniu) wiadomo to od początku.
Pirate Pay jest projektem, którego celem (zarobkowym?) jest zablokowanie sieci torrent. Powstał dość przypadkowo przy okazji prac dotyczących zarządzania ruchem sieciowym. Projekt, w który zainwestował sam Microsoft (100 tys. dolarów) chwali się zablokowaniem dużej ilości pobrań treści do których prawa posiada Walt Disney Studios i Sony Pictures. Usługa taka jednak do tanich nie należy – od 12 tys. do 50 tys. dolarów za jedną akcję blokowania. Nie zostało ujawnione, w jaki sposób to wszystko działa. Niektórzy podejrzewają, że technologia udaje innych klientów sieci, ale wysyła nieprawidłowe lub uszkodzone dane blokując dystrybucję danej treści.
Raport CERT-u
W raporcie możemy wyczytać kilka ciekawych informacji na temat anomalii zaobserwowanych w ruchu sieciowym.
CERT informuje, że ostatnio zauważył wzmożony ruch w sieci torrent, realizowany po protokole uTP. Część tego ruchu wykonywała fałszywe alarmy w systemie ARAKIS (w skrócie – projekt którego celem jest wykrywanie nowych zagrożeń w sieci).
Przeanalizowane zostały dwie próbki danych – z 1 kwietnia tego roku i analogicznego dnia rok wcześniej.:
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)
Przez anomalie należy rozumieć ruch posiadający takie właściwości:
- pakiet uTP z flagą DATA
- pakiet BT (wewnątrz uTP) zawiera hash 057a315b89b54e53e2ee583dd5cd9ef60648805e
- ten sam pakiet BT zawiera identyfikator peer-a: 0000000000000000000000000000000000000000
Jeśli do zestawienia włączyć pakiety SYN (poprzedzające DATA), a następnie pakiety ICMP informujące o zamkniętym gnieździe, anomalie wyglądają odpowiednio tak:
anomalia: 787724 (~37% całego ruchu i ~82% ruchu UDP)
anomalia: 1575448 (~73% całego ruchu)
Ustalono, że:
- Źródłowe adresy IP pakietów mogą być podrobione, ale równie dobrze mogą być użyte sieci typu TOR (choć wyrywkowe testy nie potwierdzają tego), botnety, VPN czy inne sieci służące anonimowości w sieci. Trzecia możliwość to użycie części prawdziwych i części podrobionych adresów IP. Geograficznie tak prezentują się źródłowe adresy IP:
- Źródłowe i docelowe porty są zazwyczaj wysokie (najczęściej był to port 45571)
- Źródło pakietów nie trzyma się standardów protokołu, np. po pakiecie uTP SYN ignorowane są pakiety ICMP o zamkniętym gnieździe i wysyłany pakiet uTP DATA, który normalnie nie powinien być wysłany. To wskazywało by na podrabianie adresów IP, ponieważ wtedy nie jest (prawie) możliwe odebranie komunikacji zwrotnej.
- Źródło pakietów ignoruje brak pakietu STATE, który zawiera numer potwierdzenia konieczny do nawiązania połączenia i zamiast tego numeru wstawia 0 (zero)
- Pole timestamp difference pakietów zazwyczaj zawierało wartość 0, pole windows size zawierało zazwyczaj wartość 0×380000, a timestamp microseconds było wielokrotnością 10000 (dziesięć tys.)
- Źródłem pakietów nie był standardowy klient sieci torrent, a jakaś inna aplikacja lub skrypt
Prawdopodobne są 3 przyczyny występowania takich pakietów:
- zatruwanie sieci torrent
- mapowanie (tworzenie mapy) sieci torrent
- jakiegoś rodzaju atak na określone systemy
Ponad to:
- za zatruwaniem czy mapowaniem sieci przemawiają pobrane dane z publicznych trackerów (mała ilość pobierających)
- mógł być to jakiś eksperyment lub błąd – dotyczy nieprzestrzegania protokołu uTP
- mógł być to ruch maskujący – dotyczy występowania prawdziwych i podrobionych adresów IP
- mógł być echem ataków na inne sieci – podobieństwo do DDoS w przypadku TCP
Podczas całej analizy, poza wyżej podanym hashem, trafiono jeszcze na inne. Wszystkie dotyczyły dwóch rosyjskich filmów. 1 kwietnia (dzień, z którego dane oddano analizie), 99,99% pakietów uTP zawierało ten sam hash (wspominany już wyżej).
Dla porównania pokazano w postaci graficznej ilość seedów i peerów dla wspomnianych rosyjskich filmów, których hashe zostały znalezione, oraz dla innych, wybranych i popularnych, których hashe nie zostały znalezione podczas badania:
Wyraźnie widać, ile seedów miały popularne produkcje, a ile te, których hashe były zawarte w modyfikowanych pakietach.
Konkluzja
CERT nie udało się jednoznacznie ustalić czym był ten dziwny ruch w dużych ilościach. Ja podczas wczytywania się w raport już od pierwszych chwil miałem skojarzenia z Pirate Pay, który jest rosyjskim projektem, podobnie jak blokowane filmy – też pochodzenia rosyjskiego. Podobieństw jest wiele, dedukcja dopowiada resztę. Jeśli faktycznie obie sprawy są powiązane, a jestem przekonany (no może prawie pewien z dużą dozą prawdopodobieństwa) że tak, może to potwierdzać skuteczność Pirate Pay. I to o wiele większą skuteczność niż inne narzędzia dostępne na rynku (np. od Peer Media). Co więcej, jeśli różne wytwórnie zaczną korzystać z tego rozwiązania, ceny mogą spaść a to spowoduje blokowanie coraz to większej ilości treści.
CERT jednak się zastanawiał, czy cała ta sytuacja nie może być podciągnięta pod Kodeks Karny i to nie tylko Polski. Jestem bardzo ciekawy co by się stało, gdyby do sądu trafił wniosek o podejrzeniu popełnienia przestępstwa. Być może wykorzystywanie opisywanego narzędzia przez Pirate Pay mogło by okazać się niezgodne z prawem, czy nawet niebezpieczne. Ruch taki można też porównać do SPAM-u – jest wiele podobieństw (prawdziwy lub podrobiony adres nadawcy, niezamówiona treść, potencjalnie niebezpieczne dane…).
Jestem bardzo ciekawy rozwoju sytuacji. Zobaczymy do czego to doprowadzi :)
Źródło: CERT
