ПОВЫШЕНИЕ ЗАЩИЩЕННОСТИ ИСПОЛЬЗОВАНИЯ ПРОТОКОЛА SIP В ip-АТС НА ПЛАТФОРМЕ ASTERISK

Аннотация. В данной статье рассматриваются уязвимости современных транспортных протоколов, используемых в ip-телефонии, а также перечисляются способы защиты от наиболее часто используемых атак.

Ключевые слова: RTP-пакет, пакет, SIP-сервер, прокси, сервер, сессия, абонент, злоумышленник,  UDP, атака, ip-телефония.

На сегодняшний день с целью передачи мультимедийного трафика используют UDP (User Datagram Protocol) и RTP (Real-time Transport Protocol) протоколы. Они позволяют отправлять большое количество пакетов за короткое время, сохраняя приемлемое качество передачи, учитывать порядок следования и число утраченных пакетов, поскольку это позволит приемной стороне быстрее восстановить речь отправителя.

Однако у данной связки протоколов есть существенный недостаток ─ инициализация и сброс вызова, а также передача сигналов управления. UDP (User Datagram Protocol) не позволяет организовать перезапросы пакетов ─ все поврежденные пакеты удаляются из буфера. RTP же не может установить надежное соединение между портами собеседников, из-за чего пакеты с информацией как со служебной, так и с пользовательской не будут приходить нужному адресату. Для контроля доставки управляющих пакетов используют протокол SIP (Session Initiation Protocol) [1]. Данный протокол очень распространен в VoIP (Voice over Internet Protocol), поскольку не зависит от вида транспортного протокола ─ поддерживает передачу по UDP, TCP (Transmission Control Protocol), RTP. SIP не накладывает ограничений на передвижение пользователей сети внутри домена, способен взаимодействовать с другими протоколами ip-телефонии, достаточно просто конфигурируем при расширении сети. Клиенты SIP-сети идентифицируются по универсальным идентификаторам, называемыми SIP-URI. Внешне они похожи на адреса электронной почты: sip:ivan@ivanov.ucheba.ru. С одной стороны, такое решение очень удобно для настройки администраторами. С другой ─ злоумышленник, который смог перехватить нужные пакеты, сможет без труда определить кому они предназначены, а также сформировать представление о системе доменов в сети, что влечет за собой риски для информационной безопасности.

Для того что бы убедиться в этом, необходимо понять работу протокола SIP. Перед тем как установить соединение абонентов необходимо правильно подготовить служебную информацию. На рисунке 1 показан алгоритм инициализации выходящих пакетов управления, благодаря которым будет установлено соединение с собеседником.

Рисунок 1. Алгоритм инициализации адреса прокси-сервера

Необходимо отметить, что очень часто пользователи не знают ip-адрес того, с кем хотят связаться. В связи с этим необходимо использовать службу DNS, в которой будут храниться авторизованные именные ссылки, которые в зарубежной литературе называются NAPTR (Name Authority Pointer) [2]. После того как прокси-сервер узнает адрес пользователя, который инициирует сеанс связи и того, к кому обращаются, может быть установлен поток передачи данных.

Рисунок 2. Пример инициализации разговора в VoIP по протоколу SIP

Наиболее распространенная структура взаимодействия по протоколу SIP между абонентами представлена на рисунке 2 и состоит из следующих пунктов:

• отправитель инициирует запрос INVITE;
• получатель отвечает кодом100 (попробуйте позвонить);
• отправитель начинает звонить, отправляя ответ 180;
• получатель поднимает трубку и отправляет код 200 (успешный ответ);
• подтверждение о начале сеанса, отправленное инициатором (ACK(англ. Acknowledge — подтверждение));
• трансляция пакетов пользователей по RTP-протоколу;
• отправляется запрос BYE для завершения вызова.

