?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
Траффик едет в Ростов - отчего, почему? 
29th-May-2014 03:47 pm
Смотрите, какой интересный документ. В нем много технических терминов без объяснения и канцелярита, поэтому попробую рассказать своими словами.

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

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

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

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

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

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

+---+   +---+
|HLR|-->|MSC|
+---+   +---+


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

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


+---------+   +---------+
|Tele2 HLR|-->|Tele2 MSC|
+---------+   +---------+
         `--,
            v  
+-------+   +---------+
|MTS HLR|-->|MTS MSC 1|
+-------+   +---------+
       `----,
            v
            +---------+
            |MTS MSC 2|
            +---------+


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


+---------+   +---+---------+
|Tele2 HLR|-->|VLR|Tele2 MSC|
+---------+   +---+---------+
         `--,
            v  
+-------+   +---+---------+
|MTS HLR|-->|VLR|MTS MSC 1|
+-------+   +---+---------+
       `----,
            v
            +---+---------+
            |VLR|MTS MSC 2|
            +---+---------+


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 надо обратится:


+---------+   +---+---------+   +---------+
|Tele2 HLR|-->|VLR|Tele2 MSC|-->|Tele2 SCP|
+---------+   +---+---------+   +---------+    
         `--,                     ^ 
            v                     |
+-------+   +---+---------+-------'
|MTS HLR|-->|VLR|MTS MSC 1|----,
+-------+   +---+---------+    v
       |                     +-------+
       |                     |MTS SCP|
       |    +---+---------+  +-------+
       `--->|VLR|MTS MSC 2|----^
            +---+---------+


Как видите, на картинке есть стрелка между "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.

The End
Comments 
30th-May-2014 05:43 am (UTC)
ну вот я что-то не придумаю сходу, что же надо закрыть и как.
просто добавить в черный список ряд адресов не достаточно.
ISD может прилетать вообще от любого GT, оно одностороннее.
Запретить ISD для своих MSISDN(IMSI) от не своих GT?
Запретить IDP от своих MSISDN на не свои GT?
что-то сомневаюсь, что это на AXE VLR реализуемо.

И тут еще нюанс - так можно защитить своих абонентов в домашней сети. Если они будут в роуминге, в VLR третьей стороны, кто их там прикроет?
30th-May-2014 08:54 am (UTC)
Ну самое тупое - для начала ограничить SRI for SM только от SMS центров (хотя не 100% защита, если оператор-партнёр задействован в атаке, да). ISD для своих MSISDN от не своих GT как раз с помощью Generic Message Screening and Rerouting и делается. IDP, наверное, нет.
30th-May-2014 10:17 am (UTC)
узнать, в каком VLR абонент, не так уж сложно, можно и не слать SRI for SM.
варианты:
-реально послать SMS, при этом проснифить ответ
-Если абонент не скачет по всему миру, как ДжБонд, то он все время в одном-двух VLR-ах. Для мегаполиса - 3-4. В Москве, возможно, 10-15, но это он должен опять же активно скакать везде.
-Ничто не мешает пихнуть ISD во все GT VLR атакуемой сети, их немного. Там, где этого абонента нет, ничего не случится (ну разве что disturbance счетчик щелкнет). В реальной сети столько мусора носится, что вряд ли заметят.
30th-May-2014 10:45 am (UTC)
В общем, да, можно и пофлудить на все коммутаторы. Но ISD как раз вполне реально скринить на том же АХЕ по MSISDN и GT.
30th-May-2014 09:14 am (UTC) - Screening conditions control
Anonymous
Проблема в том, что критерии срабатывания скрининга не позволяют
проверить все необходимые критерии, например, не находится ли данный
абонент в настоящий момент действительно в роуминге. Screening по статическим условиям типа, по GT или PC не поможет.
Ведь при условии выезда абона в роуминг, ISD в домашнюю сеть со стороны
принимающей сети - это совершенно естественное действие.
30th-May-2014 10:40 am (UTC) - Re: Screening conditions control
HLR Теле2 может слать ISD, но не для абонентов МТС-Украина, а для своих, которые приехали в роуминг
This page was loaded Aug 25th 2019, 10:55 pm GMT.