LINUX.ORG.RU

Логин, пробел, дефис, root. Баг в telnet позволяет захватить компьютер без пароля

 , ,


0

4

Уязвимость в пакете GNU InetUtils затронула все версии с 1.9.3 по 2.7 включительно.

Казалось бы, telnet давно ушел в прошлое вместе с модемами и dial-up, но именно он внезапно стал источником серьезной уязвимости. В GNU InetUtils обнаружен баг, который позволяет удаленно войти в систему под root без пароля, просто отправив специально сформированное значение переменной окружения.

Проблема затрагивает telnetd сервер, входящий в состав GNU InetUtils. Он передает программе login значение переменной USER, полученной от клиента, без какой-либо проверки. Этим можно воспользоваться, если клиент отправит строку «-f root» в качестве USER и подключится с параметром telnet -a или –login. В результате login воспринимает это как служебный флаг, пропускает стандартную процедуру аутентификации и автоматически авторизует пользователя как root.

Уязвимость получила идентификатор CVE-2026-24061 и оценку по CVSS: 9.8. Под угрозой находятся все версии GNU InetUtils, начиная с 1.9.3 и заканчивая 2.7 включительно. Баг присутствует в проекте почти 11 лет, с мая 2015 года, но был выявлен только сейчас. По сути, это классический пример уязвимости старой школы, где опасная строка без фильтрации передается системной утилите с привилегиями root.

Авторы advisory прямо рекомендуют вообще не использовать telnetd, ограничивать доступ к telnet-порту только доверенными клиентами и как можно быстрее установить исправление или обновиться до версии, в которой устранена проблема. Временным решением может быть полное отключение telnetd или использование кастомной версии login, которая не поддерживает параметр «-f».

Уязвимость обнаружил исследователь Карлос Кортес Альварес, патч был подготовлен и доработан разработчиками GNU InetUtils в январе 2026 года. Исправления включают санитизацию всех переменных, которые используются при формировании команды вызова login, чтобы подобные атаки стали невозможны в принципе.

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

Сразу после публикации информации об уязвимости команда исследователей развернула honeypot-сенсоры, чтобы отследить реальные попытки эксплуатации. Атакующие не заставили себя ждать. За 18 часов наблюдений было зафиксировано 60 попыток взлома с 18 уникальных IP-адресов. По данным платформы Censys, потенциально уязвимыми оказались около трёх тысяч систем по всему миру, хотя значительная часть из них, вероятно, тоже honeypot-ловушки.

Анализ перехваченного трафика показал весьма пёструю картину. Самым активным оказался атакующий с адреса 178.16.53.82, который провёл 12 сессий против 10 различных целей. Его действия были полностью автоматизированы: после получения доступа запускался стандартный набор команд разведки вроде uname -a, id, чтения /proc/cpuinfo и /etc/passwd. Характерной особенностью стала обёртка вывода команд специальными маркерами для последующего парсинга, что явно указывает на ботнет или автоматизированную систему сбора данных.

Более изощрённым оказался злоумышленник с адреса 216.106.186.24. Он сконцентрировался на конкретной подсети и попытался установить SSH-ключ для постоянного доступа, а также загрузить и запустить Python-скрипт с внешнего сервера — предположительно, вредоносное ПО для криптомайнинга или ботнета. Правда, обе попытки провалились: на целевой системе не существовало директории .ssh, а также отсутствовали curl и python.

Особый интерес представляют два атакующих с адресами 167.172.111.135 и 165.22.30.48. В отличие от остальных, они не пытались сразу получить root-доступ, а экспериментировали с учётными записями nobody, daemon и даже несуществующей nonexistent123. Задержки между сессиями и логика действий указывают на живого человека за клавиатурой. Вероятно, это более опытные хакеры, которые знают о системах обнаружения вторжений и имеют в запасе техники повышения привилегий.

