Новый Python-бэкдор проникает на хост VMware ESXi через эксплойт OpenSLP

Новый Python-бэкдор проникает на хост VMware ESXi через эксплойт OpenSLP

Новый Python-бэкдор проникает на хост VMware ESXi через эксплойт OpenSLP

Специалисты Juniper Networks обнаружили кастомный бэкдор, заточенный под серверы VMware ESXi. Вредонос написан на Python и, по данным аналитиков, не был документирован ранее.

Судя по дефолтной привязке к порту 427, для внедрения бэкдора злоумышленники скорее всего используют уязвимость OpenSLP — какую именно, установить пока не удалось. Не исключено, что это CVE-2019-5544 или CVE-2020-3992: обе позволяют захватить контроль над хостом и до сих пор провоцируют атаки на ESXi-серверы.

Анализ показа, что вредоносный имплант vmtools.py довольно бесхитростен, но цепок. Он записывается на диск, используемый для хранения образов виртуальных машин, логов и т. п. В ходе атаки хакеры также изменяют три системных файла, которые автоматически копируются и восстанавливаются после перезагрузки ОС сервера ВМ:

  • /etc/rc.local.d/local.sh,
  • /bin/hostd-probe.sh,
  • /etc/vmware/rhttpproxy/endpoints.conf.

Первый по умолчанию содержит лишь комментарии и оператор выхода; в него добавляется следующий код:

 

В результате в /bin/hostd-probe.sh появляется строка кода, запускающая Python-скрипт:

 

Заключительная команда touch, записанная в /etc/rc.local.d/local.sh, сбрасывает временные метки изменений и доступа к /bin/hostd-probe.sh, чтобы стереть следы непрошеного вмешательства.

Имя вредоносного скрипта и его расположение (/store/packages/vmtools.py) тоже выбраны таким образом, чтобы не вызывать подозрений. В начало vmtools.py, тоже для отвода глаз, помещена информация об авторском праве, скопированная из легитимного Python-файла VMware.

 

Сторонний скрипт запускает простой веб-сервер, принимающий запароленные POST-запросы. Его можно использовать двояко: для выполнения произвольных удаленных команд, с отображением результатов в виде веб-страницы, и для запуска обратного шелла с хостом и портом по выбору автора атаки.

В данном случае привязка осуществляется к порту 8008 на локальном IP-адресе 127.0.0.1. Сервер при этом настроен на прием пяти параметров с вводящими в заблуждение именами:

  • server_namespace — пароль, защищающий бэкдор от непредусмотренного использования;
  • server_instance — local или remote (прямой или обратный шелл);
  • operation_id — команда для выполнения (только для local);
  • envelope и path_set — хост и порт для обратного подключения. 

Полученный пароль (хеш MD5) сверяется со вшитым значением; при совпадении выполняется оператор, соответствующий значению server_instance. Если POST не содержит номер порта, используется дефолтный 427 (стандартный для службы OpenSLP). Поскольку IP 127.0.0.1 доступен только со скомпрометированной машины, для получения удаленного доступа автор атаки меняет настройки обратного прокси ESXi (организует проброс портов с помощью файла /etc/vmware/rhttpproxy/endpoints.conf).

Ни vmtools.py, ни модифицированный local.sh пока не детектятся на VirusTotal. Для защиты от новой угрозы эксперты советуют принять следующие меры:

  • как можно скорее установить все патчи, выпущенные вендором;
  • ограничить входящие соединения по сети доверенными хостами;
  • проверить наличие vmtools.py и содержимое системных файлов, которые используют операторы зловреда;
  • проверить сохранность всех системных файлов, переживающих рестарт хост-машины.

Минтруду не удалось оспорить штраф за утечку данных

Министерству труда не удалось оспорить в Верховном суде штраф за утечку персональных данных сотрудников и членов их семей. Ранее административное наказание было назначено судами нижестоящих инстанций. Основным аргументом ведомства стало то, что причиной инцидента стала халатность внешнего подрядчика.

Объём утечки оказался относительно небольшим — около 1400 записей. Однако в открытый доступ попали наиболее востребованные на теневом рынке сведения, включая номера паспортов и реквизиты банковских карт.

Мировой судья оштрафовал Минтруд на 100 тыс. рублей. Ведомство попыталось оспорить решение, настаивая, что ответственность за защиту данных лежала на подрядной организации, а значит, само министерство следует считать пострадавшей стороной. В итоге спор дошёл до Верховного суда.

Верховный суд подтвердил, что именно Минтруд является оператором персональных данных и несёт полную ответственность за их защиту, включая контроль за действиями подрядчиков. Суд указал, что ведомство не приняло необходимых мер для обеспечения безопасности инфраструктуры, а о факте утечки узнало лишь после запроса контролирующего органа. Кроме того, был нарушен установленный порядок уведомления о компьютерных инцидентах, что также образует состав административного правонарушения.

Руководитель практики защиты данных Stonebridge Legal Денис Бушнев в комментарии для радиостанции «Коммерсантъ FM» назвал решение Верховного суда логичным продолжением сложившейся правоприменительной практики и разъяснений Роскомнадзора:

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

«Минтруд, имея возможность провести аудит, ничего не предпринял. Если бы были представлены акты проверок, ответственность можно было бы попытаться переложить на подрядчика, но для этого необходимо выполнить ряд мер. В выигрыше оказываются юристы, которые убеждают клиентов выстраивать корректную систему работы: раньше им не хватало наглядного судебного примера. Теперь он есть — с конкретным штрафом, да ещё в отношении госструктуры. А выигрывают и те, кто заранее выстроил процессы и “подстелил соломку”», — отметила руководитель практики комплаенса юридической фирмы LCH.LEGAL Елена Шершнева.

RSS: Новости на портале Anti-Malware.ru