В конце августа Imperva оповестила клиентов сервиса Cloud WAF (бывш. Incapsula) об утечке конфиденциальной информации и инициировала сброс паролей учетных записей. Оказалось, что посторонние получили доступ к хешам паролей, ключам API и SSL-сертификатам.
10 октября исполнительный директор компании Крис Хайлен (Chris Hylen) и технический директор Кунаи Ананд (Kunal Anand) изложили post mortem с деталями инцидента. Как такое могло произойти у компании, которая специализируется на защите данных и приложений?
Если резюмировать, проблема возникла из-за некорректной миграции БД с собственного хостинга на Amazon Web Services.
В своем сообщении Крис Хайлен перечисляет ряд ошибок, сделанных во время миграции. Все вместе, они позволили неизвестным украсть админский ключ API к одному из аккаунтов в продакшне на Amazon Web Services. Расследование показало, что неавторизованный доступ произошёл ещё в октябре 2018 года.
Админский ключ дал злоумышленнику доступ к снимку БД с различными сведениями о клиентах, которые зарегистрировались до 15 сентября 2017 года. Информация включала адреса электронной почты, хэшированные и солёные пароли, а для некоторого количества клиентов — ключи API и предоставленные клиентами SSL-сертификаты.
По словам технического директора, всё началось в 2017 году, когда компания начала рассматривать переход на сервис реляционных баз данных AWS (Relational Database Service, RDS), поскольку система Incapsula «находилась под значительной нагрузкой из-за привлечения новых клиентов и удовлетворения их критических требований». Переход на облачный хостинг требовался для масштабирования бизнеса.
Однако «некоторые ключевые решения, принятые в процессе оценки AWS, в сумме позволили извлечь информацию из снапшота базы данных».
Одно из таких фатальных решений — само создание этого снапшота.
Другая ошибка — создание внутреннего вычислительного инстанса с ключом AWS API, к которому пользователи могли получить доступ извне.
Таким образом, злоумышленник смог скомпрометировать инстанс, украсть ключ и использовать его для доступа к моментальному снимку базы данных.
Хотя утечка данных состоялась в октябре 2018 года, Imperva узнала о взломе только 20 августа 2019 года, когда третья сторона прислала компании набор данных с её серверов, требуя вознаграждения по программе bug bounty. Компания Imperva утверждает, что эта третья сторона ранее была ей не известна: «Мы сравнили дамп базы SQL в представленном датасете с нашими снапшотами — и нашли совпадение. На данный момент мы можем сказать, что элементы данных клиентов ограничены учётными записями WAF до 15 сентября 2017 года. Базы данных и снапшоты других наших продуктов не были эксфильтрированы».
В соответствии с законом GDPR, компания в установленном порядке уведомила правоохранительные органы и соответствующих регуляторов. Проверка базы данных и оценка ущерба заняла несколько недель. После этого Imperva публично разгласила информацию об инциденте.
Imperva подчёркивает, что её собственный продукт для мониторинга активности базы данных Database Activity Monitoring (DAM) в 2017 году не поддерживал AWS RDS (как и любые другие облачные хостинги) и поэтому не использовался внутри компании. Только в 2019 году была разработана подходящая для PaaS система Cloud Data Security (CDS), которая сейчас применяется в том числе для мониторинга Cloud WAF.
Ананд говорит, что Imperva предприняла некоторые шаги для предотвращения будущих инцидентов, в том числе:
Мультифакторная аутентификация для консоли управления AWS была подключена ещё раньше. Однако, по словам Ананда, она бы не предотвратила несанкционированный доступ к ключу API.
Технический директор заявил, что благодаря улучшениям в области внутреннего контроля сегодня невозможно повторение такой утечки. Новая система Imperva будет сразу сигнализировать в случае обнаружения уязвимых инстансов и снапшотов БД, подобных тем, что привели к взлому 2018 года. Дело в том, что системы журналирования AWS CloudTrail и GuardDuty работали и раньше, и они записали в логи несанкционированную активность, просто не сигнализировали об этом.
По словам CTO, в процессе расследования происшествия компания не обнаружила никаких других уязвимостей и не знает о какой-либо вредоносной деятельности злоумышленников по отношению к клиентам, которые стали жертвами утечки данных.
«В самом начале нашего расследования мы сразу уведомили наших клиентов, чтобы они могли принимать обоснованные решения и действовать в соответствии с мерами безопасности, которые мы рекомендовали. Благодаря этим рекомендациям наши клиенты изменили более 13 000 паролей, поменяли более 13 500 сертификатов SSL и восстановили более 1400 ключей API, — сказал Ананд. — Наша миссия остаётся прежней: от имени наших клиентов и их пользователей возглавлять мировую борьбу за защиту данных и приложений от киберпреступников».
Для справки. Imperva — один ведущих в мире поставщиков решений в области защиты веб-приложений и данных (CDN, облачный файрвол, обратный прокси, защита от DDoS-атак и так далее).
Компания основана в 2002 году, количество сотрудников превышает 1000 человек, годовой доход: $321,7 млн (2017 год). С 2011 года акции компании торговались на Нью-Йоркской фондовой бирже, но в январе 2019 года её полностью выкупила частная инвестиционная фирма Thoma Bravo, которая специализируется на скупке технологических и софтверных компаний.
Сложно сказать, как произошедший инцидент повлияет на имидж Imperva и насколько он угрожает бизнесу. Определённо, количество клиентов не вырастет, а имидж подпорчен.
Никто не застрахован от ошибок DevOps, тем более в сложном деле настройки облачных инстансов. Но от кого менее всех ожидали таких ошибок — так это от Imperva.
«Мы принимаем на себя ответственность за то, что инцидент стал результатом нашего выбора, действий, которые мы предприняли или не предприняли до, во время и после миграции базы данных. Мы рекомендуем всем организациям уделить время, чтобы полностью осознать общую ответственность за развёртывание и управление приложениями и данными в решениях Infrastructure as a Service (IaaS), — сказал технический директор Imperva. — С безопасностью никогда нельзя ”закончить”. Мы должны каждый день продолжать работу — оценивать и улучшать свои процессы».
10 октября исполнительный директор компании Крис Хайлен (Chris Hylen) и технический директор Кунаи Ананд (Kunal Anand) изложили post mortem с деталями инцидента. Как такое могло произойти у компании, которая специализируется на защите данных и приложений?
Если резюмировать, проблема возникла из-за некорректной миграции БД с собственного хостинга на Amazon Web Services.
В своем сообщении Крис Хайлен перечисляет ряд ошибок, сделанных во время миграции. Все вместе, они позволили неизвестным украсть админский ключ API к одному из аккаунтов в продакшне на Amazon Web Services. Расследование показало, что неавторизованный доступ произошёл ещё в октябре 2018 года.
Админский ключ дал злоумышленнику доступ к снимку БД с различными сведениями о клиентах, которые зарегистрировались до 15 сентября 2017 года. Информация включала адреса электронной почты, хэшированные и солёные пароли, а для некоторого количества клиентов — ключи API и предоставленные клиентами SSL-сертификаты.
Хронология неудачи
По словам технического директора, всё началось в 2017 году, когда компания начала рассматривать переход на сервис реляционных баз данных AWS (Relational Database Service, RDS), поскольку система Incapsula «находилась под значительной нагрузкой из-за привлечения новых клиентов и удовлетворения их критических требований». Переход на облачный хостинг требовался для масштабирования бизнеса.
Однако «некоторые ключевые решения, принятые в процессе оценки AWS, в сумме позволили извлечь информацию из снапшота базы данных».
Одно из таких фатальных решений — само создание этого снапшота.
Другая ошибка — создание внутреннего вычислительного инстанса с ключом AWS API, к которому пользователи могли получить доступ извне.
Таким образом, злоумышленник смог скомпрометировать инстанс, украсть ключ и использовать его для доступа к моментальному снимку базы данных.
Хотя утечка данных состоялась в октябре 2018 года, Imperva узнала о взломе только 20 августа 2019 года, когда третья сторона прислала компании набор данных с её серверов, требуя вознаграждения по программе bug bounty. Компания Imperva утверждает, что эта третья сторона ранее была ей не известна: «Мы сравнили дамп базы SQL в представленном датасете с нашими снапшотами — и нашли совпадение. На данный момент мы можем сказать, что элементы данных клиентов ограничены учётными записями WAF до 15 сентября 2017 года. Базы данных и снапшоты других наших продуктов не были эксфильтрированы».
В соответствии с законом GDPR, компания в установленном порядке уведомила правоохранительные органы и соответствующих регуляторов. Проверка базы данных и оценка ущерба заняла несколько недель. После этого Imperva публично разгласила информацию об инциденте.
Imperva подчёркивает, что её собственный продукт для мониторинга активности базы данных Database Activity Monitoring (DAM) в 2017 году не поддерживал AWS RDS (как и любые другие облачные хостинги) и поэтому не использовался внутри компании. Только в 2019 году была разработана подходящая для PaaS система Cloud Data Security (CDS), которая сейчас применяется в том числе для мониторинга Cloud WAF.
Уроки на будущее
Ананд говорит, что Imperva предприняла некоторые шаги для предотвращения будущих инцидентов, в том числе:
- усиление контроля доступа;
- увеличение числа проверок доступа к «моментальным снимкам»;
- вывод из эксплуатации неактивных инстансов (включая скомпрометированный);
- размещение активных вычислительных инстансов за VPN по умолчанию;
- мониторинг программного обеспечения и установка патчей без промедления;
- периодическая смена учётных данных и ключей;
- улучшенный контроль управления учётными данными;
- увеличение частоты сканирования инфраструктуры.
Мультифакторная аутентификация для консоли управления AWS была подключена ещё раньше. Однако, по словам Ананда, она бы не предотвратила несанкционированный доступ к ключу API.
Технический директор заявил, что благодаря улучшениям в области внутреннего контроля сегодня невозможно повторение такой утечки. Новая система Imperva будет сразу сигнализировать в случае обнаружения уязвимых инстансов и снапшотов БД, подобных тем, что привели к взлому 2018 года. Дело в том, что системы журналирования AWS CloudTrail и GuardDuty работали и раньше, и они записали в логи несанкционированную активность, просто не сигнализировали об этом.
По словам CTO, в процессе расследования происшествия компания не обнаружила никаких других уязвимостей и не знает о какой-либо вредоносной деятельности злоумышленников по отношению к клиентам, которые стали жертвами утечки данных.
«В самом начале нашего расследования мы сразу уведомили наших клиентов, чтобы они могли принимать обоснованные решения и действовать в соответствии с мерами безопасности, которые мы рекомендовали. Благодаря этим рекомендациям наши клиенты изменили более 13 000 паролей, поменяли более 13 500 сертификатов SSL и восстановили более 1400 ключей API, — сказал Ананд. — Наша миссия остаётся прежней: от имени наших клиентов и их пользователей возглавлять мировую борьбу за защиту данных и приложений от киберпреступников».
Для справки. Imperva — один ведущих в мире поставщиков решений в области защиты веб-приложений и данных (CDN, облачный файрвол, обратный прокси, защита от DDoS-атак и так далее).
Компания основана в 2002 году, количество сотрудников превышает 1000 человек, годовой доход: $321,7 млн (2017 год). С 2011 года акции компании торговались на Нью-Йоркской фондовой бирже, но в январе 2019 года её полностью выкупила частная инвестиционная фирма Thoma Bravo, которая специализируется на скупке технологических и софтверных компаний.
Сложно сказать, как произошедший инцидент повлияет на имидж Imperva и насколько он угрожает бизнесу. Определённо, количество клиентов не вырастет, а имидж подпорчен.
Никто не застрахован от ошибок DevOps, тем более в сложном деле настройки облачных инстансов. Но от кого менее всех ожидали таких ошибок — так это от Imperva.
«Мы принимаем на себя ответственность за то, что инцидент стал результатом нашего выбора, действий, которые мы предприняли или не предприняли до, во время и после миграции базы данных. Мы рекомендуем всем организациям уделить время, чтобы полностью осознать общую ответственность за развёртывание и управление приложениями и данными в решениях Infrastructure as a Service (IaaS), — сказал технический директор Imperva. — С безопасностью никогда нельзя ”закончить”. Мы должны каждый день продолжать работу — оценивать и улучшать свои процессы».
