Телефония →Теория

Метод атаки на протокол SIP

Как взламывают самый популярный VoIP стандарт

Декабрь 17, 2018 Мерион Нетворкс

6 минут чтения

Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно.

Продвинутый курс по Asterisk

Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.

Начни обучение

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

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

Цель данной статьи - показать, к чему может привести недостаточное внимание, уделённое вопросам безопасности при настройке систем IP-телефонии и как просто это могут использовать злоумышленники.

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

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

Как показано на рисунке:

1. Клиент отправляет запрос регистрации на сервер;
2. Сервер сообщает о необходимости зарегистрироваться и запрашивает данные для аутентификации;
3. Клиент повторно отправляет запрос регистрации, но на этот раз со строкой Authorization, в которой указаны учётные данные;
4. Сервер проверяет учётные данные в локальной базе и если есть совпадения – разрешает регистрацию.

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

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

Наверное, Вы догадались, что ключевым моментом процесса SIP аутентификации является отправка клиентом повторного запроса REGISTER, который также содержит учётные данные для регистрации на сервере. Как раз в этот момент, наш потенциальный злоумышленник и нанесёт свой удар.

Давайте рассмотрим, что из себя представляет строка Authorization в повторном запросе REGISTER.

Как видно на рисунке, заголовок Authorization включает в себя следующие поля:

• Authentication Scheme - метод аутентификации;

Поскольку SIP многое унаследовал от протокола HTTP, то и схема аутентификации в нём основана на HTTP аутентификации, которая также называется Дайджест (Digest) аутентификация. Эта схема применяется серверами для обработки учётных данных от клиентов. При этом, часть учётных данных передаётся в виде хэш-сумм, которые сервер комбинирует с открытыми данными и вычисляет пароль для данного клиента. Это значительно повышает уровень безопасности, но как мы убедимся в дальнейшем – не помогает при некорректной настройке учётной записи.

• Username - имя пользователя, заданное на сервере. В нашем случае – это внутренний номер 3354;
• Realm - параметр, определяющий подключение к серверу телефонии;

Как правило, администратор VoIP сервера сам настраивает realm и транслирует его пользователю, который хочет осуществить подключение. Например, у провайдеров облачных услуг это может быть строка вида domain.com, в сервере Asterisk, по-умолчанию значение этой строки - asterisk.

• Nonce Value - рандомно сгенерированная сервером, уникальная строка, при формировании ответа 401 в сторону клиента. В дальнейшем используется сервером в вычислениях после получения учетных данных от клиента, должна совпадать с тем, что пришло от сервера;
• Authentication URI - унифицированный идентификатор ресурса. В нашем случае, ресурсом является сервер, расположенный по адресу 123.45.67.89, обращение к нему происходит по протоколу SIP, по порту 5060.
• Digest Authentication Response - ответ от клиента, посчитанный на основании данных, полученных от сервера. На основании этого значения сервер в том числе сверяет пароль, который задан клиенту.

Согласно RFC 2069, который описывает HTTP дайджест аутентификацию, response вычисляется следующим образом:

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)

Как видите, на основании MD5 хэш-сумм полей: username, realm, password (да, это пароль клиента), method, digestURI и nonce высчитывается тот самый заветный response, от которого зависит регистрация клиента на сервере, а следовательно, и возможность осуществлять им вызовы.

• Algorithm - алгоритм, по которому высчитывался response

Догадываетесь о чём идёт речь? О том, что если злоумышленник заполучит полную строку Authorization, то он может вычислить пароль клиента, зарегистрироваться на сервере и спокойно звонить куда ему вздумается.

Пространство для данной атаки достаточно обширное. Дело в том, что клиент может передавать строку авторизации в нескольких запросах – в уже известном нам REGISTER, INVITE или BYE.

Атакующему не составит труда притвориться “сервером” и затребовать от клиента аутентификации. Для этого, атакующий направит в сторону клиента, созданный с помощью специальной программы вредоносный SIP пакет с ответом 401 Unauthorized, который будет содержать строку, заставляющую клиента отправить учётные данные. Данная строка должна содержать realm и nonce . Выглядит эта строка следующим образом:

Таким образом, атака может выглядеть следующим образом:

С точки зрения атакуемого, это будет выглядеть как простой звонок, на другой стороне трубки которого будет тишина. Он даже не будет подозревать о том, что его учётные данные вот-вот утекут к злоумышленнику. Атакующий в нужный момент разорвёт соединение, отправив BYE и затем сформированный вредоносный пакет.

Нагляднее всего приводить в пример прямое взаимодействие между клиентами. Такой сценарий становится, когда есть возможность отправлять SIP запросы напрямую до оконечного клиента. Например, когда телефон выставлен в открытую сеть по SIP порту. Помимо этого, уязвимости подвержены сервера, разрешающие прямое взаимодействия между оконечными клиентами. Лучше всего, пропускать все запросы через Proxy-сервер.

Итак, данной атаке могут быть подвержены:

• IP-телефоны с открытыми в интернет SIP-портами;
• IP-телефоны, отвечающие на запросы INVITE от неизвестных серверов;
• IP-АТС, разрешающие запросы INVITE напрямую до клиентов.;

Заполучив полную строку Authorization атакующий может в оффлайн режиме подобрать пароль к учётной записи. Для этого ему нужно подать на вход специального скрипта, который перебирает хэш-суммы по словарям, перехваченные данные: username, realm, method, digestURI, nonce и наконец - response

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