?

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 04:07 pm (UTC)
Ух ты! А что с Киевстаром?
29th-May-2014 04:12 pm (UTC)
А чем в данной схеме Киевстар может отличаться от МТС?
(no subject) - Anonymous - Expand
29th-May-2014 05:01 pm (UTC)
В Донецькій області МТС - найросповсюдженіший оператор, може тому?
29th-May-2014 05:57 pm (UTC)
Щито?
29th-May-2014 05:21 pm (UTC)
Исправьте "т.к. ее делал MSC SCP" на "т.к. ее делал MTS SCP".
А так очень доходчиво, да.

Коллега, а разве в Insert Subscriber Data не передаётся информация об аутентификации абонента, которую (предположительно) злоумышленник в Ростове получить не мог?
29th-May-2014 06:36 pm (UTC)
Я запутался :)

У Insert Subscriber Data есть много подвидов сообщений, одно из них - Insert Authentication (но тут используется не оно). Вопрос про это или что-то другое?
(no subject) - Anonymous - Expand
29th-May-2014 06:04 pm (UTC)
хуйня.
вы это из текстов почерпнули или к какому-либо из операторов отношение имеете?
29th-May-2014 06:38 pm (UTC)
Ну, все расходимся ... Говорят, все хуйня. Это вы из текстов почерпнули, или имеете отношение к какому-либо из операторов?
(no subject) - Anonymous - Expand
29th-May-2014 06:09 pm (UTC)
"атака совсем не МТС-специфична" что это значит?
29th-May-2014 06:10 pm (UTC)
А там после запятой разъяснение.
29th-May-2014 06:32 pm (UTC)
Anonymous
А че. Круто. То есть всю приграничную область можно было слушать не напрягаясь ;-) Как я понимаю, несколько "хакерскими" методами было сгенерировано маршрутизирование и перенаправление пакетов внутриукраинской мобильной связи через Россию. Причем Российские узлы не загнулись. Значит заблаговременно было обеспечено достаточно мощностей для обработки траффика... Занятно ;-)
29th-May-2014 06:37 pm (UTC)
Там же траффик от пяти абонентов перенаправили только, а не от всей сети.
29th-May-2014 06:56 pm (UTC)
VLR - это visitor location register, и он содержит информацию об абонентах, которые "посетили" конкретный MSC и попали в зону покрытия, которую этот MSC обслуживает. Как только абонент оказывается в зоне покрытия MSC, информация о нем запрашивается из HLR, складывается в VLR, и живет там, пока этот абонент куда-то не денется (не выключит телефон, не уйдет в другому MSC, ...). Теперь MSC может ходить за информацией об абоненте в VLR -- это быстро, удобно, и снижает нагрузку на HLR-ы.

Хм, я считал, что в пределах одного оператора (страны) во всех MSC храниться одинаковая информация обо всех абонентах оператора, и VLR используется только для абонентов других операторов, это не так?

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

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

Тут больше вопрос не файерволла, а авторизации
29th-May-2014 08:57 pm (UTC)
в GSM/UMTS нет никакой авторизации между сетевыми элементами. Вообще. (только между сетью и абонентом есть). Так уж исторически сложилось.
(no subject) - Anonymous - Expand
ну и бред - Anonymous - Expand
(Deleted comment)
29th-May-2014 09:13 pm (UTC)
Судя по всему, да
29th-May-2014 08:13 pm (UTC)
>В качестве утешительного бонуса у Пети отключается тарификация звонков - т.к. ее делал MTS SCP, который теперь в процессе не участвует.

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

Что интересно, эту же "дыру" в G/U использует вполне себе легальная услуга Virtual Home Enviroment (VHE), которая обеспечивает абонентам в роуминге те же правила набора, что и дома. Например, немец в России так же набирает 0 и 00, а не 8 и 810, русские VLRы этого не одобрили бы, но в них прислана camel подписка этой плаформы (а домашний hlr тоже про нее ничего не знает, слал не он) которая это исправляет на универсальный int формат.

ЗЫ я тут еще подумал. Не факт, что именно SCP Tele2 (и вообще теле2) этим занимался. перехватывать сигналку можно и по пути.

Edited at 2014-05-29 09:05 pm (UTC)
29th-May-2014 09:21 pm (UTC)
Из пока не протухших ссылок:
http://nbnews.com.ua/ru/blogs/122458/
http://sensacii.net/news/907.txt
(Deleted comment)
(no subject) - Anonymous - Expand
(no subject) - Anonymous - Expand
29th-May-2014 09:12 pm (UTC)
Anonymous
Вот неплохо в целом описал, кроме этого:

> Можно, конечно, ставить аналоги файрволов с deep packet inspection на разных уровнях сетевого взаимодействия, и иногда так и делают, но чаще всего - нет.

