С чего все началось

30 апреля в 14:34 (мск) в телеграм-канале DumpForums опубликовали пост, в котором объявили о том, что «недавно была взломана компания bi.zone». К посту были прикреплены скриншоты с фрагментами конфигурационных файлов, SQL-дампов с персональными данными и перечнем конфиг-файлов с именами наших подсайтов.

Мы незамедлительно запустили реагирование на инцидент и его расследование. Перед нами стояли четыре задачи:

1. Понять, какие именно данные могут быть у злоумышленников.

2. Выяснить, как они получили к ним доступ.

3. Оценить возможность развития атаки в нашу инфраструктуру или в инфраструктуры наших клиентов.

4. Не допустить повторения подобной утечки.

Откуда были взяты данные

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

Мы используем два таких сервера — DEV и PROD: аудитории «Хабра» несложно будет догадаться, что первый используется для разработки и тестирования ресурсов, второй — для их публикации.

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

• односторонний экспорт лидов с сайтов в нашу CRM-систему через API Gateway;

• возможность отправки сообщений через наш почтовый релей.

Оба сервера находятся под мониторингом нашего SOC и защищены нашими EDR (BI.ZONE Sensors) и межсетевым экраном уровня приложений (BI.ZONE WAF).

Как злоумышленники выгрузили данные

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

1. Взлом виртуальных серверов (сперва мы считали ее основной, поскольку накануне инцидента BI.ZONE WAF фиксировал попытки эксплуатации уязвимостей для загрузки веб-шеллов).

2. Выгрузка резервных копий виртуальных серверов.

3. Взлом инфраструктуры хостинг-провайдера.

1. Взлом виртуальных серверов

Для проверки версии о взломе виртуальных серверов DEV и PROD мы исследовали множество артефактов с них.

В приоритет ставились гипотезы:

• о подключении по протоколу SSH (путем подбора пароля или через компрометацию необходимых для аутентификации криптографических ключей);

• загрузке на серверы веб-шеллов путем эксплуатации уязвимости в CMS «1С-Битрикс» (или в каком-либо скрипте вне этой CMS).

Тем не менее при исследовании мы искали признаки любой подозрительной активности на серверах.

В числе проверенных нами артефактов были:

• журналы веб-серверов (мы искали в том числе попытки успешной эксплуатации уязвимостей, обращения к веб-шеллам);

• журналы операционной системы, включая историю входов по протоколу SSH;

• история введенных через шелл команд, история команд клиентов СУБД;

• телеметрия, полученная от EDR-агентов, установленных на виртуальных серверах;

• целостность исполняемых файлов (в том числе скриптов) — согласно эталонным хеш-значениям из RPM-пакетов;

• подозрительные файлы скриптов в домашних директориях веб-сервисов (включая поддиректории), подозрительные файлы во временных директориях;

• текущие прослушиваемые порты, текущие исходящие подключения;

• текущий список процессов;

• исполняемые файлы и скрипты, прописанные в автозагрузку;

• списки учетных записей пользователей в операционной системе, наличие прописанных шеллов у сервисных учетных записей, отпечатки разрешенных SSH-ключей (для входящих подключений).

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

Таким образом, гипотеза о взломе самих виртуальных серверов не подтвердилась.

2. Выгрузка резервных копий

Резервные копии виртуальных серверов хранились на FTP-сервере, администрируемом хостинг-провайдером, поэтому наши средства защиты на этом сервере не применялись. Логин и пароль для подключения к нему можно получить в открытом виде через панель управления ispmanager.

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

Мы запросили у провайдера журналы доступа к этой панели — в них обнаружились нелегитимные события входа от 19 и 20 января, а также 4 апреля 2023 г.

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

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.

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

Какие данные утекли

Чувствительные данные в бэкапах

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

В утечке вы могли также встретить файлы конфигурации других сайтов, например bugbounty.bi.zone.conf или bcfp.bi.zone.conf, но сами эти сайты размещены на других серверах и никакие данные этих сайтов к злоумышленникам не попали.

Реквизиты почты из поста DumpForums

Отдельно стоит упомянуть логин и пароль для отправки сообщений электронной почты, которые показаны на одном из скриншотов в посте DumpForums:

На скрине — фрагмент файла настроек интеграции с нашим почтовым сервером, которая нужна для того, чтобы сайт мог отправлять письма с ящика wsm@bi.zone. Ящик был создан специально для отправки писем с сайта и не является учетной записью в нашем домене.

Поэтому с помощью реквизитов на скриншоте злоумышленники не могли войти на наш сервер электронной почты (более того, доступ к нему есть только через VPN) и получить, например, списки пользователей или корреспондентов.

Тем не менее мы уже сменили пароль к этой учетной записи.

Итоги расследования

Резюмируя наше расследование, мы выявили следующее:

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

2. Вероятнее всего, злоумышленники получили доступ к FTP-серверу хостинг-провайдера через панель управления.

3. Злоумышленники не получили доступ к нашей инфраструктуре или инфраструктуре наших клиентов.

Меры реагирования

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

К настоящему моменту мы:

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

2. Удостоверились, что на всех сайтах установлены последние версии CMS «1С-Битрикс».

3. Провели тестирование на проникновение всех сайтов и убедились, что там нет уязвимостей и критических мисконфигураций; усовершенствовали настройки WAF.

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

5. Начали инвентаризацию реквизитов (паролей, хешей от паролей, ключей) из утекших архивов — выявленные отозвали или внепланово заменили (вне зависимости от наличия двухфакторной аутентификации).

6. Начали инвентаризацию персональных данных из утекших архивов.

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

Следующие шаги

Для дальнейшего реагирования на инцидент мы планируем:

1. Продолжить расследование. В частности, выяснить причины утечки реквизитов доступа к панели управления ispmanager. Мы рассматриваем версии с утечкой как со стороны хостинг-провайдера, так и с нашей стороны. Для проверки последней мы будем изучать, как, где и кто хранил реквизиты, а также передавались ли они каким-либо образом этими лицами.

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

3. Завершить инвентаризацию реквизитов из утекших архивов.

4. Завершить инвентаризацию персональных данных из утекших архивов.

Хронология реагирования

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