Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Инциденты и уязвимости

Утечка Equifax (2017) — как неустановленное исправление Apache Struts привело к утечке данных 147M человек

Утечка Equifax (2017): данные ~147 млн человек. Причина — известная уязвимость Apache Struts (CVE-2017-5638, CVSS 10.0), оставленная без патча; истёкший сертификат мониторинга скрывал утечку 76 дней. Защита: инвентаризация и SLA на патчинг.

Опубликовано 2026-06-07 Обновлено 2026-06-07 8 мин чтения

Мы читаем реальные публичные инциденты не как повторный прогон новостей, а через призму «как бы вы от этого защитились». Эта статья основана на публичных материалах (регуляторы, официальные заявления, Apache Software Foundation, журналистика), ссылки приведены в конце.

147M
пострадавших
10.0
CVSS (наивысший класс)
76 дней
без обнаружения
$700M
мировое соглашение (крупнейшее в США)
Досье инцидента
Цель
Equifax (крупное кредитное бюро США)
Раскрытие
7 сентября 2017 (проникновение май–июль / обнаружено 29 июля)
Класс
проникновение через неустановленный известный CVE (Apache Struts RCE) + эксфильтрация
Масштаб
~147 млн человек в США (имена, SSN, даты рождения, адреса; часть номеров карт)
Первопричина
запущенный известный CVE + отсутствие инвентаризации активов + пробел в обнаружении (истёкший сертификат)
Настоящее исправление
SLA на патчинг, инвентаризация активов, машинный мониторинг, работоспособное обнаружение

Что произошло (простыми словами)

Equifax вёл онлайн-портал, где потребители оспаривают свою кредитную информацию. У лежащего под ним компонента Apache Struts была серьёзная уязвимость, позволявшая выполнение произвольного кода снаружи (CVE-2017-5638).

Исправление вышло в тот же день, когда уязвимость опубликовали (7 марта 2017). Но целевую систему оставили без патча. Двумя месяцами позже злоумышленник использовал известную дыру, продвинулся латерально по сети и эксфильтровал персональные данные в большом объёме.

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

Не «сложная атака», а «не установили»

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

Цепочка — это ещё и карта обороны

Важно, что это была цепочка из пяти шагов, и на каждом шаге было место для остановки. Читайте это как «где её можно было пресечь», а не как рецепт атаки.

① Опубликован известный CVE (исправление выпущено в тот же день)

⊘ остановка: машинно обнаруживать CVE, релевантные вам

② Публичная система оставлена без патча

Нет видимости, где работает Struts, поэтому он проскользнул сквозь сеть.

⊘ остановка: инвентаризация активов + SLA на патчинг (срок)

③ Проникновение через RCE

Выполнение произвольного кода через неустановленную дыру.

⊘ остановка: минимальные привилегии; WAF лишь как запасной слой

④ Латеральное движение по плоской сети, массовая эксфильтрация

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

⊘ остановка: сегментация сети сокращает радиус поражения

⑤ Незамечено 76 дней (истёкший сертификат мониторинга)

Устройство для обнаружения было выключено.

⊘ остановка: регулярные проверки работоспособности сертификатов/мониторинга

Каждую стадию можно было «остановить». Патч, знание активов, изоляция, обнаружение — отдельные слои, каждый страховка.

Хронология (по раскрытым данным)

  1. 2017-03-07

    Опубликован CVE-2017-5638; исправление выпущено в тот же день.
  2. 2017-03–

    Рассылается внутреннее уведомление, но целевая система остаётся без патча.
  3. 2017-05–07

    Злоумышленник эксплуатирует неустановленную дыру и эксфильтрует данные.
  4. 2017-07-29

    Сразу после обновления сертификата мониторинга обнаружен подозрительный трафик.
  5. 2017-09-07

    Публичное раскрытие; пострадали ~147 млн человек.
  6. 2019-07

    Мировое соглашение на сумму до ~$700 млн с FTC, CFPB и штатами (крупнейшее в своём роде).

