dump -0f - /dev/mind

Траффик едет в Ростов - отчего, почему?

2014-05-29T14:47:08Z

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

Если коротко, то написано, что российский оператор 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

Шановний абоненте, вас зареєстровано як учасника масових заворушень

2014-01-24T10:12:48Z

Люди, которые находились на улице Грушевского в Киеве двадцать первого января 2014 года, получали странные SMS-ы, в которых сообщалось о том, что они "зарегистрированны как участники массовых протестов".

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

UPD: если у вас есть возможность запросить у своего оператора детализацию событий, посмотрите, если там эти SMS-ы

UPD2: Таки IMSI catcher: http://proit.com.ua/news/telecom/2014/01/24/183526.html

Пишут, что "За пассажирами метро будут следить при помощи SIM-карт"

2013-07-31T15:25:21Z

В российских СМИ пишут, что за пассажирами метро будут следить при помощи SIM-карт (раз и два).

Утверждается, что "... Система будет работать следующим образом, рассказывает начальник оперативного отдела: когда пассажир пройдет в зоне действия датчика — ее радиус около 5 м, — система зафиксирует, что мимо пронесли SIM-карту с определенным номером. Если карта находится в розыске, система автоматически проложит маршрут ее передвижения и передаст информацию на пульт дежурного."

Как же это технически может быть реализовано?

Оттолкнемся от фактов:
1) Мобильный телефон в режиме ожидания почти ничего не передает (исключением являются периодические location update-ы).

2)SIM-карта не имеет непсредственной связи с внешним миром в обход телефона - это не RFID, ей нельзя послать радиосигнал и заставить послать что-то в ответ.

3)Телефон (точнее, baseband processor) реагирует на сигналы от базовых, причем не от всех подряд, а только от базовых текущего выбранного оператора, и только от той, которая является текущей "наилучшей базовой" с точки зрения телефона.

Вырисовывается два потенциальных сценария:
С1 (пассивный): "Датчик" изображает из себя базовую, при попадании в зону ее "покрытия" телефон автоматически выбирает ее в качестве "наилучшей" и тут же посылает location update

С2 (активный): "Датчик" изображает из себя базовую, при попадании в зону ее "покрытия" телефон автоматически выбирает ее в качестве "наилучшей", и базовая тут же посылает адресных или широковещательный сигнал, на который телефон каким-либо образом отреагирует.

"Пассивный" сценарий, очевидно, более интересный - чем проще будет система, тем лучше для ее разработчиков и заказчиков.

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

Получается, что необходимо добится выполнения трех условий:
У1: "Датчик" должен анонсировать себя как базовую, принадлежащую сразу нескольким (всем возможным) мобильным сетям - техически это возможно
У2: Находящиеся рядом с метро базовые GSM-операторов должны включать "датчик" в список соседей
У3: Когда абонент находится рядом с "датчиком", сигнал от датчика должен быть уверенно лучше сигналов от всех прочих соседних базовых

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

Как же сделать так, чтобы телефон сам отсылал в нужный момент информацию о SIM-карте?
Если почитать, в какие момент осуществляется location update, то легко можно выяснить, что он делается сразу после включения телефона (в процессе регистрации в сети), а затем периодически раз в несколько часов или при смене location area.

Базовые станции сгрупированы в location area для удобства работы с ними и уменьшения количества служебного траффика в сети (при входящем звонке поиск телефона происходит в рамках одной location area). Каждая базовая регулярно передает номер своей группы (location area) по широковещательному каналу. Как только телефон при смене "наилучшей" базовой обнаруживает, что новая базовая и старая базовая из разных групп, он тут же делает location update - то есть, по сути, сообщает, что теперь в случае чего его надо искать в другой группе базовых, вот тут.

Получается, что "датчику" достаточно анонсировать себя как базовую, входящую в location area, отличную от всех своих сосдей - тогда телефон автоматически сделает location update, оказавшись рядом с ним.

Начальная фаза процедуры location update выполняется без использования шифрования, что может позволить "датчику" получить IMSI сим-карты (вот тут есть любопытная схема, которая слишком детальна для того, чтобы я ее описывал в этом посте).

А что насчет фразы про выключенные мобильники?

Вот она: "Для полноценной работы датчики должны быть установлены на всех камерах системы видеонаблюдения на станциях, в вагонах метро и вестибюлях, — пояснил Мохов (начальник оперативного отдела УВД на Московском метрополитене). — [...] При этом неважно, включен телефон или нет. Главное, чтобы внутри оставалась SIM-карта."

Тут можно сделать два комментария:
- Наличие в телефоне СИМ-карты действительно критично. Телефон без СИМ-карты будет регистрироваться в произвольной сети в режиме "emergency calls only" и не будет выполнять location update-ы по правилам, описанным выше.

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

UPDATE:
По прошествии суток и после чтения комментариев мне пришли в голову такие дополнительные мысли:

Во-первых, если в метро уже есть покрытие, то с точки зрения оптимизации количества служебного траффика все базовые в метро должны быть выделены в свою отдельную location area, чтобы при переезде от станции к станции все мобильники "сидели тихо" (спасибо dumendil и kzayko). В таком случае велика вероятность, что при входе в метро мобильники оператора, обеспечивающего покрытие, уже делают location update. И если есть "плотные контакты" с оператором, то можно было бы подумать о том, как получать location update-ы с этих базовых.

С другой стороны, это не решает всех вопросов: а что делать с абонентами операторов, у которых нет покрытия в метро? А как отделять location update-ы в этих базовых от всех остальных, происходящих в сети (т.е. к какому элементу сети подключаться "людям в погонах", как фильтровать нужное/ненужное, как сделать так, чтобы инженеры сети и "люди в погонах" не ходили друг другу по ногам и не ломали (пусть даже нечаяно/ненамеренно) процессы друг друга?). Отдельное нечто, что изображает из себя базовую удобнее и для оператора и для людей в погонах.

Во-вторых, если мы говорим о получении данных о SIM-картах, то это точно не NFC и не RFID - в симке нету места для нормальной антены/транспондера RFID, а у NFC - дистанции не те (спасибо zmeuka и neograff)

Атака на SIM OTA апдейты, продолжение

2013-07-24T21:11:18Z

Начало тут.

В этой истории с атакой мне больше всего было интересно то, что атака происходит через SMS. Ведь все мы писали SMS-ы, и видели, что волшебной кнопки "послать как OTA-апдейт" там нету :)

Как же выглядит весь процесс? Ведь входящие SMS-ы принимаются GSM-модулем телефона, потом отдаются симке, и симка должна как-то определить, что этот SMS надо обработать особым образом - а именно, отдать в SIM Toolkit, в ту его часть, которая занимается OTA.

Какие же именно атрибуты SMS-а изменяют заставляют все элементы цепочки вести себя необычным образом? Я немного порылся, и нарыл вот что.

Начинается все с того, что при отсылке SMS-а надо поставить специальные значения в поля Protocol ID (PID) и Data Coding Scheme (DCS). В PID надо указать, что это "Data Download" (0x7f), в DCS - "Binary message" (0xf6). Дальше в тело SMS-а можно пихать команды, и по приходу такого SMS-а сим-карта отдаст его на обработку в SIM Toolkit.

Каждая командна будет включать в себя Toolkit Application Reference (TAR) - число, которое как-то описывает тип сообщения, и позволяет SIM Toolkit-у по-разному реагировать на разные входящие SMS-ы. По сути, указывая определенное значение TAR мы выбираем, какой именно апплет внутри SIM Toolkit получит тело SMS-а и будет его интерпретировать.

Да, кроме этого в самое начало тела SMS-а нужно вставить специальный заголовок (User Data Header, UDH), в котором вставить цифровую подпись (изначально мы ее не можем сформировать, т.к. не знаем ключа) и указать, что мы (отправитель) шифровать не будем, а будем строго подписывать, и понимаем мы только DES и никакие там AES.

А дальше начинаются плохие новости:
1)Оператор может как за нефиг запретить пересылку между абонентами любых SMS-ов с PID и DCS, отличными от "обычных" (0x00 и 0x00 соответственно). И судя по количеству страдальцев (погуглите "sim pid 7f") обычно так и происходит.
2)Более того, оператор может как за нефиг запретить отсылку подобных SMS-ов даже при прямом подключении к его SMSC
3)Про отсылку из другой сети и говорить нечего.
4)Значения TAR по большому счету не стандартизированы. То, какой TAR надо указать, чтобы SMS был передан менеджеру файловой системы (интерпретирующий команды OPEN FILE, READ FILE, STORE FILE) или в менеджер OTA - зависит от производителя SIM-карты и даже в рамках одного прозводителя они не фиксирован. Производители, понятное дело, эти данные широко не афишируют.
5)Отправитель может сказать "я умею только DES и шифровать не буду", но SIM Toolkit может ответить "ну и пошел нафиг, нешифрованные сообщения не берем"
6)Судя по сведениям энтузиастов криптоданные утекают в сообщение об ошибке у меньшенства SIM-ок, преимущественно старых. (Ну, они могут и ошибаться)

Что же делать? Судя по сведениям от тех же энтузиастов, Карстен предлагает обходит пункты 1-3 путем использования fake BTS (т.е. самопальной базовой), в пунктах 5 и 6 надеется, что ему попадется правильная симка, а до пункта 4 дело не доходит, т.к. атака демонстрирует уязвимость механизма цифровой подписи, а конкретное использование остается упражнением на будущее.

