Подпишись

* Вы будете получать самые интересные новости Украины

Трендовые новости
18 Апр 2021

Blog Post

Все рубрики

Траффик едет в Ростов, или абоненты МТС на прослушке | Everyday in Ukraine 

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

Если коротко, то написано, что российский оператор Rostov Cellular Communications (он же Tele2) сделал что-то такое эдакое, после чего звонки ряда украинских абонентов (МТС Украина) маршрутизировались … через узлы сети Tele2. Это – как минимум – дает Tele2 полные метаданные о звонках (кто, кому, когда, как долго, …), а как максимум – позволяет слушать исходящие звонки.

Справедливости ради надо сразу сказать, что атака совсем не МТС-специфична, и могла случится с любым другим оператором.

Как же это стало возможно?

Как всегда, в тексте много упрощений и аналогий, вся инфа взята из публичных источников (в частности, GSM 29.002).

У любого оператора есть база данных об абонентах, называемая HLR. Еще у любого оператора есть коммутатор, называемый MSC. Задача коммутатора – направлять входящие и исходящие звонки правильным элементам сети (в том числе – сети другого оператора), чтобы их там дальше обрабатывали.

Для того, чтобы маршрутизировать звонки, MSC периодически нужны данные из HLR:

Эта картинка – неправильная))

Как часто бывает с техническими решениями, на практике все сложнее: во-первых, коммутаторов в сети обычно много. Во-вторых, абоненты одной сети могут оказаться в зоне покрытия другой сети (роуминг), и тогда MSC надо будет обращаться к HLR-у, находящемуся черти-где (на другом континенте, например). То есть, каждый MSC обращается к куче HLR-ов, и соответственно каждый HLR отвечает на запросы кучи MSC и весь этот обмен сообщениями легко пересекает границы разных сетей:

Чтобы несчастные HLR-ы не загнулись под потоком запросов, и чтобы MSC не страдали от задержек к HLR-ам на другом континенте, в стандарт GSM были введены такие себе “кэши” данных об абонентах под названием VLR:


VLR – это visitor location register, и он содержит информацию об абонентах, которые “посетили” конкретный MSC и попали в зону покрытия, которую этот MSC обслуживает. Как только абонент оказывается в зоне покрытия MSC, информация о нем запрашивается из HLR, складывается в VLR, и живет там, пока этот абонент куда-то не денется (не выключит телефон, не уйдет в другому MSC, …). Теперь MSC может ходить за информацией об абоненте в VLR — это быстро, удобно, и снижает нагрузку на HLR-ы.

Но что делать, если информация об абоненте в HLR обновилась? Надо же каким-то образов обновить информацию и в VLR. На этот случай предусмотренно служебное сообщение (которое в документе по ссылке называется SAI_DN). HLR отправляет это сообщение нужному VLR-у, и тот обновляет у себя данные об абоненте.

Еще в сети оператора бывают такие себе “сервера приложений” под названием SCP (Service Control Point), на которых реализуются вещи вроде real-time биллинга, переносимости номеров, телефонные голосовалки и проч. В сведениях об абоненте будет записано, на каких фазах звонка коммутатор должен отдать управление SCP, и к какому именно SCP надо обратится:

Как видите, на картинке есть стрелка между “MTS MSC” и “Tele2 SCP” – казалось бы, зачем она? А вот зачем: допустим, абонент Tele2 уехал в роуминг в сеть МТС Украина, и у этого абонента есть сервисы, которые реализуются SCP: автоматическая трансляция набранных номеров в правильные международный формат, мгновенный обсчет стоимости интернета или что-то там еще. Когда абонент в домашней сети, Tele2 MSC общается с Tele2 SCP, который выполняет все необходимые действия (уменьшает баланс абонента, транслирует номера в начале соединения и т.п.).

Когда же абонент находится в роуминге, происходит вот что: данные об абоненте приезжают из Tele2 HLR в MTS VLR, там записано, что в ходе звонка надо в определенные моменты дергать Tele2 SCP, и при исходящих звонках коммутатор MTS MSC будет так и делать, и Tele2 SCP будет по-прежнему исполнять все необходимые для реализации сервиса функции (ну, или почти все. желающие гуглят и читают про CAMEL roaming).

Как видите, архитектура глобальной сети GSM подразумевает, что узлы разных сетей могут обращаться друг к другу. Если МТС и Tele2 имеют договор о взаимном подключении к сетям друг друга, то это как правило означает, что HLR-ы, MSC и SCP одной сети могут общаться с элементами другой сети и наоборот. Можно, конечно, ставить аналоги файрволов с deep packet inspection на разных уровнях сетевого взаимодействия, и иногда так и делают, но чаще всего – нет.

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