Некоторые атакующие демонстрировали поразительную небрежность в операционной безопасности. Например, злоумышленник с адреса 67.220.95.16 использовал один и тот же IP как для эксплуатации, так и для размещения сервера с вредоносным ПО. Другие случайно раскрывали имена своих хостов через переменную DISPLAY: один работал с системы под названием MiniBear, другой — с виртуальной машины shared-vm2.localdomain, третий и вовсе подключался прямо из полноценной графической среды Kali Linux.

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

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

Подробнее: https://www.securitylab.ru/news/568478.php

>>> GNU InetUtils Security Advisory: remote authentication by-pass in telnetd



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Tigger

Уязвимость обнаружил исследователь Карлос Кортес Альварес, патч был подготовлен и доработан разработчиками GNU InetUtils в январе 2026 года.

demo13
() автор топика
Р Е Ш Е Т О !
Е Е
Ш   Ш
Е     Е
Т       Т
О         О
!           !
thunar ★★★★★
()

Прикольно. Это скриптовая дрисня что ли? Где ещё можно передать «-f root» как две строки дочернему процессу, как не в скриптах.

thegoldone ★★
()

Уязвимость обнаружил исследователь Карлос Кортес Альварес

А кто добавил? Кто проверил?

thegoldone ★★
()

Чувак решивший поднять telnetd на боевом сервере вряд ли думает о безопасности.

splinter ★★★★★
()

Еще одно напоминание о том, что даже «древние» технологии могут оставаться реальной угрозой, если они до сих пор работают в продакшне.

если инфраструктура настолько древняя, что использует торчащий наружу телнет (что было моветоном уже лет тридцать назад), то вряд ли она обновлялась и с 2015.

alegz ★★★★★
()

Баг присутствует в проекте почти 11 лет, с мая 2015 года

А так это не древний баг из 80-х как я в начале подумал, а вполне современный. Мда.

firkax ★★★★★
()
Ответ на: комментарий от yars068

вангую, это какие-то новации вяленого.

alegz ★★★★★
()

Теперь осталось найти полуразрушенный завод по производству онучей, где запылённый в углу стоит RedHat 1.0, настроенный как телнет сервер.

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

seiken ★★★★★
()
Ответ на: комментарий от firkax

Древний баг из 80х я в начале 2000х нашел, когда телнетную проксю писал. Там у них было переполнение буфера на посылке однобайтовых контрольных символов. Самое смешное, что через пару недель после этого про этот баг по всей специальной прессе написали. Так совпало. :)

gns ★★★★★
()
Ответ на: комментарий от yars068

Может не везде, но во многих роутерах телнет только во внутреннюю сеть отзывается. Я проверял :)

gns ★★★★★
()
Ответ на: комментарий от gns

Да, но всё-таки, было б лучше, если бы и этого не было, я считаю. Лучше бы ssh по ключу, после предварительной настройки.

yars068 ★★★★★
()

бяан, уже было в лолксах!
http://pony.org.ru/forum/talks/18201010
[:|||||||:]
ах, да:

23:42:43 025 ~$ telnet

No command 'telnet' found, did you mean:
Command 'telnetd' from package 'inetutils-telnetd' (main)
Command 'rtelnet' from package 'socks4-clients' (main)
Command 'ztelnet' from package 'zssh' (main)
Command 'ktelnet' from package 'heimdal-clients' (main)
telnet: command not found

кулхацкеры, идите нафиг!

PerdunJamesBond ★☆
()
Последнее исправление: PerdunJamesBond (всего исправлений: 1)
Ответ на: комментарий от yars068

В домашних роутерах врядли inetutuls-telnetd.

Dimez ★★★★★
()
Ответ на: комментарий от yars068

Отключи. Это в интерфейсе настраивается. Домашним роутерам и ssh не нужен. Я на свой заходил из чистого интереса, так как им рулить из командной строки я так и не понял. Типа есть у тебя вебморда, вот и хоть обрулись.

