Горячие новости. Публикуем небольшое интервью с представителями группировки datasuckers, которые ранее заявили о взломе «Додо Пиццы».

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

*Важное примечание: администрация канала выступает против кибератак и много лет продвигает идеи информационной безопасности. Материал публикуется исключительно в познавательных целях. Технические подробности приводим со слов собеседников: это версия стороны, заявившей об атаке, а не независимо подтверждённая реконструкция инцидента.
 
1. Как проходил этап сбора информации?
Начали с их мобильного приложения — разобрали APK, вытащили Firebase-конфиги и карту из 95+ REST-эндпоинтов. Затем прошлись по публичному API, нашлись маршруты без авторизации и анонимные write-семейства. LinkedIn, GitHub-утечки и фишинг не использовались, всё через техническую разведку их публичной инфраструктуры.
 
2. Какие активы были в приоритете?
Приоритет — операционная БД юзеров и заказов. Целились в платформу данных: Databricks, Kusto, MySQL-монолиты. Бухгалтерия, переписка, шифрование для выкупа — не рылись в эту сторону.
 
3. Как оценивали периметр?
Сразу бросилось в глаза: publicapi-v1 имел 22 из 26 маршрутов без авторизации. Databricks-воркспейс допускал несанкционированное чтение внутренних файлов. QRATOR (технически говоря, WAF) стоял на части эндпоинтов, но обходился через headless Chromium.
 
4. Первоначальный вектор проникновения?
Техническая misconfiguration — file-read (LFI) в Databricks DBFS: через публичный эндпоинт читались внутренние файлы, среди которых оказался PAT-токен (ключ доступа). Сразу отмечу: не фишинг, не 0-day и не инфраструктура какого-то подрядчика.
 
5. Социальная инженерия?
Не использовалась. Никакого фишинга, deepfake, поддельных страниц. Весь путь технический, через ошибки конфигурирования.
 
6. Какую ошибку допустили администраторы?
Хранили креды в открытом виде в трёх внутренних системах: Superset-метадата (SQLalchemy_uri с паролями), OpenMetadata (PAT-токены плейнтекстом), KeyVault-скопы (доступные через компрометированные compute-токены). Главная ошибка — не encrypting secrets at rest в аналитических инструментах.
 
7. Сколько времени до прав администратора?
От первого касания (анализ APK) до полного доступа к данным — около 12–16 часов. От первой украденной креды (PAT из DBFS) до SQL-консоли на 27 прод-БД — около 4–6 часов.
 
8. Как закреплялись?
OAuth-токены с TTL 90 дней, вечная веб-сессия с auto-refresh каждые 12 часов, cluster-admin Kubernetes SA-токены. Новых пользователей не создавали, планировщик не трогали, бэкдоров в ПО не внедряли. Всё было очень просто)
 
9. Как обходили шифрование?
Данные были доступны через легитимные креды — шифрование at rest не мешало. Парадокс: Azure KeyVault (хранилище ключей) сам стал источником утечки — после получения RCE на кластере мы прочитали все секреты из KV напрямую.
 
10. Требовали ли вы выкуп?
Нет, не требовали. У Додо и Тез-Тур политика отрицания («ничего критичного не произошло — соответственно, и платить не за что»). Да и наше присутствие в Додо заметили почти сразу после скачки БД. Компания такого уровня, очевидно, не идёт на контакт с хакерами.
 
11. Один совет директору по ИТ?
Уберите пароли из инструментов аналитики. Конкретно: encrypt secrets at rest в Superset/OpenMetadata, ротируйте ВСЕ сервисные секреты (не только по чеклисту), поставьте алерты на аномальные blob-чтения. Одна эта правка закрыла бы 80% нашего пути.
 
12. Насколько легко обошли SOC?
Их SOC не заметил ничего за всё время. Выемка шла через Shar
{...продолжить в источнике}

_______
Источник | #intosecurity
@F_S_C_P

-------
Поддержи канал подпиской
-------