 |
eXeL@B —› Основной форум —› Взлом криптографии при обмене данных с устройством |
| . 1 . 2 . >> |
| Посл.ответ | Сообщение |
|
|
Создано: 04 ноября 2018 12:36 · Поправил: Vamit · Личное сообщение · #1 Введение в тему: Имеется система сервер-программа-устройство клиент, все они общаются друг с другом криптованными данными. Поток данных сервер <-> устройство проходит транзитом через программу с перепаковкой, сами данные при этом не изменяются. Потоки данных сервер <-> программа и программа <-> устройство полностью изучены, возможно посылать им криптованную информацию и получать на неё ответы. Прямой доступ есть только к коду программы, остальные две стороны - черные ящики. Схема начала криптообмена сервер-программа: - import openssl_key to rsa_key (openssl_key short 140 bytes) - create symmetric CBC key for cipher AES128 with random IV (16 bytes) and const pseudorandom key (16 bytes) - encrypt RSA key: in const pseudorandom key with random prng to SHA256 for rsa_key - отправка криптованного ключа на сервер Таблица векторов IV у клиента(программа) фиксирована 16 * 16 байт, другая информация на сервер не передается, далее идет только крипт/декрипт пакетов. Схема начала криптообмена программа-устройство: - import openssl_key to rsa_key (openssl_key long 609 bytes) - устройству дается команда, на которую оно высылает encrypted RSA key (128 bytes) - decrypt RSA key to hash SHA256 from rsa_key - create symmetric CBC key for cipher AES256 with const IV and decrypted RSA key Таблица векторов IV в программе фиксирована 16 * 16 байт и отлична от таблицы векторов для сервера, другая информация на сервер не передается, далее только крипт/декрипт пакетов. Эти схемы привел только для того чтобы было понятно какие крипто алгоритмы задействованы. Задача: декриптовать данные в потоке обмена данных с устройством. В этом случае имеем следующее: - инициатором криптообмена всегда выступает устройство - первый пакет данных на сервер состоит из двух частей фиксированной длины, первая часть постоянная размером 11 байт (её структура: 1ый байт 01, далее 8 байт назовем как серийный номер устройства, т.к. у разных устройств эти данные отличаются, 10-11 байты 0080), вторая часть пакета размером 448 байт уникальна для каждого сеанса криптообмена - сервер всегда отвечает на первый пакет от устройства даже если этот пакет был подменен и взят от старого сеанса связи - ответ сервера имеет фиксированный размер 384 байта, но информация в ответе уникальна для каждого ответа - на отправленный 2ой пакет от старого сеанса связи сервер уже не отвечает Вопрос: возможно ли на основе этих данных вычислить symmetric CBC key для потока данных сервер <-> устройство? ----- Everything is relative...  |
|
|
Создано: 04 ноября 2018 12:50 · Личное сообщение · #2 Я правильно понимаю, что этап "create symmetric CBC key" повторяется для каждой сессии и уникален между сессиями? ----- EnJoy! |
|
|
Создано: 04 ноября 2018 13:11 · Поправил: Vamit · Личное сообщение · #3 Jupiter Думаю что да, в приведенных схемах программа эти действия выполняет однократно, но запуск программы тоже можно считать сеансом работы. Причем если программа дает reset устройству, то CBC ключ генерится заново, аналогично и с сервером, если сделать его тест или новое подключение к нему, то CBC ключ генерится и посылается на сервер. Так что получается что symmetric CBC key уникален для каждой сессии с каждой стороной, аналогично, как я думаю, будет и при обмене сервер <-> устройство. В пределах же установленной сессии может передаваться в обе стороны Nое кол-во криптопакетов. ЗЫ: В схеме сервер-программа create symmetric CBC key for cipher AES128 with random IV (16 bytes) and const pseudorandom key (16 bytes) - тут нет рандомности, это random IV написано не совсем корректно, т.к. это константный вектор, но не из таблицы векторов. И для разных сеансов связи с сервером генерится всегда константный symmetric CBC key. В схеме программа-устройство create symmetric CBC key for cipher AES256 with const IV and decrypted RSA key - генерится из принятого от устройства декриптованного хеша SHA256, хеш после декрипта всегда разный, значит и symmetric CBC key для каждого сеанса программа-устройство будет уникальным. ----- Everything is relative... |
|
|
Создано: 04 ноября 2018 13:26 · Личное сообщение · #4 В таком случае я бы искусственно фиксировал некий "бесконечный" MiTM-сеанс с условным "бесконечным" количеством блоков открытых и шифртекстов, благодаря чему можно было бы более свободно реализовывать атаки на собственно шифр, применяя все доступные способы, включая внедрение в открытый и шифртекст. И вот тут важный момент: если проверяющая сторона не удостоверяется в целостности шифртекста, то можно с некой долей вероятности утверждать, что атака может быть успешной в конечном итоге. По факту CBC без MAC/HMAC (keyed-hash message authentication code) не считается безопасным для реализации. А судя по тому алгоритму, который ты описал, в данной реализации отсутствует MAC/HMAC в явном виде. Куда копать: - Padding oracle attack - Timing vulnerabilities with CBC-mode symmetric decryption using padding (тайминг-атака на CBC с пэддингом без MAC/HMAC) Ссылочки (остальное сам можешь найти, на каком проще читать): https://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html https://habr.com/post/247527/ https://habr.com/post/338072/ https://docs.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode https://www.securitylab.ru/analytics/481048.php ----- EnJoy! | Сообщение посчитали полезным: Vamit |
|
|
Создано: 04 ноября 2018 14:13 · Поправил: Vamit · Личное сообщение · #5 За ссылки благодарю, но большинство их я уже читал и изучал уязвимость padding oracle attack, но все дело в том что я не знаю с чего начинать атаку, т.к. это первый случай в моей практике... Мне также неизвестно где начинаются криптованные данные, хоть первый пакет от устройства в сервер и содержит уникальную часть 448 байт, но я не представляю что там может быть, но это не данные, т.к. на этот пакет я всегда получаю ответ от сервера. Ответ от сервера тоже нельзя считать криптованными данными (по размеру 384 байта это скорее всего таблица векторов IV (256 байт) и криптованный хеш ключа (128 байт), причем они могут быть и не в оригинальном виде, но это только моё предположение), а на все дальнейшие пакеты от старых сессий сервер не отвечает. ----- Everything is relative... |
|
|
Создано: 04 ноября 2018 15:09 · Личное сообщение · #6 можно пример первого пакета от устройства и ответ на него от сервера ? |
|
|
Создано: 04 ноября 2018 15:37 · Поправил: Vamit · Личное сообщение · #7 пакеты в прикрепленном файле, хотел обернуть в тэг кода и вывести в посте, но непропорциональный шрифт ломает всю разметку, получается жуть... приведены только данные пакетов, заголовки за ненадобностью отрезаны Причем, посылая каждый раз на сервер один и тот же первый пакет, всегда получаю от него уникальный ответ, отличный от предыдущего.  a0ae_04.11.2018_EXELAB.rU.tgz - FirstPacket.txt
----- Everything is relative... | Сообщение посчитали полезным: bartolomeo |
|
|
Создано: 04 ноября 2018 15:46 · Поправил: bartolomeo · Личное сообщение · #8 ещё нужен первый пакет от устройства но от другой сессии - и ответ на него. желательно от того же устройства. | Сообщение посчитали полезным: Vamit |
|
|
Создано: 04 ноября 2018 15:59 · Личное сообщение · #9 добавил в тот же файл 0aa3_04.11.2018_EXELAB.rU.tgz - FirstPacket.txt
----- Everything is relative... |
|
|
Создано: 04 ноября 2018 16:24 · Поправил: bartolomeo · Личное сообщение · #10 Это очень похоже на Диффи-Хеллмана - Я уже както сталкивался с таким, только у меня первые пакеты были одинаковой длины - здесь же в первом пакете передаётся вместе со значением "А" ещё и простое число "р" и его первообразный корень "g" В общем пока нужно выяснить числа "p" и "g" где они расположены в пакете - возможно что числа "р" генерируются такие что их первообразный корень один и тот же и в пакете не передаётся - поэтому предположительно число "р" = 64бит и число "А" 384бит. возможно что устройство простые числа не генерит, а берёт из таблицы - можно попробовать наснифать побольше пакетов в надежде увидеть совпадения в первом пакете. Добавлено спустя 42 минуты чёт я перемудрил - число "р" 384 бит должно быть + ещё какое то число 64 бит - может быть IV ? ) |
|
|
Создано: 04 ноября 2018 17:42 · Поправил: Vamit · Личное сообщение · #11 > чёт я перемудрил - число "р" 384 бит должно быть наверно всё таки не 384 бита, а 384 байта, а таблица IV векторов быть в любом случае обязана, т.к. заголовок каждого пакета в сообщении содержит индекс одного из 16 векторов Сама таблица должна иметь размер 16 векторов по 16 байт = 256 байт Но я не могу исключать того, что таблица может и не передаваться в сообщении, а быть фиксированной на обеих сторонах. > ещё какое то число 64 бит - может быть IV ? 64 бита это 16 байт, может быть один "случайный" вектор IV для генерации ключа, но не из таблицы, или хеш для AES128 из которого генерится ключ, его размер также 16 байт, но это больше похоже на гадание... Проснифал первые пакеты в 10 сеансах, глазом кроме рандомного кода отличий не видать) Добавлено спустя 58 минут Могу добавить что программа для криптографии использует библиотеку LibTomCrypt v1.17, поэтому не исключаю, что те же функции используются сервером и устройством. И действительно первые два пакета очень похожи на протокол Диффи-Хеллмана, который может быть реализован на следующих функциях: ECC Shared Secret To construct a Diffie-Hellman shared secret with a private and public ECC key, use the following function: int ecc_shared_secret(ecc_key *private_key, ecc_key *public_key, unsigned char *out, unsigned long *outlen); ECC Diffie-Hellman Encryption ECC--DH Encryption is performed by producing a random key, hashing it, and XOR'ing the digest against the plaintext. It is not strictly ANSI X9.63 compliant but it is very similar. It has been extended by using an ASN.1 sequence and hash object identifiers to allow portable usage. The following function encrypts a short string (no longer than the message digest) using this technique: int ecc_encrypt_key(const unsigned char *in, unsigned long inlen, unsigned char *out, unsigned long *outlen, prng_state *prng, int wprng, int hash, ecc_key *key); As the name implies this function encrypts a (symmetric) key, and is not intended for encrypting long messages directly. It will encrypt the plaintext in the array pointed to by in of length inlen octets. It uses the public ECC key pointed to by key, and hash algorithm indexed by hash to construct a shared secret which may be XOR'ed against the plaintext. The ciphertext is stored in the output buffer pointed to by out of length outlen octets. The data is encrypted to the public ECC key such that only the holder of the private key can decrypt the payload. To have multiple recipients multiple call to this function for each public ECC key is required. ECC-DH Decryption This function will decrypt an encrypted payload. The key provided must be the private key corresponding to the public key used during encryption. If the wrong key is provided the function will not specifically return an error code. It is important to use some form of challenge response in that case (e.g. compute a MAC of a known string). int ecc_decrypt_key(const unsigned char *in, unsigned long inlen, unsigned char *out, unsigned long *outlen, ecc_key *key); Вот только как проверить это предположение... ----- Everything is relative... |
|
|
Создано: 04 ноября 2018 19:36 · Личное сообщение · #12 Если это действительно Диффи-Хеллман - то нужно узнать простое число "р", которое есть только в "чёрных ящиках". |
|
|
Создано: 04 ноября 2018 20:06 · Личное сообщение · #13 Описание схем в первом посте просто вырвимозг. Вообще непонятно кто на ком стоял. Можно в виде псеводкода изобразить? ----- старый пень |
|
|
Создано: 04 ноября 2018 23:13 · Поправил: Vamit · Личное сообщение · #14 r_e Ну думал как проще)) В виде исходного кода я думаю гуру будет понятней (все функи из LibTomCrypt , её исходный код на гите ) Программа-сервер Code:
Программа-устройство Code:
----- Everything is relative... |
|
|
Создано: 05 ноября 2018 11:03 · Личное сообщение · #15 Vamit Из того что ты написал это не DH ни разу, а банальная передача ключа через ассиметрику. Send(RSA(Random(0x10))) + предопределенный IV. Ключи у тебя DER-encoded. Так что размеры что ты привел не являются корректными. 1. Распакуй ключи и посмотри реальную длину на предмет факторизации. (сильно сомневаюсь) 2. Альтернативой могла бы быть атака на генератор, но только в контролируемом окружении. sprng резолвится в один из вариантов. Соответственно, если отключить виндовый генератор будет работать базовая реализация. https://android.googlesource.com/platform/external/dropbear/+/donut-release/libtomcrypt/src/prngs/rng_get_bytes.c Что касается паддинг оракл, то он вроде проводится не на данные а на источник и в твоем случае не применим. ----- старый пень |
|
|
Создано: 05 ноября 2018 12:10 · Поправил: Vamit · Личное сообщение · #16 r_e Вы или не до конца прочитали или не уловили суть. Да, в приведенном исходном коде DH и не пахнет, да и не должно, т.к. тут код инициализации потоков данных программа-сервер и программа-устройство и они прекрасно работают в обе стороны. Но речь идет не об этом, а о третьем потоке данных сервер-устройство, который проходит транзитом через программу и какова его реализация и на каких протоколах он построен - вот это и предстоит выяснить. А что по нему известно описано в первом посте. > Что касается паддинг оракл, то он вроде проводится не на данные а на источник и в твоем случае не применим. С этим я полностью согласен ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 14:02 · Личное сообщение · #17 Vamit Да, что-то затупил. Читал по диагонали. И таки да, можно сделать предположение что используется AES256. Судя по ответу сервера в 384 байта можно предположить что это RSA-encrypted данные. Получается печаль печальная. Тогда для начального пакета устройства предположим что это RSA::PK (384 байта) + 64 байта могут быть еще что-то, типа AES IV. Если это просто бегает транзитом и с железом ничего не сделать то шансов на успех маловато. ))) ----- старый пень |
|
|
Создано: 05 ноября 2018 15:06 · Личное сообщение · #18 Я всё таки думаю, что от устройства на сервер в первом пакете должна передаваться таблица векторов IV необходимая для последующего криптообмена, т.к. иметь одну таблицу во всех устройствах и на сервере как-то нелогично - устройств же в сети может быть очень много, а так вполне логично - устройство генерит рандомную таблицу и отправляет её на сервер, это 256 байт. Остается ещё 192 байта. Если бы здесь отправлялся на сервер криптованный RSA хеш CBC ключа, то ответа от сервера в таком случае не нужно - можно сразу уже начинать обмен криптованными данными, да и стойкость такого протокола низка, он годится и реализован для локального обмена данными программа-устройство. Поэтому думаю что здесь передается криптованный ЕСС публичный ключ устройства для реализации DH протокола. Тогда в ответном сообщении от сервера получаем криптованный ЕСС публичный ключ сервера, но вот размер этого сообщения 384 байта велик для ECC ключа. Возможно тут ещё имеется хеш сигнатуры для проверки переданного устройством ключа, чтобы исключить возможную третью сторону в DH обмене ключами. ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 16:06 · Личное сообщение · #19 Vamit Откуда тут ECC нарисовался? Для DH он не нужен (если это не ECDH который вдруг внезапно появился). Если думать что это DH то выходит... Для AES256 тебе надо 32 байта на ключ. Тоесть DH компоненты будут тоже минимум по 32 байта. sizeof(A) + sizeof(p) = 64 байта. Еще есть g неопределенного размера. При передаче этих параметров в открытую ты бы видел структурированные данные в пакете, а ты говоришь что там выглядит как рандом начальные 448 байт. p можно было бы выделить по старшему байту и тесту на простоту, например. ----- старый пень |
|
|
Создано: 05 ноября 2018 16:19 · Поправил: Vamit · Личное сообщение · #20 r_e в 11 посте на этой странице написано откуда взялся ЕСС это Elliptic curve Diffie-Hellman Encryption, т.к. в используемой разработчиками либе LibTomCrypt присутствует только эта реализация DH протокола, они эту либу юзают для криптографии и в программе и в устройстве и городить что-то другое навряд-ли будут. Добавлено спустя 31 минуту Сейчас вот тестирую этот код на подбор ключа соответствующей длины (192 байта) Code:
и 192 никак не получается, макс. для ECC521 получаю 196 байт, а предыдущий ECC384 - 160 байт но в нем передается также и индекс используемого хеша (это 4 байта), который в принципе серверу не нужен (юзают обе стороны SHA256 и всё), т.ч. если индекс хеша отрезать, то получим 192 байта ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 18:24 · Личное сообщение · #21 Vamit Обычный DH реализуется на базовых операциях powmod которая 100% присутствует в либе. Так что не стоит городить ECDH если его раньше нигде не использовалось. Опять же. Если бы это был голый ECDH без крипты сверху ты бы видел передачу точек в сыром пакете. Уж их прям на глаз отличить можно. ----- старый пень |
|
|
Создано: 05 ноября 2018 21:24 · Личное сообщение · #22 также возможно что это DSA - там участвуют два простых числа 3072 и 256 бит - что больше похоже на размер первого пакета. |
|
|
Создано: 05 ноября 2018 21:28 · Личное сообщение · #23 реализуйте уже кто нибудь инструмент который будет собирать базу данных статистики распределения каких то известных данных и на основе введеных пользователем данных можно будет получать гипотезу о возможной природе данных на основе базы знаний известных данных  это хоть будет иметь какой то математический аппарат а то что вы делаете называется угадыванием с вероятностью 0 |
|
|
Создано: 05 ноября 2018 21:57 · Поправил: Vamit · Личное сообщение · #24 Если бы это был голый ECDH без крипты сверху ты бы видел передачу точек в сыром пакете Согласен, на там глазом ничего не видать, так что это что-то криптованное. Даже при передаче криптованного ЕСС ключа я глазом вижу структуру информации под криптом, да тут и криптом-то это назвать нельзя DER encoding 3х параметров: IOD хеша, рандомизированный публичный ключ и хешированный ключ, первая часть в отличие от остальных легко распознается глазом. также возможно что это DSA Возможно много чего может быть, но поясни, зачем тут DSA, он используется или для цифровой подписи или для асимметричного шифрования, ответа на сообщение с ним не требуется, можно сразу начинать криптообмен данными. Первоначально я хочу послать на сервер что-то свое вместо старого пакета от устройства, но это что-то должно быть произведено библиотекой LibTomCrypt, и посмотреть на реакцию сервера. Главное тут подобрать криптоданные совпадающие по размеру с этим пакетом и подходящие под логику обмена, а далее уже можно пробовать. а то что вы делаете называется угадыванием с вероятностью 0 Не 0, а повыше будет)) ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 22:02 · Личное сообщение · #25 если протокол ТСП то в начале должно быть длинна данных и машинку посредине и заставить пофрагментировать пакет и посмотреть что будет с обменом |
|
|
Создано: 05 ноября 2018 22:16 · Поправил: Vamit · Личное сообщение · #26 reversecode нет тут никакого ТСП, устройство само не может установить связь с сервером, установку связи делает только программа, а устройство общается уже по установленному каналу данных. Без программы сервер ничего не знает об устройстве и наоборот, и сами по себе даже при установленном соединении они ничего друг другу не передают, инициатором их обмена всегда выступает человек выполнив тот или иной запрос. Пользователь давит кнопку, программа посылает команду в устройство, устройство шлет транзитом через программу пакет на сервер и ответ от него так же транзитом уходит в устройство. Пакетов между ними в пределах одной сессии может быть от 5 штук до нескольких сотен - всё зависит от выбранной функции. Программа в транзите осуществляет только перепаковку пакетов без изменения данных (с сервера приходит длинный пакет, который отправляется в устройство несколькими короткими и наоборот) ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 22:30 · Личное сообщение · #27 отправить китайцам пусть прошивку снимут |
|
|
Создано: 05 ноября 2018 23:04 · Личное сообщение · #28 Vamit пишет: Мне также неизвестно где начинаются криптованные данные, хоть первый пакет от устройства в сервер и содержит уникальную часть 448 байт, но я не представляю что там может быть, но это не данные, т.к. на этот пакет я всегда получаю ответ от сервера. Vamit пишет: Причем, посылая каждый раз на сервер один и тот же первый пакет, всегда получаю от него уникальный ответ, отличный от предыдущего. Разница скорей всего из-за соли. Очень похоже на то, что там под RSA ключик для симметричного алгоритма, так оно часто и делается. Потому что RSA совершенен, но слишком прожорлив, его гибридят с симметричными алгоритмами. На месте разработчиков я бы так и сделал. Не имея даже открытых ключей (программа в шифровании-расшифровке этого обмена не участвует), я думаю тут совсем нечего ловить. 448 не кратно 128 и 256, это может быть RSA-512, но это ничем скорей всего не поможет. ----- 2 оттенка серого |
|
|
Создано: 05 ноября 2018 23:11 · Личное сообщение · #29 отправить китайцам пусть прошивку снимут Не могут, уже узнавали, ни наши ни китайцы пока ещё не научились ARM Cortex контроллеры вскрывать Добавлено спустя 8 минут Очень похоже на то, что там под RSA ключик для симметричного алгоритма Не соглашусь с этим, если бы это было так и я получаю от сервера ответ на первый старый пакет, то он бы с таким же успехом принял бы и ответил на второй старый пакет и на все последующие. ----- Everything is relative... |
|
|
Создано: 05 ноября 2018 23:27 · Личное сообщение · #30 Vamit пишет: Не соглашусь с этим, если бы это было так и я получаю от сервера ответ на первый старый пакет, то он бы с таким же успехом принял бы и ответил на второй старый пакет и на все последующие. Ответ от сервера (512/8)*6 байт и каждый раз разный, то есть солёный. В нем может быть второй ключ к симметричному алгоритму под RSA и он может использоваться для шифрования обмена устройство->сервер. Тогда второй старый запрос от устройства сервер не примет. ----- 2 оттенка серого |
| . 1 . 2 . >> |
|
eXeL@B —› Основной форум —› Взлом криптографии при обмене данных с устройством |
Для печати