gns ★★★★★
()
Ответ на: комментарий от gns

У меня вот залогиниться по телнету и написать в него reboot (чтобы сбросить сессию с провайдером) занимает меньше времени чем все остальные способы это сделать, такие как: 1) логинится в тормозную веб-админку и искать где там ребут, 2) логиниться в неё же и искать где там сброс сессии, 3) передёргивать питание модему, 4) передёргивать ему же телефонный провод. А ssh он вообще не поддерживает.

Но и бага этого в нём нет. Во-первых там скорее всего не GNU telnetd а что-то другое, во-вторых его прошивка древнее чем 2015 год. Зато скорее всего есть другие баги и бекдоры.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от PerdunJamesBond

То что на компе нету telnetd это обычная ситуация, а вот как может не быть telnet это уже сложно понять. У тебя там не оффтоп случаем?

firkax ★★★★★
()

Многие думают, что компьютеры - решето. А вы попробуйте PlayStation 5 взломать, сразу проникнитесь, что это сделать непросто (т.е. никак для обновляемых версий).

Saakx
()
Ответ на: комментарий от Saakx

А вы попробуйте PlayStation 5 взломать

А зачем ? деньги-то где? еслиб это было реально выгодно - это уже бы сделали. Сейчас больше половины игр или требуют онлайна, или регулярно получают обновления. Так смысл какой от пиртаских копий? Ну допустим - кому-то и есть. И многие были-бы рады. Но профит-то кто получит? Тот кто взломал? Кратковременный и мало (если вообще получит). А риски, в том числе уголовные, приличные. овчинка выделки не стоит. Когда хак-группа имеет корпорацию, или какую-то средней руки контору - выгода для них очевидна. а с игр-то что? Да и потом. Аппаратные ключи - уже утекли. Так что может быть какой-то Васян, которому ЧСВ перевешивает риски и нет мозгов - какой-то хак и сделает.

DrRulez ★★★★★
()
Ответ на: комментарий от gns

Ну если OpenWRT… Не у всех такая роскошь :)

Кинетик, который это потянет - стоит 10к в днс (на авитосе еще дешевле можно найти), а ультру на том-же авитосе вообще в раионе 15-16к нарыть можно (в днс - 20). Какая уж тут роскошь, скажешь тоже. Не 50 и не 100к все-же. а удобно и надолго. Перепрошивать его при этом - не надо. Все это ставиться уже потом на него. Хочешь во внутренную памяить, хочешь - на флешку.

DrRulez ★★★★★
()

Если кто-то до сих пор использует telnet, то он сам по себе уязвимость, которую нужно немедленно устранить увольнением с волчьим билетом.

zabbal ★★★★★
()
Ответ на: комментарий от yars068

На поверку, многие домашние роутеры имеют работающий telnet

Ни одного такого не встречал в этом веке - где ты находишь такое говно? И, главное, зачем покупать дерьмо если можно взять нормальное?

zabbal ★★★★★
()
Ответ на: комментарий от DrRulez

Ну уже есть один, держит основной оптический канал и запасной через старый ADSL. Еще в него можно симкатрту воткнуть, будет третий канал через LTE. Менять его из-за ОpenWRT нет никакого смысла. WiFi по дому и участку все равно другое железо раздает. Мне больше актуален какой-нибудь TP-Link Omada из недорогих, заодно избавлюсь от gpon терминала, воткну оптику через SFP.

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 1)
Ответ на: комментарий от gns

Ну уже есть один

Скорее всего потянет. если не квас, то гидру точно должен. Если уж не совсем совсем древний

DrRulez ★★★★★
()
Ответ на: комментарий от firkax

Мне чаще приходится gpon-терминал перегружать. А до него только ногами :)

gns ★★★★★
()
Ответ на: комментарий от DrRulez

У меня D-Link старый, под него ничего нет. И в списке поддерживаемых тем же OpenWRT он не значится.

