Остались ли ещё закладки в Telegram?

Как уже упоминалось в недавнем посте "Безопасен ли Telegram? Или как я искал закладку в MTProto ^[1]" — Telegram ^[2] — супер защищённый мессенджер для смартфонов, на столько безопасный, что за его взлом объявлен конкурс с внушительным призом. В том посте была описана эффективная атака на его протокол (MTProto ^[3]), краткая суть которой состоит в том, что "сервер Telegram может подобрать такую nonce, при которой ключи пользователей совпадут даже при MITM-атаке и никто не будет знать, что его слушают", где под nonce подразумевалась «случайная» последовательность данных участвующая в установлении ключа казалось бы просто для увеличения энтропии, а реально она давала возможность администраторам серверов Telegram легко и, самое главное, не обнаружимо для пользователей выполнять Man-in-the-middle (MITM) атаку на протокол по обмену ключами. Некоторые даже посчитали участок кода ответственный за уязвимость — закладкой.

К чести Telegram, довольно быстро было признано, что уязвимость присутствует и было анонсировано его исправление в следующей версии мессенджера, а автору обещано ^[4] вознаграждение — ibeatle ^[5] пишет: "с настоящего момента в nonce всегда будет приходить ноль, и в следующем слое мы обязательно удалим это поле из схемы и поясним в документации." Тем временем в описании протокола ^[6] мы уже видим, что злосчастное 'xor nonce' исчезло, и код поменялся ^[7] в лучшую сторону. Pavel Durov сказал: "На всякий случай, поясню для массовых пользователей: утечки данных не было, уязвимость закрыта, опасности нет." Всё хорошо, что хорошо кончается.

Но исчезла ли уязвимость и стал ли Telegram защищён от не обнаружимого MITM? Есть мнение, что не стал и администраторы Telegram серверов всё ещё могут прослушать пользователей так, что проверка ключей покажет, что они совпадают.

Для этого достаточно применить атаку вырожденного ключа на протокол Diffie-Hellman ^[8] (DH). Предыдущая атака была на часть алгоритма протокола установления ключа, которая происходит сразу после DH, но ведь есть же ещё и сам DH. В документации есть попытка защититься от от некоторых атак на DH — предписано проверять публичные параметры p и g: "client is expected to check whether p is a safe 2048-bit prime, and that g generates a cyclic subgroup of order (p-1)/2." Но ничего не говорится о проверке открытых ключей g_a и g_b.

Для проведения атаки серверу достаточно заменить присылаемые от клиентов А и В оба параметра g_a и g_b на единицу (1). В этом случае у обоих пользователей в результате расчета приватного ключа так-же получатся единицы. Сервер (и любой другой наблюдающий атакованную сессию) зная это свойство DH протокола сможет спокойно расшифровывать и читать их сообщения. Хотя внешне всё будет выглядеть «зашифрованным». Более того, key_fingerprint этого вырожденного ключа будет визуально не отличим от нормального сложного ключа, так как fingerprint, это не сам ключ, а sha1 криптохэш от ключа.

Для исправления этой уязвимости мессенджеру достаточно было бы проверить, что присылаемые g_a и g_b не равны единице.

Автор: aabc

Источник ^[9]