Przechwytywanie sesji TCP/IP na w pełni zaktualizowanym Windows7. Adam Zabrocki w akcji

25 stycznia 2021, 17:07 | W biegu | komentarzy 5
: oglądaj sekurakowe live-streamy o bezpieczeństwie IT.

Dla chcących przejść do źródłowego tekstu – link tutaj. A o co chodzi w całym temacie?

No więc zakładam że wiecie, że sesja TCP/IP zabezpieczona jest przed jej przejmowaniem za pomocą tzw. numerów sekwencyjnych (osobny dla serwera, osobny dla klienta). Jeśli np. podłączam się do serwera ftp, to w warstwie TCP moje połączenie definiowane jest przez kilka ciekawych parametrów:

  • adres IP źródłowy / docelowy
  • port źródłowy / docelowy

Jeśli teraz ktoś znałby mój adres źródłowy, port źródłowy oraz wiedział, że łączę się do danego serwera (czyli zna adres docelowy + port docelowy) mógłby wysłać sfałszowany (zespoofowany) pakiet tak żeby wykonać np. jakąś operację ftp w moim imieniu.

No nie do końca. Żeby nie było tak prosto, ktoś wymyślił generowane pseudolosowo numery sekwencyjne TCP (ustalane w momencie nawiązania połączenia TCP). Nie znasz numeru? Serwer nie przyjmie Twojego zespoofowanego pakietu.

No więc Adam pokazał jak można zdalnie zrealizować (dla połączenia jak powyżej):

  1. Namierzenie portu źródłowego (tutaj operacja opiera się o fakt, że Windows7 używa globalnego licznika dla IP_ID (IP ID to parametr pakietu IP). Oznacza to, że każdy wysłany pakiet IP przez klienta (Windows 7) zwiększa globalny IP_ID o jeden.

    Technika jest znana tutaj od dawna – tj. bada się IP ID klienta (wysyłając np. pinga), później wysyła się zespoofowany pakiet TCP/IP do serwera (z flagą SYN).

    Jeśli nie zgadłem port źródłowy serwer odpowie SYN-ACK (jak w nawiązaniu połączenia), który zostanie wysłany do klienta (Windows 7). Klient następnie wyśle RST (bo wcale nie otwierał połączenia). Ale tym samym zwiększy swoje IP ID (każde wysłanie pakietu zwiększa IP ID).

    Jeśli zgadłem port źródłowy, serwer odpowie ACK, a klient to zignoruje (brak zwiększenia IP ID).

    Monitoruję więc ponownie IP ID klienta i patrzę czy odpowieddnio się zwiększył się czy też nie.
  2. Namierzenie numerów sekwencyjnych. Tutaj ponownie udało się zaadaptować starą technikę (ale o dziwo działającą na Windows 7).

Całość działa w realnych przypadkach (PoC do pobrania tutaj), a czas przejęcia sesji to około 45 minut:

Czym to grozi? Problematyczne są nieszyfrowane połączenia (http/ftp/telnet(!)/…), w szczególności te działające w obrębie sieci lokalnych. Windows 7 nie ma już wsparcia, więc i nie ma łatki na opisany problem.

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. klecho

    Numery sekwecyjne nie powstały w celu zabezpieczenia sesji a możliwości retransmisji pakietów i składania strumienia, ogólnie poprawy niezawodności przesyłania danych i kiedyś były dość lub w pełni przewidywalne

    Odpowiedz
    • Najpewniej masz rację. Mała aktualizacja w tekście, choć nie zmienia sensu całego ataku.

      Odpowiedz
      • tt

        Przedmowca ma racje, to nie jest zabezpieczenie. Ale faktycznie zaczelo sie te numery traktowac jako element bezpieczenstwa do tego stopnia, ze niektore firewalle zaczely tym manipulowac (dla polepszenia security of course). Daje to czasem nieporzadany efekt, gdy np za duzo elementow zaczyna badac poprawnosc tych numerkow i kazdemu sie wydaje, ze lepiej zabezpiecza :-). Pierwsze co mi sie od razu pomyslalo, to tunel ipsec over gre przechodzacy na przyklad przez c.asa, ktora ma tendencje – a przynajmniej miala – do „poprawy i zabezpieczania” tcp/ip.

        Odpowiedz
  2. Od ktorej wersji?

    Niezle, niezle.

    Od ktorej wersji Windows jest ta dziura i w ktorej jest (ewentualnie) usunieta?

    Odpowiedz
  3. Andrzej

    Fajny artykuł ale nadal nie rozumiem o co w tym chodzi i czy to chodzi o przejecie sesji w sieci lokalnej czy mówimy o ataku na komputer ofiary z internetu?

    Odpowiedz

Odpowiedz na Od ktorej wersji?