NAT to nie firewall: nowa technika omijania zapór sieciowych
Chciałoby się się rzec "administratorzy go nienawidzą, znalazł jeden prosty sposób, by bezpośrednio komunikować się z komputerami zza NAT-u", ale metoda oszukiwania zapór, którą opisał niedawno Samy Kamkar, wcale nie jest taka prosta. Technika, o której mowa, polega na wykorzystaniu przeglądarki internetowej, protokołu WebRTC, usługi ALG oraz nieuniknionych zależności czasowych do ustalenia prywatnego adresu IP oraz ustanowienia komunikacji z usługą w LAN-ie.
W jaki sposób komputer z sieci WAN może rozmawiać z "niewyNAT-owaną" usługą uruchomioną na komputerze w sieci WAN? Intuicja oraz "wiedza powszechna" podpowiadają, że to niemożliwe: routery podłączone do internetu dokonują translacji adresów dzięki której cała sieć lokalna jest widoczna w WAN-ie jako jeden komputer. Połączenia wychodzące działają dlatego, że router przekierowuje komunikację, której odbiorcą jest "sieć" do konkretnego komputera. Połączenia przychodzące nie działają, ponieważ de facto próbują nawiązać połączenie z portem routera, a nie docelowego komputera. Powstaje dzięki temu, przy okazji, "bieda-zapora": różnice adresacji i brak bezpośredniej trasy chronią komputery w LAN-ie przed nieupoważnionym dostępem.
NAT Slipstreaming
Kamkar przestawił wielokrokową metodę obejścia owej architektury. Proces zaczyna się od wyświetlenia przez ofiarę strony internetowej ze "złośliwym" kodem JavaScript. Zadaniem tej strony jest zidentyfikowanie prywatnego adresu IP komputera ofiary. Należy zaznaczyć, że znajomość samego takiego adresu nie ma samo w sobie szczególnej wartości. Dla przykładu, mój obecny adres to 10.0.0.103/20. Cóż z tego, skoro w każdej podsieci oznacza on coś innego?
O adres IP można... poprosić (odpowiedzi udzieli implementacja WebRTC w Chromium) lub można go wywęszyć: żądając załadowania zasobów wołanych z najpopularniejszych, prywatnych adresów IP. W praktyce polega to na dodaniu akcji "onerror" do obiektu img.
Fragmentacja TCP
Po ustaleniu prywatnego adresu, serwer atakującego i aplikacja strony internetowej załadowanej u ofiary dokonują wymiany bardzo dużych pakietów TCP i UDP wypełnionych ściółką (używam tego terminu, bo lubię być posądzany o korzystanie z translatorów). Duże pakiety wymuszają fragmentację, ta z kolei pozwala poznać szczegóły konfiguracji stosu TCP/IP u ofiary: dzięki niej da się określić np. MTU.
Wadliwe żądanie SIP
Następnie, aplikacja na stronie generuje samodzielnie składany pakiet inicjalizujący sesję SIP. To jest najciekawszy element układanki. Przeglądarki internetowe celowo blokują ruch na popularne porty usługowe, celem ochrony przed węszeniem w sieci. Nie blokują go jednak na port 5060, czyli port komunikacji SIP dla VoIP. Aplikacja w przeglądarce wysyła więc żądanie SIP do serwera atakującego na port 5060.
Ale jak? Przeglądarka jest przecież ograniczona w kwestii tego, jakie pakiety może wysyłać. Nie da się jej nieskończenie programować i dowolnie pisać po socketach w dowolną stronę (a przynajmniej nie bez poważnych ograniczeń). Dlatego "żądanie SIP" nie jest żadnym żądaniem SIP: to zwykła komunikacja HTTP POST, bo tak rozmawiają przeglądarki. Ale dzięki temu, że atakujący poznał sieciowe MTU i rozmiary pakietów, żądanie przybiera rozmiar wymuszający fragmentację. Dokonuje się ona w ściśle określonym miejscu pakietu.