Уроки, которые можно извлечь из утечки данных Elasticsearch

Программное обеспечение с открытым исходным кодом, связанное с Национальной футбольной лигой по какой-либо причине, обычно звучит как хорошая идея, но не в этот раз. Особенно, если это программное обеспечение с открытым исходным кодом несет ответственность за утечку частной информации примерно о 1100 игроках НФЛ и их агентах. Исследователи Kromtech подсчитали, что из-за отсутствия технологии защиты паролем и аутентификации более 4500 машин Elasticsearch были заражены двумя типами вредоносных программ, а именно JackPOS и AlinaPOS. Кроме того, как минимум в одном случае злоумышленник получил доступ к данным, и в файлах осталась записка с требованием выкупа. Утверждается, что утечка данных Elasticsearch раскрыла конфиденциальную информацию об игроках и агентах.

ПОС вредоносное ПО

POS в их названиях означает, что это вредоносное ПО для торговых точек, которое пытается собрать конфиденциальную информацию, например данные кредитной карты, с помощью множества различных методов. Одним из примеров того, насколько это эффективно, является тот факт, что JackPOS может шифровать украденные данные для отправки обратно незамеченными. Он использует MAC-адрес в качестве идентификатора бота и обманывает систему, заявляя, что это утилита Java. Затем он может скопировать себя в каталог %APPDATA% или любой подкаталог на основе Java. Как только вредоносная программа установлена, злоумышленники могут получить удаленный доступ к ресурсам сервера и в основном делать все, что хотят, например, стирать жесткие диски, удаленно выполнять код с полными правами администратора или красть данные.

Основная проблема здесь заключается в том, что вредоносное ПО может оставаться активным в ряде систем даже после обнаружения на отдельных серверах. Кроме того, каждый зараженный сервер становился частью более крупного ботнета POS с функциональностью Command and Control (C&C) для других вредоносных клиентов POS. После заражения эти клиенты постоянно собирают (крадут), шифруют и передают информацию с POS-терминалов, оперативной памяти или зараженных машин Windows.

Слабая защита паролей и утечка данных Elasticsearch

Как произошло это нарушение данных Elasticsearch? Уязвимость возникла из-за отсутствия базовой защиты паролем в отношении аутентификации пользовательских сеансов. Это отсутствие аутентификации, в свою очередь, связано с чем-то еще более простым, например, с общедоступной конфигурацией, с помощью которой злоумышленники могут управлять всей системой с полными административными привилегиями. Примером проблемы общедоступной конфигурации является то, что до ES 6.0 установка X-Pack автоматически создавала трех пользователей: elastic, kibana и logstash_system с паролем «changeme». Намерение, очевидно, состояло в том, чтобы вы сразу изменили эти пароли, но обычная человеческая лень и склонность пропускать установки делают это настоящей проблемой. Это, безусловно, могло быть фактором утечки данных Elasticsearch.

Существует даже параметр под названием xpack.security.authc.accept_default_password, запрещающий этот пароль после запуска вашего кластера, но людей, которые действительно делают это, вероятно, очень мало. Хотя проблема загрузки пароля решается в версии 6.0, пароли по умолчанию далеко не идеальны в сегодняшних условиях. Пароль начальной загрузки — это временный пароль, который используется только до тех пор, пока для гибкого пользователя не будет установлен реальный пароль. Пароль начальной загрузки может быть сгенерирован автоматически или помещен в хранилище ключей Elasticsearch перед запуском узла, поэтому вам не нужно вручную устанавливать пароли для каждого узла.

Еще одна проблема — временной разрыв между запуском узла и изменением пароля по умолчанию. Даже если пароль будет изменен быстро, постороннему все еще остается окно для аутентификации и входа. Чтобы предотвратить эту ситуацию, инструмент командной строки setup-passwords используется для установки или автоматического создания надежных загрузочных паролей для внутренней эластичности, kibana, и пользователи logstash-системы.

Elasticsearch задержан с целью получения выкупа

