![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Атака на SIM OTA апдейты, продолжение
Начало тут.
В этой истории с атакой мне больше всего было интересно то, что атака происходит через 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)Апокалиписис, нарисованный СМИ ("миллионы карт под угрозой! вас всех похачат!") - отменяется. Дырка имеет очень узкое применение.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Но всё равно это не означает, что туда можно загрузить дополнительный софт.
Upd: https://www.blackhat.com/us-13/briefings.html#Brown