Каждому пользователю в организации назначена учетная запись SIP, которая содержит имя пользователя, пароль и адрес сервера SIP. Именно на этапе взаимодействия с сервером появляются угрозы информационной безопасности. Для того, чтобы войти в систему учета и инициализировать вызов клиент отправляет запрос регистрации на сервер, который отвечает ему просьбой об аутентификации и отправляет специальное число. Абонент присылает строку текста, в которой указаны учётные данные и вычисленную хэш-сумму своих данных и специального числа, после чего сервер проверяет поступившие данные. Если находит соответствие, то устанавливает соединение. Аналогично проходят аутентификацию и вызываемые пользователи, только в этом случае сервер пришлет приглашение (INVITE) на установление соединения.

 Злоумышленник будет пытаться выкрасть именно строку авторизации, в которой содержится хешированный пароль. А поскольку протокол SIP использует MD5 хэш-сумму, то нарушитель способен за считанные минуты найти коллизию и расшифровать перехваченное сообщение. Если взамен сервера клиент подключится к злоумышленнику данные учетной записи пользователя могут быть похищены. Для реализации атаки необходимо сымитировать запросы SIP-сервера, как показано на рисунке 3, и позвонить жертве.

Рисунок 3. Схема реализации атаки с подменой сервера аутентификации

Абонент отвечает на входящий звонок и не слышит ответа на другой стороне, не подозревая, что злоумышленник запрашивает его данные авторизации, имитируя разрыв соединения и ошибку авторизации. Получив заветную строку с хэшированной информацией пользователя, атакующий может в бессетевом режиме узнать учетные данные, подобрав правильное значение хэша. Для оценки уязвимости алгоритма SIP MD5 был проведен эксперимент. Для его проведения использовалось приложение SIPcrack — набор инструментов для прослушивания и взлома дайджест-аутентификаций в протоколе SIP. Методом взлома пароля был простой перебор.

Таблица

Значения

Не сложно заметить, что с увеличением длины пароля линейно возрастает время. Тем не менее это показывает, что использование MD5 не желательно даже в том случае, если предполагается, что злоумышленник будет только перебирать пароли. Анализ успешно проведенных атак показал, что большинство компаний для удобства клиентов разрешают использование паролей менее 5 символов. Следующим шагом эксперимента стало использование атаки с пользованием словарей. В качестве программного обеспечения использовался пакет Hashcat, который позволяет выбирать словари с наиболее часто используемыми паролями. В качестве пароля иcпользовалось слово «PassWord» с хэшсуммой eccb0e6cfeed40a66a8fe19c55186749. Утилита смогла подобрать хэш за 90 с.  Не сильно увеличилось время и при изменении букв на символы. «Pass#F8$». Полученный хэш: b7d1c6706c760d59c83d3904d477d556, время на подбор ─ 157 с. Таким образом, можно сделать вывод, что для выработки хэшсуммы необходим другой алгоритм, который не будет сильно уступать по времени получения хэша, но окажется гораздо устойчевее к коллизиям и атакам с применением словарей.

Атака опасна для систем ip-телефонии имеющих: открытые порты, оконечное оборудование, в котором не запрещено отвечать на INVITE-запросы с неизвестных номеров и адресов, а также ip-АТС (автоматическая телефонная станция), разрешающие отправлять пакеты-приглашения напрямую абонентам. В целях повышения защищенности системы, рекомендуется заменить MD5-хэширование на отечественный криптографический стандарт
ГОСТ Р 34.11-2012.

