?

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 
29th-May-2014 06:35 pm (UTC)
С Киевстаром теоретически это должно работать так же хорошо.
29th-May-2014 06:46 pm (UTC)
На самом деле защититься можно сконфигурив MAP Policing, думаю, что операторы уже озаботились. Но это мы сейчас такие умные.
29th-May-2014 08:06 pm (UTC)
И где же его конфигурить? Это довольно-таки непростая фича. Скажем, на AXE (которые MSC/VLR) нельзя это сделать (насколько я знаю, если в последних версиях не сделали). На STP (если он есть, выделенный) - наверное да, в зависимости от разных условий. И ведь применять эти проверки придется ко всему трафику, что прибавит нагрузки.
в общем, универсального решения нет, но придумать можно много чего.
меня больше удивляет, как нашли. в тексте об этом ничего нет.
29th-May-2014 08:18 pm (UTC)
Anonymous
Кто ищет тот всегда найдет)) Хороший анализатор сигналки SS7 позволяет найти любой фрод. Жалко, что не удалось обнаружить этот трафик раньше.
29th-May-2014 09:10 pm (UTC)
На АХЕ есть Generic Message Screening and Rerouting - стандартная опциональная фича года с 2010/11. Рост нагрузки там не настолько критичный.
Как нашли и правда интересно. Возможно, антифрод что-то заметил.
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 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, но не для абонентов МТС-Украина, а для своих, которые приехали в роуминг
30th-May-2014 04:44 pm (UTC)
у КС есть SMS Home Rerouting. + они ещё в давние времена были замечены в блокировании SRI-SM от левых СМСЦ (те, которые в IR.21 не прописаны).

SMS Rerouting скрывает IMSI и текущий MSC абонента. MSC ещё с горем пополам найти можно перебором, но с IMSI всё сложнее.
30th-May-2014 05:35 pm (UTC)
Касательно IMSI - банальный SRI, который уж точно всегда работает, его возвращает.

Касательно VLR GT - он же есть в Location Info в Any-Time-Interrogation / Provide-Subscriber-Info, которые в CDR'ы не пишутся. Хотя конечно если оператор это мониторит, то запрос ATI/PSI из какой-то внешней сети вызовет ну очень серьезное подозрение - это всё же не обычный SRI-SM, он вообще не должен "снаружи" приходить. Правда, если оператор мониторит SS7, то наверняка он её и скринит, и всё равно что ATI/PSI, что SRI_SM не пройдёт. А так - "папитка - не питка, таварищ Берия". :)

Edited at 2014-05-30 05:36 pm (UTC)
30th-May-2014 06:10 pm (UTC)
SRI от левого GMSC? Очень сомнительно, чтобы HLR отвечал на такие запросы из чужих сетей.

PSI абсолютно нормальный запрос для inbound roamers. Т.е. мониторить надо с разбором МАП-части и выискивать там свои MCC/MNC - задача не очень интересная и затратная.
Опять же, не зная IMSI его не отправишь.

ATI вам ничего не вернет. Во-первых это доп.фича, за которую вендор просит денег и не у всех оно активировано. Во-вторых, ваш GT обязательно должен быть в списке разрешенных SCP.
30th-May-2014 06:34 pm (UTC)
Кхгм, да, чё-та я про SRI протупил. :)

Но всё же по IMSI атакующего всегда может спасти человеческий фактор - у любого приличного оператора к связке MSISDN-IMSI имеет доступ несколько тысяч человек, и для конкретного интересующего MSISDN наверняка можно будет купить IMSI за разумные для атакующего (имеющего доступ к SS7 - это явно не любитель с нетбука за $200) деньги. Хотя конечно это не технический способ. :)

C другой стороны - если оператор принимает ISD по своему абоненту с чужого "HLR", то можем рассчитывать, что он и SRI с PSI не скринит. Ну а скринит - значит, не взломали. Краем уха из источников близких к минеральным :) слышал я, что КС SMS AntiSpoof имеет (прощай, SRI_SM) , а вот скрининга пару лет назад вроде не было...
30th-May-2014 06:47 pm (UTC)
Я не очень минеральный и тем не менее выше вполне отчётливо заявил, что есть у КС SMS Home Rerouting. Можно его и AntiSpoof называть и СМС-фильтр.

А ещё в 2008м году мне жаловался далёкий оператор, что после запуска нового SMSC, он на КС не доставлял сообщения. решилось всё после переписки с КС и обновления IR.21. Так что некое подобие скрининга (если я правильно понимаю о чем вы) у них имелось давно.

Насчёт связки IMSI-MSISDN, то там далеко не пару тысяч человек. Хотя если посчитать представителей вендоров, то может столько и насобирается. Я бы за 200$ точно продал бы пару IMSI )))

Edited at 2014-05-30 06:48 pm (UTC)
This page was loaded Jun 17th 2019, 2:41 pm GMT.