Открытая Kibana раскрыла торговый стек native.org

Скоординированное раскрытие, сообщённое добросовестно, без вознаграждения и какой-либо оплаты. native.org устранила проблему и согласовала этот разбор к публикации. Адрес затронутого хоста не раскрывается.

Сводка

• 207раскрытых шаблонов индексов
• 21извлечённый действующий API-ключ
• 8 700+записей в журнале каждые 15 мин

Экземпляр Kibana от native.org индексировал торговую инфраструктуру компании в средах staging и UAT, в общей сложности 207 шаблонов индексов, а стоящий за ним API-шлюз записывал действующие API-ключи в журнал открытым текстом.

native.org — это DeFi-платформа ликвидности. Её ончейн-система RFQ получает котировки от частных маркет-мейкеров и предоставляет их трейдерам в разных блокчейнах, а возникающий поток хеджируется на централизованных биржах. Раскрытый экземпляр был частью среды UAT. native.org подтвердила, что ни один из утёкших ключей не использовался в продакшене, добавила аутентификацию к экземпляру и ротировала ключи.

Открытые экземпляры Kibana встречаются часто. Здесь же большего внимания заслуживают две вещи: что именно выдаёт открытый стек наблюдаемости (observability) и насколько заурядной была ошибка, приведшая к утечке ключей.

Ключевые моменты

• Экземпляр не требовал никакой аутентификации. Интерфейс Kibana загружался, любой индекс можно было запросить, а сохранённые объекты — перечислить, и всё это без единого учётного данного.
• 207 названий индексов были картой всей операции: ценообразование, хеджирование, риск, ликвидация, расчёты, ончейн-мониторинг, интеграция с централизованными биржами, кросс-чейн-пеги и механизмы аварийной остановки. Архитектуру можно было прочитать, не открыв ни одного документа.
• API-шлюз записывал сырые API-ключи в свой вывод, который попадал в Elasticsearch. Из живого потока журналов мы извлекли 21 ключ. На тот момент один индекс принимал более 8 700 записей каждые 15 минут, так что система была явно действующей.

Что выдаёт открытая панель

Названия индексов задуманы как операционная «сантехника», а не как поверхность атаки. Полный, поимённый список всех сервисов сообщает атакующему ровно то, как устроена система. В случае native.org названия описывали торговый стек от начала и до конца: quote-order-task и order-manager для потока ордеров, pricer и quote-ticker для ценообразования, risk-manager и liquidation-price-task для риска, trade-hedger-task и hedge-signer для хеджирования, cex-monitor и cex-position-monitor для интеграции с централизованными биржами, settlement для клиринга, задачи мягкого пега в нескольких блокчейнах, а также emergency-stop-task и emergency-paused-task для аварийных выключателей.

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

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

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

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

Ключи в журналах

Более прямая проблема была в журналах API-шлюза. Функция поиска ключей в шлюзе при каждом успешном обращении записывала в журнал весь объект ключа, и эти строки журнала попадали в Elasticsearch, как и всё остальное. Открыв индекс шлюза и отфильтровав по этой функции, можно было получить поток записей вроде такой:

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

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

Последствия, без преувеличения

Это была среда UAT, и native.org подтвердила, что ключи не использовались в продакшене. Это важно, и мы не станем выдавать это за чудом предотвращённую катастрофу на действующем торговом столе. Это было не так.

Тем не менее это было серьёзно. Действующий, доступный из интернета экземпляр без аутентификации записывал реальные учётные данные открытым текстом и раскрывал всю архитектуру платформы, оперирующей деньгами. Ключи были ключами UAT, но индекс принимал тысячи строк журнала каждые несколько минут, так что трафик был реальным, а раскрытая им архитектура — та же самая, на которой работает продакшен. Весь смысл — в разрыве между «это всего лишь UAT» и «это в публичном интернете и пишет в журнал действующие ключи».

Подтверждение концепции (PoC)

Экземпляр отвечал на запросы без аутентификации на своём HTTP-порту. Подтверждение заняло три шага, ни для одного из которых не понадобился инструмент экзотичнее, чем curl или браузер:

• GET /api/status возвращал версию Kibana и имя узла без учётных данных.
• GET /api/saved_objects/_find?type=index-pattern&per_page=500 возвращал все 207 шаблонов индексов.
• Открытие индекса шлюза в Discover и фильтрация по функции поиска ключей показывали записанные в журнал ключи.

TLS-сертификат на порту 443 хоста (CN=*.native.org, выпущенный Cloudflare Origin CA) подтвердил, что экземпляр принадлежит native.org.

Хронология раскрытия

• 2 июня 2026Мы обнаружили раскрытый экземпляр в ходе исследования угроз и сообщили о нём native.org, приложив затронутую конечную точку, список индексов, отредактированный образец записанных ключей и шаги по устранению.
• 18 июня 2026native.org подтвердила раскрытие. Они добавили аутентификацию к экземпляру, ротировали затронутые ключи, подтвердили, что экземпляр и ключи принадлежали среде UAT и что продакшен-ключи не были задействованы, и обозначили, какие правки они хотят видеть перед публикацией.
• 19 июня 2026Опубликовано при участии native.org, с применением запрошенных ими правок.

native.org отреагировала быстро, устранила проблему и поработала с нами над разбором. Мы сообщили об этом потому, что раскрытие было серьёзным и им нужно было о нём знать, а не ради чего-либо взамен. Именно так и должно работать скоординированное раскрытие.

Для команд с таким же стеком

• Поставьте Kibana и Elasticsearch за аутентификацию. Включите xpack.security.enabled и держите HTTP-порт вне публичного интернета. ELK-стек без аутентификации — это база данных с веб-интерфейсом, открытым всему миру.
• Считайте, что ваше хранилище журналов доступно на чтение каждому, кто может до него дотянуться. Если учётные данные могут попасть в строку журнала, считайте, что их прочитают.
• Не записывайте в журнал целые объекты аутентификации или запроса. Журналируйте идентификатор, но никогда — сам секрет. Путь поиска ключей — ровно то место, где это идёт не так.
• Помните, что названия ваших индексов и сервисов описывают вашу систему. Держите место, где они живут, закрытым.
• Проведите инвентаризацию старых сред. Названия здесь несли метки вроде uat-v1, uat-v2, staging и shadow — слои тестовых установок, накопившиеся со временем. Публичной в итоге обычно оказывается та, о которой забыли.

Благодарности

Спасибо команде native.org за быстрый и профессиональный отклик и за совместную работу над тем, что могло и что не могло войти в этот разбор.