Ботнет, атаковавший Южную Корею, выводит из строя зомби-машины после их использования

Ботнет, атаковавший Южную Корею, выводит из строя зомби-машины после их использования

На прошлой неделе десятки правительственных сайтов Южной Кореи подверглись DDoS-атакам. Сами по себе нападения, нацеленные на отказ в обслуживании, сегодня уже никого не удивляют, однако каждый раз что-то интересное обнаруживается в 'сопутствующих' материалах; вот и теперь исследовательская лаборатория McAfee, вскрыв бот-клиент, который использовался для направления и координации потоков мусорных запросов, нашла в нем разрушительную начинку.



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


Итак, согласно блог-записи, после установки в систему бот-клиент создает файл noise03.dat, куда записывает отметку о дате / времени заражения, а также количество дней, которое отведено компьютеру. Оператор вредоносной сети может увеличить последний параметр с помощью особых команд, но общая продолжительность "срока дожития" не может превышать 10 дней. Как только время истечет, будет запущен деструктивный функционал:
- первые секторы всех физических жестких дисков перезаписываются нулями (т.е. уничтожается MBR),
- все файлы, хранящиеся на дисках, просматриваются и тоже перезаписываются нулями, если их расширения совпадают с указанными в специальном списке. Список невелик, но содержателен: в него входят популярные форматы документов (doc, docx, docm, xls, xlsx, pdf, eml) и файлов данных для некоторых языков программирования (c, cpp, h, java).
Любопытно, что разработчики бот-клиента предусмотрели даже защиту от перевода системной даты: если установить день, предшествующий моменту инфицирования, то разрушительные процедуры будут запущены немедленно.


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



(изображение из первоисточника blogs.mcafee.com. Щелкните для увеличения...)


При этом бот-клиент похож скорее на троянский загрузчик: он не получает от центра управления прямые команды, а "скачивает" с командных серверов конфигурационные файлы, содержимое которых считывают и приводят в исполнение вторичные компоненты вредоносной программы, работающие независимо от основной службы.


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


McAfee

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

Проще говоря, чем активнее подсистема используется и исследуется, тем быстрее там находят ошибки.

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

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