RTP Bleed: Опасная уязвимость, позволяющая перехватывать VoIP трафик


    В популярном решении для организации 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 пакетов атакующий не получил доступ к конфиденциальной информации.
    • +24
    • 6,8k
    • 7
    Pentestit 992,75
    Информационная безопасность
    Поделиться публикацией
    Комментарии 7
    • 0
      Кто уже протестил — FreeSwitch подвержен?
      • 0
        Скорее всего да, зависит от прокси используемого провайдером.
      • 0
        При SIP подключении, хоть клиент и отправляет свой RTP порт, но из-за NAT без UPnP нельзя узнать реальный порт клиента.
        Так сервисы RTP работают с костылем, отправляя трафик туда откуда он пришел.
        И с этим ничего не сделать, первый входящий всегда будет подключен как основной.

        Уязвимость заключается в том что RTP транслирует копию всем кто прислал валидный пакет, а фикс это лишь отброс всех ІР кроме первого в текущей сессии.
        Выходит что всегда, если кто-то флудит пакетами ваш RTP, будет шанс что клиент будет соединен с атакующим, но после фикса целевой контакт звонящего ничего не услышит.
        • 0
          Только первый — не будет работать с кучей nat-устройств.
          • 0
            Почему? Хотите сказать что внешний порт от клиента будет меняться в течении сессии?
            • 0
              Именно. Причем не только порт, но и адрес.
              На большинстве 4g провайдеров.
        • +1
          «Всего лишь знать порт» значит перехватить sip траффик как минимум.

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

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

          Самое читаемое