WebSocket Attacks
Last updated
Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Połączenia WebSocket są nawiązywane poprzez początkowe HTTP handshake i są zaprojektowane jako długoterminowe, co pozwala na dwukierunkowe przesyłanie wiadomości w dowolnym momencie bez potrzeby systemu transakcyjnego. To sprawia, że WebSockety są szczególnie korzystne dla aplikacji wymagających niskiej latencji lub komunikacji inicjowanej przez serwer, takich jak strumienie danych finansowych na żywo.
Szczegółowe wyjaśnienie nawiązywania połączeń WebSocket można znaleźć tutaj. Podsumowując, połączenia WebSocket są zazwyczaj inicjowane za pomocą JavaScript po stronie klienta, jak pokazano poniżej:
Protokół wss oznacza połączenie WebSocket zabezpieczone TLS, podczas gdy ws wskazuje na połączenie niezabezpieczone.
Podczas nawiązywania połączenia wykonywane jest uzgadnianie między przeglądarką a serwerem za pomocą HTTP. Proces uzgadniania polega na tym, że przeglądarka wysyła żądanie, a serwer odpowiada, jak pokazano w następujących przykładach:
Przeglądarka wysyła żądanie uzgadniania:
Odpowiedź serwera na handshake:
Po nawiązaniu połączenia pozostaje ono otwarte do wymiany wiadomości w obu kierunkach.
Kluczowe punkty handshake WebSocket:
Nagłówki Connection i Upgrade sygnalizują rozpoczęcie handshake WebSocket.
Nagłówek Sec-WebSocket-Version wskazuje pożądaną wersję protokołu WebSocket, zazwyczaj 13.
W nagłówku Sec-WebSocket-Key wysyłana jest losowa wartość zakodowana w Base64, co zapewnia, że każdy handshake jest unikalny, co pomaga zapobiegać problemom z proxy pamięci podręcznej. Ta wartość nie służy do uwierzytelniania, ale do potwierdzenia, że odpowiedź nie jest generowana przez źle skonfigurowany serwer lub pamięć podręczną.
Nagłówek Sec-WebSocket-Accept w odpowiedzi serwera jest hashem Sec-WebSocket-Key, weryfikującym zamiar serwera do otwarcia połączenia WebSocket.
Te funkcje zapewniają, że proces handshake jest bezpieczny i niezawodny, torując drogę do efektywnej komunikacji w czasie rzeczywistym.
Możesz użyć websocat, aby nawiązać surowe połączenie z websocketem.
Lub aby utworzyć serwer websocat:
Jeśli odkryjesz, że klienci są połączeni z HTTP websocket z twojej bieżącej lokalnej sieci, możesz spróbować ARP Spoofing Attack, aby przeprowadzić atak MitM między klientem a serwerem. Gdy klient próbuje się połączyć, możesz wtedy użyć:
Możesz użyć narzędzia https://github.com/PalindromeLabs/STEWS do automatycznego odkrywania, identyfikacji i wyszukiwania znanych vulnerabilities w websockets.
Burp Suite obsługuje komunikację MitM websockets w bardzo podobny sposób, jak robi to dla zwykłej komunikacji HTTP.
Rozszerzenie socketsleuth Burp Suite pozwoli Ci lepiej zarządzać komunikacją Websocket w Burp, uzyskując historię, ustawiając reguły przechwytywania, używając reguł match and replace, korzystając z Intruder i AutoRepeater.
WSSiP: Skrót od "WebSocket/Socket.io Proxy", to narzędzie, napisane w Node.js, zapewnia interfejs użytkownika do przechwytywania, przechwytywania, wysyłania niestandardowych wiadomości i przeglądania wszystkich komunikacji WebSocket i Socket.IO między klientem a serwerem.
wsrepl to interaktywny websocket REPL zaprojektowany specjalnie do testów penetracyjnych. Zapewnia interfejs do obserwowania przychodzących wiadomości websocket i wysyłania nowych, z łatwym w użyciu frameworkiem do automatyzacji tej komunikacji.
https://websocketking.com/ to strona internetowa do komunikacji z innymi stronami za pomocą websockets.
https://hoppscotch.io/realtime/websocket wśród innych typów komunikacji/protokółów, zapewnia stronę do komunikacji z innymi stronami za pomocą websockets.
W Burp-Suite-Extender-Montoya-Course masz kod do uruchomienia strony internetowej używającej websockets, a w tym poście możesz znaleźć wyjaśnienie.
Cross-site WebSocket hijacking, znane również jako cross-origin WebSocket hijacking, jest identyfikowane jako specyficzny przypadek Cross-Site Request Forgery (CSRF) wpływający na handshake WebSocket. Ta luka występuje, gdy handshakes WebSocket uwierzytelniają się wyłącznie za pomocą HTTP cookies bez CSRF tokens lub podobnych środków bezpieczeństwa.
Napastnicy mogą to wykorzystać, hostując złośliwą stronę internetową, która inicjuje połączenie WebSocket między witrynami z podatną aplikacją. W konsekwencji to połączenie jest traktowane jako część sesji ofiary z aplikacją, wykorzystując brak ochrony CSRF w mechanizmie obsługi sesji.
Zauważ, że podczas nawiązywania połączenia websocket cookie jest wysyłane do serwera. Serwer może go używać do powiązania każdego konkretnego użytkownika z jego sesją websocket na podstawie wysłanego cookie.
Jeśli na przykład serwer websocket wysyła z powrotem historię rozmowy użytkownika, jeśli wysłana zostanie wiadomość z "READY", to prosty XSS nawiązujący połączenie (cookie zostanie wysłane automatycznie w celu autoryzacji użytkownika ofiary) wysyłając "READY" będzie w stanie odzyskać historię rozmowy.
W tym wpisie na blogu https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ atakujący zdołał wykonać dowolny Javascript w subdomenie domeny, w której odbywała się komunikacja przez web socket. Ponieważ była to subdomena, ciasteczko było wysyłane, a ponieważ Websocket nie sprawdzał poprawnie Origin, możliwe było komunikowanie się z nim i kradzież tokenów.
Skopiuj aplikację webową, którą chcesz naśladować (na przykład pliki .html) i wewnątrz skryptu, w którym odbywa się komunikacja przez websocket, dodaj ten kod:
Teraz pobierz plik wsHook.js z https://github.com/skepticfx/wshook i zapisz go w folderze z plikami webowymi.
Ekspozycja aplikacji webowej i zmuszenie użytkownika do połączenia się z nią pozwoli ci ukraść wysyłane i odbierane wiadomości za pomocą websocket:
Warunki wyścigu w WebSocketach również istnieją, sprawdź te informacje, aby dowiedzieć się więcej.
Ponieważ WebSockety są mechanizmem do wysyłania danych na stronę serwera i klienta, w zależności od tego, jak serwer i klient obsługują informacje, WebSockety mogą być używane do wykorzystywania kilku innych podatności, takich jak XSS, SQLi lub jakiejkolwiek innej powszechnej podatności webowej, wykorzystując dane wejściowe użytkownika z websocketu.
Ta podatność może pozwolić na obejście ograniczeń odwrotnych proxy, sprawiając, że uwierzą, że komunikacja websocketowa została nawiązana (nawet jeśli to nieprawda). Może to pozwolić atakującemu na dostęp do ukrytych punktów końcowych. Aby uzyskać więcej informacji, sprawdź następującą stronę:
Upgrade Header SmugglingUcz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
