Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

В криптографии и компьютерной безопасности , A Удлинение атака представляет собой тип атаки , когда злоумышленник может использовать Hash ( сообщение 1 ) и длину сообщения 1 для вычисления Hash ( сообщение 1 ‖ сообщение 2 ) для атакующего управления сообщением 2 , без необходимо знать содержание сообщения 1 . Такие алгоритмы , как MD5 , SHA-1 и большая часть SHA-2 , основанные наКонструкции Merkle – Damgård уязвимы для такого рода атак. [1] [2] [3] Усеченные версии SHA-2, включая SHA-384 и SHA256 / 512, не восприимчивы, [4] и алгоритм SHA-3 . [5]

Когда хэш на основе Меркла-Дамгарда неправильно используется в качестве кода аутентификации сообщения с конструкцией H ( секретное ‖ сообщение ), [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 = liege

Чтобы подписать это новое сообщение, обычно злоумышленнику необходимо знать ключ, которым было подписано сообщение, и сгенерировать новую подпись, создав новый 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 \ x00 \ x02 \ x28 & waffle = liege

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

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

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

Ссылки [ править ]

  1. ^ a b Vũ, Хоанг (30 марта 2012 г.). "Атака расширения длины MD5 снова - Внутренний мир V" . Архивировано из оригинала на 2014-10-29 . Проверено 27 октября 2017 . CS1 maint: discouraged parameter (link)
  2. ^ Дуонг, тайский; Риццо, Джулиано (2009-09-28). «Уязвимость Flickr, связанная с подделкой подписи API» (PDF) . Проверено 27 октября 2017 .
  3. ^ Мейер, Кристофер (30.07.2012). «Атаки на расширение длины хэша» . Проверено 27 октября 2017 .
  4. ^ Бостром, Майкл (2015-10-29). «size_t имеет значение: объяснение атак на увеличение длины хэша» (PDF) . Проверено 23 ноября 2020 .
  5. ^ Команда Keccak. «Сильные стороны Keccak - Дизайн и безопасность» . Проверено 27 октября 2017 . В отличие от SHA-1 и SHA-2, Keccak не имеет недостатка в расширении длины, следовательно, не требует вложенной конструкции HMAC. Вместо этого вычисление MAC можно выполнить, просто добавив к сообщению ключ.
  6. ^ Lawson, Nate (2009-10-29). "Stop using unsafe keyed hashes, use HMAC". Retrieved 2017-10-27. CS1 maint: discouraged parameter (link)