ћы в Telegram - чате. “ы с нами? :)

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

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

ћерион Ќетворкс

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

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

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

¬ы убедитесь, что провести подобную атаку - совсем не сложно. »нструменты дл€ еЄ осуществлени€ не €вл€ютс€ какой-то сверхсекретной разработкой и наход€тс€ в свободном доступе.

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

¬нимание! »нформаци€, представленна€ в данной статье, носит исключительно ознакомительный характер.  омпани€ ћерион Ќетворкс не несЄт ответственности за последстви€ применени€ техник и способов, описанных в данном материале. Ќапоминаем, что неправомерный доступ к компьютерной информации преследуетс€ по закону и влечет за собой уголовную ответственность.

јтака, о которой мы поговорим, св€зана с процессом аутентификации по протоколу SIP, а именно - с получением информации из заголовков 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

. Ќа выходе он получит пароль от учЄтной записи. ≈сли пароль слабый или, ещЄ хуже, совпадает с username, то врем€ перебора не превысит 1 секунды.

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


ѕолезна ли ¬ам эта стать€?


Ёти статьи могут быть вам интересны: