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

_adept_

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

Jul 24, 2013 22:11

Начало тут.

( Поговорим подробнее про волшебный SMS )

Comments 37

arkanoid July 24 2013, 21:17:21 UTC

Зная общую леность разработчиков, я сомневаюсь, что механизмы защиты JCRE ими считаются недостаточными и на все остальное не забили сто лет назад. Разве что такие же карты делают для NSAшных спецприложений и руку сбивать неохота.

_adept_ July 24 2013, 21:27:54 UTC

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

arkanoid July 24 2013, 21:31:18 UTC

ну так вот не факт, что в JCRE нет дырок, позволяющих это обойти.

_adept_ July 24 2013, 21:32:44 UTC

Сорри, вместо JCRE прочитал вначале JRE

kaa July 24 2013, 21:20:28 UTC

а как же аркеной кредитными-то картами пользуется? ;-)

dil July 24 2013, 21:27:24 UTC

А там дополнительные приложения не предусмотрены и джавы вообще нет ;)

dmarck July 24 2013, 22:48:05 UTC

а вот не факт, кстати. другое дело, что простому пользователю об этом вряд ли сообщат ;)

dil July 25 2013, 09:23:18 UTC

Ну даже если туда удастся что-нибдуь лишнее залить, у кредитки, в отличие от телефонной карты, нет телефона, чтоб сливать данные наружу :)

Thread 14

dil July 24 2013, 21:26:34 UTC

Свою собственную SIM-карту можно засунуть не в телефон, а напрямую в программатор, и скармливать в неё что угодно, и ответы читать напрямую. Никакую базовую станцию имитировать не придётся. Правда, придётся эмулировать телефон, но это, пожалуй, попроще будет, вроде есть даже opensource'овые реализации.
Универсальный эксплойт, конечно, очень маловероятен, но под конкретные карты можно попробовать. Есть шанс, что производители не предусматривали специальной защиты данных от приложений внутри карты. Надо проверять.

_adept_ July 24 2013, 21:37:47 UTC

Судя по том, что пишут в JavaCard spec ("Applet Isolation and Object Sharing", "Applet Firewall", "Method invocation across contexts" - сорри, на вебу этого нет, но отдается с сайта оракла по поиску "javacard spec") шары нету :(

arkanoid July 25 2013, 07:02:38 UTC

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

elfadmin July 25 2013, 07:03:57 UTC

Только Оракл застенчиво не уточняет, что механизмы эти неявно предполагают что апплет прошел верификатор, который для javacard ВНЕШНИЙ т.к. на самой карте ресурсов для такой работы просто не хватает. Если действительно есть возможность загрузки произвольных аплетов - нету особой проблемы выбраться из sandbox т.е. можно получить плюс минус доступ ко всему что доступно JCRE. Хотя так на вскидку как вытащить ключи я не вижу, но я и не криптограф.

Thread 6

dmarck July 24 2013, 22:46:29 UTC

Sorry for nitpicking, но всё же привилегии ;)

qwe13 July 25 2013, 05:18:12 UTC

>3)Про отсылку из другой сети и говорить нечего.

не особо вижу варианты на каком оборудовании эти вх. смски будут анализироваться.

komarov July 25 2013, 08:31:26 UTC

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

qwe13 July 25 2013, 09:25:31 UTC

SMSC получателя не участвует в доставке вх. SMS сообщений. Абонент оператора А отправлят смс абоненту оператора Б, то смски проходят через SMSC-А, а в SMSC-Б они в общем случае не попадают.

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