По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно. В данной статье, подробно разберём один из способов атак на системы, работающие по протоколу SIP, через генерацию вредоносного пакета и последующую компрометацию учётной записи. Вы убедитесь, что провести подобную атаку - совсем не сложно. Инструменты для её осуществления не являются какой-то сверхсекретной разработкой и находятся в свободном доступе. Цель данной статьи - показать, к чему может привести недостаточное внимание, уделённое вопросам безопасности при настройке систем IP-телефонии и как просто это могут использовать злоумышленники. Внимание! Информация, представленная в данной статье, носит исключительно ознакомительный характер. Компания Мерион Нетворкс не несёт ответственности за последствия применения техник и способов, описанных в данном материале. Напоминаем, что неправомерный доступ к компьютерной информации преследуется по закону и влечет за собой уголовную ответственность. Атака, о которой мы поговорим, связана с процессом аутентификации по протоколу SIP, а именно - с получением информации из заголовков SIP пакета и её последующая обработка для извлечения учётных данных. Чтобы понять её суть и определить, какие системы уязвимы к данной атаке, нужно вспомнить как происходит SIP аутентификация. Как показано на рисунке: Клиент отправляет запрос регистрации на сервер; Сервер сообщает о необходимости зарегистрироваться и запрашивает данные для аутентификации; Клиент повторно отправляет запрос регистрации, но на этот раз со строкой Authorization, в которой указаны учётные данные; Сервер проверяет учётные данные в локальной базе и если есть совпадения – разрешает регистрацию. В стандартном процессе 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 секунды. Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.
img
Ранее мы рассмотрели, какие бывают базы данных пользователей. Теперь разберем, как работать с этими базами добавлять, редактировать и удалять пользователей. Рассмотрим следующие 3 утилиты: Useradd - создание пользователей Usermod – изменение свойств пользователей Userdel – удаление пользователей Первое, что нам потребуется это описание команды - man useradd. У данной команды огромное количество ключей. В частности, популярные такие ключи: -d — это указание домашней директории пользователя. Без этого ключа операционная система создает одноименную папку пользователя в папке /home, но с помощью данного ключа мы можем указать какую-нибудь другую. -g – можно указать id группы в которую мы хотим включить пользователя. Есть аналог этого ключа -G (помним, что регистр в Linux имеет значение) – при этом ключе мы можем использовать не id группы, а ее название. -m создание домашней директории по умолчанию, в момент создания пользователя. При данном ключе домашняя директория создается сразу, а не при первом входе пользователя в систему, по умолчанию. Он важен т.к. при автоматизации данная папка может потребоваться. -p – мы можем указать данный ключ и при создании пользователя сразу система потребует задать создаваемому пользователю пароль. -s – данный ключ позволяет задать оболочку по умолчанию для этого пользователя. Общий вид команды: useradd [опции] [имя_пользователя]. Рассмотрим небольшой пример: sudo useradd -m -G sudo buh Все работы с пользователями выполняются с повышенными привилегиями. Создаем нового пользователя buh, сразу создаем домашнюю папку и помещаем в группу sudo, т.е в группу пользователей которая может повышать привилегии. Убедимся, что пользователь был создан - sudo cat /etc/shadow В конце файла мы можем увидеть, что пользователь создан. Обратим внимание, что после логина, стоит не символ звездочки или x, а знак ! – это означает, что пароль скрыт, но может быть с помощью утилиты изменен. Утилита для изменения пароля - passwd. Синтаксис ее достаточно простой - passwd [имя_пользователя]. При использовании ее попросит ввести новый пароль и второй раз ввести для подтверждения. После этого операционная система его зашифрует и заменит в файле на набор букв-цифр-символов. Еще мы командой passwd можем поменять пароль себе. Делается это достаточно просто - passwd и нажимаем клавишу ввода. Система понимает, что пользователь хочет сменить пароль себе и попросит ввести текущий пароль и 2 раза новый пароль. Теперь мы можем посмотреть в какие группы входит пользователь - cat /etc/group Как видно пользователь согласно ключу G был добавлен в группу sudo. Ну и, конечно, для пользователя buh была создана одноименная группа buh. И посмотрим создалась ли домашняя папка пользователя с помощью команды ll /home. Папка создалась. Рассмотрим следующую команду - usermod. Синтаксис данной команды: usermod [опции] [имя_пользователя] У данной утилиты есть все те же ключи, что и у useradd, но есть и свои ключи. -L – данный ключ позволяет заблокировать пользователя. Если мы посмотрим файл /etc/shadow то мы увидим ! знак перед паролем. Что означает, что пользователь не может войти в систему. -U - ключ мы можем использовать для разблокировки пользователя. Теперь мы можем, например, заменить оболочку и подписать учетную запись. sudo usermod -s /bin/bash -c “best buh” buh Как мы видим, изменилась оболочка по умолчанию и добавился комментарий. Последняя утилита userdel исходя из названия мы понимаем, что она используется для удаления пользователей. Синтаксис: userdel [ключ] [имя_пользователя] Обычно эту команду используют примерно так: sudo userdel buh, но если добавить ключик -r то будет удалена и домашняя директория пользователя, а также будет удалена запись о пользователе во всех базах данных пользователей в операционной системе.
img
Функционал модуля CallerID Lookup Sources позволяет устанавливать некие источники для преобразования номерных идентификаторов входящих вызовов CID (caller ID) в имена. После чего, можно привязать входящий маршрут к специальному источнику CID. Таким образом, любой входящий вызов будет сперва проверен на соответствие номера и имени по заданному источнику и, если такое соответствие будет найдено, то вместо длинного номера, на экране Вашего телефона отобразится знакомое имя вызывающего абонента. Можно также создать небольшой список соответствия имен и номеров в модуле Phonebook. /p> Настройка модуля Перейдём к настройке. Для того чтобы попасть в модуль CallerID Lookup Sources, с главной страницы, переходим по следующему пути: Admin -> CallerID Lookup Sources. Обратите внимание на предупреждение, которое открывается при входе в модуль. Процесс поиска имени входящего абонента (name lookup), который запускает данный модуль, может замедлить работу Вашей IP-АТС. По умолчанию, в модуле уже есть один источник – сервис определения CallerID Name - OpenCNAM. Мы не будем подробно рассматривать данный вариант, поскольку, чтобы им воспользоваться, необходимо иметь аккаунт в OpenCNAM. Рассмотрим, какие ещё источники предлагает данный модуль. Для этого нажмите Add CIDLookup Source, откроется окно добавления нового источника В поле Source Description предлагается написать краткое описание нового источника. В поле Source type выбирается тип источника. От того, какой тип будет выбран на данном этапе, будет зависеть то, где система будет искать соответствие CID входящих вызовов. Рассмотрим каждый тип: internal - Для поиска имени используется база astdb, а для её заполнения – модуль Asterisk Phonebook ENUM - Поиск осуществляется по DNS в соответствии с конфигурационным файлом enum.conf HTTP - Выполняет HTTP GET - запрос , передавая номер звонящего в качестве аргумента, чтобы получить правильное имя Рассмотрим каждое из полей, которое необходимо заполнить при выборе данного источника: Host - IP-адрес или доменное имя сервера, куда будет отправлен запрос GET Port - Порт, который прослушивает сервер (по умолчанию - 80) Username - Логин для HTTP аутентификации Password - Пароль для HTTP аутентификации Path - Путь к файлу для запроса GET. Например, /cidlookup.php Query - Строка запроса, специальный токен [NUMBER], в котором будет заменен на номер необходимого абонента. Например, number=[NUMBER]&source=crm. В случае выбора в качестве источника для поиска сервера HTTPS всё остаётся прежним, за исключением порта. По умолчанию используется порт 443. MySQL - Поиск имени звонящего осуществляется по базе MySQL Рассмотрим каждое из полей, которое необходимо заполнить при выборе данного источника: Host - Имя сервера MySQL Database - Имя базы данных MySQL Query - Строка запроса, где специальный токен [NUMBER], будет заменен на номер необходимого абонента. Например, SELECT name FROM phonebook WHERE number LIKE '%[NUMBER]%' Username и Password для авторизации на сервере MySQL Character Set - Набор символов MySQL. Чтобы оставить набор символов по умолчанию, оставьте это поле пустым Пример работы Internal Для демонстрации примера работы данного модуля, создадим тестовый источник - test_internal. Поиск в нем будет осуществляться по базе astdb, которая заполняется при помощи модуля Asterisk Phonebook. Перейдём в данный модуль и создадим тестовую запись. Теперь, необходимо зайти в модуль Inbound Routes и добавить туда правило проверки входящих CID по ранее созданному источнику test_internal. Готово, теперь, если на номер данного входящего маршрута позвонит 456123789, то на экране нашего телефона мы увидим имя John Doe. Если вы хотите подробнее узнать о настройке входящих маршрутов, почитайте соответствующую статью в нашей Базе Знаний.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59