gns ★★★★★
()
Ответ на: комментарий от hippi90

Допустим неопытный разработчик допустил нечто подобное. Но кто принимал этот код?

И в скольких проектах такое же халатное отношение, остаётся только гадать.

thegoldone ★★
()

Ну… допустим уязвимость. Но сам по себе факт наличия telnetd - дырища же. Допустим, не было бы там этой уязвимости. Оно же пароль шлёт открытым текстом по сети, правильно? Вот считай и получил доступ, перехватив пароль.

telnetd место только на модемах и прочих устройствам с микропрограммами, куда sshd попросту не поместится. И не дальше локалки, конечно.

BattleCoder ★★★★★
()
Ответ на: комментарий от BattleCoder

получил доступ, перехватив пароль

Что у тебя там за сеть, что в ней кто попало может перехватывать трафик? Ты, конечно, в теории прав, что открытым текстом нынче стать ничего не стоит, но на практике, как правило, те, кто может перехватывать трафик, тебя ломать не станут. Вот я сижу дома, мой компьютер подключён к моему роутеру, мой - к провайдерскому, от провайдера до ЦОДа уж точно никого лишнего нет, в ЦОД от их роутера до моего сервера уже стоит оборудование хостера. Никто из них меня ломать не станет.

vbr ★★★★★
()
Ответ на: комментарий от splinter

Если боевой сервер торчит своим задом в мировую сеть.

Если это внутренняя сеть для телеметрии и управления приборами, изолированная от шаловливых ручек пользователей, то почему бы и нет. Если часть какого-то оборудования/контроллера/исполнительного механизма. Думаю, при появлении физического доступа у злоумышленника к этой сети, проблема дырявого telnetd будет наименьшей из всех прочих.

Ну и всякое шифрование у прибора может дополнительную боль вызывать у разработчика при сертификации и у пользователя при виде ценника прибора после сертификации.

PS я про применения сродни области, где обычно используется RS-485, который сам по себе тоже мало что шифрует. Всё больше контроллеров которые уже имеют не только по 485 общаться, но и через Ethernet (особенно когда питание по PoE прокинуть можно), в частности по оптике (тут ещё и вопросы ЭМС не так остро стоят).

hatred ★★★★
()

Не теряя ни минуты попробовал взломать свою виртуалку на убунте 22 и огорчился отказом (((

telnet 192.168.122.11 22                
Trying 192.168.122.11...
Connected to 192.168.122.11.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.13

Invalid SSH identification string.
Connection closed by foreign host
SpaceRanger ★★★
()
Ответ на: комментарий от gns

Может не везде, но во многих роутерах телнет только во внутреннюю сеть отзывается. Я проверял :)

Вот недавно я похоже с этим встретился, когда wget и curl не смогли ничего скачать (ощущение, что ДНСов не видит, по ИП просто виснет), но пинг почему-то до 8.8.8.8 спокойно проходит…

Sm0ke85
()
Ответ на: комментарий от gns

У меня D-Link старый, под него ничего нет. И в списке поддерживаемых тем же OpenWRT он не значится.

Можно глянуть в сторону DD-wrt, она как правило есть…

Sm0ke85
()
Ответ на: комментарий от BattleCoder

Но сам по себе факт наличия telnetd - дырища же.

Оно же пароль шлёт открытым текстом по сети, правильно?

telnetd никаких паролей точно не шлёт.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от vbr

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

firkax ★★★★★
()

это классический пример уязвимости старой школы

Как раз таки нет. Это пример того, что не стоит пускать к написанию кода левых васянов, не получивших качественного профильного образования. А ещё это пример того, что не стоит пренебрегать ревью и тестами.

mord0d ★★★★★
()
Ответ на: комментарий от vbr

от провайдера до ЦОДа уж точно никого лишнего нет

Это пока (и то не факт). В РФ — есть, причём гарантированно — ТСПУ от РКН.

CrX ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.