TCP/IP packet injection na przykładzie Gadu-Gadu


Wiele wody w Wiśle upłynęło od ostatniego wpisu, a powodów było wiele :
sesje, represje, recesje ,obsesje, sprawy zawodowe, o których zapewne wspomnę w najbliższym czasie, itd.. ale przejdźmy do meritum…

”””
Marek, Jarek i blond włosa Wiktoria w jednym mieszkali domq. Marek i Jarek na górze, a Wiktoria na dole. Całe zimowe dnie spędzali na oglądaniu filmów, graniu w StarCraft;a po LAN’e oraz rozmowach przez GG. Pewnego dnia kiedy zły Marek zaczął grać na cheatach zbulwersowany Jarek po wypiciu herbatki z prądem postanowił się zemścić. Nic innego nie przychodziło mu do głowy jak zaprzestanie przesyłania wiadomości GG w standardowy sposób(przy udziale serwerów Gadu-Gadu) i nie zwlekając ani chwili dłużej Jarek naklikawszy injector pakietów tcp/ip w pythonie zaczął siać zło i zniszczenie. Pierwsza ofiarą Jarka stał się oczywiście Marek, a dokładniej relacja Marka z Wiktoria albowiem Jarek wykorzystując swój injector przesłał pakiet TCP zawierający strukturę GG_RECV_MSG wskazującą na to iż nadawcą jest Marek do Wiktorii, o treści, o której nawet strach wspominać.
”””

Czy ta historia może mieć odzwierciedlenie w rzeczywistości?
Jak najbardziej!
Zacytuje jeszcze fragment artykułu który będę chciał Wam przedstawić:
„Osoba wysyłająca sfałszowany pakiet wcale nie musi być zalogowany do sieci GG,
ani posiadać tam konta !!!.Jakie wynikają z tego następstwa:
Napastnik może wysłać sfałszowany pakiet zawierający nr GG dowolnego adresata o
dowolnej treści bez znajomości hasła dostępowego do tego konta!!!.”

Jako, że artykuł który przygotowałem jest dość obszerny to zamiast prezentować go w formie postu na blogu postanowiłem, że udostępnię go do pobrania w formie PDF.
Do paczki zawierającej art. dorzuciłem krótki film video prezentujący atak tcp/ip packet injection na którym widać w jaki sposób można przesłać wiadomość o dowolnej treści z dowolnego nr do użytkownika Gadu-Gadu. Dołączyłem także dla zainteresowanych ruch sieciowy zarejestrowany podczas takiego ataku.
Życze miłego czytania i oglądania:
PPM Click -> Art+Video+traffic
(UWAGA!!!:Paczka jest archiwem zip takze po sciagnieciu wystarczy zmienic rozszerzenie i rozpakowac)
Oczywiście czekam na feedback ;).

This entry was posted in Analiza, Security and tagged , , , , , . Bookmark the permalink.

