Comments 7
Кто уже протестил — FreeSwitch подвержен?
При SIP подключении, хоть клиент и отправляет свой RTP порт, но из-за NAT без UPnP нельзя узнать реальный порт клиента.
Так сервисы RTP работают с костылем, отправляя трафик туда откуда он пришел.
И с этим ничего не сделать, первый входящий всегда будет подключен как основной.
Уязвимость заключается в том что RTP транслирует копию всем кто прислал валидный пакет, а фикс это лишь отброс всех ІР кроме первого в текущей сессии.
Выходит что всегда, если кто-то флудит пакетами ваш RTP, будет шанс что клиент будет соединен с атакующим, но после фикса целевой контакт звонящего ничего не услышит.
Так сервисы RTP работают с костылем, отправляя трафик туда откуда он пришел.
И с этим ничего не сделать, первый входящий всегда будет подключен как основной.
Уязвимость заключается в том что RTP транслирует копию всем кто прислал валидный пакет, а фикс это лишь отброс всех ІР кроме первого в текущей сессии.
Выходит что всегда, если кто-то флудит пакетами ваш RTP, будет шанс что клиент будет соединен с атакующим, но после фикса целевой контакт звонящего ничего не услышит.
«Всего лишь знать порт» значит перехватить sip траффик как минимум.
В связи с кучей костылей в реализации сип протокола астериска, 3g/4g глючных натов, это не будет пофикшено нормально. Врятли ктото будет патчить прокси в сторону уменьшения совместимости. Вы будете терять звонки с таким патчем.
В связи с кучей костылей в реализации сип протокола астериска, 3g/4g глючных натов, это не будет пофикшено нормально. Врятли ктото будет патчить прокси в сторону уменьшения совместимости. Вы будете терять звонки с таким патчем.
Sign up to leave a comment.
RTP Bleed: Опасная уязвимость, позволяющая перехватывать VoIP трафик