![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovНачало тут.
В этой истории с атакой мне больше всего было интересно то, что атака происходит через 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 :)
Специально для![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
arkanoid: можно ли таким образом вытащить из SIM-ки Ki и клонировать? Не думаю. И вот почему - допустим, у нас получится залить на симку свой апплет, зарегистрировать его в таблице TAR-ов и послать ему SMS, "активирующий" его. Дальше нам надо будет выбраться за рамки привелегий, данных Java-рантаймом. Допустим, нам это удалось. Дальше нам надо каким-то образом обойти механизм привелегий операционной системы, в которой крутится Java runtime (да, там есть операционка :). А у нее для операций с "файлами" (блоками байтов в EEPROM) есть интересный набор привелегий: Read, Write и Never, при этом блоки с правами Never не читаются даже ядром или процессами с админскими привелегиями. То есть, надо будет искать и эксплойтить дырку в этой ОС. Учитывая сложность разработки и отладки даже аплетов для JavaCard, в универсальный эксплоит такого уровня верится с очень большим трудом.
Итого, лично мое мнение:
1)Карстен - молодец!
2)Апокалиписис, нарисованный СМИ ("миллионы карт под угрозой! вас всех похачат!") - отменяется. Дырка имеет очень узкое применение.
В этой истории с атакой мне больше всего было интересно то, что атака происходит через 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)Апокалиписис, нарисованный СМИ ("миллионы карт под угрозой! вас всех похачат!") - отменяется. Дырка имеет очень узкое применение.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2013-07-24 09:17 pm (UTC)(no subject)
Date: 2013-07-24 09:27 pm (UTC)(no subject)
Date: 2013-07-24 09:31 pm (UTC)(no subject)
Date: 2013-07-24 09:32 pm (UTC)(no subject)
Date: 2013-07-24 09:20 pm (UTC)(no subject)
Date: 2013-07-24 09:27 pm (UTC)(no subject)
Date: 2013-07-24 10:48 pm (UTC)(no subject)
Date: 2013-07-25 09:23 am (UTC)(no subject)
Date: 2013-07-25 12:49 am (UTC)(no subject)
Date: 2013-07-25 06:52 am (UTC)(no subject)
Date: 2013-07-25 08:47 am (UTC)(no subject)
Date: 2013-07-25 09:31 am (UTC)(no subject)
Date: 2013-07-25 12:51 pm (UTC)(no subject)
Date: 2013-07-25 12:55 pm (UTC)(no subject)
Date: 2013-07-25 01:25 pm (UTC)(no subject)
Date: 2013-07-25 01:27 pm (UTC)(no subject)
Date: 2013-07-25 08:49 am (UTC)(no subject)
Date: 2013-07-25 09:21 am (UTC)Но всё равно это не означает, что туда можно загрузить дополнительный софт.
Upd: https://www.blackhat.com/us-13/briefings.html#Brown
(no subject)
Date: 2013-07-24 09:26 pm (UTC)Универсальный эксплойт, конечно, очень маловероятен, но под конкретные карты можно попробовать. Есть шанс, что производители не предусматривали специальной защиты данных от приложений внутри карты. Надо проверять.
(no subject)
Date: 2013-07-24 09:37 pm (UTC)(no subject)
Date: 2013-07-25 07:02 am (UTC)(no subject)
Date: 2013-07-25 07:03 am (UTC)(no subject)
Date: 2013-07-24 09:40 pm (UTC)(no subject)
Date: 2013-07-24 10:01 pm (UTC)(no subject)
Date: 2013-07-24 10:46 pm (UTC)(no subject)
Date: 2013-07-25 05:18 am (UTC)не особо вижу варианты на каком оборудовании эти вх. смски будут анализироваться.
(no subject)
Date: 2013-07-25 08:31 am (UTC)(no subject)
Date: 2013-07-25 09:25 am (UTC)ну я немного поспешил, я думаю наверное есть вариант блокировать трафик на STP в связке с какими нибудь антифорд системами, но интересно узнать мнение более знающих специалистов, есть ли в них возможность такого глубокого анализа.
(no subject)
Date: 2013-07-25 08:46 am (UTC)(no subject)
Date: 2013-07-25 09:21 am (UTC)(no subject)
Date: 2013-07-26 10:04 pm (UTC)Практика показывет, что вот как раз это проконтролировать и сложнее всего :)
Оператор не может запретить отсылку себе каких-то специфичных СМС из другой сети и, как правило не может контролировать доставку (если работает "по ГОСТу").
ЕМНИП, контроль этих параметров если и ведется, то на СМС-центре.
А "чужие" СМСки туда не попадают.
Многие, конечно, начали фильтровать межсетевой трафик всякими аналогами DPI
для семерки, но даалеко не все.
(no subject)
Date: 2013-07-31 09:05 am (UTC)(no subject)
Date: 2013-07-31 07:53 pm (UTC)но дальнейшую мысль я не уловил.
Новое, прекрасное
Date: 2013-07-29 09:42 am (UTC)Вы не могли бы прокомментировать техническую реализуемость?
Особенно в части выключеных телефонов.
Re: Новое, прекрасное
Date: 2013-07-31 03:25 pm (UTC)(no subject)
Date: 2013-07-30 06:47 pm (UTC)(no subject)
Date: 2013-07-31 03:25 pm (UTC)