Атака на 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 :)
Специально для 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)Апокалиписис, нарисованный СМИ ("миллионы карт под угрозой! вас всех похачат!") - отменяется. Дырка имеет очень узкое применение.