На кой хрен какие-то там DPI, если авторизация настраивается штатно прямо на MSC? Ну да, у некоторых вендоров это делаетя через задницу... но это же не повод утверждать, что тут инженеры бессильны. Раз уж просрали настройку сети и этим кто-то воспользовался - то не чего стесняться, бывает - не heartbleed всё-таки. Извинились, настроили как надо и дальше работаем.
29th-May-2014 09:24 pm (UTC)
Авторизация между сетевыми элементами?
(no subject) - Anonymous - Expand
ну дык - Anonymous - Expand
29th-May-2014 09:15 pm (UTC)
Anonymous
Блин, а какого-нибудь оригинального документа нету? Если на английском языке, то просто здорово было бы. Мне хочется сослаться на данный инцидент, но сомнительного вида новостной сайт, да ещё и на мове в качестве источника - ну совсем не комильфо.
29th-May-2014 09:23 pm (UTC)
Ээээ. А с чего бы оно было на английском языке? :)

Документ лично для меня выглядит вполне аутентично, даром что слит кем-то этому сомнительному сайту.
слив... - Anonymous - Expand
Re: слив... - Anonymous - Expand
29th-May-2014 10:07 pm (UTC)
Тю, це-ж очевидно: у Ростові-На-Дону - основний криптографічний центр МО РФ.
30th-May-2014 04:36 am (UTC)
Легітимний кріптографічний центр. :D
30th-May-2014 06:56 am (UTC)
Техническое описание нескольких атак по SS7 мы докладывали на конференции Positive Hack Days 4. И дело не в том, что "злой хакер" получит инфу о том, кто кому звонил. Он имеет возможность полностью вклиниться в разговоры абонента.
Кстати, видео доклада тут (атака с подменой профиля абонента примерно в 15:46 по шкале времени):
http://live.digitaloctober.ru/embed/2990#time1400670335
30th-May-2014 07:34 am (UTC)
Видео не проигрывается :(
30th-May-2014 07:31 am (UTC) - Вы ничего не понимаете в сетях, влепили все в кучу
"там записано, что в ходе звонка надо периодически дергать Tele2 SCP, и при исходящих звонках коммутатор MTS MSC будет так и делать"

Это все аццкий бред, как миниму НЕ ПОНИМАНИЕ БАЗОВЫХ ПРИНЦИПОВ этих сетей, что говорить фантастических передачах траффика одного номера на другой?
CAMEL руминг (как и припейд) работает без периодики, VLR ОДИН РАЗ СПРАШИВАЕТ у SCP сколько секунд может поговорить в том направлении абонент и ставит таймер, по исчетении которого или окончании разговора дает запрос на снятие баланса

"В один прекрасный день из сети Tele2 приезжает запрос: "Мы хотим послать Пете смс, где же он?". Сеть МТС Украина говорит: "Так вот же он, возле MTS MSC 1, шлите SMS прямо туда!"."

Еще одно непонимание сетей ГСМ...
Сеть Теле НИЧЕГО НЕ СПРАШИВАЕТ У МТС, она по умолчанию знает на каком VLR ДО ЭТОГО ЗАРЕГИН абонент, по этому SMSC просто берет, никого не спрашивая лупит СМС на MSC в руминге

Что более "ужастно!", так это то, что абонент чайнамобайл, захотел отправить СМС абону Теле, что находится в сети МТС, так СМСЦ спрашивает у HLR TELE где абон, тот отвечает, что на VLR МТС, после СМСЦ чайны тупо лупит СМС напрямую


""Обновите Петины данные, теперь информация о его звонках должна уходить на Tele2 SCP"."

Это фейспалм...
Зачем такое прописывать, если ОНА ВСЕГДА ОБЯЗАНА ТУДА ХОДИТЬ, БЕЗ ИСКЛЮЧЕНИЙ И ДРУГИХ ВАРИАНТОВ?

"Теперь все исходящие Петины звонки маршрутизируются через Tele2 SCP"

1. Звонок НИКОГДА не маршрутизируется через SCP, SCP этого не умеет, этим занимается MSC
2. Без согласия SCP никакой (ни родной ни руминговый) MSC работать не будет, банально траффик не пустит ибо он забесплатно не работает
30th-May-2014 07:49 am (UTC) - Re: Вы ничего не понимаете в сетях, влепили все в кучу
Вы читали как-то впопыхах, похоже...

1)Я не говорю, что домашний scp делает онлайн-рейтинг роумеров (впрочем, поправил фразу, чтобы это было совсем уже очевидно)

2)Когда абонент Tele2 посылает СМС абоненту какой-то другой сети, как так получается, что (по вашим словам) "она по умолчанию знает на каком VLR ДО ЭТОГО ЗАРЕГИН абонент". Уж не хотите ли вы сказать, что сеть Tele2 как-то знает все про всех абонентов на свете? Напомню, что Петя по тексту - абонент МТС, а не Tele2 ... Если что, в этом абзаце речь идет про SendRoutingInfoForSM - расскажите, зачем, по-вашему, оно существует и используется?

3)Касательно "Зачем такое прописывать, если ОНА ВСЕГДА ОБЯЗАНА ТУДА ХОДИТЬ, БЕЗ ИСКЛЮЧЕНИЙ И ДРУГИХ ВАРИАНТОВ?" - Петя абонет МТС, а не Tele2
Page 1 of 2
<<[1] [2] >>
This page was loaded Aug 20th 2019, 3:02 pm GMT.