Есть такой себе абонент МТС Украина – назовем его Петя. О Пете есть запись в MTS HLR, там написано, что все Петины звонки должны отправляться на MTS SCP. Петя звонит, звонки обслуживаются MTS SCP (напрмер, считаются деньги за звонки), все счастливы.

В один прекрасный день из сети Tele2 приезжает запрос: “Мы хотим послать Пете смс, где же он?”. Сеть МТС Украина говорит: “Так вот же он, возле MTS MSC 1, шлите SMS прямо туда!”. Однако никакого СМС-а Пете никто не посылает, а вместо него в MTS VLR 1 присылается сообщение SAI_DN, в котором говорится: “Обновите Петины данные, теперь информация о его звонках должна уходить на Tele2 SCP”.

Петины данные, хранящиеся в MSC VLR 1, обновляются! Это выглядит странно, почему вообще такое возможно? Проблема в том, что обычно сеть Tele2 обновляет таким образом информацию о своих абонентах, но с точки зрения стандарта ничто не мешает обновлять таким же образом данные других абонентов. Стандарт не требует проверять, обновляет ли другая сеть данные о своих абонентах (см. выше про файрволы, но тут их, похоже, не было).

Теперь все исходящие Петины звонки маршрутизируются через Tele2 SCP, который может делать с ними что угодно – просто записать, кто кому звонил, или же отправить “голосовой канал” через оборудование для записи разговоров. В качестве утешительного бонуса у Пети отключается тарификация звонков – т.к. ее делал MTS SCP, который теперь в процессе не участвует.

Если Петя выключит телефон или перейдет к другому MSC, то “перенаправление” на Tele2 SCP исчезнет, т.к. из HLR будут считаны исходные неизменные данные о Пете. В этом случае манипуляции с выяснением адреса VLR и заменой информации о SCP придется произвести заново.

Желающие могут предложить свое объяснение тому, почему оператор-манипулятор – в Ростове, почему это произошло именно сейчас и кто эти люди, звонки которых поехали на чужой SCP?

_____________________________________

Автор: _adept_

Картинки: everyday.in.ua

_____________________________________

Так же на эту тему есть развернутая статья более профессиональным языком на Хабрахабре

Публикуем ее сразу тут для удобства читателя:

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

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

Если коротко, схема такая. Атакующий внедряется в сеть сигнализации SS7, в каналах которой отправляет служебное сообщение Send Routing Info For SM (SRI4SM), указывая в качестве параметра телефонный номер атакуемого абонента А. В ответ домашняя сеть абонента А посылает атакующему некоторую техническую информацию: IMSI (международный идентификатор абонента) и адрес коммутатора MSC, который в настоящий момент обслуживает абонента.

Далее атакующий с помощью сообщения Insert Subscriber Data (ISD) внедряет в базу данных VLR обновленный профиль абонента, изменяя в нем адрес биллинговой системы на адрес своей, псевдобиллинговой системы.

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

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

Сразу скажу скептикам: схема эта не фантастична и, как можно видеть, вполне реализуема на практике. При разработке системы сигнализации SS7 в ней не было заложено механизмов защиты от подобных атак. Подразумевалось, что сама по себе сеть SS7 довольно закрытая, и «чужой» попасть туда не может. Однако времена меняются, и мы с вами становимся свидетелями злонамеренного использования технологий телефонии. К сожалению, нельзя просто так взять и включить фильтрацию сообщений SS7 из внешних сетей, поскольку это повлияет на работоспособность услуг в роуминге. А ни один оператор не хочет лишать себя доходов.

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

Что делать

Не плохо было бы закрыть так называемые «уязвимости» в стеке протоколов SS7, но любой специалист вам скажет, что это нереально. Классический случай «это не баг, это фича».

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

  1. Провести тестирование на проникновение в SS7-сети.
  2. Одновременно организовать мониторинг сообщений сигнализации на периметре сети оператора всеми доступными средствами.
  3. Проанализировать полученную информацию и принять меры для минимизации рисков.

