Повесть о том, как разработчики пренебрегают защитными мерами.
Проблема: тысячи серверов с базами данных ElasticSearch свободно доступны без смс и регистрации.
Проблема эластиков не нова, но как мы увидим дальше, разработчики все еще не спешат себя обезопасить. По умолчанию Elasticsearch не имеет никакой системы безопасности, что делает процесс сканирования довольно простым, чем мы и воспользуемся.
Я самостоятельно ничего не сканировал, т.к это незаконно во многих странах. Вся предоставленная информация получена с сервиса spyse.com.
На 15.06.2020, при запросе к порту 9200, было найдено 436 терабайт утекших данных принадлежащих таким предприятиям, как Amazon, DigitalOcean, Google, Microsoft, ESPN и многим китайским корпорациям.
Найденная информация содержит конфиденциальную информацию пользователей (имейлы, номера телефонов, пароли, история заказов, привязанные методы оплаты и тд.), бизнес данные (внутренняя информация компании, информация о поставках, продуктах…), адреса биткоин кошельков и многое другое.
Пример полей найденных у Amazon:
*Важно — это лишь пример. Сервер может принадлежать тому, кто использует Amazon в качестве хостинга. Найти и детально изучить базы можно будет после прочтения этого гайда.
Утекшие данные ElasticSearch
Самые популярные индексы баз данных называются Readme, Kibana или nightlionsecurity.com.
Readme — скорее всего говорит о том что база данных взломана и залочена с требованием выкупа.
Kibana — помогает анализировать логи (в которых тоже много всего интересного)
Последний — компания, рекламирует себя путем переименования утекших баз данных.
После анализа удалось выяснить что 4,1% баз данных уже были взломаны с требованием выкупа.
Благодаря автоматическому анализу и связыванию данных можно быстро проанализировать или произвести поиск с учетом связей между IP, доменами, организацией, странной и другими сущностями интернета. Получаем такую аналитику:
Топ 3 самых уязвимых стран
China — 5468 серверов
United States — 4256 серверов
Germany — 1070 серверов
Топ 10 самых уязвимых организаций
Hangzhou Alibaba Advertising Co., Ltd. — 2478 серверов
Amazon.com, Inc. — 1933 серверов
DigitalOcean, LLC — 1332 серверов
Google LLC — 1203 серверов
Shenzhen Tencent Computer Systems Company Limited — 910 серверов
OVH SAS — 825 серверов
Microsoft Corporation — 745 серверов
Hetzner Online GmbH — 336 серверов
Linode, LLC — 32 серверов
China Unicom Beijing Province Network — 236 серверов
Как хакеры могут воспользоваться данными
Вариантов эксплуатации подобных данных очень много, рассмотрим несколько простых.
Продажа данных. Простой дамп базы данных и продажа ее в даркнете. Это может быть как продажа целой базы так и отдельный тип данных, номера и пароли платежных карт.
Выкуп. База данных закрывается локером который шифрует всю информацию и дает доступ только при наличии специального ключа, или нет. Зачастую даже после выплаты требуемой суммы данные остаются заблокированными.
Бесплатные покупки. При наличии доступа к базе данных где хранятся продукты, злоумышленник может поменять статус заказа на «оплачено» и бесплатно рассылать себе товары/продукты.
Шпионаж. Данные могут быть проданы конкурентам или использованы для собственного обогащения. Например можно вложиться в компанию перед большим слиянием.
Как найти базы данных Elasticsearch
WEB интерфейс
Все данные фактически лежат на поверхности, нужно только постучаться. Что мы и сделаем используя поисковик Spyse.
Самый простой способ поиска информации это использование Web интерфейса.
Алгоритм поиска:
Переходим на spyse.com, нажмите кнопку расширенного поиска (advanced search) на домашней странице и используем всего один фильтр, чтобы найти нужную информацию — IP > Ports & Technologies > Opened Ports List > equals to > цель – 9200 (номер порта который мы исследуем)
URL поискового запроса.
В результатах поиска мы найдем все IP-адреса с открытым портом 9200, на котором мы предполагаем есть Elasticsearch. Но если нужно убедиться, можно использовать простой Get запрос для каждого IP-адреса и в ответе получим подтверждение гипотезы.
Вся дополнительная информация — связанные организации, интернет-провайдеры, домены и поддомены, рейтинг Alexa, номер AS и т. д… Уже связана с помощью алгоритмов Spyse. Можно провалиться в каждый результат и исследовать его детальнее.
Для более продвинутых пользователей которые хотят сдампить базу, автоматизировать поиск, и тд, рекомендуется освоить API.
Использование API
Первый запрос предоставляет почти ту же информацию, что и web, за исключением только «всех доменов», связанных с IP. Это связано с тем, что если IP не имеет PTR записи, он не будет связан с доменом. Чтобы предотвратить эту ситуацию и расширить диапазон исследования, добавив доменов, нужно использовать один дополнительный запрос.
Пример первого запроса:
https://api.spyse.com/v2/data/ip/searc? limit=10&search_params% 7% 22ip_port_open_port% 22%3% 20%5% 7% 22operato% 22%3% 20%22e% 22%2% 20%22valu% 22%3% 20%229200%22%7% 5% 7D
Запрос можно проверить прямо в документации API Spyse. Для этого авторизуйтесь используя API token найденный на странице https://spyse.com/user. После, найдите POS / Ip / port и введите значения {«ip_port_open_ports»: [{«operator»: «eq», «value»: «9200»}]}
Пример:
Результаты:
Для проверки действительно ли на порту есть Elasticsearch рекомендуется написать короткий скрипт который сам будет проверять цели. Проверили, и теперь мы имеем все IP на которых есть Elasticsearch. Второй запрос подразумевает сбор всех доменов привязанных к IP.
Пример запроса:
Проверьте это в документации API Spyse – GET /domain/search > {«domain_dns_a”: [{«operator”: “eq”, “value»: “8.8.8.8»}]}
Данные собраны.
Дальнейшие действия применимы только к базам данных Elasticsearch и направлены на получение информации с базы данных. Нужно только правильно обратиться к базе (это зависит от версии эластика). Запросы, как принято, представлены в документации Elasticsearch.
Анализ баз данных Elasticsearch
Алгоритм поиска:
Обращаемся к адерсу где находится Elasticsearch в формате «ip: port / _stats».
Пример:
curl http://171.244.129.66:9200/_stats
Ответ вернет индексы, размер и количество документов.
Или > Информацию о том, что у нас нет разрешения на такие действия.
Или > Ошибку.
Если доступ запрещен или у нас нет доступа, можно попробовать получить информацию другим способом, указав путь _nodes.
Пример:
curl http://171.244.129.66:9200/_nodes
Когда индексы будут собраны, собираем их маппинги делая запросы формата: «ip:port/_mapping”, и после собираем их поля по пути «sql?format=json” запросы с пейлоадом в формате “{“query”:»DESC indexname“}»
Пример:
curl http://171.244.129.66:9200/_mapping
На последнем этапе — получение точных данных.
Отправляем путь «index / _search» в для получения 10 случайных записей каждого индекса.
curl --header «Content-Type: application/json» --request GET --data '{«query»:«DESC products»}' '178.32.101.214:9200/_sq? format=json'
Решение Проблем Elasticsearch
Важно понимать, что это не разовая утечка, эти базы данных постоянно доступны, но из-за пренебрежения базовыми методами защиты список постоянно пополняется.
На данный момент создано и описано множество методов для того чтобы сделать свои базы данных безопасными, так команда Elasticsearch разработала основные правила и рекомендации по безопасности. Настоятельно рекомендую изучать вопрос безопасности перед разработкой чего бы то ни было.
Может, все же принадлежащим клиентам их облаков?
В том числе. Ниже указано.
Комментарий недоступен
Вариантов сильно много.
Эластик часто используется для сбора и анализа логов. Хранения больших обьемов информации + как уже заметил Дмитрий фэ, бд могут принадлежать клиентам
Комментарий недоступен
Поисковый движок.
Что Эластику мешает по-умолчанию в конфиге писать network.host: localhost; я искренне не понимаю.