Атака с расширением длины

В криптографии и компьютерной безопасности атака с расширением длины — это тип атаки , при которой злоумышленник может использовать хэш ( сообщение ₁ ) и длину сообщения ₁ для вычисления хеша ( сообщение ₁ ‖ сообщение ₂ ) для контролируемого злоумышленником сообщения ₂ без необходимо знать содержание сообщения ₁ . Это проблематично, когда используется в качестве кода аутентификации сообщения с конструкцией Hash ( секретное хеш сообщение ), ^[1] И сообщение , и длина секрета известны, поскольку злоумышленник может включить дополнительную информацию в конец сообщения и создать действительный хэш, не зная секрета. Такие алгоритмы, как MD5 , SHA-1 и большая часть SHA-2 , основанные на конструкции Меркла-Дамгорда, подвержены такого рода атакам. ^[1]^[2]^[3] Усеченные версии SHA-2, включая SHA-384 и SHA-512/256, не поддерживаются. ^[4] ни алгоритм SHA-3 . ^[5] HMAC также использует другую конструкцию и поэтому не уязвим для атак с расширением длины. ^[6] Наконец, просто выполнить Hash ( сообщение секретное ) , достаточно чтобы это не повлияло.

Объяснение [ править ]

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

Пример [ править ]

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

Original Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo
Original Signature: 6d5f807e23db210bc254a28be2d6759a0f5f5d99

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

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

Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege

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

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

New Data: 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, то есть длина ключа плюс исходное сообщение, добавленное в конце). Злоумышленник знает, что состояние хешированной пары ключ/сообщение для исходного сообщения идентично состоянию нового сообщения вплоть до последнего знака «&». Злоумышленнику также известен хеш-дайджест на данный момент, что означает, что он знает внутреннее состояние хеш-функции на данный момент. Тогда в этот момент тривиально инициализировать алгоритм хеширования, ввести последние несколько символов и сгенерировать новый дайджест, который может подписать новое сообщение без исходного ключа.

New Signature: 0e41270260895979317fff3898ab85668953aaa2

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

Примечания [ править ]

^ Этот пример также уязвим для атаки повторного воспроизведения , поскольку тот же запрос и подпись отправляются второй раз.

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

^ Jump up to: Перейти обратно: ^а ^б Ву, Хоанг (30 марта 2012 г.). «Возвращение к атаке на расширение длины MD5 — внутренний мир Vũ» . Архивировано из оригинала 29 октября 2014 г. Проверено 27 октября 2017 г.
^ Дуонг, Тайский; Риццо, Джулиано (28 сентября 2009 г.). «Уязвимость подделки подписи API Flickr» (PDF) . Проверено 18 марта 2023 г.
^ Мейер, Кристофер (30 июля 2012 г.). «Атаки на расширение длины хеша» . Проверено 27 октября 2017 г.
^ Бостром, Майкл (29 октября 2015 г.). «size_t имеет значение: объяснение атак на расширение длины хеша» (PDF) . Проверено 23 ноября 2020 г.
^ Команда Кечак. «Сильные стороны Keccak – Дизайн и безопасность» . Проверено 27 октября 2017 г. В отличие от SHA-1 и SHA-2, Keccak не имеет недостатка расширения длины и, следовательно, не нуждается во вложенной конструкции HMAC. Вместо этого вычисление MAC можно выполнить, просто добавив к сообщению ключ.
^ Лоусон, Нейт (29 октября 2009 г.). «Прекратите использовать небезопасные хэши с ключами, используйте HMAC» . Проверено 27 октября 2017 г.

[7] Этот пример также уязвим для атаки повторного воспроизведения , поскольку тот же запрос и подпись отправляются второй раз.

[vudang-1] Jump up to: Перейти обратно: ^а ^б Ву, Хоанг (30 марта 2012 г.). «Возвращение к атаке на расширение длины MD5 — внутренний мир Vũ» . Архивировано из оригинала 29 октября 2014 г. Проверено 27 октября 2017 г.

[2] Дуонг, Тайский; Риццо, Джулиано (28 сентября 2009 г.). «Уязвимость подделки подписи API Flickr» (PDF) . Проверено 18 марта 2023 г.

[3] Мейер, Кристофер (30 июля 2012 г.). «Атаки на расширение длины хеша» . Проверено 27 октября 2017 г.

[4] Бостром, Майкл (29 октября 2015 г.). «size_t имеет значение: объяснение атак на расширение длины хеша» (PDF) . Проверено 23 ноября 2020 г.

[5] Команда Кечак. «Сильные стороны Keccak – Дизайн и безопасность» . Проверено 27 октября 2017 г. В отличие от SHA-1 и SHA-2, Keccak не имеет недостатка расширения длины и, следовательно, не нуждается во вложенной конструкции HMAC. Вместо этого вычисление MAC можно выполнить, просто добавив к сообщению ключ.

[6] Лоусон, Нейт (29 октября 2009 г.). «Прекратите использовать небезопасные хэши с ключами, используйте HMAC» . Проверено 27 октября 2017 г.

[1]

[2]

[3]

[4]

[5]

[6]

[примечание 1]