Первопричина — не одно «не установили»

Закончить на «забыли про патч» — и это повторится. На деле несколько слоёв отказали последовательно.

Как было (на тот момент)

  • Запущенный известный CVE (исправление существовало, не применено к публичной системе)
  • Нет инвентаризации активов (не могли определить, где работает компонент)
  • Плоская сеть (позволила латеральное движение и распространение по данным)
  • Пробел в обнаружении (мониторинг выключен из-за истёкшего сертификата)

Как должно быть (профилактика)

  • SLA на патчинг: срок от публикации до применения, с приоритетом KEV / высокого CVSS
  • Инвентаризация активов: машинно отслеживать зависимости и где они работают
  • Сегментация сети: сократить радиус поражения от утечки
  • Работоспособное обнаружение: регулярно проверять, что сертификаты и мониторинг живы

«Патчинг» — это операция, а не разовое действие

Суть не в «исправим когда-нибудь», а в наличии срока (SLA): применить в течение N часов/дней от публикации. И чтобы не упустить цели, машина должна знать, что и где работает. Полагайтесь на память — и, как у Equifax, «всего одна коробка» останется забытой.

Как предотвратить это в вашей среде

Исправления в порядке приоритета, работающие в любом масштабе, с опорой на одно: не запускайте опубликованный CVE.

1

Ведите инвентаризацию активов (что и где работает)

Перечислите свои библиотеки-зависимости и то, какие сервисы/контейнеры их запускают. Крупнейшим промахом Equifax было упущение цели. Судите по реально работающей версии.

2

Установите SLA на патчинг (срок от публикации до применения)

Заранее решите «применять критические CVE в течение N дней от публикации». Приоритизируйте KEV (эксплуатируемые) и высокий CVSS. Срок делает «пренебрежение» видимым.

3

Доверьте мониторинг машинам (не гоняйтесь вручную)

Гоняться за CVE вручную невозможно. Проверяйте lock-файлы с помощью Dependabot (GitHub) или osv-scanner и авто-уведомляйте только о релевантных вам CVE. См. как построить мониторинг зависимостей.

4

Имейте изоляцию и обнаружение (страховка после удара)

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

Этот сайт делает это сам

Этот сайт держит собственные зависимости под мониторингом CVE, ровно как написано здесь. Урок Equifax — закрывайте известные дыры процессом, который люди не могут забыть — это убеждение продукта. Замените «исправим когда-нибудь» на «исправим в срок, с помощью машин».

Источники (публичные материалы)

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

  • Apache Software Foundation, "Media Alert: Equifax Data Breach Due to Failure to Install Patches" (2017) — news.apache.org
  • Equifax, "Releases Details on Cybersecurity Incident" (2017) — investor.equifax.com
  • CFPB/FTC/states settlement announcement (2019) — consumerfinance.gov
  • CSO Online, "Equifax data breach FAQ" — csoonline.com

Читать дальше

FAQ

QВ чём была первопричина утечки Equifax?
A

Не новая, изощрённая атака, а «известная, уже исправленная уязвимость (Apache Struts CVE-2017-5638 / CVSS 10.0), оставленная без установки в публичной системе». К тому же они не могли определить, где работает компонент, а устройство мониторинга было выключено из-за истёкшего сертификата, поэтому эксфильтрация оставалась незамеченной 76 дней.

QИсправление существовало — почему его не установили?
A

Согласно публичным материалам, исправление вышло в тот же день, когда уязвимость опубликовали (7 марта 2017). Внутреннее уведомление разослали, но патч не установили на целевую систему онлайн-споров. Недостаточная инвентаризация активов — «где работает этот компонент» — привела к тому, что он проскользнул.

QЕсть ли урок для небольших проектов?
A

Да. Независимо от масштаба, верны те же три пункта: не запускайте известные CVE, знайте, есть ли этот компонент в ваших зависимостях, и доверьте мониторинг машинам, чтобы ничего не упустить. Гоняться за CVE вручную невозможно — пусть следят Dependabot или osv-scanner.