Подводя итог, получается, что из всего этого можно соорудить целевую точечную атаку на конкретный SIM, если порядком попотеть: сделать и подогнать в нужное место базовую (или жертву), знать наверняка (или надеяться), что из сообщений об ошибке "протекут" данные, позволящие подобрать ключ для подписи. А дальше надо выяснить заранее, какие значения TAR использовать, и придумать, что бы такое с полученной дырой делать. Можно слить контакты из SIM-ки, или переписать IMSI :)

Специально для arkanoid: можно ли таким образом вытащить из SIM-ки Ki и клонировать? Не думаю. И вот почему - допустим, у нас получится залить на симку свой апплет, зарегистрировать его в таблице TAR-ов и послать ему SMS, "активирующий" его. Дальше нам надо будет выбраться за рамки привелегий, данных Java-рантаймом. Допустим, нам это удалось. Дальше нам надо каким-то образом обойти механизм привелегий операционной системы, в которой крутится Java runtime (да, там есть операционка :). А у нее для операций с "файлами" (блоками байтов в EEPROM) есть интересный набор привелегий: Read, Write и Never, при этом блоки с правами Never не читаются даже ядром или процессами с админскими привелегиями. То есть, надо будет искать и эксплойтить дырку в этой ОС. Учитывая сложность разработки и отладки даже аплетов для JavaCard, в универсальный эксплоит такого уровня верится с очень большим трудом.

Итого, лично мое мнение:
1)Карстен - молодец!
2)Апокалиписис, нарисованный СМИ ("миллионы карт под угрозой! вас всех похачат!") - отменяется. Дырка имеет очень узкое применение.

Атака на SIM OTA апдейты

2013-07-23T21:10:44Z

Привет.

Мне тут пишут про то, что Карстен Нол нарыл очередную дыру (и таки да!). Правда, почему-то присылают при этом бестолковые ссылки типа вот этой.

Так вот, бестолковые ссылки читать не надо. Надо читать либо первоисточник, либо журналистов, которые умеют копать и думать самостоятельно.

Краткое изложение для тех, кому лень читать многабукв.Поскольку я ленив, я не стал перечитывать спеку на JavaCard, и буду вам рассказывать по памяти, рассчитывая на то, что если что - меня ~~закидают шапками~~ вежливо поправят знающие товарищи :)

В современных SIM-картах, в какую не плюнь, есть процессор и память, и как не удивительно - обкоцанная среда исполнения Java. Кому хочется пикантных подробностей - ищите в гугле по словам JavaCard или ходите по ссылкам, которые я давал на pro-gsm. При этом помните, что JavaCard - это не только про SIM-ки, а про все SmartCard-ы вообще (например, кредитки или всякие проездные).

А что же исполняется в этом Java runtime-а? А что, что туда положит заказчик SIM-карты, то есть оператор. Это может быть, например, прикольное или дебильное анимированное меню или "каталог сервисов" или еще что-то подобное.

Единственный канал связи с "внешним миром" у этого софта лежит через телефон, то есть данные можно принимать или отправлять по SMS (в обе стороны), USSD (в обе стороны) или через cell broadcast-ы (только принимать). Вплоть до версии 3 в JavaCard Spec не было возможности открывать сокеты (читай - интернета не было), но в версии 3 интернет таки завезли. Как находящиеся в оборте симки разбиваются по версиям JavaCard Spec, которая в них реализована - мне с наскоку найти не удалось.

Почему я заговорил про каналы связи? А потому, что оператору хочется время от времени обновлять этот софт или закидывать ему какие-то данные. Делается это обычно через каналы связи, которые оператор полностью контролирует - через SMS, реже - USSD или cell broadcast. Почему именно SMS? Потому, что USSD должен инициировать сам пользователь (т.е. нельзя сделать push), а cell broadcast - без обратной связи (непонятно, сколько симок реально обновилось).

UPD: Меня поправляют USSD push таки бывает (но, как я понимаю, не везде).

Чтобы обновить софт, или как-то еще порыться в потрохах симки, оператор отправляет специальный подписанный SMS. Этот SMS перехватывается SIM Toolkit-ом, подпись проверяется, содержимое извлекается и с ним что-то делается.

Так вот, Карстен обнаружил, что можно послать кривоподписанный SMS и получить в ответ сообщение об ошибке, в котором будет криптографически подписанная симкой часть. Если для используется DES, то можно взять его и сломать при помощи rainbow tables и получить в результате правильный секретный ключ. А им уже можно подписать правильный вредоносный SMS и наворотить дел.

Очевидно, что этот способ работает при выполнении определенных условий:
* SIM Toolkit принимает служебные сообщения с произвольного номера ИЛИ есть возможность подставить произвольный номер отправителя
* SIM Toolkit отправляет сообщения об ошибке, в которых есть зашифрованная часть
* Для шифрования используется DES (а не AES или что-то другое)

Из доступных материалов пока непонятно, насколько большую статистику собрал Карстен (и собирал ли). Статья в Форбс утверждает (со ссылкой на него), что атаке подвержено "большое количество" карточек, выпускаемых Gemalto и Oberture. Учитывая объемы этих производителей, даже уязвимость 10% от выпушенных карточек может обернуться многозначными цифрами. Операторы и производители карточек говорят, что на самом деле у них все шито-крыто, и масштабы бедствия сильно преувеличены.

Правы, что характерно, могут быть и те и другие.

31 июля Карстен будет выступать на конференции Black Hat, где обещается демонстрация вживую. Интересно, будут ли в выступлении статистика по кол-ву уязвимых карт и ее обоснование.

UPD: Продолжение

Меряем микрометром, помечаем мелом, отрубаем топором

2012-07-11T10:09:20Z

Дискуссии про то, что можно, а что нельзя сделать определенным техническими средствами очень часто скатываются в унылый срач, в котором стороны по кругу повторяют одно и то же из-за того, что:
1)Технические проблемы обсуждаются на уровне самой простой возможной реализации
2)Фичи и возможности обсуждаются на уровне навороченного сервиса или коммерческого продукта
3)Разрыв в сложности и требованиях к качеству между (1) и (2) одной из сторон напрочь игнорируются.

Чем меньше человек шарит в обсуждаемом, тем больший разрыв между (1) и (2) у него получается, и тем охотнее он его игнорирует.

Что я имею в виду? Перефразируя "Мистический человеко-месяц" Брукса (см. напрмер раздел Tar pit вот тут), разные уровни сложности технического решения можно описать вот так:

Накодили: мы делаем что-то один раз "на колене".
Превратили в практику: мы можем повторить свой успех "на колене" много раз.
Сделали сервис: мы формализовали наш опыт и отгородились от ошибок. Спецификации на исходные данные и результат. Контроль потребления ресурсов.
Сделали продукт: может использоваться человеком с минимальной квалификацией. Документирован. Протестирован. Интегрирован.

(это одна из возможных классификаций, не претендующая на роль единственной истинной)

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

Этот грустный аспект всегда учитывается при рассчете потенциальной отдачи - стоит ли тратить столько-то времени и сил? Какого качества результат мы получим? Оправдывает ли выхлоп усилия? Какой угодно (точнее - best-effort) результат может быть приемлимым или оправданным при однократной деятельности, но если мы ставим что-то на поток - то best effort уже явно недостаточен, более того - он может быть вреден. Типичный пример - изымание жидкостей на входе в самолет, повсеместно практикуемое сейчас.

Попробую проиллюстрировать сказанное на примере из предыдущего поста.

Задача

Оповестить тех, кто находится в зоне (предполагаемого) стихийного бедствия используя возможности мобильной связи.

"Накодили"

Пришла беда, а никакой системы оповещения нет. Допустим, кто-то деятельный из МЧС связывается с оператором и просит помочь. Оператору не пофиг, и происходит что-то такое:
* Кто-то решает: "давайте разошлем СМС!" (для обсуждения именно СМС как средства оповещения есть другой пост).
* Радиопланирование берет зону на карте и выдает базовые, которые ее покрывают
* Эксплуатация базовой сети берет базовые и выдает TMSI/MSISDN тех, кто там делал location update
* Кто-то дает текст SMS
* Эксплуатация сервисных платформ осуществляет рассылку SMS

При этом самым главным элементом процесса будет какой-то технически подкованный сотрудник, который при помощи sed, grep, sql и такой-то матери "заинтегрирует" все этапы процесса: например, возьмет XML, который умеет экспортировать система радиопланеров и выберет оттуда идентификаторы базовых в виде, понятном эксплуатации базовой сети. Возьмет список MSISDN и отделит абонентов других "домашних сетей" (но оставит роумеров). Набросает скрипт, сующий SMS-ы в SMS-центр. Побъет список рассылки на куски, если надо. Посидит рядом, пока он расыслается, устраняя возникающие проблемы.

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

Весь процесс идет в режиме best effort - если получилось, то хорошо; если не получилось - ну, по крайней мере мы старались. При наличии умных инициативных людей на местах реально все сделать за 3-6 часов (большая часть времени уйдет на ожидание и синхронизацию участников). Но вполне реально, что может не повезти - где-то новичок чего-то не знает, где-то кто-то в отгуле и т.п.

"Сделали процедуру"

После первого успеха вместо того, чтобы строить нормальную систему оповещения, кто-то решает "ну, в прошлый же раз как-то справились? давайте так и делать". И вот Оператору вменено в обязанность осуществлять подобные рассылки. Деятельность, описанная выше, становится частью должностных инструкций. Оператор следит за тем, чтобы люди с нужными знаниями были доступны (не ушли вместе в отпуск, имели дублера и т.п.). Новые сотрудники обучаются необходимым навыкам. Вовлеченные технические специалисты пишут на колене скрипты, облегчающие им жизнь (определяющие и устраняющие типичные ошибки). Время от времени проводятся тестовые рассылки. При необходимости (и при возможности) у поставщиков железа заказываются дополнительные API и лицензии.

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

