Операторы Ragnarok прекратили атаки и выпустили бесплатный дешифратор

Операторы Ragnarok прекратили атаки и выпустили бесплатный дешифратор

Операторы Ragnarok прекратили атаки и выпустили бесплатный дешифратор

Киберпреступники, распространяющие программу-вымогатель Ragnarok (также известен как Asnarök), решили приостановить атаки и выпустить бесплатный дешифратор, который поможет жертвам восстановить пострадавшие файлы.

В утилите для расшифровки жёстко запрограммирован мастер-ключ. Злоумышленники выложили его на одном из своих форумов в дарквебе, где ранее группировка публиковала украденные у жертв файлы.

 

Несколько исследователей в области кибербезопасности уже успели изучить дешифратор, отметил The Record. По их словам, утилита действительно работает, однако всё равно лучше дождаться, когда специалисты подготовят свои версии дешифратора. Ожидается, что абсолютно безопасный расшифровщик можно будет скачать с официального сайта проекта NoMoreRansom.

Операторы Ragnarok начали свои атаки в конце 2019 года (по другим данным — в начале 2020-го). Группировка использовала известные эксплойты для проникновения в сеть организаций, после чего злоумышленники старались зашифровать критически важные серверы и рабочие станции жертвы.

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

Так сложилось, что кибергруппа выбрала в качестве цели шлюзы Citrix ADC, а также использовала эксплойт для 0-day в файрволах Sophos XG. За месяц до прекращения операций преступники поменяли дизайн своего сайта и удалили данные прошлых жертв.

Таким образом, Ragnarok стал уже третьим шифровальщиком за это лето, прекратившим свои кибератаки. Напомним, что ранее этим же отметились операторы Avaddon и SynAck.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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