Основные положения
Небезопасно опубликованная служба – одна из наиболее часто встречающихся ошибок конфигурации в облачных средах. Эти сервисы доступны для обнаружения в Интернете и могут представлять значительный риск для облачных рабочих нагрузок в той же инфраструктуре. Известные группы программ-вымогателей, такие как REvil и Mespinoza, используют уязвимые службы для получения первоначального доступа к среде жертв. Используя глобально развернутую инфраструктуру приманки из 320 узлов, исследователи стремятся лучше понять атаки на открытые службы в общедоступных облаках.
Исследователи Unit 42 развернули несколько экземпляров сервисов удаленного рабочего стола (RDP), SSH, SMB и базы данных Postgres в инфраструктуре приманки (honeypot). Исследователи обнаружили, что 80% из 320 приманок были взломаны в течение 24 часов, а все приманки – в течение недели.
Некоторые выводы, которые выделяются:
– SSH был самым атакуемым сервисом. Количество злоумышленников и компрометирующих событий было намного больше, чем у трех других сервисов.
– Самая атакуемая приманка SSH, была взломана 169 раз за один день.
– В среднем каждая приманка SSH взламывалась 26 раз в день.
– Один злоумышленник скомпрометировал 96% наших 80 приманок Postgres по всему миру в течение 30 секунд.
– в среднем 85% IP-адресов злоумышленников наблюдаемые за день – уникальны. Это число указывает на то, что межсетевые экраны уровня L3 неэффективны, поскольку злоумышленники редко повторно используют одни и те же IP-адреса для запуска атак. Список вредоносных IP-адресов, созданный сегодня, скорее всего, устареет завтра.
Скорость управления уязвимостями обычно измеряется днями или месяцами. Тот факт, что злоумышленники могли найти и взломать наши приманки за считанные минуты, шокировал. Это исследование демонстрирует риск небезопасных публикаций сервисов. Результат еще раз подтверждает важность быстрого устранения проблем безопасности и исправления их. Когда неправильно настроенная или уязвимая служба открывается в Интернете, злоумышленникам требуется всего несколько минут, чтобы обнаружить и взломать службу. Когда дело доходит до сроков исправлений безопасности, нет предела погрешности.
Prisma Cloud может выявлять и предотвращать уязвимости и неправильные конфигурации на протяжении всего жизненного цикла приложения, при этом уделяя приоритетное внимание рискам для ваших облачных сред. Межсетевые экраны серии VM могут помочь обнаруживать вредоносные действия в виртуализированных средах и защищаться от них.
Методология
В период с июля 2021 года по август 2021 года исследователи Unit 42 развернули 320 приманок в Северной Америке (NA), Азиатско-Тихоокеанском регионе (APAC) и Европе (ЕС). В ходе исследования было проанализировано время, частота и источники атак, наблюдаемых в нашей инфраструктуре-приманке.
Четыре типа приложений – SSH, Samba, Postgres и RDP, были равномерно развернуты в инфраструктуре приманки. Мы намеренно настроили несколько учетных записей со слабыми учетными данными, такими как admin: admin, guest: guest, administrator: password. Эти учетные записи предоставляют ограниченный доступ к приложению в изолированной среде. Приманка будет сброшена и повторно развернута при обнаружении компрометирующего события, т. е. когда злоумышленник успешно аутентифицируется с помощью одной из учетных записей и получает доступ к приложению.
Чтобы проанализировать эффективность блокировки трафика сканирования сети, мы заблокировали список известных IP-адресов сканера на подмножестве приманок. Политики брандмауэра обновлялись один раз в день на основе наблюдаемого трафика сканирования сети. В зависимости от приложений и дней каждая политика брандмауэра может блокировать 600–3000 известных IP-адресов сканера.
Журналы со всех приманок были собраны в кластере Elasticsearch. Контроллер-сервер постоянно следил за журналами и проверял работоспособность каждой приманки. Если было обнаружено компрометирующее событие или виртуальная машина перестала отвечать, контроллер повторно развернул виртуальную машину и приложение. На рисунке 1 показана архитектура инфраструктуры приманки.
Рисунок 1. Инфраструктура приманок.
Шаблоны атак
На рисунках 2-5 анализируются время, частота и происхождение атак. Мы определяем время до первой компрометации как время, в течение которого приложение остается нетронутым до первого взлома. На рисунке 2 показано среднее время до первого взлома всех 320 приманок. Время до первого взлома – это время, которое злоумышленники тратят на обнаружение и взлом новой службы в Интернете. Это также похоже на то время, когда ИТ-администраторы должны реагировать на предупреждение системы безопасности о незащищенных службах, прежде чем подвергнуться атаке.
Время до первого взлома зависит от приложений. Как правило, оно обратно пропорционально количеству злоумышленников, нацеленных на приложение (рисунок 4). Когда количество злоумышленников увеличивается, время до первого взлома этого приложения уменьшается.
Рисунок 2. Время между развертыванием приманки и первым событием компрометации.
Среднее время между попытками взлома – это среднее время между двумя последовательными событиями взлома целевого приложения. На рисунке 3 показано среднее время между взломами каждого приложения-приманки в течение 30 дней.
Уязвимая служба в Интернете обычно несколько раз взламывается несколькими разными злоумышленниками. Чтобы побороться за ресурсы жертвы, злоумышленники обычно пытаются удалить вредоносное ПО или бэкдоры, оставленные другими киберпреступными группами (например, Rocke, TeamTNT). Среднее время между попытками взлома напоминает время, проведенное злоумышленником в скомпрометированной системе до того, как появится следующий злоумышленник. Подобно времени до первого взлома, среднее время между взломом приложения также обратно пропорционально количеству злоумышленников, нацеленных на приложение.
Рисунок 3. Среднее время между двумя последовательными событиями взлома приложения.
На рисунке 4 показано среднее количество уникальных IP-адресов злоумышленников, наблюдаемых на каждой приманке в течение 30 дней. Число также указывает, сколько раз каждая приманка была взломана. Обратите внимание, что это не общее количество IP-адресов злоумышленников. Поскольку большинство IP-адресов злоумышленников достигают лишь небольшого подмножества наших приманок, количество IP-адресов злоумышленников, наблюдаемых во всем мире, намного выше. В нашем эксперименте только 18% IP-адресов злоумышленников достигли более одной приманки.
Рисунок 4. Среднее количество уникальных IP-адресов злоумышленников, обнаруженных на приманке за 30 дней.
На рисунке 5 показан процент IP-адресов злоумышленников, неоднократно наблюдаемых в разные дни. В течение 30 дней, охваченных этим исследованием, 85% IP-адресов злоумышленников наблюдались только в течение одного дня. Число указывает на то, что межсетевой экран уровня L3 неэффективен, поскольку злоумышленники редко повторно используют одни и те же IP-адреса для запуска атак. Список вредоносных IP-адресов, созданный сегодня, скорее всего, устареет завтра.
Рисунок 5. Процент IP-адресов злоумышленников, обнаруженных в течение одного или нескольких дней.
В рамках проекта сетевого сканирования ежедневно выявлялось более 700 000 IP-адресов сканеров. Нам было любопытно, может ли упреждающая блокировка трафика сканирования сети помешать злоумышленникам обнаружить приманки и уменьшить количество атак. Чтобы проверить гипотезу, мы создали экспериментальную группу из 48 приманок и применили политики брандмауэра для блокировки IP-адресов от известных сетевых сканеров. Политика брандмауэра блокирует IP-адреса, которые сканировали определенное приложение ежедневно в течение последних 30 дней. На рисунке 6 сравнивается количество атак, наблюдаемых на каждую приманку между контрольной группой (без межсетевого экрана) и экспериментальной группой (с межсетевым экраном). Мы не смогли увидеть существенной разницы между этими двумя группами, а это означает, что блокировка известных IP-адресов сканера неэффективна для предотвращения атак.
Рисунок 7. Среднее количество уникальных IP-адресов злоумышленников, наблюдаемых на приманке в разных регионах.
Рисунок 8. Топ-10 стран происхождения IP-адресов злоумышленников.
Выводы
Проблема незащищенного доступа к службам не нова для общедоступного облака, но гибкость управления облачной инфраструктурой ускоряет создание и тиражирование таких неверных конфигураций. Исследование подчеркивает риск и серьезность таких неправильных конфигураций. Когда уязвимый сервис доступен в Интернете, злоумышленники могут найти и атаковать его всего за несколько минут. Поскольку большинство этих интернет-сервисов подключены к некоторым другим облачным рабочим нагрузкам, любой взломанный сервис потенциально может привести к компрометации всей облачной среды.
Однако этот тип неправильной конфигурации несложно предотвратить и исправить с помощью облачных подходов. Некоторые стратегии, которые могут использовать системные администраторы:
– Ограничьте возможность открытия привилегированных портов. Например, используйте политики AWS Service Control или Azure Firewall Management.
– Создайте правила аудита для мониторинга всех открытых портов и открытых сервисов. Например, используйте инструменты AWS Config, Checkov или Cloud Security Posture Management.
– Создавайте правила автоматического ответа и автоматического исправления ошибок конфигурации. Например, рассмотрите AWS Security Hub или Prisma Cloud Automated Remediation.
– Разверните межсетевые экраны нового поколения переда приложениями (NGFW) Palo Alto Networks, такие как CN-Series, VM-Series или Web Application Firewall, для блокировки вредоносного трафика.