Серия атак с целью выкупа в прошлом году уже поразила более 33 000 баз данных MongoDB. расширили свои цели до экземпляров Elasticsearch. Пострадавших администраторов Elasticsearch встречают в атаках одного актера с сообщением следующего содержания:

Отправьте 0,2 биткойна на этот кошелек: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r, если вы хотите восстановить (sic) свою базу данных! Отправьте на этот адрес IP-адрес вашего сервиса после отправки биткойнов [email protected] (так в оригинале).

Elastic опубликовал сообщение в блоге, чтобы сообщить о риске оставить серверы открытыми для Интернета и предоставить инструкции о том, как их защитить. Номером 1 в списке рекомендуемых практик было «обновить до последней версии».

TLS и сеть с нулевым доверием

Безопасность на самом деле стала настолько серьезной проблемой для ES, что версия 6.0 включает в себя то, что называется сетью с нулевым доверием, что при объяснении звучит как что-то из фильма о глубоком шпионаже или эпизода «Нарко». Основная концепция заключается в том, что мир резко изменился за последние несколько лет, и мы достигли точки, когда вашей собственной сети больше нельзя доверять, потому что ваши ранги были скомпрометированы. Верно, любой из хороших парней может работать на другую сторону, и это предположение, с которого вам нужно начать.

Поскольку передача данных даже по вашим собственным проводам теперь вызывает подозрения, связь TLS между узлами в кластере Elasticsearch будет обязательной в ES 6.0. Transport Layer Security (TLS) и его предшественник, Secure Sockets Layer (SSL), оба часто называемые «SSL», представляют собой криптографические протоколы, обеспечивающие безопасность связи в компьютерной сети. TLS использует сертификаты, подписи и шифрование, чтобы обеспечить безопасность связи между двумя конечными точками, даже если сеть между этими конечными точками является враждебной. Существуют также «проверки начальной загрузки», которые запускаются, когда Elasticsearch переходит в рабочий режим. Проверка включения TLS теперь является частью процесса проверки начальной загрузки.

Защитите свою резинку

Существует около 4000 зараженных серверов Elasticsearch, и около 99 процентов из них размещены на Amazon. Платформа хостинга Amazon дает пользователям возможность настроить кластер Elasticsearch всего за несколько кликов, но обычно люди пропускают все настройки безопасности в процессе быстрой установки. Именно здесь простая ошибка может иметь большие последствия, и прежде чем вы успеете сказать об утечке данных Elasticsearch, вы попадете в новости из-за раскрытия огромного количества конфиденциальных данных. Это, без сомнения, худшая реклама, на которую может рассчитывать фирма, работающая с данными клиентов. Но есть несколько вещей, которые можно сделать, чтобы избежать ситуации.

Kromtech Security Center настоятельно рекомендует предпринять следующие действия, необходимые для эффективного реагирования на инциденты. Установите последний патч Elastic или полностью переустановите его. Закройте все неиспользуемые порты от внешнего доступа, внесите в белый список только доверенные IP-адреса, проверьте файлы журналов, подключения и трафик на всех серверах и создайте резервные копии всех работающих систем. Кроме того, вы также можете переустановить все скомпрометированные системы, если не хотите проверять каждую подозрительную отдельно и внимательно следить за ними в течение следующих трех месяцев. Вы также можете извлечь образцы вредоносных программ и передать их компании Kromtech ([email protected]) для дальнейшего анализа.

Быть на шаг впереди

Хранение записей, обеспечение безопасности на уровне полей, защита паролем и управление пользователями — все это рекомендуется ES для обеспечения безопасности вашего кластера ES. Как и все остальное на предприятии, если вы остановитесь, вы станете удобной мишенью для злоумышленников и умрете, и точка. Решение состоит в том, чтобы продолжать двигаться (вперед) и активно думать на шаг впереди ваших злоумышленников, чтобы убедиться, что вы продумали и спланировали каждый возможный сценарий атаки. Также рекомендуется рассматривать каждый сбой, такой как утечка данных Elasticsearch, как опыт обучения, потому что вы только что получили отличный пример того, как ваш злоумышленник думает на шаг впереди вас.