Утечка данных сайтов BI.ZONE: результаты расследования и процесс реагирования
С чего все началось
30 апреля в 14:34 (мск) в телеграм-канале DumpForums опубликовали пост, в котором объявили о том, что «недавно была взломана компания bi.zone». К посту были прикреплены скриншоты с фрагментами конфигурационных файлов, SQL-дампов с персональными данными и перечнем конфиг-файлов с именами наших подсайтов.
Скриншот из поста в телеграм-канале DumpForums
Мы незамедлительно запустили реагирование на инцидент и его расследование. Перед нами стояли четыре задачи:
Понять, какие именно данные могут быть у злоумышленников.
Выяснить, как они получили к ним доступ.
Оценить возможность развития атаки в нашу инфраструктуру или в инфраструктуры наших клиентов.
Не допустить повторения подобной утечки.
Откуда были взяты данные
В первый же час реагирования мы выяснили, что выложенные злоумышленниками данные соответствуют данным, хранящимся на виртуальных серверах, где размещалась часть наших маркетинговых и информационных веб-ресурсов. Серверы не были задействованы в оказании коммерческих услуг.
Мы используем два таких сервера — DEV
и PROD
: аудитории «Хабра» несложно будет догадаться, что первый используется для разработки и тестирования ресурсов, второй — для их публикации.
Оба виртуальных сервера находятся в инфраструктуре стороннего хостинг-провайдера и не имеют какой-либо сетевой связности ни с инфраструктурой наших клиентов, ни с нашей внутренней инфраструктурой. Исключений два:
односторонний экспорт лидов с сайтов в нашу CRM-систему через API Gateway;
возможность отправки сообщений через наш почтовый релей.
Оба сервера находятся под мониторингом нашего SOC и защищены нашими EDR (BI.ZONE Sensors) и межсетевым экраном уровня приложений (BI.ZONE WAF).
Как злоумышленники выгрузили данные
В ходе расследования мы рассматривали три версии того, как злоумышленники могли получить доступ к данным сайтов и служебным файлам серверов:
Взлом виртуальных серверов (сперва мы считали ее основной, поскольку накануне инцидента BI.ZONE WAF фиксировал попытки эксплуатации уязвимостей для загрузки веб-шеллов).
Выгрузка резервных копий виртуальных серверов.
Взлом инфраструктуры хостинг-провайдера.
1. Взлом виртуальных серверов
Для проверки версии о взломе виртуальных серверов DEV
и PROD
мы исследовали множество артефактов с них.
В приоритет ставились гипотезы:
о подключении по протоколу SSH (путем подбора пароля или через компрометацию необходимых для аутентификации криптографических ключей);
загрузке на серверы веб-шеллов путем эксплуатации уязвимости в CMS »1С-Битрикс» (или в каком-либо скрипте вне этой CMS).
Тем не менее при исследовании мы искали признаки любой подозрительной активности на серверах.
В числе проверенных нами артефактов были:
журналы веб-серверов (мы искали в том числе попытки успешной эксплуатации уязвимостей, обращения к веб-шеллам);
журналы операционной системы, включая историю входов по протоколу SSH;
история введенных через шелл команд, история команд клиентов СУБД;
телеметрия, полученная от EDR-агентов, установленных на виртуальных серверах;
целостность исполняемых файлов (в том числе скриптов) — согласно эталонным хеш-значениям из RPM-пакетов;
подозрительные файлы скриптов в домашних директориях веб-сервисов (включая поддиректории), подозрительные файлы во временных директориях;
текущие прослушиваемые порты, текущие исходящие подключения;
текущий список процессов;
исполняемые файлы и скрипты, прописанные в автозагрузку;
списки учетных записей пользователей в операционной системе, наличие прописанных шеллов у сервисных учетных записей, отпечатки разрешенных SSH-ключей (для входящих подключений).
Проверка не выявила каких-либо следов взлома виртуальных серверов, а найденные подозрительные события оказались легитимной активностью.
Таким образом, гипотеза о взломе самих виртуальных серверов не подтвердилась.
2. Выгрузка резервных копий
Резервные копии виртуальных серверов хранились на FTP-сервере, администрируемом хостинг-провайдером, поэтому наши средства защиты на этом сервере не применялись. Логин и пароль для подключения к нему можно получить в открытом виде через панель управления ispmanager.
В ходе инвентаризации процессов на стороне хостинг-провайдера, связанных с виртуальными серверами, мы обнаружили, что 4 апреля в панель управления услугой резервного копирования был совершен вход с подозрительного IP-адреса.
Мы запросили у провайдера журналы доступа к этой панели — в них обнаружились нелегитимные события входа от 19 и 20 января, а также 4 апреля 2023 г.
История входов в панель управления ispmanager
Нам никогда не требовалось использовать эту панель — именно поэтому она, к сожалению, оказалась в слепой зоне. Поэтому же нет никаких сомнений в том, что указанные события входов не были инициированы со стороны наших сотрудников.
IP-адрес, с которого входили 4 апреля, принадлежит публичному VPN-сервису. Остальные четыре IP-адреса — с высокой вероятностью тоже, поскольку их подсети известны принадлежностью к VPN.
Мы направили уведомление хостинг-провайдеру о необходимости проверить панели других его клиентов на аналогичные инциденты.
Примечательно, что доступ 4 апреля 2023 г. осуществлялся с помощью браузера, в котором приоритетным задан украинский язык:
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: ACTION_NAME=file
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: AUTH_IP=156.146.50.4
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: AUTH_LEVEL=16
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: AUTH_METHOD=system
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: AUTH_USER=[удалено]
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: EVENT_TYPE=action
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTPS=on
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_ACCEPT=application/json, text/plain, /
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_ACCEPT_LANGUAGE=uk-UA, uk; q=0.8, en-US; q=0.5, en; q=0.3
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_CONNECTION=keep-alive
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_COOKIE=ispmgrses5=3095bde49ea4119c593a30ba; ispmgrlang5=dragon: en
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_HOST=[удалено]
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_ISP_CLIENT=Web-interface
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_REFERER=[удалено]
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_SEC_FETCH_DEST=empty
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_SEC_FETCH_MODE=cors
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_SEC_FETCH_SITE=same-origin
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: LANG=en_US.UTF-8
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: MGR_INTERNAL=ispmgr
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: MGR_NAME=ispmgr
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: PARAM_clickstat=yes
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: PARAM_func=file
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: PARAM_out=xjson
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: PARAM_p_cnt=1000
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: QUERY_STRING=out=xjson&func=file&clickstat=yes
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: RECORD_LIMIT=5000
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: REMOTE_ADDR=156.146.50.4
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: REMOTE_PORT=32308
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: REQUEST_METHOD=GET
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: REQUEST_URI=/ispmgr
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: SCRIPT_NAME=/ispmgr
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: SERVER_ADDR=[удалено]
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: SERVER_NAME=[удалено]
Apr 4 00:10:14 [1466:127106] core_module EXTINFO env: SERVER_PORT=1500
Вопрос, как злоумышленники получили реквизиты доступа к панели управления, пока остается открытым. Согласно предварительной информации от хостинг-провайдера, попыток перебора паролей к скомпрометированной учетной записи не зафиксировано — следовательно, пароль не был подобран злоумышленниками.
Реквизиты доступа для скомпрометированной учетной записи хостинг-провайдер высылал на два наших адреса электронной почты. При этом до выявления инцидента наши сотрудники не использовали панель управления услугой резервного копирования. Сейчас мы, помимо прочего, проверяем, где и как эти данные хранились на нашей стороне.
Узнав о факте несанкционированного доступа, мы стали считать версию с выгрузкой бэкапа приоритетной. Мы запросили у специалистов хостинг-провайдера сведения о предыдущих и текущих FTP-сессиях из-под нашей учетной записи. К сожалению, к моменту расследования история входов по FTP уже не была доступна.
3. Взлом инфраструктуры хостинг-провайдера
Хотя доказательства убедительно говорят в пользу версии с выгрузкой бэкапов виртуальных серверов, мы не отметаем полностью третье предположение. В частности, это может быть одним из объяснений утечки реквизитов доступа к панели ispmanager.
Мы планируем провести некоторые проверки по этой ветке расследования. Однако рассказать о них, к сожалению, мы сейчас не можем, так как инфраструктура хостинг-провайдера находится вне нашего административного контроля.
Какие данные утекли
Чувствительные данные в бэкапах
Чтобы понять масштабы утечки, мы исследуем данные с сервера бэкапов. Сейчас этот анализ продолжается, но мы уже готовы поделиться основными выводами.
Имя сервера | Сайт | Назначение сайта | Чувствительные данные |
---|---|---|---|
PROD |
| Сайт компании | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Данные некоторых форм для сбора обратной связи Данные некоторых форм для регистрации на вебинары |
| Промолендинг (закрыт) | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Данные некоторых форм для сбора обратной связи Данные некоторых форм для подключения сервиса PhishZone | |
| Сайт конференции | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Данные из заявок для выступления на конференции | |
| Сайт конференции (не используется, конференция не проводится уже несколько лет) | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Адреса эл. почты подписчиков рассылки | |
| Партнерский ресурс | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Данные форм для сбора обратной связи | |
| Интерактивная панель для конференции (не используется несколько лет) | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) Данные некоторых форм для сбора обратной связи | |
| Сайты конференций | Учетные данные администраторов сайта (эл. почта, пароли, хеши от паролей, ключи) | |
| |||
| Промолендинги (закрыты) | ||
| |||
| Партнерский ресурс (разработка остановлена в начале 2022 г., никогда не был запущен) | ||
| Сайт конференции | Данные не утекли, так как их резервное копирование не проводилось | |
| Интерактивная панель для конференции (не используется несколько лет) | ||
DEV |
| Сайт компании (тестовый стенд) | В процессе исследования |
| Сайт конференции (тестовый стенд) | ||
| Сайт конференции (тестовый стенд) | ||
| Сайт конференции (тестовый стенд) | ||
| Сайт конференции (тестовый стенд, не используется) | ||
| Промолендинг (тестовый стенд, закрыт) | ||
| Сайт конференции (тестовый стенд, не используется несколько лет) | ||
| Интерактивная панель для конференции (тестовый стенд, не используется несколько лет) | ||
| Партнерский ресурс (тестовый стенд, не используется несколько лет) | ||
| Партнерский ресурс (тестовый стенд, разработка остановлена в начале 2022 г., в прод никогда не был запущен) | ||
| Корпоративный проект (тестовый стенд, разработка остановлена, ресурс никогда не был запущен в прод) | ||
| Пустой тестовый стенд (не используется) | ||
| Тестовый стенд, закрыт |
В утечке вы могли также встретить файлы конфигурации других сайтов, например bugbounty.bi.zone.conf
или bcfp.bi.zone.conf
, но сами эти сайты размещены на других серверах и никакие данные этих сайтов к злоумышленникам не попали.
Реквизиты почты из поста DumpForums
Отдельно стоит упомянуть логин и пароль для отправки сообщений электронной почты, которые показаны на одном из скриншотов в посте DumpForums:
На скрине — фрагмент файла настроек интеграции с нашим почтовым сервером, которая нужна для того, чтобы сайт мог отправлять письма с ящика wsm@bi.zone
. Ящик был создан специально для отправки писем с сайта и не является учетной записью в нашем домене.
Поэтому с помощью реквизитов на скриншоте злоумышленники не могли войти на наш сервер электронной почты (более того, доступ к нему есть только через VPN) и получить, например, списки пользователей или корреспондентов.
Тем не менее мы уже сменили пароль к этой учетной записи.
Итоги расследования
Резюмируя наше расследование, мы выявили следующее:
Злоумышленники выгрузили данные с резервных копий виртуальных серверов для сайтов. В основном речь идет о данных, которые пользователи оставляли в формах для регистрации на события и сбора обратной связи.
Вероятнее всего, злоумышленники получили доступ к FTP-серверу хостинг-провайдера через панель управления.
Злоумышленники не получили доступ к нашей инфраструктуре или инфраструктуре наших клиентов.
Меры реагирования
Реагируя на этот инцидент, мы делаем все возможное, чтобы минимизировать ущерб от него и не допустить новых утечек данных.
К настоящему моменту мы:
Перенесли архивы с бэкапами внутрь инфраструктуры и удалили их с сервера хостинг-провайдера (предварительно отключив создание новых бэкапов), а также установили нашим подразделениям запрет на разворачивание бэкапов без дополнительного контроля (на случай, если злоумышленники модифицировали бэкапы и включили в них что-то свое).
Удостоверились, что на всех сайтах установлены последние версии CMS »1С-Битрикс».
Провели тестирование на проникновение всех сайтов и убедились, что там нет уязвимостей и критических мисконфигураций; усовершенствовали настройки WAF.
Сменили пароли ко всем учетным записям, к которым имели или могли иметь доступ злоумышленники, либо заблокировали эти учетные записи.
Начали инвентаризацию реквизитов (паролей, хешей от паролей, ключей) из утекших архивов — выявленные отозвали или внепланово заменили (вне зависимости от наличия двухфакторной аутентификации).
Начали инвентаризацию персональных данных из утекших архивов.
Придерживаясь принципов открытого и ответственного реагирования, мы публично рассказываем о расследовании и сообщили об инциденте всем регуляторам. Мы также уведомили хостинг-провайдера о необходимости проверки других клиентов на аналогичные инциденты.
Следующие шаги
Для дальнейшего реагирования на инцидент мы планируем:
Продолжить расследование. В частности, выяснить причины утечки реквизитов доступа к панели управления ispmanager. Мы рассматриваем версии с утечкой как со стороны хостинг-провайдера, так и с нашей стороны. Для проверки последней мы будем изучать, как, где и кто хранил реквизиты, а также передавались ли они каким-либо образом этими лицами.
Проверить бэкапы виртуальных серверов на наличие несанкционированных модификаций.
Завершить инвентаризацию реквизитов из утекших архивов.
Завершить инвентаризацию персональных данных из утекших архивов.
Хронология реагирования
Пусть это не классический отчет о реагировании, но мы решили привести хронологию наших действий к моменту написания этого поста.
30.04.2023
14:34
Телеграм-канал DumpForums опубликовал объявление о взломе.
Мы создали рабочую группу для оценки обнаруженных данных и расследования.
Выяснили, что выложенные злоумышленниками данные соответствуют данным с виртуальных серверов в инфраструктуре стороннего хостинг-провайдера.
Выдвинули гипотезы относительно того, как злоумышленники получили данные: взлом через CMS »1C-Битрикс» (эта версия стала основной из-за недавних детектов WAF), утечка логина и пароля для учетной записи администратора CMS, утечка резервной копии, взлом инфраструктуры хостинг-провайдера.
16:00
Мы подтвердили, что виртуальные серверы не имели какой-либо сетевой связности (ни задокументированной, ни фактической) с нашей внутренней инфраструктурой или с инфраструктурой наших клиентов.
Начали мониторинг телеграм-каналов, форумов и иных источников данных на предмет других утекших от нас данных (на случай, если масштаб инцидента окажется шире, чем показала наша первоначальная оценка).
16:33
Мы написали об утечке и промежуточных находках расследования в телеграм-канале BI.ZONE.
17:00
Определили, что явных следов взлома самих виртуальных серверов нет (видны были лишь неуспешные попытки эксплуатации уязвимостей и события сканирования).
Начали тестирование на проникновение виртуальных серверов, чтобы найти незакрытые уязвимости.
18:00
Начали при содействии специалистов хостинг-провайдера инвентаризацию получаемых на стороне хостинг-провайдера данных с виртуальных серверов и соответствующих процессов (резервное копирование и пр.). Позднее начало этого этапа реагирования связано с разницей в часовых поясах между нами и хостинг-провайдером.
19:00
Обнаружили вход с подозрительного IP-адреса в панель управления ispmanager (для хранилища резервных копий) от 4 апреля 2023 г. Впоследствии будет установлено, что эти бэкапы содержат все опубликованные утекшие данные.
20:00
Взлом виртуальных серверов опровергнут данными мониторинга и исследованием артефактов с них.
Утечка бэкапов с FTP-сервера стала приоритетной версией.
21:00
Получен журнал истории входов в панель управления ispmanager от хостинг-провайдера. Из него мы выяснили, что злоумышленники впервые заходили в нее 19 и 20 января 2023 г.
Хостинг-провайдер предварительно сообщил о том, что попыток перебора паролей к скомпрометированной учетной записи панели управления ispmanager не зафиксировано.
01.05.2023
00:00
К концу 30 апреля мы запросили у специалистов хостинг-провайдера сведения о журналах подключения к FTP-серверу (из-под нашей учетной записи). К сожалению, к моменту расследования история входов по FTP не была доступна.
01:48
Мы запостили обновление о расследовании в телеграм-канале.
06:00
В ночь с 30 апреля на 1 мая завершили меры по защите от угрозы:
сменили пароль к панели управления ispmanager и отключили учетные записи, которые не используются в расследовании;
через специалистов хостинг-провайдера изменили пароль к FTP-серверу с бэкапами (и пароль к веб-версии интерфейса, предоставляющего аналогичный доступ к тем же бэкапам);
перенесли архивы с бэкапами внутрь инфраструктуры и удалили их с сервера хостинг-провайдера (предварительно отключив создание новых бэкапов);
изменили пароли к административным учетным записям в CMS »1С-Битрикс» (и отключили учетные записи, которые используются в расследовании).
02.05.2023
По состоянию на момент публикации поста продолжается инвентаризация утекших данных (из резервных копий файлов и баз данных).