Приветствую! В этой статье поговорим об уязвимости решении для организации IP-телефонии Asterisk. Уязвимость позволяет проводить инжект RTP пакетов в разговор или прослушивать RTP трафик.
Для использования уязвимости нужно отправить RTP пакет на порт сервера, к которому в данный момент привязан RTP поток. Если сервер уязвим, то он ответит пакетами RTP стрима, предназначенными для абонента, который на самом деле использует этот порт для разговора. Данная уязвимость не требует от атакующего находиться между сервером и абонентом. Данная атака чем-то напоминает MITM, но даже скорее “Человек сбоку”, так как ARP Spoofing не используется.
Это становится возможным из-за алгоритма работы некоторых RTP прокси. В процессе решения «проблем», связанных с доставкой RTP пакетов при использовании NAT, прокси не требует никакой аутентификации для внесения в свою внутреннюю таблицу информации о конечных IP адресе и порте, на которые следует отправлять RTP ответы, чтобы они были доставлены абоненту. RTP прокси «запоминает» пары IP/Порт основываясь на том, с какого IP/порта прокси получает RTP пакеты от абонента.
Для того чтобы получить пакеты от стороннего абонента, нужно лишь знать RTP порт, который используется абонентом и начать отправлять на него RTP пакеты, тем самым вводя RTP прокси в заблуждение.
Уязвимости подвержены версии Asterisk c 11.4.0 по 14.6.1.
Подробнее изучить проблему можно на официальном сайте уязвимости - rtpbleed.com
Ну а моя задача проверить на уязвимость один из рабочих серверов Asterisk.
Существует бесплатный инструмент для проверки сервера на уязвимость – Rtpnatscan.
Скачиваем его себе со страницы разработчика на Github.
> git clone https://github.com/kapejod/rtpnatscan.git
> cd rtpnatscan
Компилируем утилиты:
> make rtpnatscan
> make rtcpnatscan
Зайдем на Asterisk, посмотрим, идут ли звонки, какие порты используются для RTP и т.д.
Сделать это можно командой:
> rtp set debug on
Теперь можно запустить на атакующем хосте RTPnatscan и попробовать захватить RTP пакеты.
> ./rtcpnatscan 23.45.545.454 0 65535 10000
Где:
· IP-адрес сервера.
· Диапазон портов, я указал полный 0 – 65535
· Количество пакетов, которое мы хотим послать.
Как видно, ниже, сервер нам отвечает:
Заглянем внутрь захваченных пакетов:
Закрашено, адрес сервера и точное его местоположение с координатами. Смотрим далее:
Удалось найти MAC и IP Cisco, которая есть в сети, но я не понял, к чему она тут… В целом неплохо, можно продолжать сниффить пакеты, но я на этом закончу.
Избавление от этого кроется в следующем:
· Существует официальный патч для Asterisk, но он не полностью закрывает уязвимость, поэтому есть дополнительный патч, который рекомендуется также применить. Он скачивается вместе с rtpnatsccan.
· Нужно не задавать параметр nat=yes в конфигурации Asterisk, если это допустимо в вашем случае.
· Так же рекомендуется использовать шифрование голосового трафика, чтобы даже при перехвате RTP пакетов атакующий не получил доступ к конфиденциальной информации.
На этом все. Спасибо за внимание.
Для использования уязвимости нужно отправить RTP пакет на порт сервера, к которому в данный момент привязан RTP поток. Если сервер уязвим, то он ответит пакетами RTP стрима, предназначенными для абонента, который на самом деле использует этот порт для разговора. Данная уязвимость не требует от атакующего находиться между сервером и абонентом. Данная атака чем-то напоминает MITM, но даже скорее “Человек сбоку”, так как ARP Spoofing не используется.
Это становится возможным из-за алгоритма работы некоторых RTP прокси. В процессе решения «проблем», связанных с доставкой RTP пакетов при использовании NAT, прокси не требует никакой аутентификации для внесения в свою внутреннюю таблицу информации о конечных IP адресе и порте, на которые следует отправлять RTP ответы, чтобы они были доставлены абоненту. RTP прокси «запоминает» пары IP/Порт основываясь на том, с какого IP/порта прокси получает RTP пакеты от абонента.
Для того чтобы получить пакеты от стороннего абонента, нужно лишь знать RTP порт, который используется абонентом и начать отправлять на него RTP пакеты, тем самым вводя RTP прокси в заблуждение.
Уязвимости подвержены версии Asterisk c 11.4.0 по 14.6.1.
Подробнее изучить проблему можно на официальном сайте уязвимости - rtpbleed.com
Ну а моя задача проверить на уязвимость один из рабочих серверов Asterisk.
Существует бесплатный инструмент для проверки сервера на уязвимость – Rtpnatscan.
Скачиваем его себе со страницы разработчика на Github.
> git clone https://github.com/kapejod/rtpnatscan.git
> cd rtpnatscan
Компилируем утилиты:
> make rtpnatscan
> make rtcpnatscan
Зайдем на Asterisk, посмотрим, идут ли звонки, какие порты используются для RTP и т.д.
Сделать это можно командой:
> rtp set debug on
Теперь можно запустить на атакующем хосте RTPnatscan и попробовать захватить RTP пакеты.
> ./rtcpnatscan 23.45.545.454 0 65535 10000
Где:
· IP-адрес сервера.
· Диапазон портов, я указал полный 0 – 65535
· Количество пакетов, которое мы хотим послать.
Как видно, ниже, сервер нам отвечает:
Заглянем внутрь захваченных пакетов:
Закрашено, адрес сервера и точное его местоположение с координатами. Смотрим далее:
Удалось найти MAC и IP Cisco, которая есть в сети, но я не понял, к чему она тут… В целом неплохо, можно продолжать сниффить пакеты, но я на этом закончу.
Избавление от этого кроется в следующем:
· Существует официальный патч для Asterisk, но он не полностью закрывает уязвимость, поэтому есть дополнительный патч, который рекомендуется также применить. Он скачивается вместе с rtpnatsccan.
· Нужно не задавать параметр nat=yes в конфигурации Asterisk, если это допустимо в вашем случае.
· Так же рекомендуется использовать шифрование голосового трафика, чтобы даже при перехвате RTP пакетов атакующий не получил доступ к конфиденциальной информации.
На этом все. Спасибо за внимание.