Следует отметить, что из-за уязвимости протокола передачи RTP очень часто реализуется несанкционированное подслушивание трафика абонентов посредством MITM-атаки (Man-in-the-middl). Простейшая схема этой атаки показана на рисунке 4. Дело в том, что во время обработки запросов прокси-сервер отвечает на RTP пакеты, не требуя аутентификации. В результате чего, злоумышленнику достаточно отправить RTP-пакет во время передачи потока данных [3]. В этом случае сервер ответит пакетами RTP-стрима, внесет нарушителя в информационную таблицу об оконечных пользователях, и злоумышленник станет полноценным участником разговора. При этом никакого оповещения уже участвующих в обмене данными не произойдет. Единственное, что нужно знать злоумышленнику ─ номер порта приложения, который используют стороны переговоров. Узнать порт также не составит труда ─ информация управления и взаимодействия, передаваемая по протоколу SIP в незашифрованном текстовом формате, может быть перехвачена в сети общего пользования, через которую проходит передача пакетов.

Рисунок 4. Простейшая схема MITM-атаки

Решением проблемы могут стать виртуальные частные сети (VPN), которые шифруют данные пользователя, передаваемые по туннелю. Шифрованную речь сразу можно передать на сервер, тем самым уменьшив нагрузку на узел обработки сети и не понижая качество разговора. Кроме того, на базе программной платформы Asterisk [4] версии выше 14.6.1 существуют официальные программные решения, основанные на идее аутентификации пользователей на момент инициализации сессии, а также ее обновления в момент добавления новых пользователей, что значительно снижает риски несанкционированного доступа. Системы SIP поддерживают протокол безопасности транспортного уровня (TLS) для шифрования кодов, отправляемых для запроса соединения. Это гарантирует, что только авторизованные абоненты, участвующие в соединении, смогут правильно принять коды, не позволяя хакерам получить к ним доступ. Для преодоления проблем, связанных с атаками на SIP-сеть, компания Cisco предлагает использовать криптографические туннели IPSec, для безопасного шифрования SIP-сообщений. Практическое решение реализовано на базе сервера Cisco Unified Communications Manager, который выступает в качестве узла доступа в туннеле IPSec. Атаки типа MITM можно предотвратить с помощью коммутаторов Cisco Catalyst, которые проводят проверку таблиц подключенных пользователей при помощи цифровых подписей.

Однако не устраняется проблема со сканированием портов SIP-сервера и отправки на NAT-адрес запросов RTP. Так, например, при помощи перебора диапазонов подсетей злоумышленники могут узнать работающий порт, используемую VoIP платформу и служебную информацию пользователя, а именно его сетевой идентификатор. Снизить угрозу можно, заменив протокол RTP на его более защищенную версию ─ SRTP (Secure Real-time Transport Protocol), который защищает отправителя и получателя во время соединения. Он шифрует данные пользователя, так что только легитимные пользователи могут получить доступ к отправленному аудиосообщению. При использовании защищенного SRTP-протокола необходимо будет учесть, что потребуется большая вычислительная мощность серверов и более объемные буферы обработки приходящих пакетов, поскольку время на обработку возрастет, а вместе с тем могут появиться нежелательные задержки и джиттер, которые способны оборвать соединение между абонентами. Кроме того, по SIP будут рассылаться ключи шифрования, что потребует шифрования и служебной информации. Тем не менее риски при применении протокола SRTP значительно снижаются, по сравнению с возможным использованием злоумышленниками уязвимостей протокола RTP.