Best effort уже недостаточно. Оператор гарантирует (или его обязывают гарантировать) определенный уровень сервиса - скорость, объем рассылки, время реакции и т.п.

Чтобы создать и отладить этот процесс, потребуется, допустим, 2-6 месяцев (не в последнюю очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).

"Сделали сервис"

После пары факапов или чтобы разгрузить людей Оператор создает или покупает систему, у которой есть API, позволяющее делать такие рассылки сравнительно небольшими усилиями. Одному-двум сотрудникам поручена ее эскплуатация. Система умеет фильтровать большинство типичных ошибок (кривые номера телефонов, сбои при доставке, ...) и ведет себя пристойно с точки зрения потребления разных ограниченных ресурсов (нагрузка на SMS, HLR/VLR, ...).

Чтобы сделать спецификацию на такую систему, разработать или купить и интегрировать ее, потребуется, допустим, 6-12 месяцев (в первую очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).

"Продукт"

Сотрудник МЧС может выделить мышкой область на карте, ввести текст СМС, после чего произойдет рассылка, а он в реальном времени будет видеть ее ход.

Для этого государство в лице МЧС выбирает поставщика (не надо смеяться :), который говорит "СМС-ы?! Да вы все упоролись!" и выкатывает спеку на, допустим, сервис на основе cell broadcast + специфического sim toolkit. Потом поставщик интегрируется с операторами, операторы потихоньку меняют абонентам сим-карты (или через OTA обновляют toolkit), и сервис запускается. Если есть в принципе доступна - сервис будет работать и информировать всех, у кого включен телефон (т.е. качество будет максимально возможным для данной технологии).

Чтобы все это интегрировать и внедрить нужно 6-24 месяцев.

Какие можно из этого сделать выводы?

Рассуждения вида "ну, можно было бы все равно разослать СМС-ы - даже если бы 10% дошло, все равно было бы хорошо" - это best effort, и это справедливо только в случае "пришла беда, откуда не ждали, и мы делаем все возможное и невозможное, чтобы спасти ситуацию". Если же риск или потребность прогнизируемы (а система оповещения, очевидно, необходима), если это не одноразовая работа (а система оповещения, очевидно, не одноразова), то best effort никуда не годится (тем более что есть гораздо более надежные или простые или дешевые альтернативы: cell broadcast, машины с матюгальником, радиоточки, ...).

Да, СМС может быть вспомогательным средством (наряду с фейсбуком, твиттером и прочими слабо подходящими средствами) в какой-то 10 или 15 версии сервиса, но при отсутствии альтернатвных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении. Усилия надо тратить на что-то реально полезное, а не на фигню.

Just saying.

Почему SMS не используют для оповещения населения?

2012-07-10T21:51:03Z

В твиттере smart_haos пишет (после недавнего наводнения в Кубани): "У сотовых операторов есть информация по координатам абонентов. Почему МЧС не умеет использовать этот ресурс для адресных оповещений?"

1)Потому, что SMS - негарантированный сервис. Ни скорость доставки, ни сама доставка - не гарантированы. То, что обычно все доходит быстро - это, грубо говоря, просто "везет". Пока не начались перегрузки сети, например.

2)Потому, что SMS - это не multicast/broadcast. Нет стандартного протокола "взять вот этот текст (1 раз), послать по вот этому списку". Можно только медленно и печально отправлять один и тот же текст раз за разом каждому получателю отдельно. Скорость может быть на уровне 30000 отправленных SMS в час, например.

3)Потому, что координаты абонентов совершенно не факт, что есть. Я про это писал 100500 * 10^6 раз, в очередной раз даже не хочется начинать.

4)Потому, что МЧС не почесался, а на оператора нечего пенять - не операторово это дело.

Если пофантазировать, то можно найти какие-то альтернативы. Есть, допустим, Cell Broadcast, и если сеть позволяет _быстро_ его менять/устанавливать - можно было бы использовать его. Это таки broadcast, и был бы реальный шанс, что он _быстро_ будет увиден кучей народу.

Распознавание и анализ разговоров

2012-07-05T06:45:32Z

В продолжение вчерашней дискуссии.

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

Расскажите мне пожалуйста, что с этими текстами делать потом? (напомню, что мы говорим про Кровавый Режим, который надеется получить с этого какой-то профит).

Суммируя вчерашние аргументы, были названы такие цели:
1)использовать тексты для бинарной классификации (террорист - не террорист, протестующий - не протестующий)
2)использовать тексты для последующего полнотекстового поиска (с целью той же бинарной классификации, но без четких критериев)
3)складировать тексты про запас с тем, чтобы потом читать про тех, кто "попал на карандаш".

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

Классификация
=============
Как учить такой классификатор? Откуда взять training set тех самых true positive целевых разговоров достаточного объема?

У классификатора будут ужасные precision и recall - что с этим делать? Поясню: классы будут сильно перекошены по размеру (1 террорист на пару миллионов обычных людей), соответственно, любые неточности классификации в сумме с false positives приведут к тому, что классификатор будет практически бесполезен. Допустим, мы с вероятностью в 30% не узнаем нужный единственный разговор из миллиона, зато с вероятностью 0.01% тыкаем пальцем в ненужный - посчитайте сами, что мы получим на выходе.

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

Использовать же unsupervised методы, как мне кажесят, не получится из-за размерности простанства. Грубо говоря - у нас слишком много всех возможных слов и разговоров, чтобы какой-то unsupervised алгоритм это прошерстил. Да и на выходе мы получим слишком много классов, которые потом надо будет обработать вручную. Добавим к этому, что почти наверняка нужный "один разговор из миллиона" будет объединен в один класс с мешком других, и получаем на выходе один пшик.

Полнотекстовый поиск
====================

Учитывая, что целевая аудитория (гипотетические "террористы") шифруется, поиск надо будет вести по неуникальным, "бытовым" словам. Любой желающий может поиграть с гуглом и поскать "террористов" там, и увидеть, насколько это безнадежная затея.

Читать постфактум
=================

Казалось бы, какие тут могут быть возражения - бери и читай? Но для начала надо сгруппировать разговоры "по людям", то есть вместо "это разговор между номерами А и Б" получить "это разговор между Ивановым и Петровым", и потом уже читать все разговоры Иванова. При это _надо_ исходить из предположения, что владелец контракта и тот, кто реально говорит по телефону - это могут быть разные люди. Я верю, что подобная задача решается в условиях ограниченного количества людей и аудиозаписей, но для всех-всех-всех разговоров - нереально.

Итого
=====

Вагон затрат (особенно временных), минимальный (неотличимый от нуля) выхлоп. Если бы было социально приемлемо прослушивать всех подряд, из этого вышел бы хороший PR-проект (или, иначе, security theatre) - смотрите, мол, как у нас граница на замке. Ни одна мышь не проскочет - у нас этажи сервером и кубометры винчестеров, всех поймаем. Делать же это втайне, надеясь получить какой-то результат - глупо.

Discuss?

Теория заговора интереса, следовательно она верна!

2012-07-04T08:09:00Z

Забавно наблюдать, как люди стартуют с посылки "Кровавый Режим удаленно включает телефон и СЛУШАЕТ", а когда им начинают задавать вопросы, это превращается в "Ну, может и не включает удаленно, но уж точно внедряет в телефон ЧТО-ТО, чтобы он сам потом включался и передавал".

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

В результате мы говорим про запись разговоров, которую Кровавому Режиму в 100 раз проще вести через СОРМ (и не зависить от того, поменяет субъект свой телефонный аппарат на что-то другое или нет, например). Но теория заговора производителей телефонов и спецслужб гораздо интереснее и привлекательнее. Это же прямо как фильм про Бонда - брутальный агент Кровавого Режима знает 100500 способов удаленного внедрения в firmware любого телефона закладки, которая будет заниматся зверским шпионажем.

Скандалы, интриги, расследования! - снова включение телефона на расстоянии.

2012-07-02T09:09:48Z

Некая мадам olga_andronova (говорят, даже технический редактор где-то там) рассказала, как ей кровавый режим Путина удаленно включал телефон в летящем самолете(!): http://olga-andronova.livejournal.com/170052.html

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

* Свидетелей мобильной связи, работающей в летящем самолете (вышки обычно не "светят" вверх - пофиг! скорость самолета не позволит укладываться во временные рамки TDMA - пофиг!)

* Широкий ассортимент ценителей шапочек из фольги (цитата: "современный мобильный телефон это никакой не телефон. Это небольшая эвм имеющая приемопередающее устройство и способное взаимодействовать с базовой станцией на куда более глубоком уровне чем вам кажется. Иначе говоря специальный протокол не воспроизводит вообще никаких звуковых фаилов, не зажигает экран и попросту не реагирует на ваши нажатия исключая кнопку питания. При нажатие на нее он имитирует включение.")

* Сеанс образцового троллинга со стороны to_the_future: http://olga-andronova.livejournal.com/170052.html?thread=709444#t709444

* Прочие примеры некритического мышления в ассортименте.

Читающие меня люди "в теме" могут сходить и получить нашару немножко LOL-ов.

PS
Я бы ставил на барахлящую кнопку включения.

