# WebRTC DoS

{{#include ../../banners/hacktricks-training.md}}

**Цю проблему було виявлено в цьому блозі:** [**https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/**](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альні порти для медіа-сесій, не підлягають цій вразливості.

### Висновок

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

{{#include ../../banners/hacktricks-training.md}}