Токсичные комбинации: как мелкие сбои приводят к большим утечкам

В 3 часа ночи один IP-адрес запросил страницу входа. Безобидно. Но затем с нескольких хостов и по различным путям один и тот же источник начал добавлять ?debug=true — признак того, что злоумышленник зондирует окружение, чтобы оценить технологический стек и спланировать взлом.

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

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

«Токсичную комбинацию» можно определить несколькими способами, но вот практичное определение, основанное на том, как мы анализируем наши собственные наборы данных. Большинство веб-атак в конечном итоге масштабируются за счёт автоматизации; как только злоумышленник находит жизнеспособную эксплуатацию, он обычно превращает её в скрипт для бота, чтобы завершить работу. Анализируя пересечение трафика ботов, определённых путей приложения, аномалий запросов и ошибок конфигурации, мы можем обнаружить потенциальный взлом. Мы используем эту структуру для анализа миллионов запросов в секунду.

Хотя точечные средства защиты, такие как Межсетевые экраны веб-приложений (WAF), обнаружение ботов и защита API, эволюционировали, включив поведенческие шаблоны и репутационные сигналы, они по-прежнему в основном сосредоточены на оценке риска отдельного запроса. В отличие от них, обнаружение Cloudflare «токсичных комбинаций» смещает фокус на более широкий умысел, анализируя совокупность контекста, окружающего множество сигналов, чтобы выявить назревающий инцидент.

^{Токсичные комбинации как контекстуальные обнаружения}

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

• Сигналы ботов

• Пути приложений, особенно чувствительные: административные, отладка, метрики, поиск, процессы оплаты

• Аномалии, включая: неожиданные HTTP-коды, географические скачки, несоответствие идентичности, высокая смена ID, обход ограничения скорости (распределённые IP-адреса, делающие одно и то же), всплески запросов или успешных операций

• Уязвимости или ошибки конфигурации: отсутствующие сессионные куки или заголовки аутентификации, предсказуемые идентификаторы

Мы изучили 24-часовое окно данных Cloudflare, чтобы увидеть, как часто эти паттерны действительно появляются в популярных стеках приложений. Как показано в таблице ниже, около 11% проанализированных нами хостов были подвержены этим комбинациям, с перекосом из-за уязвимых сайтов WordPress. Исключая сайты WordPress, только 0,25% хостов показывают признаки эксплуатируемых токсичных комбинаций. Хотя они редки, они представляют хосты, уязвимые для компрометации.

Чтобы осмыслить данные, мы разбили их на три этапа атаки:

• Примерное количество хостов, подвергшихся зондированию: Это «широкий охват». Подсчитываются уникальные хосты, где мы видели HTTP-запросы к определённым чувствительным путям (например, /wp-admin).

• Примерное количество хостов, отфильтрованных по токсичной комбинации: Здесь мы сузили список до конкретных хостов, которые действительно соответствовали нашим критериям токсичной комбинации.

• Примерное количество достижимых хостов: Уникальные хосты, которые успешно ответили на попытку эксплуатации — «улика» атаки. Простой ответ 200 OK (например, вызванный добавлением ?debug=true) может быть ложным срабатыванием. Мы проверяли пути, чтобы отфильтровать шум, вызванный аутентифицированными путями, требующими учётных данных, несмотря на статус 200, редиректами, маскирующими истинный путь эксплуатации, и ошибками конфигурации источника, которые возвращают успешные коды для недостижимых путей.

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

Таблица 1. Сводка по токсичным комбинациям

Мы наблюдали, как автоматизированные инструменты сканируют распространённые административные страницы входа — такие как панели администрирования WordPress (/wp-admin), менеджеры баз данных и серверные дашборды. Шаблонная версия запроса, исполняемая в Cloudflare Log Explorer, приведена ниже:

SELECT
  clientRequestHTTPHost,
  COUNT(*) AS request_count
FROM
  http_requests 
WHERE
  timestamp >= '{{START_DATE}}'
  AND timestamp <= '{{END_DATE}}'
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '{{PATH_PATTERN}}' //например, '%/wp-admin/%'
  AND NOT match( extract(clientRequestHTTPHost, '^[^:/]+'), '^\d{1,3}(\.\d{1,3}){3}(:\d+)?$') // закомментируйте эту строку для Cloudflare Log Explorer
  AND botScore < {{BOT_THRESHOLD}} // мы использовали botScore < 30
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

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