Кино и немцы: как быстро можно отследить звонок?

2012-05-29T21:35:53Z

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

Это кажется очень нелогичным, не могли бы вы дать комментарий специалиста?"

Мне это тоже кажется нелогичным.

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

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

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

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

Я думаю, что как сформировалось клише где-то до 80-х/90-х годов, так оно и тянется. Опять же, удобный способ нагнетать напряжение: все волнуются, успеют на этот раз "отследить" или опять сорвется? Если снимать "опер запросил распечатку - опер получил распечатку" такой интриги не будет :)

UPD 1: конечно же, надо уточнить, что это в GSM (но не в CMDA и других code-division сетях) базовые работают на разных частотах.

UPD 2: в комментах правильно напоминают про RRLP, но RRLP работает независимо от того, говорят по телефону или нет

Еще раз про запись всех разговоров

2012-05-18T19:25:43Z

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

Для начала текущее положение вещей

Все известные мне законы (я в курсе про Россию-Украину, Евросоюз, UK, страны Балтии) обязывают операторов делать ровно две вещи:

* Хранить (много лет) и предоставлять метаданные о разговорах (кто кому когда звонил)
* По решению суда/прокуратуры записывать разговоры конкретного абонента или предоставлять техническую возможность вести такую запись с момента поступления к ним такого предписания. Список тех, кого слушают, "не резиновый" - нельзя взять и, грубо говоря, запихнуть туда все номера всех абонентов.

Записи разговоров и тексты СМС операторы сохранять не обязаны.

А если все же обяжут?

Если вдруг эти требования ужесточатся, оператору будет:
(1) Достаточно легко начать хранить тексты СМС. Так как SMS-центров мало, они расположены централизовано, SMS мелкий - возможно даже меньше, чем объем метаданных о том, кто кому и как его послал)
(2) Не очень легко начать хранить записи всех разговоров. Так как объемы солидные, коммутаторов много, они могут быть территориально разнесены, потребуется их апгрейд, плюс возможно понадобится пост-процессинг - в процессе разговоров звонки могут "кочевать" по узлам сети, и каждый отдельно взятый коммутатор может "слышать" только часть разговора. Плюс, если вдуматься, у оператора существующая базовая сеть рассчитана на определенную нагрузку. Если начать, грубо говоря, передавать тот же объем данных дважды (пусть и без жестких realtime-требований), то потребуется либо доп. каналы связи (чтобы сразу передавать куда-то в центр и там обрабатывать), либо процессорные мощности и каналы связи (жмем в mp3, а уже потом передаем), или какие-то другие инженерные решения. Естественно, это все решаемые проблемы. Все, что я хочу сказать - задача не сводится к "поставили винт побольше, и всего делов", как это многим кажется на первый взгляд.

А вдруг оператор сам ...?

А вдруг оператор сам хранит эти данные для каких-то своих нужд, и это делается для всех абонентов без разбора?

(3) Это справедливо в отношении метаданных - по ним производится биллинг, то есть определяется объем потребленных услуг и выставляются счета.
(4) Это может быть справедливо для СМС: они могут попадать в какие-то логи на SMS-центре, быть частью бэкапов, и т.п.
* Хранить записи всех разговоров оператору никакой необходимости нет
(5) При этом я вполне допускаю, что в процессе разбирательств с какой-то проблемой оператор вполне может выборочно сохранять как СМС-ы, так и звонки - но, скорее всего, критерием выборки будет не "для вот этих абонентов", а "для вот этого оборудования".

А вдруг все-таки оператор это делает?

Пофантазируем. Может ли все-таки получится, что оператор сохраняет все записи всех звонков? Может, он из этого извлекает какую-то выгоду? Честно говоря, как я ни старался, я не смог придумать подходящего сценария кроме "группа сотрудников вступила в сговор и продает данные криминальным элементам".

Ок, насколько это реально? Проблема в том, что сначала надо эти звонки где-то сохранять. Сделать это "на вот этом сервере вот тут в закутке" - не выйдет, не те объемы (если сохранять всё). Купить для этого отдельно железо - не выйдет, по понятным причинам. Да и потом, технически проще "торговать налево" чем-то, что имеет альтернативное легитимное применение - помогать спаммерам рассылать SMS, занижать суммы счетов, торговать распечатками метаданных или кодами пополнений баланса. И то, для этого, по моим прикидкам, потребуется соучастие не двух, и не пяти и даже не десяти человек в самых разных подразделениях, и подобная затея имеет очень большие шансы на провал даже при том, что можно попытаться сделать хорошую мину при плохой игре ("да мы тут просто ... это ... тестируем ...."). А большой склад записей звонков - это чистый криминал, никаких альтернативных объяснений ему быть не может, и любой безопасник с радостью съест всех замешанных без соли и перца.

А вот моего друга кума говорила, что ей показывали распечатки или записи звонков за 2006 год ...

У меня есть два гораздо более простых (по сравнению с "оператор пишет все") объяснения этому факту. Куму прослушивали в рамках оперативных мероприятий (см. выше), или же ее собеседника прослушивали точно таким же образом.

Для удобства восприятия информация сведена в табличку

	Метаданные о звонке (кто, кому, когда, как долго, в какой соте, ...)	Тексты СМС	Запись разговоров
Обязывает ли закон операторов хранить и предоставлять эти данные для всех абонентов?	Да	Нет	Нет
Если оператора обяжут, легко ли ему будет хранить эти данные в полном объеме?	--	Да(1)	Нет(2)
Обязывает ли закон осуществлять выборочную запись этих данных (по предписанию прокуратуры, ...)	--	Да	Да
Хранит ли оператор такие данные для всех абонентов независимо от требований закона?	Да(3)	Возможно(4)	Нет
Хранит ли оператор такие данные выборочно?	--	Возможно(5)	Возможно(5)

Эшелон записей разговоров

2012-05-16T20:04:58Z

И снова мне пишет Олег: Как понимать тогда: Директиву Евросоюза №2006/24/ЕС «О сохранении данных, создаваемых или обрабатываемых при оказании услуг связи», телефонные компании обязаны хранить не менее полугода все записи всех телефонных разговоров, всех SMS, а также местоположение звонившего начиная с 15 сентября 2007 года." ?

И еще. Что же тогда перехватывает АНБ, Эшелон, ОСНАЗ (станция слежения на Кубе) и пр. ?

Я не знаю, что перехватывает Эшелон, АНБ, станция слежения на Кубе и девочка на шаре :)

Зато Директива Евросоюза 2006/24/EC совершенно свободно доступна в интернете и там в Разделе 5 можно прочитать (дальше мой вольный перевод и выжимка):

Категории данных, подлежащих хранению:

(a) Данные, указывающие источник: имя, номер, адрес абонента (для фикс. связи)).

(b) Данные указывающие приемник/получателя: номер телефона, плюс в случае перенаправлений - номера, на которые было выполнено перенаправление. IMSI и IMEI вызываемого абонента, для анонимного препейда - время и место (CellID) его активации.

(c) Данные, указывающие время и длительность: дата и время начала и конца разговора

(d) Данные, описывающие тип коммуникации: тип сервиса телефонии (возможно, тут имеется в виду что-то типа fullrate/halfrate и т.п., но подробнее это в тексте не объяснено)

(e) Данные, описывающие использованное оборудование: номера обоих абонентов, IMEI и IMSI обоих сторон, дату и место активаци в случае анонимного препейда (не спрашивайте меня, почему это идет отдельным пунктом, и частично повторяет (a) и (b))

(f) Данные, описывающие местоположение: CellID соты, в которой начался звонок, а также ее координаты.

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

Там еще было про интернет-сервисы и email, но это не по теме разговора, и я все пропустил.

Уважаемый Олег, если уж у Вас об открытых источниках такая искаженная информация, то сложно даже представить степень недостоверности имеющихся у Вас сведений о Эшелоне и АНБ :)

Фемтосоты, репитеры и опять про IMSI Catcher.

2012-05-15T21:46:53Z

Эх, давно я не брал в руки шашки и не писал про GSM. А тут как раз в комментариях на pro-gsm.info мне пишет некто Олег: Имеются в продаже так называемые репитеры для организации мобильной связи в местах плохого приема сигнала. Фактически это маленькая базовая станция (промежуточная), которая сама связывается с БС оператора и поддерживает связь с другими мобильными телефонами в радиусе ее действия. Эта БС имеет приемную и передающую часть. Если поднять ее мощность настолько, что ей телефон будет давать предпочтение, то через нее можно запустить работу интересующего абонента. Правда, необходимо находиться в непосредственной близости от жертвы. Возможно ли такое ?

Он же: IMSI перехватываемой SIM-карты можно при желании узнать запустив репитер и анализируя полученные IMSI в процессе некоторого времени слежения.

И вот что я хочу по этому поводу сказать. Тут, мне кажется, мешаются в кучу кони, люди и залпы 100500 орудий. Бывают репитеры, но они не "связываются сами" с базовыми станциями оператора. Бывают пико- и фемотосоты, которые общаются с сетью оператора, но совсем не так, как это предполагает Олег - в частности, они не дают доступ к "сырому" звонку, который можно брать и слушать. В ходе регистрации в сети предъявляется IMSI и выделяется TMSI, но происходит это по уже зашифрованному каналу, и т.д и т.п. Попробуем во всем разобраться.

