Атака с расширением длины — это атака, связанная со свойствами определенных типов хэш-функций, таких как MD5, SHA-1 и SHA-2. Проще говоря, эта атака использует тот факт, что, зная H(сообщение) и длину сообщения, мы можем легко вычислить H(сообщение || заполнение || расширение), не зная самого сообщения. Среди них «||» означает соединение, а «заполнение» добавляется в соответствии с положениями хэш-функции.
Это связано с тем, что эти хэш-функции используют структуру Меркла-Дамгорда, которая разбивает входные данные на блоки, и хэш каждого блока зависит от хеша предыдущего блока. Это означает, что после того, как мы вычислили хеш определенного сообщения, у нас есть состояние, из которого мы можем начать и добавить больше блоков.
Режим проверки на стороне сервера
Чтобы облегчить описание сценариев уязвимости, мы сначала предположим, что существует такой режим аутентификации на стороне сервера, то есть, когда пользователь пытается войти в систему, сервер передает определенный хеш на основе идентификатора пользователя, имени и 30-битный ключ известен только серверу.Алгоритм генерирует хэш-значение и отправляет его клиенту. Впоследствии, когда клиент попытается получить доступ к определенным интерфейсам, таким как интерфейс изменения разрешений пользователя, сервер повторно сгенерирует хэш для проверки на основе идентификатора роли, имени роли, разрешений роли и того же 30-битного ключа фронт-сервера. конец ПОСТ. Если загруженный хэш соответствует хешу, сгенерированному сервером, проверка считается пройденной, и новые разрешения роли будут записаны в базу данных.
Для простоты понимания ниже приведены несколько простых кодов, написанных по описанию в качестве примеров:
Мыслить за пределами полномочий
Из-за уязвимостей в режиме проверки злоумышленник может обойти проверку разрешений, реконструировав запрос транзакции, не зная SecretKey. Основная идея несанкционированной атаки заключается в использовании характеристик атак с расширением длины. Злоумышленнику сначала необходимо получить исходное значение хеш-функции и вычислить длину исходных данных с помощью простого итерационного алгоритма. Как только эта информация будет получена, к исходным данным можно будет добавить дополнительные несанкционированные параметры и тот же алгоритм хэширования можно будет использовать для генерации вредоносных хэшей.
Атака по принципу расширения длины
Атака расширения длины происходит из-за внутреннего механизма некоторых хеш-функций. Эти функции обрабатывают входные данные, сначала разбивая их на фрагменты фиксированной длины, а затем дополняя конец каждого фрагмента в соответствии с конкретными требованиями. Такая конструкция позволяет злоумышленнику создать новый действительный хеш путем заполнения и добавления новых данных, зная хеш и длину исходного сообщения.
Возьмем, к примеру, SHA-256, который работает с 512-битными блоками. Для данных, длина которых не кратна 512 битам, требуется заполнение. Правила его заполнения следующие:
Добавьте бит «1» в конец данных;
Добавить определенное количество бит «0» так, чтобы длина данных по модулю 512 была равна 448 (подробнее см. [1] ）；
Добавьте в конце 64-битный блок, указывающий длину исходных данных.
Короче говоря, в конец сообщения добавляется цифра «1», за которой следуют m «0», а также 64-битное или 128-битное целое число, чтобы создать заполняющее сообщение длиной 512*n. Добавленное целое число — это длина исходного сообщения. Сообщение заполнения затем обрабатывается хеш-функцией в n 512-битных блоков.
Метод построения
В этом примере мы будем использовать код, упомянутый на рисунке выше, в качестве конкретного сценария, где строка данных — data="user_id=1&user_name=aa", а ключ — SecretKey="Length_extension\ _attack\ _секрет". Сервер проанализирует поле данных в загруженных данных и выполнит анализ необходимых параметров user_id и user_name через разделитель &. Если поле роли существует, сервер также получит значение этого поля. Затем сервер хэширует все поля с помощью SecretKey и сравнивает их с загруженным проверочным хешем. Если хэш-значения согласованы, параметры считаются соответствующими правилам и используются напрямую.
Сначала мы авторизуемся в интерфейсе loginHandler, чтобы получить хеш-значение hash="37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68", сгенерированное с использованием SHA-256 на основе данных и SecretKey.
Далее мы рассмотрим сложность взлома. Взяв в качестве примера нашу тестовую ситуацию, в соответствии с принципом атаки расширения длины, пока мы знаем H (сообщение) и длину сообщения, мы можем добавлять новые данные с помощью атаки расширения длины. Исходное сообщение = SecretKey + данные, теперь у нас есть H(сообщение), нам нужно знать только длину сообщения, чтобы построить новое значение хеш-функции. Поскольку SecretKey — это 30-битный ключ, реальная длина сообщения может быть известна только после 30 итераций. Следовательно, мы можем легко создать новое значение хеш-функции. Поскольку нам необходимо использовать права администратора, нам необходимо вставить вредоносное поле «&role=admin» в исходные данные.
Мы можем воспользоваться функцией атаки с расширением длины, чтобы добавить новые данные и сгенерировать новое значение хеш-функции, не зная SecretKey. Здесь мы используем библиотеку, которая уже реализует эту функцию [2] чтобы завершить тест. Затем используйте этот инструмент для генерации нового значения хеш-функции.
Поскольку проверка интерфейса adminActionHandler проверяет хеш на основе загруженного user_id, user_name и роли, данные, которые мы загрузили в этот момент, имеют вид user_id=1, user_name=aa\x80\x00\x00\x00. \ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x70 и role=admin, как показано на следующем рисунке:
Хэш-значение: 84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0. Далее можно вызвать интерфейс adminActionHandler.После получения данных сервер сравнит загруженный хеш с sha256 (SecretKey+fakeData), и после прохождения проверки выполнит некоторые чувствительные операции. Таким образом, мы успешно использовали атаку расширения длины, чтобы обойти проверку на стороне сервера и добиться несанкционированных операций.
Другие возможные сценарии атак
1. Проверка целостности файла. Если целостность файла проверяется путем объединения ключа и содержимого файла, а затем его хеширования, злоумышленник может расширить файл и сгенерировать действительный хэш, тем самым минуя проверку целостности. ;
2. Безопасность веб-приложений. Если в веб-приложениях для проверки данных, отправленных пользователем, используется хеш-функция, чувствительная к атакам с расширением длины, злоумышленники могут воспользоваться этим для передачи вредоносных данных;
3. Цифровые подписи: В некоторых схемах цифровых подписей, если подпись создается путем объединения закрытого ключа и сообщения и последующего хеширования, злоумышленник может расширить сообщение и создать действительную подпись;
**4. Хранение паролей: **Хотя это и редкость, но если пароль хранится путем объединения ключа (например, соли) и пароля, а затем его хэширования, злоумышленник может попытаться взломать его, используя пароль для атаки с расширением длины.
Как предотвратить
1. Выберите хеш-функцию, которая не подвержена атакам расширения длины, например SHA-3;
**2. Используйте HMAC: **HMAC требует в качестве входных данных ключ и сообщение, а выходные результаты зависят как от ключа, так и от сообщения, поэтому злоумышленник не может выполнять атаки с расширением длины, не зная ключа;
**3. Усиление проверки полномочий: **Добавьте дополнительные этапы проверки полномочий на стороне сервера, например использование многофакторной аутентификации.
Ниже приведены характеристики некоторых часто используемых алгоритмов хеширования:
Эффективной защитой от атак расширения длины является использование хеш-функций, устойчивых к таким атакам, таких как SHA-3 и BLAKE2. Кроме того, его также можно защитить с помощью структуры HMAC (код аутентификации хешированного сообщения с ключом). Эти меры могут эффективно повысить безопасность системы и обеспечить целостность данных и стабильность приложений.
Справочная ссылка:
[1]
[2]
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Скрытые опасности хеш-функций: атаки на расширение длины и риски безопасности на стороне сервера
Введение
Атака с расширением длины — это атака, связанная со свойствами определенных типов хэш-функций, таких как MD5, SHA-1 и SHA-2. Проще говоря, эта атака использует тот факт, что, зная H(сообщение) и длину сообщения, мы можем легко вычислить H(сообщение || заполнение || расширение), не зная самого сообщения. Среди них «||» означает соединение, а «заполнение» добавляется в соответствии с положениями хэш-функции.
Это связано с тем, что эти хэш-функции используют структуру Меркла-Дамгорда, которая разбивает входные данные на блоки, и хэш каждого блока зависит от хеша предыдущего блока. Это означает, что после того, как мы вычислили хеш определенного сообщения, у нас есть состояние, из которого мы можем начать и добавить больше блоков.
Режим проверки на стороне сервера
Чтобы облегчить описание сценариев уязвимости, мы сначала предположим, что существует такой режим аутентификации на стороне сервера, то есть, когда пользователь пытается войти в систему, сервер передает определенный хеш на основе идентификатора пользователя, имени и 30-битный ключ известен только серверу.Алгоритм генерирует хэш-значение и отправляет его клиенту. Впоследствии, когда клиент попытается получить доступ к определенным интерфейсам, таким как интерфейс изменения разрешений пользователя, сервер повторно сгенерирует хэш для проверки на основе идентификатора роли, имени роли, разрешений роли и того же 30-битного ключа фронт-сервера. конец ПОСТ. Если загруженный хэш соответствует хешу, сгенерированному сервером, проверка считается пройденной, и новые разрешения роли будут записаны в базу данных.
Для простоты понимания ниже приведены несколько простых кодов, написанных по описанию в качестве примеров:
Мыслить за пределами полномочий
Из-за уязвимостей в режиме проверки злоумышленник может обойти проверку разрешений, реконструировав запрос транзакции, не зная SecretKey. Основная идея несанкционированной атаки заключается в использовании характеристик атак с расширением длины. Злоумышленнику сначала необходимо получить исходное значение хеш-функции и вычислить длину исходных данных с помощью простого итерационного алгоритма. Как только эта информация будет получена, к исходным данным можно будет добавить дополнительные несанкционированные параметры и тот же алгоритм хэширования можно будет использовать для генерации вредоносных хэшей.
Атака по принципу расширения длины
Атака расширения длины происходит из-за внутреннего механизма некоторых хеш-функций. Эти функции обрабатывают входные данные, сначала разбивая их на фрагменты фиксированной длины, а затем дополняя конец каждого фрагмента в соответствии с конкретными требованиями. Такая конструкция позволяет злоумышленнику создать новый действительный хеш путем заполнения и добавления новых данных, зная хеш и длину исходного сообщения.
Возьмем, к примеру, SHA-256, который работает с 512-битными блоками. Для данных, длина которых не кратна 512 битам, требуется заполнение. Правила его заполнения следующие:
Добавьте бит «1» в конец данных;
Добавить определенное количество бит «0» так, чтобы длина данных по модулю 512 была равна 448 (подробнее см. [1] ）；
Добавьте в конце 64-битный блок, указывающий длину исходных данных.
Короче говоря, в конец сообщения добавляется цифра «1», за которой следуют m «0», а также 64-битное или 128-битное целое число, чтобы создать заполняющее сообщение длиной 512*n. Добавленное целое число — это длина исходного сообщения. Сообщение заполнения затем обрабатывается хеш-функцией в n 512-битных блоков.
Метод построения
В этом примере мы будем использовать код, упомянутый на рисунке выше, в качестве конкретного сценария, где строка данных — data="user_id=1&user_name=aa", а ключ — SecretKey="Length_extension\ _attack\ _секрет". Сервер проанализирует поле данных в загруженных данных и выполнит анализ необходимых параметров user_id и user_name через разделитель &. Если поле роли существует, сервер также получит значение этого поля. Затем сервер хэширует все поля с помощью SecretKey и сравнивает их с загруженным проверочным хешем. Если хэш-значения согласованы, параметры считаются соответствующими правилам и используются напрямую.
Сначала мы авторизуемся в интерфейсе loginHandler, чтобы получить хеш-значение hash="37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68", сгенерированное с использованием SHA-256 на основе данных и SecretKey.
Далее мы рассмотрим сложность взлома. Взяв в качестве примера нашу тестовую ситуацию, в соответствии с принципом атаки расширения длины, пока мы знаем H (сообщение) и длину сообщения, мы можем добавлять новые данные с помощью атаки расширения длины. Исходное сообщение = SecretKey + данные, теперь у нас есть H(сообщение), нам нужно знать только длину сообщения, чтобы построить новое значение хеш-функции. Поскольку SecretKey — это 30-битный ключ, реальная длина сообщения может быть известна только после 30 итераций. Следовательно, мы можем легко создать новое значение хеш-функции. Поскольку нам необходимо использовать права администратора, нам необходимо вставить вредоносное поле «&role=admin» в исходные данные.
Мы можем воспользоваться функцией атаки с расширением длины, чтобы добавить новые данные и сгенерировать новое значение хеш-функции, не зная SecretKey. Здесь мы используем библиотеку, которая уже реализует эту функцию [2] чтобы завершить тест. Затем используйте этот инструмент для генерации нового значения хеш-функции.
Поскольку проверка интерфейса adminActionHandler проверяет хеш на основе загруженного user_id, user_name и роли, данные, которые мы загрузили в этот момент, имеют вид user_id=1, user_name=aa\x80\x00\x00\x00. \ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x70 и role=admin, как показано на следующем рисунке:
Хэш-значение: 84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0. Далее можно вызвать интерфейс adminActionHandler.После получения данных сервер сравнит загруженный хеш с sha256 (SecretKey+fakeData), и после прохождения проверки выполнит некоторые чувствительные операции. Таким образом, мы успешно использовали атаку расширения длины, чтобы обойти проверку на стороне сервера и добиться несанкционированных операций.
Другие возможные сценарии атак
1. Проверка целостности файла. Если целостность файла проверяется путем объединения ключа и содержимого файла, а затем его хеширования, злоумышленник может расширить файл и сгенерировать действительный хэш, тем самым минуя проверку целостности. ;
2. Безопасность веб-приложений. Если в веб-приложениях для проверки данных, отправленных пользователем, используется хеш-функция, чувствительная к атакам с расширением длины, злоумышленники могут воспользоваться этим для передачи вредоносных данных;
3. Цифровые подписи: В некоторых схемах цифровых подписей, если подпись создается путем объединения закрытого ключа и сообщения и последующего хеширования, злоумышленник может расширить сообщение и создать действительную подпись;
**4. Хранение паролей: **Хотя это и редкость, но если пароль хранится путем объединения ключа (например, соли) и пароля, а затем его хэширования, злоумышленник может попытаться взломать его, используя пароль для атаки с расширением длины.
Как предотвратить
1. Выберите хеш-функцию, которая не подвержена атакам расширения длины, например SHA-3;
**2. Используйте HMAC: **HMAC требует в качестве входных данных ключ и сообщение, а выходные результаты зависят как от ключа, так и от сообщения, поэтому злоумышленник не может выполнять атаки с расширением длины, не зная ключа;
**3. Усиление проверки полномочий: **Добавьте дополнительные этапы проверки полномочий на стороне сервера, например использование многофакторной аутентификации.
Ниже приведены характеристики некоторых часто используемых алгоритмов хеширования:
|Алгоритм |Сопротивление столкновению |Атака столкновением с выбранным префиксом |Сопротивление прообразу |Атака удлинением длины | | --- | --- | --- | --- | --- | |MD5 | 2^18 | 2^39 | 2^123,4 |Уязвимый | | SHA-1 | 2^61,2 | 2^63,4 | 2^160 | Уязвимый | |SHA-256 (SHA-2) |2^65,5 | - |2^254,9 |Уязвимый| |SHA-512 (SHA-2) |2^32,5 |- |2^511,5 |Уязвимый| | SHA-3 | 2^50 | - | Неизвестно | Не уязвимо | | BLAKE2s | 2^112 | - | 2^241 | Не уязвим | | BLAKE2b | 2^224 | - | 2^481 | Не уязвим |
Заключение
Эффективной защитой от атак расширения длины является использование хеш-функций, устойчивых к таким атакам, таких как SHA-3 и BLAKE2. Кроме того, его также можно защитить с помощью структуры HMAC (код аутентификации хешированного сообщения с ключом). Эти меры могут эффективно повысить безопасность системы и обеспечить целостность данных и стабильность приложений.
Справочная ссылка:
[1]
[2]