WebSocket Attacks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
WebSocket з'єднання встановлюються через початковий HTTP рукопашний і призначені для тривалого використання, що дозволяє двостороннє повідомлення в будь-який час без необхідності в транзакційній системі. Це робить WebSockets особливо вигідними для додатків, які вимагають низької затримки або ініційованого сервером зв'язку, таких як потоки фінансових даних в реальному часі.
Детальне пояснення про встановлення WebSocket з'єднань можна знайти тут. Підсумовуючи, WebSocket з'єднання зазвичай ініціюються за допомогою JavaScript на стороні клієнта, як показано нижче:
Протокол wss
позначає з'єднання WebSocket, захищене TLS, тоді як ws
вказує на незахищене з'єднання.
Під час встановлення з'єднання виконується обмін повідомленнями між браузером і сервером через HTTP. Процес обміну повідомленнями включає в себе надсилання запиту браузером і відповідь сервера, як показано в наступних прикладах:
Браузер надсилає запит на обмін повідомленнями:
Відповідь на хендшейк сервера:
З'єднання залишається відкритим для обміну повідомленнями в обох напрямках після встановлення.
Ключові моменти рукостискання WebSocket:
Заголовки Connection
та Upgrade
сигналізують про ініціацію рукостискання WebSocket.
Заголовок Sec-WebSocket-Version
вказує на бажану версію протоколу WebSocket, зазвичай 13
.
У заголовку Sec-WebSocket-Key
надсилається випадкове значення, закодоване в Base64, що забезпечує унікальність кожного рукостискання, що допомагає запобігти проблемам з кешуючими проксі. Це значення не призначене для аутентифікації, а для підтвердження того, що відповідь не згенерована неправильно налаштованим сервером або кешем.
Заголовок Sec-WebSocket-Accept
у відповіді сервера є хешем Sec-WebSocket-Key
, що підтверджує намір сервера відкрити з'єднання WebSocket.
Ці функції забезпечують безпечний і надійний процес рукостискання, прокладаючи шлях для ефективної комунікації в реальному часі.
Ви можете використовувати websocat
для встановлення сирого з'єднання з вебсокетом.
Або для створення сервера websocat:
Якщо ви виявите, що клієнти підключені до HTTP websocket з вашої поточної локальної мережі, ви можете спробувати ARP Spoofing Attack, щоб виконати атаку MitM між клієнтом і сервером. Якщо клієнт намагається підключитися, ви можете використовувати:
Ви можете використовувати інструмент https://github.com/PalindromeLabs/STEWS для автоматичного виявлення, ідентифікації та пошуку відомих вразливостей у вебсокетах.
Burp Suite підтримує MitM вебсокетну комунікацію дуже схожим чином, як це робить для звичайної HTTP-комунікації.
Розширення socketsleuth для Burp Suite дозволить вам краще керувати вебсокетною комунікацією в Burp, отримуючи історію, встановлюючи правила перехоплення, використовуючи правила збігу та заміни, використовуючи Intruder та AutoRepeater.
WSSiP: Скорочення від "WebSocket/Socket.io Proxy", цей інструмент, написаний на Node.js, надає інтерфейс для захоплення, перехоплення, надсилання користувацьких повідомлень та перегляду всіх комунікацій WebSocket і Socket.IO між клієнтом і сервером.
wsrepl є інтерактивним вебсокетним REPL, спеціально розробленим для тестування на проникнення. Він надає інтерфейс для спостереження за вхідними вебсокетними повідомленнями та надсилання нових, з простим у використанні фреймворком для автоматизації цієї комунікації.
https://websocketking.com/ це веб для комунікації з іншими вебами за допомогою вебсокетів.
https://hoppscotch.io/realtime/websocket серед інших типів комунікацій/протоколів, надає веб для комунікації з іншими вебами за допомогою вебсокетів.
У Burp-Suite-Extender-Montoya-Course у вас є код для запуску вебу за допомогою вебсокетів, а в цьому пості ви можете знайти пояснення.
Перехоплення вебсокетів між сайтами, також відоме як перехоплення вебсокетів з різних джерел, визначається як специфічний випадок Cross-Site Request Forgery (CSRF), що впливає на вебсокетні з'єднання. Ця вразливість виникає, коли вебсокетні з'єднання аутентифікуються виключно через HTTP-куки без токенів CSRF або подібних заходів безпеки.
Зловмисники можуть скористатися цим, розмістивши шкідливу веб-сторінку, яка ініціює з'єднання вебсокетів між сайтами до вразливої програми. В результаті це з'єднання розглядається як частина сесії жертви з програмою, експлуатуючи відсутність захисту CSRF у механізмі обробки сесій.
Зверніть увагу, що при встановленні з'єднання вебсокет кука надсилається на сервер. Сервер може використовувати її для пов'язування кожного конкретного користувача з його вебсокетною сесією на основі надісланої куки.
Тоді, якщо, наприклад, вебсокетний сервер повертає історію розмови користувача, якщо надіслано повідомлення з "READY", тоді проста XSS, що встановлює з'єднання (кука буде надіслана автоматично для авторизації жертви) надсилаючи "READY" зможе отримати історію розмови.
В цьому блозі https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ зловмисник зміг виконати довільний Javascript в піддомені домену, де відбувалася комунікація через веб-сокети. Оскільки це був піддомен, cookie були надіслані, і оскільки Websocket не перевіряв Origin належним чином, було можливим спілкуватися з ним і викрасти токени з нього.
Скопіюйте веб-додаток, який ви хочете наслідувати (файли .html, наприклад), і всередині скрипта, де відбувається комунікація через веб-сокети, додайте цей код:
Тепер завантажте файл wsHook.js
з https://github.com/skepticfx/wshook і збережіть його в папці з веб-файлами.
Відкриваючи веб-додаток і змушуючи користувача підключитися до нього, ви зможете вкрасти надіслані та отримані повідомлення через websocket:
Умови гонки в WebSockets також існують, перевірте цю інформацію, щоб дізнатися більше.
Оскільки Web Sockets є механізмом для відправки даних на серверну та клієнтську сторони, залежно від того, як сервер і клієнт обробляють інформацію, Web Sockets можуть бути використані для експлуатації кількох інших вразливостей, таких як XSS, SQLi або будь-яка інша поширена веб-вразливість, використовуючи введення користувача з вебсокета.
Ця вразливість може дозволити вам обійти обмеження зворотних проксі, змушуючи їх вірити, що вебсокетна комунікація була встановлена (навіть якщо це не так). Це може дозволити зловмиснику отримати доступ до прихованих кінцевих точок. Для отримання додаткової інформації перевірте наступну сторінку:
Upgrade Header SmugglingLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)