Репитер, по сути , есть простой ретранслятор + усилитель сигнала. То есть, он слушает указанную базовую(-е) на определенной частоте и ретранслирует с помощью другой антенны на другой частоте сигнал внутрь помещения или другой зоны без покрытия. Сигнал, посылаемый мобильным телефоном, передается в обратном направлении. Для базовой станции сам репитер не виден и не слышен, он себя никак не проявлять.

Фемтосоты же соединяются с сетью оператора вовсе не изображая из себя телефон. Они используют для этого vpn поверх tcp/ip, а уж где вы возьмете этот интернет - это ваше лично дело. Кроме того, в фемтосотах ставят GPS, чтобы абоненты не возили их с собой в роуминг, но речь сейчас не об этом. Ключевой момент - фемтосоты стандарта GSM не делают, только 3G.

Я хочу объяснить, почему репитер или фемтосота не помогут прослушивать мобильный телефон. Я воспользуюсь аналогией, и надеюсь, что никто не станет воспринимать ее буквально, и придираться именно к ней, ок? Если у вас есть возражения - переводите их сразу в терминологическое поле GSM, там и поспорим.

Описание системы

Итак, предположим, что есть на свете что-то вроде банка, который обслуживает людей [как оператор обслуживает мобильные телефоны].

Люди приходят в банк, подходят к окошку у входа, показывают свой паспорт, называют заранее известный банку пароль и получают взамен билетик с номером в очереди и зашифрованную рацию (walkie-talkie) для общения с сотрудников банка. Все рации уникальные и могут связываться только с банковскими сотрудниками [телефон регистрируется в сети, предъявляя IMSI и случайное число, зашифрованное своим Ki, и получает взамен Kc и TMSI].

При этом люди никак не проверяют, кто же сидит в окошке - сотрудник банка или какой-то пройдоха [в стандарте GSM (но не 3G!) телефоны не выполняют аутентификацию базовых].

Дальше люди сидят себе и спокойно ждут, играют в блекджек и общаются с куртизанками :) В какой-то сотрудник банка называет номер с билетика одного из ожидающих [входящий звонок, базовая вызывает телефон по TMSI]. Или же человек сам называет свой номер и общается по рации [исходящий звонок, телефон вызывает базовую]

Так или иначе, человек берет свою зашифрованную рацию и общается по ней с человеком, которого он узнает по голосу [телефон общается с базовой, используюя собственный таймслот и шифруя его с помощью Kc, абонент знает, кому он звонит или кто ему звонит (с какого номера)].

По окончании разговора человек либо уходит [телефон выходит из сети], либо ждет дальше [продолжаем использовать тот же Kc и TMSI], либо опять идет к окошку [оператор генерирует новый TMSI и Kc].

Теперь разберем возможные атаки, а потом поглядим, как нам могут помочь фемтосоты и репитеры. Мы хотим прослушать, что говорит клиент, а для этого мы должны либо сделать так, чтобы он говорил не с банком, а с нами[пресловутая псевдно-базовая, иначе называемая IMSI-catcher], либо записать все, что происходит в эфире, а потом вычленить оттуда сигнал нужной рации, зная номер с бумажки [то есть TMSI] и ключ шифрования.

Атака man in the middle

Мы можем открыть рядом с банком свое окошко по выдаче билетиков с номером и раций. Если к нам придет кто-то доверчивый, то мы легко сможем выдать ему билетик с номером [TMSI], но вот беда - рации "такие как в банке" мы делать не умеем, поэтому выдаем какие-то самопальные [мы не знаем Ki, поэтому не можем сгенерировать у себя Kc. Приходится предлагать телефону регистрацию без шифрования]. Дальше мы можем быстро сбегать в банк и взять там бумажку и рацию для себя.

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

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

Полуактивное прослушивание

Допустим, мы оходимся за конкретным Иваном Ивановым. Мы можем тихо сесть в уголке в банке и наблюдать за ожидающими. Мы не знаем, кому какой достался номер на бумажке [TMSI]. Мы можем ходить в кассу и переводить И. Иванову 1 копейку [посылать обычный или flash SMS] и смотреть, какой номер будет назван [для какого TMSI будет сделан пейджинг]. Дальше мы можем ждать, пока И. Иванов опять будет вызван, записывать все, что происходит в эфире, и потом пытаться подобрать ключ шифрования.

Это то, чем занимается уважаемый Карстен Нол. Читать тут и дальше по ссылкам.

Скрещиваем ужа и ежа
Если мы знаем, где примерно может быть жертва, и не боимся "спалится", то можно с помощью IMSI Catcher-а выяснить его TMSI, а потом слушать эфир. Риски: клиент заметит, что с телефоном "что-то не то", и оператор может поменять TMSI, и придется все начинать сначала.

И как это связано с репитерами или фемтосотами?

Фемтосоту нельзя использовать в качестве IMSI Catcher-а, т.к. фемтосоты только стандарта 3G, а там телефон аутентифицирует базовую, и оператору легко сделать шифрование, которое вы, даже сидя посередине и разобрав фемтосоту, не сможете вот так вот взять и просто слушать - вам нужны будут закрытые ключи симки и операторской сети. Читаем по атаки man-in-the-middle на системы криптографии с открытыми ключами.

Репитер же не дает вам никаких преимуществ по сравнению с простым прослушиванием эфира (хоть и облегчает собственно прослушивание). Выделение TMSI идет по шифрованному каналу, поэтому просто слушать эфир недостаточно - нужно либо активничать, как товарищ Нол, либо использовать IMSI Catcher.

Тут мне могут возразить: но ведь можно же взять репитер и доработать! Ведь можно же взять фемтосоту и что-то там эдакое дизассемблировать! Я считаю, что, как говорят в этих ваших интернетах, "пруф или такого не было". Говорить "а ведь можно ...!" все горазды, а вот взять и сделать ... Плюс, недаром Карстен Нол пошел другим путем - я бы ему в этом вопросе доверял :)

Wideband GSM Sniffing (доклад на 27C3)

2012-01-18T22:51:28Z

Сегодня по пути на работу я посмотрел доклад Karsten Nohl и Sylvain Munaut с 27-го Chaos Communication Congress, также известного как 27C3 (да, я в курсе, что он был чуть ли не год тому назад, но мне было не до грибов :). Видео можно найти тут по словам "wideband GSM sniffing".

Далее - заметки, сделанные в процессе просмотра.

После доклада авторов 26C3 (про который я писал тут) они связывали с операторами, и операторы, помимо прочего говорили - "уязвимости в криптографии - это одно, а вот поди перехвати и запиши все" (я, собственно, писал о том же самом). Тогда, напомню, они собирались показать перехват на практике, но что-то не срослось. Демонстрацию пришлось отложить на год, до 27C3.

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

Для обнаружения местоположения они используют интернет-сервисы, которые дают возможность вбрасывать в сеть SS7 запросы "send routing info". Напомню, что SS7 - это сеть/стек протоколов, которые используются для общения телефонных операторов (GSM и "наземных") друг с другом и для общения компонент сети GSM друг с другом. Тут пока все ОК, сервисы такие натурально есть.

Далее авторы делают интересный финт ушами. Они говорят: а вот в Германии, например, полученное в результате запроса "волшебное число" хорошо коррелирует с area code/zip code. Поэтому мы можем послать такой запрос и понять с точностью до города или даже части города, где в Германии находится этот абонент. Перефразируя классику, надо заметить, что то, что немцу хорошо - русскому смерть :) То есть, никто не обязывает оператора делать именно так, и с Германией им крупно повезло.

Ладно, едем дальше. Они узнали город. Что потом? Потом они берут сниффер (про него отдельно), едут в этот город и начинают "посещать" все его LAC-и (т.е. группы сот, в рамках которых происходит поиск телефона). Приехав на территорию, которая входит в какой-то LAC, они посылают жертве SMS и слушают, идет ли paging телефона жертвы (это происходит по незашифрованному каналу, во всех базовых сразу). Если "клюет" - то они получают сведения о TMSI (temporary IMSI), который был выдан абоненту. Если "не клюет" - едут проверять следующий LAC.

UPD: Совсем забыл рассказать! Поскольку IMSI при пейджинге не передается (и они его не знают), а передается только TMSI (который они и хотят узнать), то производится timing attack. Они посылают несколько SMS-ов с паузами между ними, и смотрят, для каких TMSI производится paging, повторяя процедуру до тех пор, пока в списке "подозрительных" TMSI не останется только один (или ни одного).

Чтобы жертва их "не спалила", SMS посылается не простой, а такой, который не будет показан абоненту (это или специально сделанный flash sms, или кривой-битый SMS, который телефон "прожует и выплюнет", а пользователю не покажет)

Выяснив LAC, они начинают посещать все соты этого LAC, посылать SMS-ы и слушать, отзывается ли кто-то на paging. Если да, то жертва кэмпится вот в этой соте, и можно начинать 1)ломать ее сессионный ключ (Kc) и 2)слушать ее разговоры.

Но для начала поговорим про то, как же записывать происходящее в эфире. Тут было сказано несколько интересных вещей:
1)Существуют делаемые на заказ FPGA-платы, которые способны одновременно писать все каналы либо uplink, либо downlink частот GSM, но стоит такое железо 40-50К, и простому исследователю безопасности недоступно (смех в зале). Карстен упоминает, что не видел готовых устройств, которые используют такое железо, но ведь если его делают - то значит это кому-то же нужно?
2)можно брать менее мощное и более дешевое железо служать часть частот на каждом из них. Можно вписаться в 3.5К EUR с решением на базе USRP2.
3)А можно сначала сломать сессионный ключ, и потом декодировать траффик "на лету" и следовать за frequency hopping-ов при помощи четырех телефонов, в которых вместо родной прошивки - OsmocomBB. Ключевая тема номер один - OsmocomBB допилили до пригодного к использованию состояния как раз за год, прошедший с 26C3 до 27C3, так что я все свои ранние комментарии считаю справедливыми - на тот момент действительно не было практического работающего решения.