• Сканированию на наличие эксплойтов: Злоумышленники определяют конкретную версию программного обеспечения, которое вы используете (например, Tomcat или WordPress), и запускают целевые эксплойты для известных уязвимостей (CVE).

• Перечислению пользователей: Многие административные панели случайно раскрывают действительные имена пользователей, что помогает злоумышленникам создавать более убедительные фишинговые или логин-атаки.

Токсичная комбинация автоматизации ботов и открытых интерфейсов управления, таких как: /wp-admin/, /admin/, /administrator/, /actuator/*, /_search/, /phpmyadmin/, /manager/html/ и /app/kibana/.

1. Внедрите Zero Trust Access.

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

3. Внедрите список разрешённых IP-адресов: Используйте свой WAF или конфигурацию сервера, чтобы гарантировать, что административные пути доступны только из корпоративной VPN или определённых офисных IP-адресов.

4. Сокройте административные пути: Если ваша платформа позволяет, переименуйте административные URL-адреса по умолчанию (например, измените /wp-admin на уникальную, не угадываемую строку).

5. Разверните геоблокировку: Если ваши администраторы работают только из определённых стран, блокируйте весь трафик к этим чувствительным путям, поступающий из-за пределов этих регионов.

6. Внедрите многофакторную аутентификацию (MFA): Убедитесь, что каждая точка входа для администраторов требует второго фактора; одного пароля недостаточно, чтобы остановить целевого краулера.

Мы обнаружили API-эндпоинты, доступные любому пользователю в Интернете без пароля или входа в систему (см. OWASP: API2:2023 – Broken Authentication (Сломанная аутентификация)). Что еще хуже, способ идентификации записей (с использованием простых, предсказуемых числовых идентификаторов, см. OWASP: API1:2023- Broken Object Level Authorization (Сломанная авторизация на уровне объектов)) позволяет любому просто "перебирать" вашу базу данных — что значительно упрощает злоумышленникам перечисление и "скрапинг" ваших бизнес-записей, даже без прямого посещения вашего сайта.

SELECT
  uniqExact(clientRequestHTTPHost) AS unique_host_count
FROM  http_requests
WHERE timestamp >= '2026-02-13'
  AND timestamp <= '2026-02-14'
  AND edgeResponseStatus = 200
  AND bmScore < 30
  AND (
       match(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'),  '^[0-9]{3,10}$')
    OR match(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)'), '^[0-9]{3,10}$')
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'))  BETWEEN 3 AND 8
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)')) BETWEEN 3 AND 8
  )

Это уязвимость типа "zero-exploit" (не требующая эксплойта), что означает, что злоумышленнику не нужно быть хакером, чтобы украсть ваши данные; ему просто нужно изменить число в веб-ссылке. Это приводит к:

• Массовой утечке данных: Крупномасштабный скрапинг всего вашего набора данных о клиентах.

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

• Регуляторным рискам: Серьезные нарушения конфиденциальности (GDPR/CCPA) из-за раскрытия конфиденциальной PII (персональных данных).

• Мошенничеству: Конкуренты или злоумышленники получают представление об объемах вашего бизнеса и клиентской базе.

Токсичное сочетание отсутствующих средств защиты и автоматизации, нацеленной на определенные API-эндпоинты.

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

1. Внедрите аутентификацию: Немедленно потребуйте действительную сессию или API-ключ для затронутого эндпоинта. Не разрешайте "Анонимный" доступ к данным, содержащим PII или коммерческие секреты.

2. Внедрите авторизацию (проверку на IDOR): Убедитесь, что бэкенд проверяет, имеет ли аутентифицированный пользователь разрешение на просмотр конкретного tid, который он запрашивает.

3. Используйте UUID: Замените предсказуемые, последовательные целочисленные ID на длинные случайные строки (UUID), чтобы сделать "угадывание" идентификаторов вычислительно невозможным.

4. Разверните API Shield: Включите API Shield от Cloudflare с такими функциями, как Проверка схемы (Schema Validation) (для блокировки неожиданных входных данных) и Обнаружение BOLA.

Мы обнаружили свидетельства добавления debug=true к веб-путям для раскрытия деталей системы. Шаблонная версия запроса, исполняемая в Cloudflare Log Explorer, приведена ниже:

SELECT
  clientRequestHTTPHost,
  COUNT(rayId) AS request_count
FROM
  http_requests
WHERE
  timestamp >= '{{START_TIMESTAMP}}'
  AND timestamp < '{{END_TIMESTAMP}}'
  AND edgeResponseStatus = 200
  AND clientRequestQuery LIKE '%debug=false%'
  AND botScore < {{BOT_THRESHOLD}}
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

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

• Скрытые поля данных: Конфиденциальная внутренняя информация, которая не должна быть видна пользователям.

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

• Подсказки о логике: Сообщения об ошибках или трассировки стека, которые объясняют, как именно работает ваш код, помогая найти способы его сломать.

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

Хотя запрос проверял показатель бота и пути с debug-параметрами, такие сигналы, как повторяющееся зондирование, размеры ответов и раскрытие схемы, были проверены на выборке трафика, соответствующего запросу. 

1. Отключите отладку в продакшене: Убедитесь, что все переменные окружения "debug" или "development" строго установлены в false в конфигурациях вашего рабочего развертывания.

2. Фильтруйте параметры на границе сети (edge): Используйте ваш WAF или API-шлюз, чтобы удалять известные debug-параметры (такие как ?debug=, ?test=, ?trace=) до того, как они достигнут ваших серверов приложений.

3. Очищайте ответы об ошибках: Настройте свои веб-серверы (Nginx, Apache и т.д.) так, чтобы они показывали общие страницы ошибок вместо детальных трассировок стека или внутренних системных сообщений.

4. Аудит правил Firebase/БД: Если вы используете Firebase или подобные NoSQL базы данных, убедитесь, что доступ по путям /.json ограничен строгими правилами безопасности, чтобы публичные пользователи не могли выгрузить всю схему или данные.

Мы обнаружили, что "проверки работоспособности" (health check) и панели мониторинга видны всему Интернету. В частности, пути типа /actuator/metrics отвечают любому, кто к ним обращается. Ниже представлен шаблон запроса, выполняемый в Cloudflare Log Explorer:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // пример
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

Почему это серьезно?

Хотя эти конечные точки обычно не раскрывают напрямую пароли клиентов, они предоставляют "чертежи" для сложной атаки. Их раскрытие приводит к следующему:

• Стратегический выбор времени: Злоумышленники могут отслеживать использование вашего ЦП и памяти в реальном времени, чтобы запустить атаку типа "отказ в обслуживании" (DoS) именно в момент, когда ваши системы уже испытывают нагрузку.

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

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

Токсичное сочетание неправильно настроенных элементов управления доступом и автоматизированной разведки, нацеленной на Актив/Путь: /actuator/metrics, /actuator/prometheus и /health.

1. Ограничьте доступ через WAF: Немедленно создайте правило межсетевого экрана, чтобы блокировать любой внешний трафик, запрашивающий пути, содержащие /actuator/ или /prometheus.

2. Привязка к localhost: Измените конфигурацию ваших фреймворков приложений, чтобы они обслуживали эти конечные точки мониторинга только на localhost (127.0.0.1) или в частной сети управления.

3. Внедрите базовую аутентификацию: Если к ним необходимо обращаться через Интернет, убедитесь, что они защищены надежной аутентификацией (как минимум, сложная базовая аутентификация или mTLS).

4. Отключите ненужные конечные точки: В Spring Boot или аналогичных фреймворках отключите любые функции "Actuator", которые не являются строго необходимыми для мониторинга в production-среде.

Конечные точки поиска (например, Elasticsearch или OpenSearch), обычно предназначенные для внутреннего использования, полностью открыты для публичного доступа. Шаблон запроса:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\d{1,3}(\.\d{1,3}){3}(:\d+)?$')
GROUP BY
  clientRequestHTTPHost

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

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

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

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

Мы наблюдаем токсичное сочетание неправильно настроенной доступности, автоматизированного трафика и перечисления данных, нацеленного на  /_search, /_cat/indices и /_cluster/health.

Хотя запрос проверял оценку бота и пути, такие сигналы, как повторяющиеся шаблоны запросов, размеры ответов и раскрытие схемы, были протестированы на выборке трафика, соответствующего запросу. 

1. Ограничьте сетевой доступ: Немедленно обновите настройки Межсетевого экрана/Групп безопасности, чтобы убедиться, что порты поиска (например, 9200, 9300) и пути доступны только с определенных внутренних IP-адресов.

2. Включите аутентификацию: Включите функции "Безопасности" для вашего поискового кластера (например, Shield или Search Guard), чтобы требовать действительных учетных данных для каждого вызова API.

3. Блокировка WAF: Разверните правило WAF для немедленной блокировки любого запроса, содержащего /_search, /_cat или /_cluster, поступающего из публичного Интернета.

4. Аудит на предмет утечки данных: Проверьте журналы вашей базы данных на наличие больших запросов "Scroll" или "Search" с неизвестных IP-адресов, чтобы точно определить, какой объем данных был извлечен.

Мы выявили злоумышленников, которые отправили вредоносный запрос — конкретно SQL-инъекцию, предназначенную для обмана баз данных. Ниже представлен шаблон запроса, выполняемый в Cloudflare Log Explorer:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

Это "тихий путь" к утечке данных. Поскольку система возвращала успешный код состояния (HTTP 200), такие атаки часто сливаются с легитимным трафиком. Если их не устранить, злоумышленник может:

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

• Похитить данные: Медленно осушить содержимое базы данных или раскрыть конфиденциальные секреты (например, API-ключи), передаваемые в URL.

• Оставаться невидимым: Большинство автоматических оповещений ищут "отклонённые" попытки; "успешную" эксплуатацию намного сложнее обнаружить в море логов.

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

1. Немедленное виртуальное исправление: Обновите правила WAF, чтобы явно блокировать обнаруженные SQL-шаблоны (например, временные зонды).

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

3. Устраните утечку секретов: Переместите все конфиденциальные данные из параметров URL в тело запроса или заголовки. Замените все ключи, отмеченные как скомпрометированные.

4. Аудит логов: Проверьте логи базы данных за период времени "HTTP 200" ответов, чтобы увидеть, были ли успешно извлечены какие-либо данные.

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

В платежных потоках (/payment, /checkout, /cart) мы обнаружили определенные часы дня, когда либо почасовой объем запросов от ботов, либо почасовой коэффициент успешности платежей превышал свое почасовое базовое значение за предыдущие 30 дней более чем на 3 стандартных отклонения. Это может быть связано с тестированием карт, когда злоумышленник пытается проверить множество украденных кредитов. Конечно, маркетинговые кампании могут вызывать всплески запросов, а сбои в платежах — внезапное падение коэффициента успешности.

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

Мы использовали сочетание сигналов ботов и аномалий на /payment, /checkout, /cart:

Используйте 30-дневный базовый уровень почасового объема запросов на платежных путях в качестве почасового лимита скорости для всех запросов с оценкой бота < 30 на платежных путях.

В платежных потоках (/payment, /checkout, /cart) мы обнаружили определенные часы дня, когда либо почасовой объем запросов от людей (или ботов, имитирующих людей), либо почасовой коэффициент успешности платежей превышал свое почасовое базовое значение за предыдущие 30 дней более чем на 3 стандартных отклонения. Это может быть связано с истощением карт, когда злоумышленник (люди или боты, имитирующие людей) пытается приобрести товары, используя действительные, но украденные кредиты. Конечно, маркетинговые кампании также могут вызывать всплески запросов и коэффициента успешности, поэтому дополнительный контекст в виде типичных платежных запросов с данного IP-адреса является важным, как показано на рисунке.

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

Мы использовали сочетание сигналов ботов и аномалий на /payment, /checkout, /cart:

Ограничение скорости на основе идентификатора: Используйте плотность IP для реализации ограничений скорости для запросов с оценкой бота >=30 на платежных конечных точках.

Мониторинг коэффициента успешности: Оповещайте о любом часе, когда коэффициент успешности для "человеческого" трафика с оценкой бота >=30 на платежных конечных точках отклоняется более чем на 3 стандартных отклонения от его 30-дневного базового уровня.

Проверка: Если запрос с высокой оценкой бота (вероятно, от человека) обращается к платежным потокам более 3 раз за 10 минут, инициируйте проверку, чтобы замедлить их.

В настоящее время мы работаем над интеграцией этих обнаружений "токсичных комбинаций" непосредственно в панель управления Security Insights, чтобы обеспечить немедленную видимость таких рисков. Наш план включает создание путей устранения угроз с помощью ИИ — где панель управления не просто показывает вам токсичную комбинацию, но и предлагает конкретное правило WAF или конфигурацию API Shield, необходимое для её нейтрализации.