13 Responses to TCP/IP packet injection na przykładzie Gadu-Gadu

  1. mentor says:

    witam
    udostepnisz binarke albo zrodlo tego injectora w pythonie

  2. mentor says:

    Witam
    domyslam sie pobudek przez ktore nie publikujesz tego kodu w stylu OFB
    A moje zainteresowanie wynika wlasnie przez to stwierdzenie “(doslownie) parunastu linijek kodu” moja nieudana pruba w oparciu na raw soxy to 100 lini kodu i efekt mizerny
    w kazdym badz razie pomysl ciekawy i przygladnol bym sie temu z bliska ..
    pozdrawiam

  3. default_name says:

    Ciężko coś doradzić w tej kwestii. Z jednej strony jeśli ktoś zasługuje na ten kod, to jest też raczej w stanie sam sobie takie cos sklepać. Ale może też być ktoś taki jak mentor, który mimo to nie może sobie poradzić z problemem.
    Mogłbyś udostępnić kod po “przeróbkach”. Tzn tak, że trzeba odpowiednio te przeróbki usunąć, żeby skrypt zadziałał. Może to być dobra ochrona przed sk.
    Tyle ode mnie. Pzdr ;>

  4. grafzero says:

    zainteresowanym proponuje trochę poklikać w google’u; na początek polecam dokumentację do libgadu – swietny reference

  5. mentor says:

    witam
    widze ze temat troche ucichl … a szkoda

  6. NS says:

    Czego sie obawiasz?
    Moze i bylbym wstanie cos takiego napisac, ale jakos nie mam czasu, a twoj art jest bardzo ciekawy (nie ma co ukrywac), i chetnie bym poprostu przeczytal te kilka linijek. Bez zadnego celu w tym. Sam uzywam jabbera.
    Pozdro

  7. cOndemned says:

    Dobre arcidło, a odnosnie publikacji kodu injectora – ja to widzę prosto – kto wie czym jest RFC, i programuje w jakims języku poradzi sobie, reszta prosi bo chcą isc na łatwiznę… Lenie śmierdzące, hah…

  8. Icewall says:

    Myślę, że już dość sporo czasu upłynęło od rozpoczęcia tej dyskusji i pora na podsumowanie.
    Rozmawiałem o tej sprawie z paroma osobami na live’e i tak ja pewna część osób wypowiadających się tutaj stwierdziła, że większego sensu nie ma w publikacji tego skrawka kodu, ponieważ wszystkie potrzebne informacje do stworzenia takie narzędzia zostały podane w artykule i każdy badacz zainteresowany przeprowadzeniem własnego research’u jest w stanie naklikać swój tool.
    Niemniej jednak dziękuje wszystkie za wzięcie udziału w dyskusji i zainteresowanie tematem;).
    @mentor
    Proponuje na początku użyć czegoś „wygodniejszego” niż RAW socket’y, bo tam nie trudno o drobną pomyłkę, która zburzy całą logikę twojej aplikacji, a po drugie to rozwiązanie dostarcza Ci wydajności której ty tak naprawdę w tym narzędziu nie potrzebujesz.
    @default_name
    Kod po przeróbkach w tym wypadku musiał by wyglądać raczej jak pseudokod, bo tu nawet nie ma co „psuć”.
    @grafzero
    Tak jest;),ale myśle, że nawet nie trzeba iść w tą stronę, bo tak jak pisałem w art.’e wszystkie niezbędne informacje potrzebne do przeprowadzenia tego typu ataku są w nim zawarte.
    @NS
    „twoj art jest bardzo ciekawy (nie ma co ukrywac)”
    Dzięki za dobre słowa;).
    „Moze i bylbym wstanie cos takiego napisac, ale jakos nie mam czasu”
    myślę, że takiego rodzaju „podatność” szybko nie zniknie także jeszcze znajdziesz czas żeby to protestować na własną rękę.
    @cOndemned
    „Dobre arcidło”
    Thx man;).
    “ja to widzę prosto – kto wie czym jest RFC, i programuje w jakims języku poradzi sobie”
    Otóż to, także ja ze swojej strony polecam python + scapy czy C/CPP + winpcap.
    Jeszcze raz wielkie dzięki za komentarze, temat „gotowego kodu” uważam za zamknięty ,ale oczywiście nadal z chęcią odpowiem na wasze pytania/wątpliwości odnośnie artu.
    Pozdrawiam

  9. default says:

    Witam. Nie wiem czy jeszcze ktos tutaj zagladnie czy tez nie.
    Zaczalem sie interesowac ostatnio w/w tematem i chcialem zrobic wlasnego injectora. Pytanie do Icewall’a: mozesz mi tylko powiedziec czy obecnie Twoj skrypt dziala ? poniewaz zauwazylem, ze komunikacja w ramach tego protokolu odbywa sie inaczej niz bylo to opisane. tzw. host A i B prowadzac rozmowe komunikuja sie z dwoma roznymi serwerami GG, przez co numery sekwencyjne i potwierdzen TCP sa rozne i nie mozliwym jest ich odgadniecie na podstawie odebranej wiadomosci od nadawcy. Tzn numer ACK, ktory otrzymujemy od serwera nie jest numerem SEQ, ktory powinnismy wyslac w naszym pakiecie. Zatem czy wykonanie takiego injectora dalej jest mozliwe ?

  10. Icewall says:

    Witam,
    “mozesz mi tylko powiedziec czy obecnie Twoj skrypt dziala ?”
    oczywiście nadal działa 🙂 i będzie działał tak dlugo, aż do momentu kiedy protokół GG będzie posiadał odpowiedni poziom szyfrowania komunikacji.
    ” poniewaz zauwazylem, ze komunikacja w ramach tego protokolu odbywa sie inaczej niz bylo to opisane. tzw. host A i B prowadzac rozmowe komunikuja sie z dwoma roznymi serwerami GG…
    to nic nowego, tak było od zawsze. Nie wspominałem o tym, bo to tylo zaciemniło by schematy, a na dobra sprawę nie jest nam to do niczego potrzebne.
    “.. przez co numery sekwencyjne i potwierdzen TCP sa rozne i nie mozliwym jest ich odgadniecie na podstawie odebranej wiadomosci od nadawcy. “ zupełnie nie tak. Nas nie interesują wszystkie sesje :
    Attacker Serwer GG1
    Victim Serwer GG2
    ponieważ sesja Attacker SerwerGG1 może nawet nie istnieć, jest ona nam do nieczego nie potrzebna. Na potrzeby filmiku przesłałem wiadomość do ofiary po to tylko żeby przyspieszyć (i tu kluczowe słowo)ODCZYTANIE informacji o sesji Victim SerwerGG2, równie dobrze moglibyśmy poczekać, aż ofiara otrzyma odpowiedź na ping od serwer,otrzyma dowolną wiadomość or whatever.
    Proponuje jeszcze raz rzucić okiem do artykułu i sprawdzić topologię sieciową na której zaprezentowałem atak. Po co w takim wypadku chcesz co kolwiek zgadywać? Wszystkie informacji możesz uzysakć sniffując traffic. Schemat przedstawiony w artykule nazwijmy “MITM by topology”:D, jeżeli chcesz to testować u siebie w lanie to robisz MITM’a i sytuacja jest taka sama ,niczego nie zgadujesz,wszystko masz na tacy. Tak jak wspominałem w ART’e, można to zrobić zdalnie i wtedy dopiero musiszmy “zgadywać” informacje o sesji tcp/ip Victim SerwerGG, ale to już inna historia.

  11. default says:

    Dzieki za odpowiedz. Jednak mam jeszcze pewne watpliwosci. Po kilku probach na kilku stacjach roboczych nie pojawiaja sie pakiety nazwane w artykule jako unknow. odebranie wiadomosci wyglada tak, ze przychodzi pakiet z wiadomoscia, stacja wysyla ACK i tyle. A co wazniejsze zauwazylem, ze gdy otrzymuje jedna wiadomosc, a za chwile druga wiadomosc, numery ID nie sa o 1 wieksze, ale np o 5, 10, 3. Oczywiscie wartosci sa zblizone do siebie ale nie sa o 1 wieksze. I tutaj moje pytanie, skad to sie bierze bo nie moge tego wyjasnic w zaden sposob. Skad nasza stacja wie jakiego numeru ID ma sie spodziewac ?
    Dzieki za pomoc, btw jezeli bedzie to dla Ciebie wygodniejsze prosze podaj mi maila, bo nie wiem czy zyczysz sobie zeby zasmiecal bloga.
    Pozdrawiam

Leave a Reply

Your email address will not be published. Required fields are marked *