Очерк безопасности SIP

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

    Одним из решений этой задачи является протокол SIP (Session Initiation Protocol). Это протокол с интересной историей, но сейчас мы коснемся только некоторых его особенностей. SIP — это протокол установления сеанса для последующей передачи данных; передает информацию в открытом виде. Среди данных могут присутствовать учетные данные абонента — логин, домен, пароль (в открытом или хешированном виде), а также многие другие интересные поля. Отметим, что в некоторых случаях аутентификация может отсутствовать вовсе (соединение настраивается на обоих сторонах как пара IP:port). Рассмотрим несколько угроз, возникающих при использовании протокола SIP, и способы эти угрозы реализовать.

    image

    Угрозы


    Перейдем к анализу нехороших штук, которые можно делать с помощью протокола. Отметим, что для реализации некоторых атак злоумышленник должен находиться на пути трафика от клиента до сервера (или организовать MITM-атаку).

    Кража учетных данных


    Поскольку протокол передает данные в открытом виде, любой, кто имеет возможность «слушать» идущий от нас трафик, может узнать много всего интересного. К примеру, возьмем процесс аутентификации. Пароль в SIP хэшируется с использованием MD5, который, во-первых, уже давно настоятельно не рекомендуется к использованию вообще нигде, а во-вторых, может быть подобран (например, с помощью SIPcrack). Выглядит это примерно вот так:

    image

    Полученные учетные данные могут использоваться в различных интересных схемах. Если жертва является клиентом услуг Triple Play, злоумышленник может получить доступ ко всем сервисам, на которые подписан абонент. Что намного опаснее — полученный SIP-аккаунт может использоваться в мошеннических схемах с PRS-номерами, а также для прогона большого количества звонков по дорогим направлениям (суммы, которые абоненту придется заплатить за чужие разговоры, могут быть весьма и весьма значительными).

    Поподробнее о подборе SIP-пароля: www.sipsorcery.com/mainsite/Help/SIPPasswordSecurity

    Прослушка


    Сам по себе SIP звук не передает. Для передачи полезной нагрузки (например, аудиопотока) используется протокол RTP (Real-time Transport Protocol). Протокол дружелюбен и не шифрует передаваемые данные. Тут немедленно возникает вопрос: не может ли человек, который сидит посередине и «по-дружески» прослушивает наш трафик, — прослушать и наш разговор? Вполне. Например, используя популярный в народе Cain, который не только любезно поможет осуществить MITM, но и сразу даст послушать перехваченный разговор. Полученную таким образом информацию очевидно можно использовать с целью шантажа или шпионажа.

    image

    Отслеживание звонков


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

    Атака за NAT’ом


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

    Подобное часто встречается в бизнес-центрах: множество небольших фирм проходят через NAT местного провайдера.

    image

    image

    Как видно на картинке, в пришедшем к провайдеру пакете находится IP-адрес вызывающей стороны еще до трансляции (NAT), но это поле при установлении соединения не проверяется (проверяется белый IP-адрес), и там может быть как адрес легитимного абонента, так и адрес злоумышленника.

    Выдача себя за провайдера (с помощью DNS)


    Путем атаки на DNS-сервер клиента с помощью MITM-атаки или отравления кэша DNS (например, с помощью Kaminsky attack) злоумышленник может выдать себя за провайдера, проводя все звонки через свою систему.

    image

    Перенаправление звонков


    Осуществив атаку типа MITM, злоумышленник имеет возможность перенаправлять звонки клиента на произвольный номер, в том числе на несуществующий (приводя к DoS).

    image

    Перехватывая INVITE-пакеты, злоумышленник отвечает на запрос пакетом с кодом 301 Moved Permanently, перенаправляя звонок.

    image

    Разрыв соединений


    Злоумышленник, зная или подбирая поля CallID, FromTag, ToTag, имеет возможность разрывать активные сессии, отправляя заранее сформированные зловредные пакеты, содержащие SIP BYE-request (запрос на завершение соединения), например с помощью scapy.

    image

    image


    Ложные вызовы


    Так как SIP чаще всего использует протокол UDP, возможны различные спуфинг-атаки. Например, можно сгенерировать кучу запросов с вызовом абонента-жертвы. Это приводит к отказу в обслуживании АТС жертвы, парализуя всю систему телефонии.

    image

    Заключение


    К сожалению, несмотря на то, что давно существуют методы защиты от большинства перечисленных угроз, все участники рынка — как операторы (что самое печальное!), так и их клиенты, — активно игнорируют меры безопасности. Поэтому watch your back — провайдер за тебя не подумает!

    Автор: Илья Сафронов.
    Метки:
    Positive Technologies 167,96
    Компания
    Поделиться публикацией
    Комментарии 28
    • +1
      К счастью уже сто лет в обед есть и всеми поддерживается secure sip, а связка SRTP+TLS снимает большинство проблем безопасности цифровой телефонии (кроме человеческого фактора).

      Недавно как раз тоже исследовали безопасность железной АТС на базе астериска — в последних билдах уже практически никакие атаки на SIP не действуют, кроме спама инвайтами на конечные аппараты пользователей.
      • +1
        Да какое там всеми? Провайдера, дающего городской номер с поддержкой SRTP+TLS очень поискать надо. Но чаще номер привязан к конкретному провайдеру и выбирать вообще не из чего.
        • 0
          Нынче поднять свою PBX на астериске не сложнее, чем винду переставить и подключить к ней то, что дает провайдер, но на вход выставив пресловутый secure sip.
          • 0
            А что делать если провайдер secure SIP не поддерживает? А он обычно не поддерживает.
            • 0
              Заводить в Asterisk обычный SIP от провайдера, а на участке Asterisk-Client использовать TLS+SRTP.
              • 0
                Asterisk-Client и так внутри LAN, там особо опасаться нечего. А трафик через внешнюю сеть между астериском и провайдером по прежнему будет нешифрованный.
                • 0
                  Так в статье большинство проблем уровня LAN, а проблемы небезопасного обмена информацией в Интернет — это уже не уровень телефонных воров, это уже проблемы государственного масштаба (коррупция, слежка, низкая ответственность сотрудников телекоммуникационных компаний).
                  • +1
                    Вот прослушка со стороны органов (и конкурентов) обычно куда опаснее чем прослушка внутри собственного LAN.
                    • 0
                      Тогда рецепт простой — удаленный максимально далеко Asterisk анонимно подключенный к SIP-провайдеру и линки SRTP+TLS до него от клиентов. Задача только в качественной реализации, доверии к исполнителю и соблюдении всех мер предосторожности.
            • 0
              Построить с провайдером, например, ipsec туннель.
      • 0
        Когда поднимал свой SIP, то из популярных звонилок, кроме последней версии Bria, добиться поддержки SSL не удалось больше ни от кого.
    • 0
      совсем недавно стали жертвой СИП-телефонии.
      У нас стоял голосовой шлюз для городских телефонов прямиком в Интернете с белым ip.
      Провайдера просили фильтровать наши логины по нашему ip
      Но в итоге в субботу ночью через провайдера телефонии попер огромный международный трафик.
      Об этом узнали только в понедельник. Итог счет на 225+т.р. за международку.
      Ожидаем судебную тажбу.
      • 0
        Для исключения подобных атак единственный эффективный способ — заблокировать префикс 810.
        • +2
          будите смеяться, но я 810 заблокировал на самом шлюзе.
          А по факту они звонили подключаясь напрямую к сип-прокси из Палестины.
          • 0
            «Провайдера просили фильтровать наши логины по нашему ip» если на бумаге зафиксировано то это уже не ваши проблемы.
            • 0
              просил, но на бумаге не зафиксировал
              • 0
                Зря не зафиксировали. Провайдеру теперь ничего не докажешь. Вот похожий случай (http://ain.ua/2013/10/10/497317), чем там закончилась история неизвестно, но все шло к тому что виноват конечный пользователь, не обеспечивший безопасность своей АТС.
              • 0
                А хотя бы переписка в электронке сохранилась? Или это все было устно?
                • 0
                  сохранилась, но толку… по договору айпи телефония вобще не фигурирует.
                  • 0
                    а на каком основании Вам тогда предоставляли услуги? о_О
                    • 0
                      на основании договора местной телефонной связи.

                      Не могу всем ответить, т.к. лимит на 1 комментарий в час.
                  • 0
                    Я, конечно, не специалист в гражданском праве, но имхо вам стоит посоветоваться с грамотным юристом на тему того, не получится ли съехать, зацепившись за эту переписку. Прецеденты, когда суд принимал письма из электронной почты как доказательство, уже бывали.
                    • 0
                      тут вопрос кто на кого в Суд подавать будет. Должны то мы РОСТЕЛЕКОМУ. А сами телефоны подключены от ООО «Местный провайдер». И каким образом мы долг в Суде против нас от РОСТЕЛЕКОМА на основании электронной почты скинем на ООО «Местный провайдер». По поводу долга есть на что списать, т.к. услуга оказана не нам, то и оплачивать мы ее не должны.
      • 0
        Если FXS шлюз — Linksys spa8000 — то трафик пролили через него, и звонки прошли с вашего адреса. Есть уязвимость у них.
        Для spa8000 один вариант, убирать за nat.
        • 0
          Все подобные железки надо убирать за NAT. По-хорошему, в интернет должна смотреть только IP-PBX с жестким ограничением доступа по IP только для транков провайдеров, а вся внутренняя телефония, если сеть распределенная, должна ходить по VPN с запретом регистрации извне. Либо, если внешние клиенты необходимы, опять-таки по возможности делать ограничение по адресам или подсетям, и пользоваться fail2ban либо его аналогом.
      • 0
        Был у меня похожий случай — с год назад делал одну задачу по телефонии на астериске фирмочке из Украины, так они FXO шлюз D-Link DVG-7111 на белый адрес повесили. Мне-то что, предупредил о возможных последствиях — сказали, мол, временно. Когда сдавал работу, предупредил их еще раз, чтобы убрали шлюз во внутреннюю сеть от греха подальше. Ну а далее классика жанра — «временное» стало постоянным, шлюз взломали «кубинские телефонисты», назвонили бедолагам на пару-тройку килобаксов. А поскольку шлюз был воткнут в аналоговую телефонную линию, то отпереться им не было никакой возможности. В итоге они выгнали своего местного админа, который забил на рекомендации по безопасности.
    • 0
      Еще можно слушать rtp в ulaw&alaw кодеке WireShark, для g.729 есть Hammer.
    • 0
      >Ложные вызовы
      Что за такой интересный провайдер на последней картинке, который дает возможность слать инвайты без какой-либо авторизации?

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое