ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Привет, я уже пятый раз выступаю на Black Hat USA и DEFCON. Вы можете получить копию слайда и видео здесь:
CVE-2022-22025 — DoS-наводнение хэшей Microsoft IIS
CVE-2022-22040 — атака с отравлением кэша Microsoft IIS
CVE-2022-30209 — Обход аутентификации Microsoft IIS
PS Все уязвимости, рассмотренные в этом блоге, были ответственно отправлены в Microsoft и исправлены в июле 2022 года.
1. DoS-атака IIS с хэш-флудом
Трудно представить, что мы все еще можем увидеть такую классическую атаку алгоритмической сложности, как атака Hash-Flooding в IIS в 2022 году. Хотя Microsoft настроила поток, удаляющий устаревшие записи каждые 30 секунд, чтобы смягчить атаку, мы все же обнаружили ошибку разделения ключей. в реализации, чтобы усилить нашу силу более чем в 10 раз, чтобы победить Стража с помощью нулевого хэша . Из-за этой ошибки мы можем сделать установленный по умолчанию сервер IIS не отвечающим примерно с 30 подключениями в секунду!
Поскольку эта ошибка также соответствует требованиям программы Windows Insider Preview Bounty Program , мы также вознаградили 30 000 долларов США за этот DoS. Это максимальная награда для категории Denial-of-Service!
Вы можете посмотреть полное демонстрационное видео здесь:
2. Атака отравления кэша IIS
По сравнению с другими замечательными исследованиями Cache Poisoning, это относительно простое исследование. Ошибка обнаружена в компоненте кэширования вывода, модуле, отвечающем за кеширование динамических ответов для уменьшения дорогостоящего доступа к базе данных или файловой системе в веб-стеках. Кэширование вывода использует неверный синтаксический анализатор строки запроса, который принимает только первое вхождение в качестве ключа кэша, когда ключи строки запроса дублируются. Такое поведение на самом деле не является проблемой самостоятельно. Однако это проблема с точки зрения всей архитектуры с серверной частью ASP.NET. Серверная часть объединяет значения всех повторяющихся ключей вместе, что приводит к несоответствию поведения парсеров. Таким образом, классическое загрязнение параметров HTTP может привести к неправильному результату кэширования IIS !
3. Обход аутентификации IIS
Это может быть самая интересная ошибка этого доклада. LKRHash — это алгоритм хеш-таблицы, разработанный и запатентованный Microsoft в 1997 году. Он основан на линейном хешировании и создан Полом Ларсоном из Microsoft Research, Мурали Кришнаном и Джорджем Рейли из команды IIS.
Целью LKRHash является создание масштабируемой и высококонкурентной хеш-таблицы в многопоточной и многоядерной среде. Создатели приложили много усилий, чтобы сделать эту реализацию портативной, гибкой и настраиваемой для адаптации к различным продуктам Microsoft. Приложение может определять свои собственные функции, связанные с таблицами, такие как хеш-функция, функция извлечения ключей или функция сравнения ключей. Такая расширяемость создает множество возможностей для поиска уязвимостей. Таким образом, в этом контексте нас больше заботит взаимосвязь между записями, ключами и функциями.
Поскольку «Вход в систему» является дорогостоящей операцией, для повышения производительности IIS кэшировал все токены для аутентификации на основе пароля, такой как обычная аутентификация по умолчанию, и ошибка, которую мы обнаружили на этот раз, находится в логике функции сравнения ключей, когда происходит столкновение.
Если попытка входа в систему, хэш которой попадает в ключ, который уже находится в кеше, LKRHash входит в специфичный для приложения pfnEqualKeysфункция, чтобы определить, является ли ключ правильным или нет. Логика конкретного приложения TokenCacheModuleсоставляет:
Моя любимая ошибка среди представленных сегодня уязвимостей!
Первоначальная цель состояла в том, чтобы сравнить пароль. Однако разработчик скопировал и вставил код, но забыл заменить имя переменной. Это приводит к обходу аутентификации в IIS. pic.twitter.com/NLDDLQNYX2 Поскольку логика сравнивает несколько частей для принятия решения, странно, почему IIS сравнивает имя пользователя дважды.
Я предполагаю, что первоначальная цель состояла в том, чтобы сравнить пароль. Однако разработчик скопировал и вставил код, но забыл заменить имя переменной. Это приводит к тому, что злоумышленник может повторно использовать токен другого пользователя, вошедшего в систему, со случайными паролями.
Чтобы создать наименьшую PoC для тестирования, вы можете создать тестовую учетную запись и настроить обычную аутентификацию в IIS.
Под терминалом злоумышленника:
Как видите, злоумышленник может войти в систему под пользователем orangeс другим паролем, хэш которого совпадает с исходным.
Однако столкнуться с хешем непросто. Вероятность каждой попытки составляет всего 1/2^32, потому что хэш представляет собой 32-битное целое число, и злоумышленник не может узнать хэш существующих ключей кэша. Это смехотворная цифра, чтобы использовать эту ошибку как игру в лотерею. Единственный плюс в том, что попытка ничего не стоит, и у вас есть неограниченное количество попыток! Чтобы сделать этот баг более практичным, мы предложили несколько способов выиграть в лотерею, например:
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Привет, я уже пятый раз выступаю на Black Hat USA и DEFCON. Вы можете получить копию слайда и видео здесь:
- Потанцуем в кеше: дестабилизация хеш-таблицы в Microsoft IIS (слайды)
- Давайте потанцуем в кеше — дестабилизация хеш-таблицы в Microsoft IIS (видео — подлежит уточнению)
CVE-2022-22025 — DoS-наводнение хэшей Microsoft IIS
CVE-2022-22040 — атака с отравлением кэша Microsoft IIS
CVE-2022-30209 — Обход аутентификации Microsoft IIS
PS Все уязвимости, рассмотренные в этом блоге, были ответственно отправлены в Microsoft и исправлены в июле 2022 года.
1. DoS-атака IIS с хэш-флудом
Трудно представить, что мы все еще можем увидеть такую классическую атаку алгоритмической сложности, как атака Hash-Flooding в IIS в 2022 году. Хотя Microsoft настроила поток, удаляющий устаревшие записи каждые 30 секунд, чтобы смягчить атаку, мы все же обнаружили ошибку разделения ключей. в реализации, чтобы усилить нашу силу более чем в 10 раз, чтобы победить Стража с помощью нулевого хэша . Из-за этой ошибки мы можем сделать установленный по умолчанию сервер IIS не отвечающим примерно с 30 подключениями в секунду!
Поскольку эта ошибка также соответствует требованиям программы Windows Insider Preview Bounty Program , мы также вознаградили 30 000 долларов США за этот DoS. Это максимальная награда для категории Denial-of-Service!
Вы можете посмотреть полное демонстрационное видео здесь:
2. Атака отравления кэша IIS
По сравнению с другими замечательными исследованиями Cache Poisoning, это относительно простое исследование. Ошибка обнаружена в компоненте кэширования вывода, модуле, отвечающем за кеширование динамических ответов для уменьшения дорогостоящего доступа к базе данных или файловой системе в веб-стеках. Кэширование вывода использует неверный синтаксический анализатор строки запроса, который принимает только первое вхождение в качестве ключа кэша, когда ключи строки запроса дублируются. Такое поведение на самом деле не является проблемой самостоятельно. Однако это проблема с точки зрения всей архитектуры с серверной частью ASP.NET. Серверная часть объединяет значения всех повторяющихся ключей вместе, что приводит к несоответствию поведения парсеров. Таким образом, классическое загрязнение параметров HTTP может привести к неправильному результату кэширования IIS !
3. Обход аутентификации IIS
Это может быть самая интересная ошибка этого доклада. LKRHash — это алгоритм хеш-таблицы, разработанный и запатентованный Microsoft в 1997 году. Он основан на линейном хешировании и создан Полом Ларсоном из Microsoft Research, Мурали Кришнаном и Джорджем Рейли из команды IIS.
Целью LKRHash является создание масштабируемой и высококонкурентной хеш-таблицы в многопоточной и многоядерной среде. Создатели приложили много усилий, чтобы сделать эту реализацию портативной, гибкой и настраиваемой для адаптации к различным продуктам Microsoft. Приложение может определять свои собственные функции, связанные с таблицами, такие как хеш-функция, функция извлечения ключей или функция сравнения ключей. Такая расширяемость создает множество возможностей для поиска уязвимостей. Таким образом, в этом контексте нас больше заботит взаимосвязь между записями, ключами и функциями.
Код:
CLKRHashTable::CLKRHashTable(
this,
"TOKEN_CACHE", // An identifier for debugging
pfnExtractKey, // Extract key from record
pfnCalcKeyHash, // Calculate hash signature of key
pfnEqualKeys, // Compare two keys
pfnAddRefRecord, // AddRef in FindKey, etc
4.0, // Bound on the average chain length.
1, // Initial size of hash table.
0, // Number of subordinate hash tables.
0 // Allow multiple identical keys?
);Если попытка входа в систему, хэш которой попадает в ключ, который уже находится в кеше, LKRHash входит в специфичный для приложения pfnEqualKeysфункция, чтобы определить, является ли ключ правильным или нет. Логика конкретного приложения TokenCacheModuleсоставляет:
Моя любимая ошибка среди представленных сегодня уязвимостей!
Первоначальная цель состояла в том, чтобы сравнить пароль. Однако разработчик скопировал и вставил код, но забыл заменить имя переменной. Это приводит к обходу аутентификации в IIS. pic.twitter.com/NLDDLQNYX2 Поскольку логика сравнивает несколько частей для принятия решения, странно, почему IIS сравнивает имя пользователя дважды.
Я предполагаю, что первоначальная цель состояла в том, чтобы сравнить пароль. Однако разработчик скопировал и вставил код, но забыл заменить имя переменной. Это приводит к тому, что злоумышленник может повторно использовать токен другого пользователя, вошедшего в систему, со случайными паролями.
Чтобы создать наименьшую PoC для тестирования, вы можете создать тестовую учетную запись и настроить обычную аутентификацию в IIS.
Код:
# add a test account, please ensure to remove that after testing
> net user orange test-for-CVE-2022-30209-auth-bypass /add
# the source of login is not important, this can be done outside IIS.
> curl -I -su 'orange:test-for-CVE-2022-30209-auth-bypass' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK
Код:
# script for sanity check
> type test.py
def HashString(password):
j = 0
for c in map(ord, password):
j = c + (101*j)&0xffffffff
return j
assert HashString('test-for-CVE-2022-30209-auth-bypass') == HashString('ZeeiJT')
# before the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 401 Unauthorized
# after the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OKОднако столкнуться с хешем непросто. Вероятность каждой попытки составляет всего 1/2^32, потому что хэш представляет собой 32-битное целое число, и злоумышленник не может узнать хэш существующих ключей кэша. Это смехотворная цифра, чтобы использовать эту ошибку как игру в лотерею. Единственный плюс в том, что попытка ничего не стоит, и у вас есть неограниченное количество попыток! Чтобы сделать этот баг более практичным, мы предложили несколько способов выиграть в лотерею, например:
- Увеличьте вероятность коллизий — LKRHash объединил LCG, чтобы зашифровать результат, чтобы сделать хэш более случайным. Однако мы можем уменьшить пространство ключей, потому что LCG не является однозначным отображением для 32-битного целого числа. Должны быть результаты, которые никогда не появятся, чтобы мы могли предварительно вычислить словарь, исключающий пароль, хэш которого отсутствует в результатах, и увеличить вероятность успеха как минимум на 13% !
- Вернуть инициативу. Поняв первопричину, мы обдумываем несколько вариантов использования, которые могут навсегда кэшировать токен в памяти и больше не ждать взаимодействия с пользователем , например функция IIS « Подключиться как » или использование шаблонов проектирования программного обеспечения.