Login, spacja, myślnik, root. Błąd w telnet pozwala na przejęcie komputera bez hasła

Luka w pakiecie GNU InetUtils dotknęła wszystkie wersje od 1.9.3 do 2.7 włącznie.

Wydawałoby się, że telnet dawno przeszedł do przeszłości wraz z modemami i dial-upem, ale to on nagle stał się źródłem poważnej luki. W GNU InetUtils odkryto błąd, który pozwala zdalnie zalogować się do systemu jako root bez hasła, po prostu wysyłając specjalnie sformułowaną wartość zmiennej środowiskowej.

Problem dotyczy serwera telnetd, który jest częścią GNU InetUtils. Przekazuje on programowi login wartość zmiennej USER, otrzymaną od klienta, bez jakiejkolwiek weryfikacji. Można to wykorzystać, jeśli klient wyśle ciąg „-f root” jako USER i podłączy się z parametrem telnet -a lub –login. W rezultacie login interpretuje to jako flagę serwisową, pomija standardową procedurę autoryzacji i automatycznie autoryzuje użytkownika jako root.

Luka otrzymała identyfikator CVE-2026-24061 i ocenę według CVSS: 9.8. Pod zagrożeniem znajdują się wszystkie wersje GNU InetUtils, zaczynając od 1.9.3 i kończąc na 2.7 włącznie. Błąd jest obecny w projekcie prawie 11 lat, od maja 2015 roku, ale został zidentyfikowany dopiero teraz. W istocie jest to klasyczny przykład luki starej szkoły, gdzie niebezpieczny ciąg bez filtrowania jest przekazywany do systemowej narzędzia z uprawnieniami root.

Autorzy advisory bezpośrednio zalecają, aby w ogóle nie używać telnetd, ograniczać dostęp do portu telnet tylko do zaufanych klientów i jak najszybciej zainstalować poprawkę lub zaktualizować do wersji, w której problem został rozwiązany. Tymczasowym rozwiązaniem może być całkowite wyłączenie telnetd lub użycie niestandardowej wersji login, która nie obsługuje parametru „-f”.

Lukę odkrył badacz Carlos Cortes Alvarez, a łatka została przygotowana i dopracowana przez programistów GNU InetUtils w styczniu 2026 roku. Poprawki obejmują sanitację wszystkich zmiennych używanych podczas tworzenia polecenia wywołania login, aby takie ataki były zasadniczo niemożliwe.

Historia wydaje się niemal symboliczna: przestarzały protokół, zapomniana usługa i klasyczny błąd logiczny doprowadziły do całkowitego kompromitacji systemu. Jeszcze jedno przypomnienie o tym, że nawet 'stare' technologie mogą pozostać realnym zagrożeniem, jeśli nadal działają w produkcji.

Zaraz po opublikowaniu informacji o lukach bezpieczeństwa zespół badaczy uruchomił czujniki honeypot, aby śledzić rzeczywiste próby wykorzystania. Atakujący nie kaślić się długo. W ciągu 18 godzin obserwacji zarejestrowano 60 prób włamań z 18 unikalnych adresów. adresów IP. Z danych platformy Censys wynika, że potencjalnie podatnych było około trzech tysięcy systemów na całym świecie, chociaż znaczna ich część prawdopodobnie też była pułapkami honeypot.

Analiza przechwyconego ruchu wykazała bardzo różnorodny obraz. Najaktywniejszy był atakujący z adresu 178.16.53.82, który przeprowadził 12 sesji przeciwko 10 różnym celom. Jego działania były całkowicie zautomatyzowane: po uzyskaniu dostępu uruchamiano standardowy zestaw poleceń wywiadowczych, takich jak uname -a, id, czytanie /proc/cpuinfo i /etc/passwd. Charakterystyczną cechą było opakowanie wyników poleceń specjalnymi znacznikami do późniejszego parsowania, co wyraźnie wskazuje na botnet lub zautomatyzowany system zbierania danych.

Bardziej wyrafinowany okazał się intruz z adresu 216.106.186.24. Skoncentrował się na konkretnej podsieci i próbował ustawić klucz SSH dla stałego dostępu, a także załadować i uruchomić skrypt Python z zewnętrznego serwera – przypuszczalnie złośliwe oprogramowanie do kopania kryptowalut lub botnet. Jednak obie próby się nie powiodły: w systemie docelowym nie istniała katalog .ssh, a także brakowało curl i python.

Szczególne zainteresowanie budzą dwaj atakujący z adresami 167.172.111.135 i 165.22.30.48. W przeciwieństwie do pozostałych, nie próbowali od razu uzyskać dostępu do roota, lecz eksperymentowali z kontami nobody, daemon, a nawet nieistniejącym nonexistent123. Opóźnienia między sesjami i logika działań wskazują na żywego człowieka przy klawiaturze. Prawdopodobnie są to bardziej doświadczeni hakerzy, którzy znają systemy wykrywania włamań i mają w zanadrzu techniki podnoszenia uprawnień.

Niektórzy atakujący wykazywali zdumiewającą lekkomyślność w operacyjnej bezpieczeństwie. Na przykład, sprawca z adresu 67.220.95.16 użył tego samego IP zarówno do eksploatacji, jak i do hostowania serwera z złośliwym oprogramowaniem. Inni przypadkowo ujawniali nazwy swoich hostów poprzez zmienną DISPLAY: jeden pracował na systemie o nazwie MiniBear, inny — na wirtualnej maszynie shared-vm2.localdomain, a trzeci łączył się bezpośrednio z pełnoprawnego graficznego środowiska Kali Linux.

Ogólnie poziom atakujących okazał się dość niski. Spośród 18 źródeł ataków zaledwie nieliczne wykazały oznaki profesjonalizmu. Większość korzystała z najprostszych zautomatyzowanych narzędzi lub po prostu klikała w klawisze, podążając za instrukcjami z Internetu. System wykrywania włamań Suricata skutecznie zarejestrował moment uzyskania dostępu root przez jednego z atakujących, co jeszcze raz potwierdza znaczenie wielowarstwowej ochrony i monitorowania ruchu sieciowego.

Badacze zauważają, że ta luka, z jednej strony, dała możliwość hobbistycznym hakerom na zdobycie doświadczenia, a z drugiej — pozwoliła specjalistom ds. bezpieczeństwa zebrać cenne dane o aktualnych taktykach i narzędziach przestępców.

Dowiedz się więcej: https://www.securitylab.ru/news/568478.php

Źródło: linux.org.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster