В популярном решении для организации IP-телефонии Asterisk обнаружена уязвимость, позволяющая проводить инжект RTP пакетов в разговор или прослушивать RTP трафик.

Как это работает


Чтобы проэксплуатировать уязвимость, атакующему нужно отправить RTP пакет на порт сервера, к которому в данный момент привязан RTP стрим. Если сервер уязвим, то он ответит пакетами RTP стрима, предназначенными для абонента, который на самом деле использует этот порт для разговора. Данная уязвимость не требует от атакующего находиться между сервером и абонентом. Хотя по названию она напоминает heartbleed, в действительности уязвимость скорее позволяет провести, как раз таки, MITM атаку.

Это становится возможным из-за алгоритма работы некоторых RTP прокси. В процессе решения «проблем», связанных с доставкой RTP пакетов при использовании NAT, прокси не требует никакой аутентификации для внесения в свою внутреннюю таблицу информации о конечных IP адресе и порте, на которые следует отправлять RTP ответы, чтобы они были доставлены абоненту. RTP прокси «запоминает» пары IP/Порт основываясь на том, с какого IP/порта прокси получает RTP пакеты от абонента.

Таким образом, для того чтобы получить пакеты от стороннего абонента, нужно лишь знать RTP порт, который используется абонентом и начать отправлять на него RTP пакеты, тем самым вводя RTP прокси в заблуждение.

Уязвимости подвержены версии Asterisk c 11.4.0 по 14.6.1.

Подробнее изучить проблему можно на официальном сайте уязвимости rtpbleed.com

Инструменты


Чтобы проверить, уязвимы ли ваши системы к RTP Bleed можно воспользоваться бесплатным инструментом rtpnatscan.

Для установки нужно склонировать репозиторий и скомпилировать утилиты

git clone https://github.com/kapejod/rtpnatscan.git
cd rtpnatscan
make rtpnatscan
make rtcpnatscan

Далее нужно совершить звонок, проверить какие порты используются для RTP, например через CLI Asterisk

asterisk -r
rtp set debug on

Далее, на сторонней машине запустить сканирование rtpnatscan и попробовать получить RTP пакеты

./rtpnatscan сервер начальный_порт конечный_порт число_пакетов 

Для этого не нужно использовать никакие MITM техники, вроде ARP-спуфинга. Нужно лишь иметь возможность отправлять RTP пакеты на уязвимый сервер и порт.

Если удаленный сервер отправил RTP пакеты в ответ, значит ваша конфигурация уязвима.

rtpnatscan это лишь сканер и не позволяет прослушивать разговор.

Помимо утилиты rtpnatscan, существует платный инструмент, имеющий более широкие возможности.

Как защититься


Прежде всего нужно проверить, уязвимы ли ваши системы к RTP Bleed при помощи инструмента, описанного выше.

Существует официальный патч для Asterisk, но он не полностью закрывает уязвимость, поэтому есть дополнительный патч, который рекомендуется также применить.

Если нет возможности установить патч, нужно не задавать параметр nat=yes в конфигурации Asterisk, если это допустимо в вашем случае.

Так же рекомендуется использовать шифрование голосового трафика, чтобы даже при перехвате RTP пакетов атакующий не получил доступ к конфиденциальной информации.

Комментарии (7)


  1. antivoland
    15.09.2017 16:21

    Кто уже протестил — FreeSwitch подвержен?


    1. arheops
      15.09.2017 23:38

      Скорее всего да, зависит от прокси используемого провайдером.


  1. IGHOR
    15.09.2017 17:01

    При SIP подключении, хоть клиент и отправляет свой RTP порт, но из-за NAT без UPnP нельзя узнать реальный порт клиента.
    Так сервисы RTP работают с костылем, отправляя трафик туда откуда он пришел.
    И с этим ничего не сделать, первый входящий всегда будет подключен как основной.

    Уязвимость заключается в том что RTP транслирует копию всем кто прислал валидный пакет, а фикс это лишь отброс всех ІР кроме первого в текущей сессии.
    Выходит что всегда, если кто-то флудит пакетами ваш RTP, будет шанс что клиент будет соединен с атакующим, но после фикса целевой контакт звонящего ничего не услышит.


    1. arheops
      15.09.2017 23:32

      Только первый — не будет работать с кучей nat-устройств.


      1. IGHOR
        15.09.2017 23:34

        Почему? Хотите сказать что внешний порт от клиента будет меняться в течении сессии?


        1. arheops
          15.09.2017 23:38

          Именно. Причем не только порт, но и адрес.
          На большинстве 4g провайдеров.


  1. arheops
    15.09.2017 23:32
    +1

    «Всего лишь знать порт» значит перехватить sip траффик как минимум.

    В связи с кучей костылей в реализации сип протокола астериска, 3g/4g глючных натов, это не будет пофикшено нормально. Врятли ктото будет патчить прокси в сторону уменьшения совместимости. Вы будете терять звонки с таким патчем.