Как же они ломают сессионный ключ? Находясь в одной соте с жертвой, они посылают ей SMS, записывают общение жертвы с базовой, и ломают ключ, пользуясь тем, что во время session setup ходит много пакетов полу-пустых или с предсказуемым содержимым. Для ускорения взлома используются rainbow tables. Ключевая тема номер два - на момент 26C3 rainbow tables были не такие модные, и взлом делался отнюдь не за минуты и даже не за десятки минут (авторы, ЕМНИП, упоминают час). То есть, до 27C3 даже у Карстена (основного двигателя прогресса в этой области) не было решения, которое позволяло взломать Kc за приемлемое время (в течении которого, скорее всего, не произойдет rekeying).

Дальше они пользуются тем, что редко кто делает rekeying после каждого звонка или SMS, и сессионный ключ, который они узнали, не будет меняться в течении какого-то времени. Теперь, зная ключ, они могут декодировать зашифрованный траффик к/от жертвы в режиме реального времени, и делать frequency hopping одновременно с жертвой. Для захвата эфира в этом случае реально достаточно четырех перепрошитых телефонов, так как не требуется писать все частоты и даже все таймслоты.

Далее все это было продемонстрировано вживую. Условия, опять же, были слегка тепличные - "жертва" сидела на месте, обслуживалась одной сотой.

Вот теперь я верю, что Карстен Нол действительно может сделать достаточно дешевое/"наколенное" решение для перехвата GSM-разговоров :) (Надо бы пройтись по старым постам, и сделать ссылку сюда).

Традиционно, не обойдется без "но":
1)Эта технология не существует в виде, доступном script kiddies. Есть даже не конструктор, а заготовки для деталей конструктора, которые надо обтачивать и подгонять по месту. В демонстрации неоднократно говорят: "вот это мы еще не зарелизили, и когда зарелизим - непонятно". Т.е. на основании этих наработок китайцы не клепают тысячами устройства за 100 баксов, которые "берут и слушают".
2)OsmocomBB поддерживает только одно семейство чипов. Я не знаю, насколько редки телефоны на этом чипе - похоже, не очень. Но когда-то они кончатся, и придется ждать нового Sylvain Munaut, который расхачит какую-то другую прошивку :)
3)Определение местоположения по запросам к HLR и перебору LAC - это способ, работающий скорее в теории, чем на практике. На практике вы или знаете, где находится жертва физически, или у вас баааальшие проблемы с тем, чтобы попасть в ту же соту, в которой сидит жертва.
3а)Если вы не можете послушать ту же соту, в которой кэмпится жертва - способ не работает.
4)Если жертва перемещается между сотами (кэмпится в разных сотах) - у вас опять проблемы, вам надо быть в той же самой соте
5)Этот способ не подходит для перехвата GPRS
6)Если в сети регулярно происходит rekeying или меняются TMSI (справедливости ради, непохоже, чтобы кто-то всерьез этим занимался), то это способ не работает вообще.
7)Если жертва параноидальна, она может "спалить" процесс ее "нащупывания" и ломания Kc.
8)Слушать кого ни попадя не получится - надо знать номер телефона

С момента окончания 27C3 прошел почти год, и можно бы проверить, зарелизили ли таки весь софт, необходимый для повторения этого эксперимента в домашних условиях кем-то, кто не разбирается в устройстве радиоинтерфейса GSM, но у меня руки не дошли. Никто из читателей не любопытствовал?

Ну, и, как правильно замечают авторы, забороть этот конкретный способ достаточно легко:
1)Вместо константного байта использовать для паддинга пустых GSM-сообщений случайные значения
2)Менять Kc после каждого звонка
3)Менять TMSI как можно чаще

Пунты 2 и 3 должны, по идее, реализовываться простой переконфигурацией элементов сети (не требуют апгрейда прошивок или железа). Было бы желание

На очереди - видео с 28C3 :)

GPS + GSM = RRLP

2011-03-08T07:24:18Z

В комментариях ко вчерашнему посту мне подсказали интересную ссылку: http://security.osmocom.org/trac/wiki/RRLP

Если коротко, то таки есть стандарт на то, как выудить из телефона с GPS его текущие координаты. Сеть даже может прислать телефону набор данных для "быстрого старта" GPS, чтобы определение координат заняло мало времени.

Я попытался найти какие-то данные о том, какие телефоны (или какой их процент) сейчас поддерживает RRLP, но не нашел ничего кроме вот такой ссылки: http://cweiske.de/tagebuch/RRLP%20in%20current%20mobile%20phones.htm . Я не смог посмотреть отчет, на который она ссылается, так что остается поверить на слово: большое кол-во смартфонов с GPS имеют эту "фичу", особенно те, у которых американские корни.

Получается, имея доступ к core-сети или подсунув телефону "ненастоящую" базовую, можно попросить у него его GPS-координаты, и от бодро отрапортует (при условии поддержки RRLP в сети и в телефоне).

Век живи - век учись :)

Про телефоны и иммиграцию

2011-03-07T23:45:59Z

Сегодня я хочу рассказать о том, как я регистрировался в полиции графства Эссекс и о том, как нелегко живется сомалийским террористам в Голландии

У МВД Великобритании есть список стрёмных стран, выходцы из которых - либо террористы, либо носители какой-то заразы, либо и то, и другое вместе. Кроме африканских стран, там находится большая часть экс-СССР и в том числе и Украина.

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

Чтобы не тянуть до последнего, я решил зарегистрироваться на следующий же день. По совету аборигенов я нагуглил телефон местного полицейского участка и позвонил туда. Меня встретил автоответчик, сообщивший, что "все ушли на фронт", и если у меня что-то срочное и неотложное - то надо звонить 999, а если нет - просто оставить сообщение. Я надиктовал свой вопрос, оставил номер телефона и приготовился перезвонить где-то через час-другой.

Через пол-часа мне перезвонила сотрудница из полиции, которая быстро и внятно рассказала, какие мне нужны бумаги, куда с ними надо подойти, договорилась со мной на конкретное время, объяснила, как все будет происходить и дала пару ценных советов, лишь косвенно касающихся моего вопроса. В назначенное время у меня приняли документы, задали пару уточняющих вопросов, за 10 минут сделали мне Certificate of police registration, ответили на все мои вопросы и с улыбкой выпроводили на улицу.

Я, конечно, знал, что местная полиция нифига не похожа на нашу милицию, но все равно остался впечатлен :)

Будем считать, что это была присказка. А сказка будет про вот эту новость о том, как в Голландии поймали сомалийских нелегалов, подозреваемых в террористической деятельности. В новости говорится, что каким-то образом запросила по SMS сведения с GPS-приемников, встроенных в телефоны нелегалов, и таким образом "накрыла" их.

Я по этому поводу думаю вот что: во-первых, полиция Голландии вовсе не заинтересована выкладывать "карты на стол" и объяснять в деталях и подробностях, что и как она делала. Во-вторых, то, что написано в новости - выглядит маловероятным. Сложно поверить, что у всех нелегалов были телефоны с GPS, да плюс к тому в них всех оказался некий "бэкдор" (ведь стандартного-то интерфейса для таких действий нет), позволяющих посредством SMS инициировать включение GPS-приемника, получение координат и их отправку "куда надо", да плюс к тому, с приемом сигнала GPS не было никаких проблем (телефоны не были за 5 слоями железобетона, ...).

Гораздо вероятнее такой сценарий:
1)Легальные сомалийские иммигранты проходят процедуру регистрации, подобную той, что я описал выше.
2)В ходе ее они сообщают государству свой номер мобильного телефона и свой адрес (причем адрес, скорее всего, настоящий - ведь мы пока говорим про нормальных легальных иммигрантов)
3)Через некоторое время в страну тем или иным способом прибывают сомалийские нелегалы
4)Они так или иначе контачат с легальными соотечественниками
5)Когда нелегалы попадают "на карандаш" полиции, то в ходе наблюдения полицейские так или иначе узнают их номера телефонов.
6)Тут у полиции есть два варианта:
а)послать на телефон так называемый "flash sms" (получение которого не отображается телефоном), чтобы телефон выполнил location update для приема этой SMS-ки и у полиции оказались актуальные данные о его местоположении с точностью до соты (при условии что полиция и мобильный оператор хорошо сотрудничают друг с другом и делятся информацией). В условиях города этого может быть достаточно, чтобы убедится, что человек до сих пор находится "примерно тут", а не "ушел огородами".
б)поднять исходящие звонки с этого номера и "потрусить" тех "легалов", кому звонят подозрительные люди - чтобы выяснить, например, где живут/обычно тусуются подозрительные люди.

Если использовать оба варианта, то можно выяснить, где живут/бывают подозрительные люди, и убедится, что все они сейчас "там". После чего - брать и "вязать".

А рассказ про GPS - это, думаю, сознательное или неосознанное упрощение для обывателей, или же вообще плод творчества журналистов.

UPD: похоже, я бы не прав.

Еще про переносимость номера (MNP)

2011-02-03T21:54:55Z

Раз уж я сам не пишу, так буду хоть других рекламировать: http://kzayko.livejournal.com/5407.html

GSM-VoIP гейты и роутинг по А-номеру - реально?

