Исследователи обнаружили ботнет из роутеров и DSL-модемов

Исследователи обнаружили ботнет из роутеров и DSL-модемов

Исследователи из DroneBL несколько недель назад, борясь с нацеленной на их сервис DDoS-атакой, наткнулись на необычный ботнет.Тщательно изучив ботнет, исследователи пришли к выводу, что червь под названием psyb0t захватывает исключительно роутеры и DSL-модемы, при этом игнорируя обычные компьютеры.

Заражению подвержены любые маршрутизаторы на базе Linux/MIPS, доступ к администрированию которых производится через службы SSHd или telnetd, при условии, что сами устройства находятся в демилитаризованной зоне DMZ.

Как выяснилось, первые упоминания об этой вредоносной программе появились ещё в декабре прошлого года. Тогда речь шла только об ADSL-модемах Netcomm NB5 и аналогичных аппаратах, а для захвата управления над ними червь использовал значения логина и пароля по умолчанию. При этом уязвимость, которой пользовался тогда psyb0t, существует только в определённой версии прошивки устройства, и в более поздних версиях уже устранена.

Однако, специалисты из DroneBL имели дело с более поздней версией червя, которая для взлома маршрутизаторов использовала перебор пар логин-пароль по списку. Кроме того, раньше не было замечено, чтобы зомби-роутеры получали какие-либо инструкции из координирующего центра, хотя такая возможность и была предусмотрена посредством одного из IRC-каналов. Однако специалисты DroneBL считали, что ботнет использовался для проведения распределённой DoS-атаки на их серверы.

После того, как в блоге DroneBL появилось подробное описание червя, поступила новая информация автора psyb0t. Он уверяет, что написал червя с исследовательскими целями и теперь прекращает дальнейшую работу над ним. Вирусописатель уверяет, что сумел захватить порядка 80 000 устройств, но никогда не использовал этот ботнет для DDoS-атак, фишинга или кражи личных данных.

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

 

Источник 

Баги в ядре 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