Тесты на проникновение

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

  1. Проверка на раскрытие конфиденциальных технических параметров: IMSI абонента; адрес коммутатора MSC, где абонент зарегистрирован; адрес БД HLR, где хранится профиль абонента. Зная эти параметры, злоумышленник будет иметь возможность проводить более сложные атаки.
  2. Проверка на раскрытие данных соты, обслуживающей абонента. Зная идентификатор соты, злоумышленник может определить местонахождение абонента. В условиях городского покрытия местонахождение абонента может определяться с точностью до десятков метров.
  3. Проверка на возможность нарушения доступности абонента для входящих вызовов (DoS на абонента). В случае успешной атаки абонент-жертва перестает получать входящие вызовы и СМС. При этом мобильный аппарат жертвы показывает наличие сети. Такое состояние абонента-жертвы продержится до тех пор, пока абонент не совершит исходящий вызов, не переместится в зону действия другого коммутатора или не перезагрузит телефон.
  4. Проверка на раскрытие частной СМС-переписки. Данная атака является следствием атаки номер 3. В случае успешной атаки входящие СМС начинают приходить на оборудование злоумышленника, прочитать их не составит труда. Чтобы СМС не была доставлена получателю впоследствии, в СМС-центр отправляется уведомление о получении.
  5. Проверка манипуляции USSD-командами. В случае успешной атаки злоумышленник получает возможность отправлять USSD-команды от имени абонента. Возможный ущерб будет определяться набором сервисов, которые предоставляет оператор по USSD (к примеру, тем, есть ли возможность с помощью USSD-команд переводить средства между счетами абонентов).
  6. Проверка возможности подмены профиля абонента в VLR. В случае успешной атаки злоумышленник получает возможность задействовать свое оборудование в качестве интеллектуальной платформы для расширения возможностей голосовых вызовов и манипуляций с тарификацией.
  7. Проверка на возможность перенаправления исходящих вызовов. Является продолжением атаки 6. В случае успешной атаки злоумышленник получает возможность перенаправлять исходящие голосовые вызовы абонента-жертвы. Кроме того, атака позволяет злоумышленнику устроить конференц-вызов, несанкционированно «вклинившись» в разговор.
  8. Проверка на возможность перенаправления входящих вызовов. В случае успешной атаки злоумышленник получает возможность перенаправлять входящие голосовые вызовы, предназначенные абоненту-жертве. Кроме того, звонки по направлениям с высокими тарифами могут либо не тарифицироваться, либо плата за вызов будет начисляться абоненту-жертве.
  9. Проверка устойчивости коммутатора к DoS-атаке. В случае успешной атаки коммутатор перестает обрабатывать входящие вызовы на абонентов, находящихся в зоне его действия.
  10. Проверка возможности прямых манипуляций с биллингом. В случае успешной атаки злоумышленник получает возможность опустошения персонального счета, таким образом лишая абонента возможности осуществлять вызовы.

Как защититься

Наши исследования показали, что подавляющее большинство атак в сетях SS7 начинаются с получения технических данных об абоненте (идентификатор IMSI, адреса коммутатора MSC и БД HLR). Эти параметры получаются из ответа на то самое сообщение SRI4SM, которое упомянуто в начале статьи.

Одним из решений безопасности является процедура SMS Home Routing, предложенная организацией 3GPP в 2007 году. Иногда ее называют SMS Firewall или SMS-фильтр.

В сеть оператора внедряется дополнительный узел, обеспечивающий фильтрацию злонамеренных сообщений SRI4SM. Принцип его работы заключается в следующем. Когда в сеть оператора приходит сообщение SRI4SM из другой сети, оно перемаршрутизируется на новый фильтрующий узел. Этот узел отправляет нормальный ответ, выдавая в качестве адресов коммутатора MSC и БД HLR свой адрес, а в качестве IMSI абонента — фальшивые данные. Если сообщение SRI4SM было сгенерировано злоумышленником, то он в ответе не получит никакой полезной информации, и его атака захлебнется еще на первом этапе. Если же сообщение SRI4SM было началом легальной транзакции для отправки СМС-сообщения, то сеть отправителя передаст это СМС-сообщение на фильтрующий узел, а он уже, в свою очередь, доставит сообщение адресату внутри своей домашней сети.

Прошло 7 лет с момента выпуска этой рекомендации, но, как мы видим, до сих пор далеко не все операторы запустили такое решение. И к слову, сообщение SRI4SM это не единственный способ получить IMSI абонента.

Вместо заключения

Сеть оператора мобильной связи, как и любая другая, является потенциально уязвимой. В силу специфичности сетей мобильной связи атаки в них могут носить более изощренный характер, чем атаки в сети Интернет. Мы рекомендуем проводить мероприятия для защиты таких сетей по традиционному сценарию: пентест с выявлением проблемных мест, аудит безопасности с установкой рекомендуемых настроек, периодическая проверка настроек безопасности в соответствии с шаблоном. Это минимальный объем работ, который поможет поднять уровень защищенности сети чуть выше плинтуса, но в качестве первого шага этого достаточно. Абонентам будет спать спокойнее.

P. S. Во время форума Positive Hack Days IV мы делали доклад о возможных атаках в сетях операторов мобильной связи, в котором коснулись прослушки телефонных разговоров практически из любой точки Земли.

________________________________________
Видео: live.digitaloctober.ru/embed/2990#time1400670335

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

Авторы: Сергей Пузанков и Дмитрий Курбатов, исследовательский центр Positive Research.

Хабрахабр

Related posts