Upgrade Header Smuggling
Група Try Hard Security
Перехоплення H2C
HTTP2 через текст (H2C)
H2C, або http2 через текст, відхиляється від норми тимчасових HTTP-з'єднань, оновлюючи стандартне HTTP з'єднання на постійне. Це оновлене з'єднання використовує бінарний протокол http2 для подальшого спілкування, на відміну від одноразового характеру звичайного HTTP через текст.
Суть проблеми перехоплення виникає при використанні зворотнього проксі-сервера. Зазвичай зворотній проксі-сервер обробляє та пересилає HTTP-запити на бекенд, повертаючи відповідь бекенду після цього. Однак, коли заголовок Connection: Upgrade присутній у HTTP-запиті (зазвичай бачиться з підключеннями websocket), зворотній проксі-сервер підтримує постійне з'єднання між клієнтом та сервером, сприяючи постійному обміну, необхідному для деяких протоколів. Для з'єднань H2C дотримання RFC передбачає наявність трьох конкретних заголовків:
Уразливість виникає тоді, коли після оновлення з'єднання обернений проксі припиняє керувати окремими запитами, вважаючи, що його завдання маршрутизації завершено після встановлення з'єднання. Використання H2C Smuggling дозволяє обійти правила оберненого проксі, застосовані під час обробки запитів, такі як маршрутизація на основі шляху, аутентифікація та обробка WAF, за умови успішного ініціювання з'єднання H2C.
Уразливі Проксі
Уразливість залежить від обробки оберненим проксі заголовків Upgrade та іноді Connection. Наступні проксі вбудовано пересилають ці заголовки під час проксі-переходу, тим самим автоматично увімкнюючи H2C smuggling:
HAProxy
Traefik
Nuster
Навпаки, ці служби не вбудовано пересилають обидва заголовки під час проксі-переходу. Однак вони можуть бути налаштовані небезпечно, дозволяючи фільтроване пересилання заголовків Upgrade та Connection:
AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server
Використання
Важливо зауважити, що не всі сервери вбудовано пересилають необхідні заголовки для сумісного оновлення з'єднання H2C. Такі сервери, як AWS ALB/CLB, NGINX та Apache Traffic Server, серед інших, природно блокують з'єднання H2C. Тим не менш, варто протестувати з невідповідним варіантом Connection: Upgrade, який виключає значення HTTP2-Settings з заголовка Connection, оскільки деякі бекенди можуть не відповідати стандартам.
Незалежно від конкретного шляху, вказаного в URL proxy_pass (наприклад, http://backend:9999/socket.io), встановлене з'єднання за замовчуванням переходить до http://backend:9999. Це дозволяє взаємодіяти з будь-яким шляхом у межах цієї внутрішньої точки доступу, використовуючи цей метод. Отже, вказівка шляху в URL proxy_pass не обмежує доступ.
Інструменти h2csmuggler від BishopFox та h2csmuggler від assetnote сприяють спробам обійти захист, накладений проксі, встановлюючи з'єднання H2C, тим самим дозволяючи доступ до ресурсів, захищених проксі.
Для додаткової інформації про цю уразливість, особливо щодо NGINX, див. цей докладний ресурс.
Перенаправлення Websocket
Перенаправлення Websocket, на відміну від створення тунелю HTTP2 до точки доступу через проксі, встановлює тунель Websocket для обходу можливих обмежень проксі та сприяє прямому спілкуванню з точкою доступу.
Сценарій 1
У цьому сценарії зловмисний клієнт спрямовується на бекенд, який пропонує публічний WebSocket API поряд з недоступним внутрішнім REST API, щоб отримати доступ до внутрішнього REST API. Атака відбувається у кілька етапів:
Клієнт починає, відправляючи запит на оновлення до оберненого проксі з неправильною версією протоколу
Sec-WebSocket-Versionу заголовку. Проксі, не перевіряючи заголовокSec-WebSocket-Version, вважає запит на оновлення дійсним і пересилає його на бекенд.Бекенд відповідає статусним кодом
426, вказуючи неправильну версію протоколу у заголовкуSec-WebSocket-Version. Обернений проксі, не звертаючи уваги на відповідь бекенда, вважається готовим до спілкування через WebSocket і пересилає відповідь клієнту.В результаті обернений проксі вводиться в оману, вважаючи, що між клієнтом та бекендом встановлено з'єднання WebSocket, тоді як насправді бекенд відхилив запит на оновлення. Незважаючи на це, проксі підтримує відкрите з'єднання TCP або TLS між клієнтом та бекендом, дозволяючи клієнту необмежений доступ до приватного REST API через це з'єднання.
Серед уразливих обернених проксі є Varnish, який відмовився вирішувати проблему, та Envoy proxy версії 1.8.0 або старішої, пізніші версії якого змінили механізм оновлення. Інші проксі також можуть бути вразливими.
Сценарій 2
У цьому сценарії бекенд має як публічне WebSocket API, так і публічне REST API для перевірки стану здоров'я, разом з недоступним внутрішнім REST API. Атака, більш складна, включає наступні кроки:
Клієнт відправляє запит POST для спрацювання API перевірки стану здоров'я, включаючи додатковий HTTP заголовок
Upgrade: websocket. NGINX, як обернений проксі, інтерпретує це як стандартний запит на оновлення, базуючись лише на заголовкуUpgrade, і пересилає його на бекенд.Бекенд виконує API перевірки стану здоров'я, звертаючись до зовнішнього ресурсу, керованого зловмисником, який повертає HTTP відповідь із статусним кодом
101. Ця відповідь, після отримання бекендом та пересилання на NGINX, вводить проксі в оману, думаючи, що встановлено з'єднання WebSocket через його перевірку лише статусного коду.
Попередження: Складність цієї техніки збільшується, оскільки вона потребує можливості взаємодії з точкою доступу, яка може повертати статусний код 101.
У кінцевому підсумку NGINX вводиться в оману, вважаючи, що між клієнтом та бекендом існує з'єднання WebSocket. Насправді такого з'єднання немає; цільовим було REST API перевірки стану здоров'я. Тим не менш, обернений проксі підтримує відкрите з'єднання, дозволяючи клієнту отримати доступ до приватного REST API через нього.
Більшість обернених проксі вразливі до цього сценарію, але використання залежить від наявності зовнішньої вразливості SSRF, яку зазвичай вважають проблемою низької серйозності.
Лабораторії
Перевірте лабораторії, щоб протестувати обидва сценарії на https://github.com/0ang3el/websocket-smuggle.git
Посилання
Last updated
