WebRTC DoS

Reading time: 3 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримайте HackTricks

Цю проблему було виявлено в цьому блозі: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/

Описана вразливість у медіа-серверах WebRTC виникає через умову гонки під час ініціалізації медіа-сесій, зокрема між перевіркою згоди медіа ICE та ініціацією трафіку DTLS. Ось детальний розгляд:

Походження вразливості

  1. Розподіл UDP портів: Коли користувач ініціює дзвінок WebRTC, медіа-сервер розподіляє UDP порти для обробки медіа-потоків, з IP та портом, які передаються через сигналізацію.
  2. Процеси ICE та STUN: Браузер користувача використовує ICE для перевірки згоди медіа, використовуючи STUN для визначення шляху з'єднання до медіа-сервера.
  3. Сесія DTLS: Після успішної перевірки STUN починається сесія DTLS для встановлення SRTP майстер-ключів, переходячи до SRTP для медіа-потоку.

Механізм експлуатації

  • Експлуатація умови гонки: Зловмисник може експлуатувати умову гонки, надіславши повідомлення DTLS ClientHello до того, як це зробить законний користувач, потенційно використовуючи недійсну шифрувальну сукупність, таку як TLS_NULL_WITH_NULL_NULL. Це викликає помилку DTLS на сервері, що заважає встановленню сесії SRTP.

Процес атаки

  • Сканування портів: Зловмисник повинен вгадати, які UDP порти обробляють вхідні медіа-сесії, надсилаючи повідомлення ClientHello з нульовою шифрувальною сукупністю на ці порти, щоб активувати вразливість.
  • Схема атаки: Послідовність включає кілька повідомлень ClientHello, надісланих зловмисником на сервер, чергуючи їх з законними сигналізаційними та DTLS повідомленнями, що призводить до збою рукостискання через помилкову шифрувальну сукупність.

Тестування та пом'якшення

  • Безпечне тестування: Використовуючи інструменти, такі як Scapy, зловмисники повторно відтворюють повідомлення DTLS ClientHello, націлюючись на конкретні медіа-порти. Для етичного тестування були внесені зміни до Chromium (наприклад, JsepTransport::AddRemoteCandidates), щоб безпечно імітувати поведінку жертви.
  • Заходи пом'якшення: Рішення включають скидання пакетів з неперевірених адрес, як це реалізовано в новіших версіях бібліотек, таких як libnice. Основне рішення підкреслює довіру до процесу перевірки ICE та обробку пакетів лише з перевірених комбінацій IP та портів.

Невразливі сценарії

  • Конфігурації сервера DTLS: Випадки, коли браузер діє як сервер DTLS або коли медіа-сервер не використовує епhemerальні порти для медіа-сесій, не підлягають цій вразливості.

Висновок

Ця вразливість підкреслює тонкий баланс у процесах ініціалізації медіа-сесій та необхідність точного таймінгу та механізмів перевірки для запобігання експлуатації. Розробникам рекомендується впроваджувати рекомендовані заходи безпеки та забезпечувати надійні процеси перевірки для пом'якшення таких вразливостей.

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримайте HackTricks