Wprowadzenie do problemu / definicja luki
W ostatnich dniach wrócił temat, który wielu administratorów uważało za „zamknięty rozdział”: Telnet wystawiony do internetu. Shadowserver raportuje prawie 800 000 publicznie dostępnych instancji z „odciskami palca” Telnet, co oznacza ogromną powierzchnię ataku, zwłaszcza w kontekście krytycznej luki w GNU InetUtils telnetd: CVE-2026-24061.
CVE-2026-24061 to zdalne obejście uwierzytelnienia, które w praktyce może dać atakującemu dostęp root bez hasła – o ile usługa telnetd jest osiągalna po sieci.
W skrócie
- Co jest podatne: GNU InetUtils 1.9.3–2.7.
- Co naprawia: wydanie 2.8 (20 stycznia 2026).
- Jak groźne: CVSS 3.1 9.8 (Critical).
- Czy ktoś to już atakuje: tak — zaobserwowano próby wykorzystania luki w realnym ruchu.
- Skala ekspozycji: ~800k instancji Telnet widocznych z internetu (globalnie; m.in. duże skupiska w Azji i Ameryce Południowej).
Kontekst / historia / powiązania
Telnet jest historycznym protokołem zdalnego dostępu (domyślnie TCP/23), który nie zapewnia szyfrowania i od lat jest wypierany przez SSH. Mimo to przez cały czas bywa obecny w środowiskach „legacy”, urządzeniach embedded oraz IoT, które potrafią działać latami bez aktualizacji. Właśnie dlatego komponent telnetd z paczki GNU InetUtils przez cały czas występuje w wielu obrazach systemów i firmware’ach.
W tym samym czasie mamy klasyczny problem „internet-exposed management”: usługa administracyjna wystawiona publicznie + krytyczna luka = szybka monetyzacja przez boty, skanery i operatorów kampanii oportunistycznych.
Analiza techniczna / szczegóły luki
Sedno CVE-2026-24061: GNU InetUtils telnetd niewłaściwie obchodzi się ze zmienną środowiskową USER przekazywaną od klienta i używa jej przy wywołaniu systemowego programu login. Atakujący może podać wartość w stylu -f root, co skutkuje wywołaniem odpowiadającym logice login -f root – a przełącznik -f powoduje ominięcie standardowego uwierzytelnienia. Efekt: root shell bez hasła (unauthenticated).
Co ważne operacyjnie: to nie jest „egzotyczny łańcuch” wymagający precyzyjnych warunków. Według analiz, jeżeli telnetd jest osiągalny, podatność jest trywialna do użycia.
BleepingComputer opisał również obserwacje GreyNoise dotyczące wczesnych prób nadużyć: aktywność miała ruszyć 21 stycznia 2026, pochodzić z 18 adresów IP i obejmować 60 sesji Telnet, z elementem negocjacji opcji Telnet (IAC) wykorzystywanym do wstrzyknięcia parametru w stylu USER=-f <user>.
Praktyczne konsekwencje / ryzyko
Jeżeli Twoja organizacja ma (świadomie lub nie) telnetd wystawiony do internetu, ryzyko jest bardzo konkretne:
- Natychmiastowe przejęcie hosta jako root (bez credentiali) → pełna kontrola nad systemem.
- Szybka automatyzacja ataków: kampanie skanujące port 23 i „masowe” próby wejścia, szczególnie na urządzeniach trudnych do patchowania (embedded/IoT).
- Dalsza eskalacja w sieci: pivoting do segmentów wewnętrznych, kradzież kluczy/sekretów, modyfikacja konfiguracji, dołączenie do botnetu, wykorzystanie w DDoS. (To naturalna ścieżka po uzyskaniu powłoki root na urządzeniu brzegowym).
Warto podkreślić: choćby jeżeli nie potwierdzono publicznie, ile z tych ~800k instancji jest faktycznie podatnych na CVE-2026-24061, sama ekspozycja Telnet jest z definicji złą praktyką, a przy aktywnych próbach exploitacji — robi się to problem „tu i teraz”.
Rekomendacje operacyjne / co zrobić teraz
Priorytetem jest redukcja ekspozycji i szybkie odcięcie wektora.
- Zidentyfikuj ekspozycję
- Skan zewnętrzny: czy masz TCP/23 wystawiony?
- Inwentaryzacja: gdzie działa telnetd / pakiet GNU InetUtils telnetd.
- Załataj
- Zaktualizuj do GNU InetUtils 2.8 (lub wersji dystrybucyjnej zawierającej poprawki). Patch został wydany 20 stycznia 2026.
- Zweryfikuj status w swojej dystrybucji (np. komunikaty bezpieczeństwa dla CVE-2026-24061).
- Wyłącz lub odetnij Telnet
- Najlepiej: wyłącz telnetd i przejdź na SSH.
- Jeżeli nie możesz od razu: zablokuj port 23 na firewallach i ogranicz dostęp wyłącznie do zaufanych adresów/segmentów (VPN/jump host).
- Hunting / detekcja
W środowiskach, gdzie Telnet istniał „od zawsze”, sprawdź ślady:
- procesy login uruchomione z argumentem -f (podejrzane w tym kontekście),
- sesje Telnet kończące się root shellem bez typowych zdarzeń logowania,
- nietypowe modyfikacje autostartu/cronów/uprzywilejowanych kont po czasie potencjalnej ekspozycji.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
CVE-2026-24061 wyróżnia się na tle wielu współczesnych podatności dwoma cechami:
- „Old school” mechanika (argument injection do login) zamiast złożonych łańcuchów RCE,
- niski próg ataku: brak uwierzytelnienia, brak interakcji użytkownika, a w praktyce często brak nowoczesnych mechanizmów EDR na urządzeniach, które wciąż oferują Telnet (embedded/IoT/OT).
W porównaniu do typowych incydentów z internet-wystawionymi panelami www, Telnet daje atakującemu często prostszy i „czystszy” kanał do powłoki, a do tego bywa gorzej monitorowany.
Podsumowanie / najważniejsze wnioski
- Telnet w internecie przez cały czas żyje — i to w skali, która realnie boli: ~800k instancji według Shadowserver.
- CVE-2026-24061 to krytyczne obejście uwierzytelnienia w GNU InetUtils telnetd (1.9.3–2.7), naprawione w 2.8.
- Próby nadużyć zostały już zauważone — nie warto zakładać, iż „u mnie nikt nie skanuje portu 23”.
- Najskuteczniejsza strategia to wyłączyć Telnet, a jeżeli to niemożliwe natychmiast — zablokować ekspozycję i patchować w trybie pilnym.
Źródła / bibliografia
- BleepingComputer – „Nearly 800,000 Telnet servers exposed to remote attacks” (26 stycznia 2026). (BleepingComputer)
- Horizon3.ai – analiza CVE-2026-24061 (szczegóły techniczne, timeline, IOCs). (Horizon3.ai)
- NIST NVD – wpis dla CVE-2026-24061 (CVSS 9.8, opis). (nvd.nist.gov)
- OSS-Security (Openwall) – advisory dot. błędu w GNU InetUtils telnetd (20 stycznia 2026). (openwall.com)
- Ubuntu Security – karta CVE-2026-24061 (status i opis w kontekście dystrybucji). (Ubuntu)
