Атака удлинения длины - Length extension attack

В криптография и компьютерная безопасность, а атака удлинения длины это тип атака где злоумышленник может использовать Хеш(сообщение1) и длина сообщение1 вычислять Хеш(сообщение1сообщение2) для контролируемого злоумышленником сообщение2, без необходимости знать содержание сообщение1. Алгоритмы вроде MD5, SHA-1 и большая часть SHA-2 которые основаны на Строительство Меркле-Дамгарда восприимчивы к такому виду атак.[1][2][3] Усеченные версии SHA-2, включая SHA-384 и SHA256 / 512, не восприимчивы,[4] и не SHA-3 алгоритм.[5]

Когда На основе Меркла – Дамгарда хэш неправильно используется как код аутентификации сообщения со строительством ЧАС(секретсообщение),[1] и сообщение и длина секрет Как известно, атака с расширением длины позволяет любому включить дополнительную информацию в конец сообщения и создать действительный хэш, не зная секрета. С HMAC не использует эту конструкцию, хэши HMAC не подвержены атакам на расширение длины.[6]

Объяснение

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

Пример

Сервер для доставки вафель определенного типа конкретному пользователю в определенном месте может быть реализован для обработки запросов данного формата:

Исходные данные: count = 10 & lat = 37.351 & user_id = 1 & long = -119.827 & waffle = eggo Исходная подпись: 6d5f807e23db210bc254a28be2d6759a0f5f5d99

Сервер будет выполнять данный запрос (доставить десять вафель типа eggo в указанное место для пользователя «1»), только если подпись действительна для пользователя. Используемая здесь подпись - MAC, подписанный ключом, неизвестным злоумышленнику. (Этот пример также уязвим для повторная атака, отправив тот же запрос и подпись второй раз.)

Злоумышленник может изменить запрос, в этом примере переключив запрошенную вафлю с "eggo" на "liege". Это можно сделать, воспользовавшись преимуществом гибкости формата сообщения, если дублирующееся содержимое в строке запроса отдает предпочтение последнему значению. Эта гибкость не указывает на эксплойт в формате сообщения, потому что формат сообщения никогда не проектировался как криптографически безопасный в первую очередь, без помощи алгоритма подписи.

Желаемые новые данные: count = 10 & lat = 37,351 & user_id = 1 & long = -119,827 & waffle = eggo& waffle = сеньор

Чтобы подписать это новое сообщение, злоумышленнику обычно необходимо знать ключ, которым было подписано сообщение, и сгенерировать новую подпись, создав новый MAC. Однако с помощью атаки с расширением длины можно передать хэш (подпись, указанную выше) в состояние хеш-функции и продолжить с того места, где был остановлен исходный запрос, если вы знаете длину исходного запроса. . В этом запросе длина исходного ключа составляла 14 байтов, что можно было определить, попробовав поддельные запросы с различной предполагаемой длиной и проверив, какая длина приводит к запросу, который сервер принимает как действительный.[требуется дальнейшее объяснение ]

Сообщение, загружаемое в функцию хеширования, часто мягкий, поскольку многие алгоритмы могут работать только с входными сообщениями, длина которых кратна некоторому заданному размеру. Содержимое этого заполнения всегда определяется используемой хеш-функцией. Злоумышленник должен включить все эти биты заполнения в свое поддельное сообщение до того, как внутреннее состояние своего сообщения, и оригинал выровняется. Таким образом, злоумышленник создает несколько иное сообщение, используя следующие правила заполнения:

Новые данные: count = 10 & lat = 37,351 & user_id = 1 & long = -119,827 & waffle = eggo x80  x00  x00           x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00           x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00           x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00  x00           x00  x00  x02  x28 & waffle = сеньор

Это сообщение включает в себя все заполнение, которое было добавлено к исходному сообщению внутри хеш-функции перед их полезной нагрузкой (в данном случае 0x80, за которым следует число 0x00 и длина сообщения, 0x228 = 552 = (14 + 55) * 8 (длина ключа плюс исходное сообщение, добавленное в конце). Злоумышленник знает, что состояние пары хешированный ключ / сообщение для исходного сообщения идентично состоянию нового сообщения до последнего символа «&». Злоумышленник также знает хэш-дайджест на этом этапе, что означает, что он знает внутреннее состояние хеш-функции в этот момент. Затем тривиально инициализировать алгоритм хеширования в этой точке, ввести несколько последних символов и создать новый дайджест, который может подписать новое сообщение без исходного ключа.

Новая подпись: 0e41270260895979317fff3898ab85668953aaa2

Объединив новую подпись и новые данные в новый запрос, сервер увидит поддельный запрос как действительный, поскольку подпись будет такой же, как если бы пароль был известен.

Рекомендации

  1. ^ а б Вэ, Хоанг (30 марта 2012 г.). "Атака на расширение длины MD5 - еще раз - Внутренний мир V". Архивировано из оригинал в 2014-10-29. Получено 2017-10-27.
  2. ^ Дуонг, тайский; Риццо, Джулиано (2009-09-28). "Уязвимость Flickr, связанная с подделкой подписи API" (PDF). Получено 2017-10-27.
  3. ^ Мейер, Кристофер (30.07.2012). «Атаки на расширение длины хэша». Получено 2017-10-27.
  4. ^ Бостром, Майкл (2015-10-29). "size_t Does Matter: Объяснение атак на увеличение длины хэша" (PDF). Получено 2020-11-23.
  5. ^ Команда Keccak. «Сильные стороны Keccak - Дизайн и безопасность». Получено 2017-10-27. В отличие от SHA-1 и SHA-2, Keccak не имеет недостатка в расширении длины, следовательно, не требует вложенной конструкции HMAC. Вместо этого можно выполнить вычисление MAC, просто добавив к сообщению ключ.
  6. ^ Лоусон, Нейт (2009-10-29). «Прекратите использовать небезопасные хэши с ключами, используйте HMAC». Получено 2017-10-27.