2011-01-27T22:58:17Z

Попал в ситуацию "сапожник без сапог" и буду просить у вас совета :)

Скажите, как у бюджетных GSM-VoIP решений обстоят дела с роутингом по A-номеру и передачей CallerID при форварде?

Я хочу вот чего: найти знакомых (или не очень) людей, которые согласятся вписать мой мобильный номер в свой диалплан так, чтобы звонки с него на входящий номер гейта рулили в указанном направлении по SIP. Use case такой: я беру свою мобилку, ставлю безусловный call forward на номер гейта и уезжаю .. ну, скажем, в подземный бункер, где GSM нет, а VoIP - есть.

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

А теперь расскажите мне, где мои замечательные умозрительные построения разобьются о суровую правду жизни :) И если вы знаете людей, которые готовы предоставить подобный сервис - тоже расскажите.

Возможно ли прослушивание GSM с помощью телефона за $15?

2010-12-31T12:26:37Z

Мне пришла дюжина писем с просьбой прокомментировать выступлиение Karsten Nohl-а на двадцать седьмом Chaos Club Congress (27C3) о том, что им удалось улучшить прошлогодние результаты и прослушать GSM-переговоры жертвы с помощью довольно-таки бюджетного оборудования.

Большинство пишущих ссылаются на пересказ, опубликованный на OpenNet, но там есть мелкие и большие косяки, и я не буду ее использовать (и вам не рекомендую - читайте вместо этого слайды параллельно с новосью в Wired). Вместо этого приборы и материалы будут такими:

Оригинальная англоязычная заметка в Wired
Слайды самого выступления с официального сайта 27C3
Мой пост годичной давности про выступление Карстена на 26C3

Краткое содержание предыдущих серий: на 26C3 Карстен показал, что он сотоварищи достигли успеха в создании rainbow tables для (относительно) быстрого слома A5/1. При этом в области собственно прослушивания эфира и записи коммуникаций между телефоном и базовой сетью у них и конь не валялся.

Весь этот год они, похоже, "валяли коня" и под Новый Год продемонстрировали результат. И он (судя по слайдам) таков:

Зная TMSI (временное IMSI) телефона и находясь в физической близости от жертвы, они умеют выполнять мониторинг GSM-диапазона, обрабатывать frequency hopping (переход телефона и базовой с частоты на частоту, что выполняется часто и регулярно), и писать "сырые" шифрованные данные на диск, чтобы потом ломать их с помощью своих rainbow tables. Это действительно существенный и значимый результат, учитывая стоимость их оборудования.
Способ перехвата не является пассивным. Чтобы получить TMSI, им необходимо находится физически близко от жертвы, посылать ей flash sms-ы (прием которых не показывается телефоном), и мониторить эфир.
Чтобы выяснить, где находится жертва, они используют доступные через интернет службы, которые позволяют произвести HLR interrogation для того, чтобы выяснить очень-очень приблизительное текущее местоположение жертвы. О том, почему этот способ будет фигово работать в наших реалиях, я писал раньше.
Быстрота атаки основана на том, что в определенных служебных сообщениях сети GSM неиспользуемые байты заполняются значением 0x2B, что позволяет сильно уменьшить пространство возможных ключей. Если бы все операторы реализовали принятое два года тому назад предложение по рандомизации этих значений - шары бы не было.
После того, как сессионный ключ единожды сломан, мы можем слушать разговоры жертвы до тех пор, пока не произойдет rekey-инг, или жертва не поменяет TMSI (и при этом тоже произойдет rekey-инг). Если бы перегенерация сессионного ключа происходила после каждой сессии, шары бы опять же не было.

Итого: основное достижение автора, как по мне - это демонстрация готового end-to-end решения для прослушивания, которое работает с очень небольшим (по сравнению с предыдущими наработками в этой области) набором предварительных требований и допущений. С другой стороны, это все еще не те системы прослушивания, которые "показывают в боевиках": все еще нельзя собрать некое устройство, которое будет, как радио, принимать и расшифровывать все переговоры в окрестностях.

Очень хочется посмотреть на видео (когда его выложат), чтобы понять, сколько же им реально понадобилось перепрошитых телефонов для того, чтобы мониторить 1 канал GSM (и, соответственно, как такое решение масштабируется).

Карстен абсолютно правильно указывает на шаги, которые могут быть предприняты, чтобы уменьшить опасность от прослушивающих устройств подобного рода: 1)взаимная аутентификация телефона и базовой (это уже есть в 3G), 2)рандомизация значений, заполняющих пустые байты, 3)более строгие меры безопасности в рамках глобальной сети SS7, особенно в области доставки SMS - чтобы нельзя было легко и запросто делать HLR interrogation кому ни попадя (кое-где гайки закручены уже сейчас).

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

А пока - с наступающим Новым Годом вас всех! Будьте счастливы!

UPD (вытащу из комментариев): Спасибо Александру Чемерису за ссылку на письмо одного из авторов демонстрации, помогающее лучше понять, что же именно они продемонстрировали: http://lists.osmocom.org/pipermail/baseband-devel/2010-December/000912.html

Почему у всех GSM-операторов проверка баланса выглядит как *1xx#?

2010-12-24T09:06:09Z

Чтобы бесполезная информация не загромождала голову, надо делится ею с другими - коллективом мучаться веселее :)

Итак, почему "жизненно важные" функции, которые доступны по USSD (это когда вы набираете на клавиатуре "звездочка-цифра-цифра-...-решетка-позвонить") выглядят у всех операторов примерно одинаково? Проверка баланса - это *100# или *101#, пополнение ваучерами или callback в роуминге - тоже начинается на *1xx, и так далее.

А разгадка простая: как говорит GSM 02.90 (USSD Stage 1) и GSM 03.90 (USSD Stage 2), только USSD-посылки с префиксами *100 - *149 будут всегда и безусловно доставлены в "домашнюю" сеть, где бы абонент не находился. Все остальные USSD-префиксы будут маршрутизироваться "на общих основаниях", т.е., например, как захочет роуминг-партнер.

Поэтому теоретически в роуминге можно "по привычке" набрать что-то вроде *333# и вместо бесплатного сервиса родной сети получить платный от гостевой. Но на практике я о таких проблемах не слышал.

PS
С наступающим всех!

PPS
Специально для предпраздничной пятницы - рождественское развлечение.

Автоматическая отправка SMS на контент-номер

2010-11-23T20:45:23Z

Вопрос из комментариев: "может ли так заглючить БС или телефон? http://gazetaby.com/index.php?sn_nid=32507&sn_cat=35"
Краткое изложение того, что по ссылке: "Абонент компании «Велком» Сергей Сивенков стал жертвой «SMS утечки». Ночью его мобильный телефон с интервалом в 2-5 секунд начал отправлять сообщения на платный номер 5555. За три часа было отослано 938 SMS, в результате чего Сивенков ушел «в минус» на 9 млн рублей. «Паранормальное» явление с ожившей техникой произошло в полтретьего ночи. По словам гомельчанина Сергея Сивенкова, с его 3G модема компании «Велком» сами собой стали отправляться SMS-сообщения. Не понимая, что происходит, парень переставил SIM-карту из модема в мобильный телефон. Однако история повторилась. Один за другим на экране появлялись отчеты о доставке сообщений. Сергей позвонил представителю компании с просьбой заблокировать номер, но общего языка с оператором не нашел.
На логичный вопрос, почему он не достал из телефона SIM-карту, молодой человек теперь отвечает: запаниковал, звонил оператору, ругался, через каждую минуту проверял баланс…"

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

По моему личному опыту, подавляющее большинство случаев единичного опротестования расходов сводятся к "абонент по недосмотру или по глупости потратил кучу денег, а теперь хочет не платить", и я склонен считать, что этот случай - не исключение. Сбои сети обычно влияют на массу абонентов - сотни, тысячи, десятки тысяч, и почти никогда не ограничиваются одним-двумя людьми.

Спонсором дальнейшей части поста является система сборки компилятора GHC :) Пока он собирается, я попробую показать вам, как можно прикинуть, какая из гипотез-объяснений наиболее правдоподобна. По горизонтали у нас гипотезы, по вертикали - факты, на пересечении - информация о том, поддерживает ли факт данную гипотезу, или же опровергает ее.

Судя по суммарнму счету "за и против", лично для меня побеждает первая гипотеза.

PS
Да, и хотелось бы заметить, что цитируемый в заметке "специалист" совершенно очевидно не прав, представляя SIM-карту эдаким пассивным куском электроники. См., например, тут.

	Гипотезы
