anti bruteforce что это
Brute-force атаки с использованием Kali Linux
Brute-force (атака полным перебором) – метод решения математических задач, сложность которого зависит от количества всех возможных решений. Сам же термин brute-force обычно используется в контексте хакерских атак, когда злоумышленник пытается подобрать логин/пароль к какой-либо учетной записи или сервису.
Рассмотрим инструменты, которые можно использовать для выполнения brute-force атак на SSH и WEB-сервисы, доступные в Kali Linux (Patator, Medusa, Hydra, Metasploit), а также BurpSuite.
Все материалы, предоставленные в рамках данной статьи, предназначены для использования исключительно в учебных целях. Использование материалов в противоправных и противозаконных запрещено.
Brute-force SSH
Для примера возьмем тестовую машину 192.168.60.50 и попробуем подобрать пароль пользователя test по SSH. Мы будем использовать популярные пароли из стандартного словаря rockyou.txt.
Patator
Для подбора пароля средствами Patator используем команду:
где:
ssh_login — необходимый модуль
host – наша цель
user – логин пользователя, к которому подбирается пароль или файл с логинами для множественного подбора
password – словарь с паролями
-x ignore:mesg=’Authentication failed’ — команда не выводить на экран строку, имеющую данное сообщение. Параметр фильтрации подбирается индивидуально.
Hydra
Для подбора пароля используя Hydra выполним команду:
где:
-V – показывать пару логин+пароль во время перебора
-f – остановка как только будет найден пароль для указанного логина
-P – путь до словаря с паролями
ssh://192.168.60.50 – указание сервиса и IP-адрес жертвы
Medusa
Для подбора пароля с использованием Medusa выполним команду:
где:
-h – IP-адрес жертвы
-u – логин
-P – путь к словарю
-M – выбор модуля
-f – остановка после нахождения валидной пары логин/пароль
-v – настройка отображения сообщений на экране во время процесса подбора
Metasploit
Произведем поиск инструмента для проведения brute-force атаки по SSH:
search ssh_login и получили ответ:
Указание необходимых параметров производится через команду «set«.
set rhosts 192.168.60.50
set username test
set userpass_file /root/wordlist
set stop_on_success yes
set threads 4
set rport 22
Указав необходимые параметры набираем команду «run» и ждем.
Противодействие
Ограничить количество устанавливаемых соединений с использованием межсетевого экрана. Пример настройки iptables:
Такое правило установит ограничение доступа к SSH для каждого IP-адреса до 1 соединения в секунду, значительно усложнив перебор. Также эффективным решением может быть использование двухфакторной аутентификации (например, используя eToken) или аутентификации с использованием ключевой пары, а также использование ACL на основе IP-адресов.
Brute-force WordPress
Рассмотрим другой пример — подбор пароля окна авторизации веб-формы.
Для примера будем подбирать пароль от учетной записи администратора wordpress.
BurpSuite
Для начала нам необходимо понять, как происходит процесс авторизации. Для этого мы будем использовать BurpSuite. Нам необходимо попробовать авторизоваться с любым паролем и логином, чтобы посмотреть какие запросы проходят через BurpSuite.
Отлично, мы увидели POST запрос для авторизации с ним мы и будем работать.
В BODY указано какой логин и пароль проверялись, а значит, мы можем попробовать самостоятельно подставить нужные нам значения.
Передаем этот запрос в Intruder и там выбираем необходимые параметры для атаки. В пункте Payload Positions тип атаки оставляем sniper, но для проверки оставляем только параметр pwd. Таким образом, при атаке будет изменяться только этот параметр.
Загружаем необходимый словарь и начинаем атаку.
Из поведения веб-приложения мы видим, что неверный пароль возвращает код ответа 200. После перебора словаря, видим, что один из паролей дал ответ с кодом 302 — он и является верным.
Данный метод перебора занимает намного больше времени, чем при использовании Patator, Hydra, Medusa и т.д. Даже с учетом того, что мы взяли небольшой словарь, BurpSuite перебирал словарь около 40 минут.
Hydra
Попробуем подобрать пароль с помощью Hydra.
Как мы уже знаем, при неверной авторизации возвращается код 200, а при успешной – 302. Попробуем использовать эту информацию.
Для запуска используем команду:
Здесь мы указываем обязательные параметры:
-l – имя пользователя
-P – словарь с паролями
-t – количество потоков
http-post-form – тип формы, у нас POST.
/wp-login.php – это URL страницы с авторизацией
^USER^ — показывает куда подставлять имя пользователя
^PASS^ — показывает куда подставлять пароль из словаря
S=302 – указание на какой ответ опираться Hydra. В нашем случае, ответ 302 при успешной авторизации.
Patator
Как мы уже знаем, при неудачной авторизации возвращается код 200, а при удачной – 302. Будем использовать тот же принцип, что и с Hydra:
Запуск производится командой:
http_fuzz – модуль для brute-force атаки http
url – адрес страницы с авторизацией
FILE0 — путь до словаря с паролями
body – информация, которая передается в POST запросе при авторизации
-t — количество потоков
-x – В данном случае мы указали команду не выводить на экран сообщения строки, содержащие параметр с кодом 200
accept_cookie – сохранение параметра cookie и передачи его в следующий запрос
Как итог – нам удалось подобрать пароль.
Nmap
Утилита Nmap позволяет в том числе производить подбор паролей для веб-форм авторизации, если использовать скрипт http-wordpress-brute с соответствующими аргументами:
—script-args – добавление аргументов
user или userdb – логин или файла с логинами
pass или passdb — указание пароля или словаря
thread – количество потоков
firstonly=true – выводить результат после первого же правильного пароля
Противодействие
Усложнить задачу перебора можно используя следующие методы:
— Применение межсетевого экрана и прочего ПО для ограничения количества обращений к защищаемому сервису. О том, как мы используем машинное обучение для выявления подобных атак (в том числе распределенных), можно почитать в статье.
— Использование средств, препятствующих быстрой проверке корректности ключа (например, Captcha).
Заключение
В данной статье мы поверхностно рассмотрели некоторые популярные инструменты. Сократить риск подбора пароля можно, следуя следующим рекомендациям:
— используйте устойчивые к подбору пароли;
— не создавайте пароли, используя личную информацию, например: дату рождения или имя + дата рождения или мобильный телефон;
— регулярно меняйте пароль;
— на всех аккаунтах применяйте уникальные пароли.
Подобные рекомендации (как и рекомендации по безопасной веб-разработке) мало кто соблюдает, поэтому необходимо использовать различные программные решения, позволяющие:
— ограничить подключение по IP-адресу, или, если это невозможно, ограничить одновременное количество соединений с сервисом (средствами iptables, nginx и прочими);
— использовать двухфакторную аутентификацию;
— выявлять и блокировать подобные атаки средствами SIEM, WAF или другими (например, fail2ban).
При освещении в СМИ вируса NotPetya не сообщалось, что он мог наделать еще больше зла. Например, брутфорс на парламент Великобритании. Это является еще одним напоминанием того, что brute force остается глобальной угрозой:
Это также наводит нас на важные вопросы — в первую очередь, как такое могло произойти:
Подобные проблемы заставляют задуматься о том, что нужно глубже исследовать этот тип атаки.
Брутфорс — что это?
Классическая brute force атака — это попытка « угадать » пароль в ПК, когда злоумышленник завладел зашифрованным его значением.
Оно позволяет хакеру использовать мощные компьютеры для тестирования большого количества паролей без риска быть обнаруженным. С другой стороны, такая brute force атака не может быть первым этапом. Для этого злоумышленник должен уже иметь копию зашифрованных паролей.
Онлайн-атака — это, когда злоумышленник пытается взломать функцию входа в систему или приложение с помощью подбора учетных данных. Так как ему не нужно сначала получать зашифрованные пароли, хакер может использовать этот метод при попытке проникнуть в систему.
Имеют ли место brute force атаки онлайн?
Одновременно подобрать имя пользователя и пароль непросто. Большинство систем при неудачном входе в систему не сообщают, что было введено неверно: имя пользователя или пароль. Первый шаг, который предпринимает злоумышленник — это попытка атаковать известных пользователей.
Хакер может находить имена пользователей, используя открытые исследования. Во многих организациях, например, логины пользователей имеют предсказуемую структуру, основанную на имени сотрудника. Простой поиск в LinkedIn позволяет выявить большое количество имен пользователей.
Тем не менее, этот тип классической brute force атаки онлайн является скорее гипотетической. Причина проста: у большинства современных систем и приложений есть встроенная блокировка. Если пользователю не удается войти в систему за несколько попыток, учетная запись блокируется и для ее разблокировки требуется вмешательство администратора.
Рост количества случаев credential stuffing
Credential stuffing — это атака, в которой злоумышленники используют пары имя пользователя / пароль, украденные с общедоступных сайтов, чтобы проникнуть в атакуемую систему.
Количество успешных атак на общедоступные сайты увеличивается, и злоумышленники публикуют базы учетных данных или продают их на подпольных биржах. Предположение, которое слишком часто оправдывается, заключается в следующем: люди используют одинаковое имя пользователя и пароль на разных сайтах.
Подбор пароля брутфорсом при Credential stuffing позволяет обойти блокировку, поскольку каждое имя пользователя вводится только один раз. Использование известной пары имя пользователя / пароль увеличивает вероятность успеха с меньшим количеством попыток.
Поскольку в качестве контрмеры блокировка не эффективна, организации часто применяют двухфакторные механизмы аутентификации. Двухфакторная аутентификация требует, чтобы у пользователя было что-то еще помимо пароля. Например, номер мобильного, на который пользователь может получить текстовое сообщение.
Поскольку двухфакторная аутентификация громоздка, успешная аутентификация обычно одобряется на основе любого « аналогичного » доступа. « Аналогичный » доступ может представлять собой использование одного и того же устройства или географического местоположения.
Многие из нас сталкивались с сайтами, требующими двухфакторной аутентификации при обращении с нового устройства, публичной сети или во время поездок.
Хотя двухфакторная аутентификация является надежным решением, она имеет существенные недостатки: при ней изменяется пользовательский интерфейс и она предполагает интерактивный вход в систему.
Нет ничего более раздражающего, чем натолкнуться на двухфакторную аутентификацию при входе со смартфона. В результате эта опция часто оставляется на усмотрение пользователя в качестве дополнительного варианта. Поэтому возникает необходимость в системе обнаружения, связанной с использованием аналитики, которая бы распознавала метод брутфорса.
Обнаружение brute force атак
Часто рекомендуемый метод обнаружения brute force атак связан с определением классических атак. Это обнаружение нескольких неудачных попыток входа в систему для одного пользователя за короткий промежуток времени.
Многие рекомендации для начинающих при создании правил корреляции SIEM ( Security Information and Event Management ) делают упор на обнаружение brute force атак именно по такому сценарию. Хотя это изящный и простой путь, но он предназначен для определения практически несуществующего вектора атак.
Фактор, который дает возможность идентифицировать brute force атаку при аутентификации — это большое количество неудачных попыток входа в систему. Но поскольку пользователь не может быть ключом к обнаружению, система должна сосредоточиться на другом ключе, чтобы связать поток событий, составляющих атаку.
Практика обнаружения атак
До сих пор мы предполагали, что события, анализируемые для установления атаки, являются ярко выраженными. Любое событие неудавшегося входа в систему определяется как успешная или безуспешная попытка, а имя пользователя всегда находится в одном поле и имеет один формат.
Но обработка потока событий для подготовки их к анализу и обнаружению брутфорс также является проблемой, которую нужно рассматривать отдельно.
Когда поймем, какие события отслеживать, нам все равно нужно знать, как правильно идентифицировать успешную или безуспешную попытки входа в систему. Успешная или безуспешная попытки локального входа — это отдельные события, которые для аутентификации контроллера домена помечаются внутри события.
Обнаружение атак через Cyber Kill-Chain
Поэтому крайне важно, чтобы любая система, используемая для обнаружения brute force атак, включала в себя нестандартные алгоритмы и, чтобы эти алгоритмы обнаружения постоянно обновлялись.
Дайте знать, что вы думаете по данной теме в комментариях. За комментарии, лайки, дизлайки, отклики, подписки низкий вам поклон!
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, отклики, дизлайки, подписки, лайки!
Что такое атака перечислением и чем она опасна
При аудите веб-приложения наши эксперты нашли уязвимость к атаке перечислением имен пользователя. Рассказываем, что это за проблема и как с ней бороться.
Недавно наши эксперты из Kaspersky Blockchain Security проверяли блокчейн-платформу на наличие уязвимостей. В процессе они обнаружили, что механизм восстановления забытого пароля их веб-приложения уязвим к атаке перечислением пользовательских имен. Мы решили, что это неплохой повод рассказать в нашем блоге, что это за атака и чем она опасна.
Что значит атака перечислением
В веб-приложениях с аутентификацией при помощи пароля и логина, как правило, есть несколько механизмов, которые обращаются к базе пользователей. Это окно логина (по понятным причинам), форма регистрации (чтобы избежать дублирования имен пользователя) и страница сброса забытого пароля (чтобы удостовериться в том, что учетная запись, пароль от которой сбрасывают, существует). Если эти механизмы реализованы недостаточно безопасно, то злоумышленники могут попытаться использовать их для того, чтобы выявить, есть ли такой логин в базе.
Раньше все эти механизмы применялись без какой-либо защиты. Поэтому злоумышленник мог вооружиться списком логинов и программой, которая пробовала вводить все эти логины по очереди. Чтобы не давать потенциальным вредителям лишней информации, со временем разработчики стали применять различные защитные трюки (капчу, ограничение количества попыток входа, сокрытие деталей ответа).
В современных веб-приложениях окно логина практически всегда имеет такую защиту. А вот про форму регистрации и страницу сброса пароля иногда забывают. К тому же разработчики веб-приложений не всегда задумываются о том, что наличие или отсутствие имени пользователя в базе иногда можно определить по различиям во времени отклика сервера на запросы. Например, если имя в базе найдено, то ответ сервера приходит через две миллисекунды, а если не найдено, то через четыре. Человек разницы не заметит, а вот автоматизированные инструменты перебора — могут.
Чем опасна атака перечислением имени пользователя
Атака перечислением позволяет злоумышленнику удостовериться, что такое имя есть в базе. Да, это не позволит ему незамедлительно войти в систему, но даст половину требуемой информации. Например, при организации брутфорс-атаки он будет не перебирать пары имен и паролей, а подбирать пароли к проверенной учетной записи. Это сэкономит ему время и усилия.
К тому же не надо забывать, что в качестве имени пользователя сейчас практически повсеместно используется почтовый адрес. Соответственно, логин у среднестатистического человека един для множества сервисов. И не все они относятся к безопасности одинаково серьезно — новости об утечках пар логинов и паролей с разных сайтов появляются достаточно регулярно. И коллекции утекших данных доступны на хакерских форумах. А людям свойственно использовать одни и те же пароли на разных сервисах. Соответственно, удостоверившись, что имя пользователя есть на вашем сайте, злоумышленник обратится к коллекции логинов и паролей и посмотрит, нет ли там данных той же учетной записи на других сайтах. А потом попробует ввести эти данные.
Кроме того, атаку перечислением часто применяют операторы целевого фишинга на этапе разведки. Удостоверившись, что их цель имеет учетную запись в вашем сервисе, они могут послать от вашего имени письмо о необходимости смены пароля со ссылкой на фишинговую страницу, имитирующую ваш сайт. Ничего не подозревающий клиент введет новый пароль, подтвердит старый и тем самым снабдит мошенников всем тем, за чем они охотятся.
Как защититься от атаки перечислением?
Вы когда-нибудь обращали внимание, как современные сервисы реагируют на форму сброса пароля? Они не говорят: «Ссылка на сброс пароля выслана на почту» или «Введенной почты нет в базе», как это происходило раньше. Вместо этого они пишут: «Если ваш адрес есть в базе, то на него будет выслано письмо со ссылкой…». То есть прямо не подтверждают и не опровергают наличие такого имени пользователя. Это делается именно для того, чтобы защититься от атаки перечислением.
Точно так же и в окне логина никогда не нужно детально объяснять «неверный пароль» или «нет такого имени пользователя». Просто — пара логин/пароль не найдена. Да, с точки зрения UX-специалиста такие ответы не оптимальны. Они могут вызывать недовольство пользователя (меня, например, ужасно бесит, когда я забываю, при помощи какого адреса регистрировался, а сервис мне не подсказывает). Но безопасность практически всегда достигается в ущерб удобству. И в случае с сервисами авторизации небольшой перекос баланса в сторону безопасности оправдан.
Разумеется, капча и ограничение попыток также не помешают. Ну и кроме того, для обеспечения безопасности вашего веб-приложения имеет смысл проводить сторонний аудит. Если вы также занимаетесь блокчейн-технологиями, то наши коллеги из Kaspersky Blockchain Security могут помочь с анализом защищенности веб-приложений.
Et tu, Brute? Что хотят от нас брутфорсеры?
Каждый владелец сервера с «белым» IP-адресом наблюдал в логах бесчисленные попытки подключиться к серверу по SSH с разных точек мира. Администраторы ставят средства противодействия, такие как fail2ban, переносят SSH на другие порты и всячески пытаются защититься от брутфорсеров. Но чего же хотят эти замечательные люди от наших серверов?
Поверхностный ответ, конечно, прост: наживы на бесплатных вычислительных ресурсах и полученных чувствительных данных. Но этот ответ недостаточно подробный. Давайте разложим виртуальные «приманки» и проследим, что происходит, когда автоматический брутфорс оказывается успешным.
В данной статье мы рассматриваем только случаи попадания под «автоматический» перебор и исключаем целенаправленные атаки на наш сервер.
Не пытайтесь повторить описанное в статье, если у вас нет должной подготовки. Ни в коем случае не повторяйте на продакшн-серверах!
Сперва узнаем «врага» в лицо.
Пассивно-агрессивное наблюдение
У нас есть сервер, который уже пару недель стоит с открытым 22 портом. Этого достаточно, чтобы его заметили и начали атаковать.
Для начала узнаем, откуда к нам приходят, как часто и с какими данными. Не будем изобретать велосипед и просто (это действительно просто!) модернизируем исходный код OpenSSH. Ставим необходимые зависимости.
Команда для Ubuntu:
Получаем самую свежую версию с GitHub:
Проводим этап конфигурации перед сборкой. Здесь и далее мы проводим все операции от имени суперпользователя. Чтобы не сломать оригинальный SSH-сервер, указываем префикс для установки патченной версии.
Если все прошло без ошибок, то можно приступать к изменению исходного кода OpenSSH. Брутфорс организуется по методу аутентификации password. Заглядываем в файл auth-passwd.c. В этом файле интересна функция auth_password(), вернее ее начало.
Этот метод вызывается всякий раз, когда кто-нибудь пытается пройти аутентификацию по паролю. Контекст аутентификации (Authctxt) и структура ssh содержат все полезные нам поля:
Конечно, это не самый потокобезопасный код. Но так как мы пишем всего одну строку и нам не критичен порядок записей, то буферы ОС сами разберутся. Собираем и устанавливаем. Установка необходима для генерации ключей хоста.
Правим конфиг /root/ssh/etc/sshd_config, добавляем следующую строчку.
Если не разрешить вход для суперпользователя, то метод auth_password не будет вызываться. Уносим свой рабочий локальный SSH на другой порт и запускаем нашу ловушку.
За 10 дней наблюдений было предпринято 74 865 попытки зайти c 1 131 IP-адресов. В среднем в секунду было от одной до двух попыток аутентификации. Максимально зафиксированное число — 10 попыток за секунду. Примечательно, что все они были совершены с одного IP-адреса.
В этой статье не будет указания точных IP-адресов, так как это очень непостоянная информация. А вот статистика по странам и автономным системам (AS) будет весьма полезна.
Легко заметить, что Китай преобладает по количеству брутфорса.
Вот так выглядит топ самых настырных адресов из следующих AS:
В этом топе отображаются самые активные брутфорсеры, но если взглянуть на весь список адресов, то обнаружится еще одна интересная закономерность: почти половина останавливается на 50 или 70 попытках.
По источникам брутфорса посмотрели, перейдем к топу паролей. Нам удалось собрать словарь на 2 018 пользователей и 32 238 паролей. Вот топ паролей:
Вот он: ababablkljkjhghfgdfdgjhkfdgfhghfgfgqqqqqqwwwwwwgqqqqqqababab.
Примечательно, что это не попытка ручного подбора методом соприкосновения головы и клавиатуры, а вполне себе словарный пароль, который засветился шесть раз с разных мест.
Также один адрес перебирал пароль по датам, а еще несколько десятков адресов как будто бы плохо сконфигурированы: они всегда приходили с паролем root, а в имени пользователя был просто набор символов, например, 1!2@3#4$5%6^7&8*9(0)-_=+.
Из полученной информации следуют такие выводы:
Карт-бланш
Сперва необходимо выяснить, как действует атакующий. Единственное, в чем мы можем быть уверены, так это в том, что на сервер зайдут через ssh. Сперва пропатчим метод аутентификации, чтобы пропускать всех, кто к нам пришел.
Далее изучаем документацию и находим три полезных ключа для sshd.
Запуск программ в *NIX-подобных системах сопряжен с двумя системными вызовами: fork(2) и execve(2). Первый просто дублирует текущий процесс и не несет никакой полезной информации, а вот второй содержит путь и аргументы новой программы.
Воспользуемся удобным инструментом для трассировки системных вызовов в программах — strace. Настраиваем фильтр по execve, разрешаем трассировать потомков и снимаем ограничения на длину выводимой строки. Итоговая команда для трассировки выглядит так:
На выходе получается несколько перегруженный лог, так как атакующий запускает команды, содержащие конвейеры. Тем не менее, извлечь из лога итоговый скрипт несложно.
К слову, именно этот публичный ключ уже фигурировал на Хабре, но при других обстоятельствах, а автор не потерял доступ к собственному оборудованию. Потенциально имя ключа может пролить свет на назначение этого ботнета, так как во второй части имени ключа, fckr, легко восстановить недостающие гласные. А вот что такое mdr, автору понять не удалось.
На первый взгляд кажется, что атакующий бот проверяет наличие сессий на сервере (команда w) и стесняется что-либо загружать. Возможно, конечно, владелец ботнета остерегается администраторов, которые внимательно относятся к своим серверам, и выжидает некоторое время перед загрузкой зловредных бинарников.
Сделаем вид, что мы безответственные администраторы, и составим следующий shell-скрипт, который запустим через nohup:
Так, первая попытка позволит нападающему пройти в ОС сервера и изменить данные для подключения на свои, а после отключения SSH-сервер перезапустится на обычный, который примет теперь уже подходящие доступы.
Единственный минус данного метода — необходимо несколько раз перезапустить скрипт, прежде чем брутфорсер придет с логином root. Но нам повезло — первый же встречный пришел с логином root.
Но отдаваться первому встречному было плохой идеей. Атакующий собрал информацию о виртуальной машине, сменил пароль и ключ, и в течение следующих двух дней никто по новому ключу не пришел.
Пришлось откатить виртуальную машину на момент до атаки. Из этой попытки был сделан вывод, что ловить хороших людей по одному нецелесообразно: их намерения неясны и тратят много времени.
Решение простое: раз уж мы разрешили заходить каждому встречному, а каждый встречный выполняет отдельные команды в неинтерактивном режиме, так давайте будем записывать приходящие команды вместо исполнения. Находим метод do_child() в session.c.
Можно просто записывать все команды и ничего не выводить, но, кажется, атакующий принимает решения на основе полученной информации. По крайней мере при отсутствии вывода атакующий отключился после первой команды.
Пришлось придумать способ «отсеять» атакующих, которые выполняют простой сбор информации о машине, и запретить деструктивные действия. Также я попытался сделать сервер более привлекательным для атакующих и сделал обманывающие заглушки, которые «говорят», что в сервере 72 ядра, а процессор — Intel® Xeon® Gold 6354.
При этом запуск интерактивной сессии не будет логироваться, но это, на мой взгляд, было не так важно, так как нас атакуют боты. Это предположение, конечно, оказалось неверным, но процесс ssh трассируется на системный вызов execve, поэтому команды мы все равно узнаем.
Колизей
Первое время приходили только атакующие с ключом mdrfckr. Заглушки в сервере SSH не давали им испортить мой ключ, а больше вреда от них и не было. В первый час к нам заглянули 12 серверов, которые суммарно выполнили этот скрипт 79 раз. Кажется, что этот ботнет очень простой и его единственная цель — заставить администратора понервничать и вспомнить, как сбросить пароль в Linux. Дело было под вечер, поэтому виртуальная машина была оставлена в покое в надежде утром найти следы более «серьезных» атакующих.
Утром я вернулся к гипервизору и увидел, что vCPU трудятся на 100%. Заглянул внутрь сервера, проверил логи strace и понял, что ночью мой сервер был полем жарких битв.
Первым пришел любопытствующий скрипт из Испании (Мадрид, AS12479 Orange Espagne SA).
Следом пришел майнер из Америки (Невада, AS53667 FranTech Solutions). В отличие от всех предыдущих, майнер максимально непривередлив. Как-нибудь прокатит. При этом IP-адрес нападавшего и IP-адрес сервера с архивом (Нью-Йорк, AS53667 FranTech Solutions) не совпадают.
Кстати, именно этот майнер дожил до встречи со мной. У него два исполняемых файла krn и krane, а также текстовый файл config.json, это конфиг XMRIG. Тем не менее, майнер непрост: он подчищает за собой историю в .bash_history, удаляет конфиг и исходный архив, а также чистит за собой логи.
Далее были попытки протолкнуть исполняемый файл 8nlh4fpijnyueflljkd2bi9f69 через scp по путям:
На этом моменте место для логирования закончилось, и выяснить IP-адрес атакующего теперь не представляется возможным, так как strace сохраняет только pid. Недостаток места повлиял и на crontab.
Успех был достигнут только по последнему пути, но исходный файл тут же был стерт, а его место занял dhpcd. Этот сервис тоже дожил до встречи со мной, но оригинальный файл уже отсутствовал. К счастью, procfs позволяет вытащить файл даже после его удаления.
Следующий зашедший пытался сменить пароли для пользователей ubuntu, test, oracle, admin, test1, после чего проверил authorized_keys на предмет ключа mdrfckr и заменил ключи на собственный безымянный.
Далее был загружен исполняемый файл r в /dev/shm. Похоже, что данный исполняемый файл избавляется от конкурентов. Он проверяет наличие aliyun.one и скачивающихся скриптов в cron, а затем удаляет множество файлов и грубо завершает другие вредоносные процессы.
/bin, а также по файлам запущенных процессов (/proc/$PID/exe) и применил следующий фильтр:
Назначение этой проверки осталось неизвестным.
Затем в логах появились вторые попытки перечисленных атакующих, а потом — рассвет и прекращение эксперимента. Казалось, что можно очистить сервер от лишнего ПО, заменить команду rm пустышкой и попытаться еще раз.
В идеале, конечно, нужно подменить или запретить системный вызов unlink(2), чтобы вообще ничего не удалялось, но этот трюк достаточно сложный. И может скорее навредить, чем помочь.
Вторая попытка
Теперь первым пришел невиданный ранее посетитель. Он работал через интерактивную оболочку и интересовался наличием masscan на моем сервере. Затем он собрал подробную информацию по процессору и памяти. После — собрал информацию об IP, запустил тесты дисковой подсистемы и проверил скорость доступа к сети Интернет.
Интересно, что скрипт тестирования скачивался с передачей адреса и через stdin: это помогло скрыть источник скрипта от логов трассировки.
Однако большая часть скрипта легко восстанавливается по логу трассировки.
Затем пришел эксперт по смене паролей. Его единственная цель — сменить пароль. И он не справился! Ни одна из перечисленных команд не выполнилась успешно на моем сервере.
А вот и «зашифрованные» в base64 скрипты пошли:
При этом в скрипте используется dota3.tar.gz, но этот файл, увы, не был загружен на сервер. 🙁
Последним на сервер зашел уже известный нам krane, он же продолжил трудиться до рассвета.
Выводы
Мы предложили Интернету беззащитную виртуалку и посмотрели, что произойдет. Все в рамках наших ожиданий, но давайте подведем итог.