Следующая проблема заключается в том, что трафик SIP-сообщений передается в виде обычного текста. Делается это для того, чтобы уменьшить время при обработке служебной информации, снизить размер пакета и тем самым избежать лишней фрагментации данных. Провайдеры стремятся сохранить требования качества предоставляемых услуг, мало задумываясь об информационной безопасности пользователей. На сегодняшний день качество передачи возможно гарантировать, если правильно настроить политики обслуживания абонентов и верно выбрать протокол транспортного уровня для SIP. Транспортные протоколы, используемые в VoIP, являются основным источником уязвимостей. SIP запрос передается в обычном текстовом виде, что облегчает анализ с помощью стандартных инструментов синтаксического анализа, таких как язык шаблонов Perl. При установлении сеансов связи SIP-телефоны взаимодействуют, отправляя свои SIP-сообщения в виде обычного текста по UDP или TCP. Если злоумышленник сможет вставить нужную ему информацию в поток сообщений, то он, как минимум, определит адреса источника и назначения для медиапотока. В худшем же варианте, он перенаправит поток туда куда ему нужно или прервет вещание. Без служебной информации злоумышленнику пришлось бы постоянно отправлять большое количество пакетов через большой диапазон портов для перегрузки работы сервера, чтобы нарушить медиапотоки RTP, что вполне возможно, однако сопряжено с определенными трудностями. Так, например, во второй половине 2021 года участились случаи DDOS-атак на серверы ip-АТС [5]. Анализ уязвимостей показал, что при достаточной загруженности сети и большом количестве VPN-туннелей, серверное оборудование не выдерживало массового потока запросов. В результате атак компании-поставщики услуг VoIP долгое время не могли восстановить работу системы. Как выяснилось, связано это было с некорректными настройками качества обслуживания (QoS), которые неравномерно распределяли полосу пропускания канала передачи для виртуальных частных сетей. В результате в часы наибольшей загруженности сети общего доступа, когда по ней перемещалось большое количество данных разного рода, а потребление ресурса полосы пропускания росло за счет увеличения числа защищенных туннелей, злоумышленнику гораздо проще было вызвать отказ в работе сервера.

Существуют и другие типы атак, которые направлены на голосовые сети. К ним относятся:

1. SPIT ─ спам через IP-телефон, который включает, например, отправку нежелательных сообщений на дисплей IP-телефона или заставляет IP-телефон время от времени звонить;
2. фишинг ─ вид мошенничества, в котором жертва предоставляет свою личную информацию по телефону.

Однако современные тенденции атак склоняются к несанкционированному доступу к разговорам пользователей или полной невозможности использования средств ip-телефонии. В августе 2022 года на конференции DEFCON [6] была опубликована уязвимость, основанная на отправке специальных UDP-пакетов. Особенность ее заключается в том, что при переполнении буфера, накапливающего пришедшие пакеты, возникает вероятность перезаписи памяти за пределами выделенного участка памяти. То есть, если на SIP-сервер поступили пакеты с некорректно заполненными полями данных появляется возможность последующими UDP-пакетами, содержащими вредоносный код, внедрить скрипт злоумышленника в оперативную память работающей системы, будь то сервер или маршрутизатор. Подобным образом нарушитель сможет открыть ранее закрытые порты, подключиться к сессиям пользователей и подслушать их разговор, а самой серьезной угрозой является то, что у нарушителя есть возможность выкрасть учетные записи администраторов. На данный момент готового решения этой проблемы нет. Существуют общие рекомендации по предотвращению переполнения буфера приложений. Самым лучшим решением данной проблемы будет правильная настройка брандмауэра, который будет просматривать содержимое пакетов и отбрасывать некорректные UDP-пакеты.

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

В целях повышения защищенности использования протокола SIP в ip-АТС на платформе Asterisk рекомендуется использовать следующую методику:

• закрывать неиспользуемые порты;
• использовать отечественный криптографический стандарт ГОСТ Р 34.11-2012 для получения хэш-образов паролей абонентов;
• при инициализации соединения SIP предварительно должна быть произведена двусторонняя аутентификация сервера и абонента, после чего проверке подвергаются вызывающая и приемная стороны по таблицам легитимных пользователей, хранящихся на SIP-сервере.
• сеанс связи организовывать по TLS-туннелю, поскольку он является более легким и более простым в управлении протоколом, чем IPSec, который применяет сквозное шифрование и для быстрой обработки пакетов потребует большей производительности от оконечного оборудования.
• запретить доступ конечных абонентов к прокси-серверу, все запросы должна перенаправлять ip-АТС. Это позволит сократить время на обработку пакетов, поскольку вычислительные сложности идентификации, аутентификации и управления передачей будут распределены.

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