Факты	Абонент сам отослал СМС-ы (программой), чтобы победить в конкурсе/заработать «симпафок»/купить рингтонов, а теперь отмазывается	Злоумышленники, имея доступ к core-сети оператора, сделали OTA-обновление SIM-карты и разослали SMS-ы с помощью SIM-тулкита	Глючная прошивка телефона и/или залипающие клавиши + абонент отправил первый SMS сам, а потом они начали отправляться «автоматом»	Сбой сети, приведший к тому, что СМС отправлялись «полностью самостоятельно»
За 3 часа — 938 смс	Consistent (примерно с такой скоростью и можно отправлять СМС-ы через AT-интерфейс)	Consistent (примерно с такой скоростью и можно отправлять СМС-ы)	Consistent (примерно с такой скоростью и можно отправлять СМС-ы)	Inconsistent (в SMSC можно вливать SMS-ы с большей скоростью)
Абонент ушел в минус на 9 млн. рублей	Neutral	Inconsistent (для мошенничеств такого типа характерно «взять по чуть-чуть у многих и не палиться», а не «взять много у 2-3 человек»)	Neutral	Neutral
Рассылка СМС началась в 3 часа ночи	Consistent (глупые идеи чаще приходят ночью, чем днем)	Consistent (лучше отсылать СМС-ы ночью, когда абонент спит)	Neutral	Neutral
Владелец сим-карты, судя по всему, в это время не спал	Consistent	Neutral	Consistent	Neutral
Сим-карта изначально стояла в модеме	Consistent (модем проще контролировать программно)	Neutral (тулкиту все равно, где стоит карта)	Inconsistent (сложно представить, что сначала «залип» модем, а потом — телефон)	Neutral
Сим-карта позже была переставлена в телефон	Inconsistent (проще рассылать с помощью модема)	Neutral (тулкиту все равно, где стоит карта)	Inconsistent (сложно представить, что сначала «залип» модем, а потом — телефон)	Neutral
После 938 СМС рассылка, судя по всему, прекратилась	Consistent (сам начал, сам прекратил)	Slightly inconsistent (некруглое число отосланных СМС, некруглый баланс — странно, что «робот» остановился в такой момент)	Inconsistent (рассылка была бы до «победного конца»)	Consistent (зафиксили «сбой», рассылка прекратилась)
СМС отсылались только на один короткий номер, по которому покупается премиум-контент для «Одноклассников»	Consistent	Consistent («робот» отсылает СМС на 5555, контент-провайдер делится с «накрутчиками»)	Inconsistent (удивительно, что залип именно этот СМС — логично предположить, что СМС-ов живым людям у среднего пользователя больше, и вероятность залипнуть на них — тоже больше)	Inconsistent (удивительно, что «залип» именно этот СМС)
Есть минимум еще один пострадавший абонент	Neutral	Consistent	Inconsistent	Inconsistent (был бы либо 1 пострадавший, либо сотни)
В сообщении не упоминаются массовые жертвы, интернет тоже молчит	Consistent (то есть это не «массовый вирус», ...)	Inconsistent (это должно было бы иметь массовый характер)	Consistent	Inconsistent (был бы либо 1 пострадавший, либо сотни)
У второй жертвы СМС-ы уходили на разные номера	Consistent	Neutral	Consistent (вторая жертва могла рассылать СМС-ы самостоятельно)	Inconsistent («встал, упал на нож, и так 18 раз»)
СИМ-тулкит может сам отправлять СМС-ы	Neutral	Consistent	Neutral	Neutral
На видео виден не весь телефон (возможно, он к чему-то подключен)	Consistent	Neutral	Neutral	Neutral
Телефон на видео находится в режиме написания СМС	Inconsistent (для программных рассылок это не нужно)	Consistent	Consistent	Inconsistent (телефон был бы вообще ни при чем)
На видео видно, что телефон рапортует об окончании отправки СМС	Consistent	Slightly inconsistent (как мне помнится, тулкит может подавлять эти уведомления)	Consistent	Inconsistent (телефон был бы вообще ни при чем)
Не видно репортов о доставке смс-ов	Consistent (у людей обычно включены отчеты о доставке, а для программной рассылки они не нужны)	Consistent (у людей обычно включены отчеты о доставке, а для программной рассылки они не нужны)	Inconsistent	Neutral
Если на телефоне нокия нажать семь раз на кнопку меню, отправится смс на первый номер в телефонной книге или истории СМС-ов (в зависимости от модели)	Neutral	Neutral	Consistent	Neutral
За — против	11 — 2	7 — 4	7 — 6	1 — 7

UPD: Пишут, что таких абонентов прибывает. Если это действительно так, и пострадавших наберется хотя бы с десяток - то я бы поменял свое мнени в пользу версии с SIM Toolkit-ом.

Отключение ciphering indicator ("замочка" на экране телефона)

2010-11-18T22:30:15Z

Когда я последний раз писал про IMSI catcher, я упоминал, что не смог найти в спецификациях 3GPP подтвержения того, что SIM-карта может запретить телефону показывать, что он находится в режиме шифрования A5/0 - то есть без шифрования вообще. Оказалось, что это действительно возможно.

Другими словами, сим-карта может запретить аппарату показывать пресловутый разомкнутый "замочек" на дисплее тогда, когда шифрование радиоканала отключено. Благодаря записи в блоге OpenBTS (который я всячески рекомендую), я узнал, что я, оказывается, искал информацию совсем не там.

Правильный номер спецификации - GSM 02.07, и в ней написано (Normative Annex B.1.26), что сим-карта содержит специальный бит OFM в поле Administrative Data (в elementary file "EF_AD"), который, будучи взведенным, приведет к запрету индикации "замочка".

В GSM 11.11 написано, что права доступа к этому полю следующие: чтение доступно всегда, а права на запись описаны как "ADM". Если мне не изменяет склероз, это означает, что конкретный набор прав, регулирующих запись в это поле, задается операторо на этапе создания (читай - заказа) сим-карт.

Получается (возвращаясь к докладу про IMSI Catcher-ы, который я комментировал в предыдущем посте на эту тему), что, со слов докладчика, в США большая часть карт выпускается с взвденными битом и телефоны у них действительно не показывают замочки при отключении шифрования.

Это действительно существенно облегчает работу IMSI Catcher-а (т.к. его больше нельзя "спалить" за 10 секунд), но не меняет моего отношения к IMSI Catcher-ам в целом. Также рекомендую почитать вот этот интересный тред, если вы его еще не видели.

А вот кому Nokia 1100 за $520? Налетай, подешевело!

2010-08-29T20:48:56Z

Возможно, вы еще помните, как я пренебрежительно отзывался о новостях о том, что неустановленные личности покупают Nokia 1100 за 25K EUR. В то же время, на прошлой неделе мне прислали ссылку на любопытный bid на EBay: Nokia 1100 за $520.

Это, конечно, не 25000 EUR, но все равно на два порядка выше нормальной цены такого б/у телефона. Неужели все-таки в невероятных историях о том, что с помощью этого чудо-телефона можно "ломать" чужие банковские счета, есть толика правды?

Поглядим на историю ставок: сразу бросается в глаза странное поведение пользователя "s***e", который неоднократно перебивал свои же собственные ставки, и практически единоручно взвинтил цену до финальных $520. Чтобы у вас не было сомнений, что это действительно один и тот же пользователь - вот история его ставок по этому bid-у. Этот пользователь действительно сделал 22 ставки, торгуясь преимущественно сам с собой.

Мне лично вывод кажется очевидным: продавцом искусственно создается видимость ажиотажа в надежде на то, что кто-то "клюнет" и поставит еще больше. У меня не сильно большой опыт покупок на ebay, но я не удивлюсь, если узнаю, что это "общепринятая" практика, а не персональное изобретение данного конкретного продавца.

А что думаете вы?

Очередные новости про IMSI Catcher

2010-08-02T08:49:04Z

За сегодня пришло сразу два вопроса с просьбой прокомментировать http://gizmodo.com/5601826/this-1500-system-can-intercept-your-cellphone-calls (перевод-перепевка: http://ko.com.ua/51423).

Комментирую:

Автор собрал IMSI Catcher. Что это такое - я уже писал (см. например http://www.mobile-review.com/articles/2009/imsi-catcher.shtml). Там же описаны ограничения и недостатки такого устройства. Об одном из них прямо пишут на gizmodo - абоненту нельзя доставлять входящие звонки и SMS. В сетях 3G IMSI Catcher не применим (из-за двухсторонней процедуры аутентификации телефона и базовой), а в сетях 2G его работу можно вычислить по ряду признаков (см. ссылку выше)
Собрать такое устройство за $1500 - это, несомненно, круто.
Надо понимать, что условия для демонстрации были тепличными: imsi catcher, как я понял, был единственной базовой в диапазоне GSM-900, расстояние до телефонов было менее 100 метров, не было помех, не было проблем с организацией backhaul-а до родной сети AT&T (хоть при помощи проводной, хоть при помощи беспроводной технологии), не было задачи вычленить и "сопровождать" один конкретный телефон-цель, не было (как я понимаю) задачи обрабатывать frequency hopping и handover-ы и т.п. То есть, до серьезных применений этот конмплекс надо еще пилить и пилить. Сейчас это proof-of-concept.
Самый большой вопрос - это отключение индикации того, что телефон работает в режиме A5/0 (то есть без шифрования). Как я уже писал в http://users.livejournal.com/_adept_/102375.html, "докладчики утверждают, что SIM-карта легко может запретить телефону показывать, что он работает в режиме шифрования A5/0 (т.е. без шифрования вообще) и что большинство SIM-карт в обороте - именно такие. [...] Я не дам зуб, что этого сделать нельзя, но тщательное грепанье текста GSM 11.11/GSM 11.14/GSM 03.20 (и более новых их версий для 3G) не дает даже намеков на подобную функциональность. [..] Мне кажется, что товарищи несколько преувеличивают. Кто может прокомментировать?". Пока я продолжаю придерживаться мнения о том, что ему сильно везет с телефонами, на которых он экспериментирует, или же это какая-то локальная особенность телефонов для американского рынка.

Подводя итоги: IMSI Catcher - это не "прослушивание всего и вся" и не "конец света". Надо понимать, что у него есть куча ограничений и недостатков. С другой стороны, если авторы реально нашли способ подавлять индикацию работы в режиме A5/0, то практическая полезность IMSI Catcher-а резко возрастает.