Обнаружен Python-шифровальщик, нацеленный на серверы Jupyter Notebook

Обнаружен Python-шифровальщик, нацеленный на серверы Jupyter Notebook

Обнаружен Python-шифровальщик, нацеленный на серверы Jupyter Notebook

В ханипот-ловушку Aqua Security попался незнакомый шифровальщик, написанный на Python. Как оказалось, новоявленный зловред ориентирован на корпоративные окружения, использующие среду разработки Jupyter Notebook.

Это интерактивное веб-приложение с открытым исходным кодом предназначено для работы с данными. Продукт позволяет создавать и запускать коды на разных языках программирования, визуализировать результаты анализа, обмениваться блокнотами и публиковать их в интернете. Среди пользователей софта числятся Microsoft, IBM, Google, Oracle, а также ряд американских ВУЗов.

Найденный образец шифровальщика был похож на других Python-собратьев (об одном из них, нацеленном на VMware ESXi, рассказала Sophos в октябре прошлого года). Не исключено, что автор зловреда попросту позаимствовал чьи-то исходники и приспособил их для своих нужд.

Анализ также показал, что это не полнофункциональный шифровальщик; так, аналитики не нашли свидетельств существования записки с требованием выкупа. В Aqua полагают, что им попался тестовый семпл — либо время соединения с ловушкой истекло до завершения атаки. Тем не менее, эксперты уверены, что это не вайпер: зловред не стирает данные и не пытается вывести их на сторонний сервер.

Вредоносная атака начинается с поиска возможностей для взлома: пользователь Jupyter Notebook может допустить ошибку при настройке веб-приложения или упустить из виду защиту доступа. Для проверки уязвимости сервера злоумышленники также пытаются дистанционно загрузить на него текстовый файл с именем f1gl6i6z (в папку /tmp).

Этот файл содержит единственное слово — bl*t, которое навело исследователей на мысль, что авторами атаки могут быть русскоязычные хакеры. Такой же файл аналитики из Aqua не раз находили ранее при разборе атак криптоджекеров на серверы с установленным софтом Jupyter.

Взломав уязвимое приложение брутфорсом, автор атаки открывает шелл-доступ к серверу, используя соответствующую функцию Jupyter Notebook, затем загружает на него необходимые инструменты (напрмер, шифраторы), вручную создает вредоносный скрипт (вставкой Python-кода) и запускает его на исполнение. Итоговый зловред шифрует каждый файл в заданной папке с помощью пароля, также выбранного вручную, и по завершении процесса удаляет себя из системы.

 

В комментарии для SecurityWeek представитель Aqua отметил, что они обнаружили в интернете свыше 11 тыс. серверов с Jupyter Notebooks. Некоторые из них могут оказаться ловушками, однако остальные потенциально уязвимы для подобных атак.

Поскольку интерактивная платформа Jupyter используется для анализа данных и построения моделей данных, новый Python-шифровальщик может причинить большой ущерб организациям, пренебрегающим резервным копированием. Эксперты рекомендуют защитить Jupyter Networks адекватной аутентификацией, ограничить права пользователям, использовать SSL для передачи данных и отключить интернет-доступ к таким серверам — или организовать его через VPN.

История файлов в Windows сообщает об отключённом диске и срывает бэкапы

Microsoft подтвердила проблему с Историей файлов в Windows 10 и Windows 11. Пользователи начали жаловаться, что система упорно показывает предупреждение «Подключите диск "Истории файлов" повторно», даже когда диск для резервного копирования на месте и никуда не отключался. На этом фоне резервные копии у части пользователей просто перестают выполняться.

Судя по описанию Microsoft, Windows в какой-то момент ошибочно решает, что накопитель с File History был отключён слишком надолго.

Причём это касается не только обычных внешних USB-дисков, но и сетевых каталогов, используемых для бэкапов. В результате система может остановить резервное копирование, а пользователю останется только однотипное предупреждение без понятного объяснения, что именно пошло не так.

Хорошая новость в том, что речь не идёт о повреждении уже созданных копий или удалении файлов. Проблема скорее в надёжности процесса: если пользователь уверен, что История файлов продолжает работать как обычно, а на самом деле копирование уже остановилось, это легко может выясниться в самый неприятный момент.

Microsoft дала совет: если резервная копия хранится на внешнем диске, нужно убедиться, что он действительно подключён, а затем дождаться следующего запланированного бэкапа или запустить его вручную через Историю файлов.

Если же используется сетевое расположение, его рекомендуют заново выбрать в настройках Истории файлов и после этого тоже вручную инициировать резервное копирование.

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