Přeskočit na obsah
Magazín Chatujme.cz
Bezpečnost · čtení na 3 min

DD-WRT opravil díru v UPnP v roce 2021. Záznam CVE vyšel letos, botnet ji zneužívá

Jediné volání strcpy v obsluze protokolu SSDP dovolovalo přetéct zásobník routeru s firmwarem DD-WRT. Vývojáři to opravili 9. února 2021, ale veřejný záznam o zranitelnosti vyšel v databázi CVE až 16. července 2026. To už ji několik měsíců používal botnet C0XMO k šíření po routerech.

Bezdrátový router Linksys WRT54GS
Linksys WRT54GS. Pro řadu WRT54G vznikl firmware DD-WRT původně; dnes běží na stovkách modelů různých výrobců. Foto: Evan-Amos, Wikimedia Commons (volné dílo)

DD-WRT je náhradní firmware pro bezdrátové routery, který si nadšenci nahrávají místo softwaru od výrobce. Vznikl pro řadu Linksys WRT54G a dnes běží na stovkách modelů. Součástí je i obsluha protokolu UPnP, kterým si zařízení v domácí síti samy hlásí, co umí – a právě v ní byla chyba, kterou letos v červenci zapsala americká agentura CISA mezi zranitelnosti, o jejichž zneužívání ví.

Jedno volání strcpy v obsluze SSDP

Zranitelnost CVE-2021-27137 je učebnicové přetečení zásobníku. UPnP se ohlašuje protokolem SSDP a zařízení se v něm hledají dotazem M-SEARCH na port UDP 1900. V takovém dotazu je pole ST, do kterého lze zapsat identifikátor uuid. DD-WRT ho zkopíroval do vnitřní vyrovnávací paměti o velikosti 128 bajtů, aniž by se ptal, kolik dat přišlo.

Oprava, kterou vývojář vystupující jako brainslayer uložil do repozitáře jako změnu číslo 45724, je jediný řádek v souboru src/router/upnp/src/ssdp.c:

-        strcpy(name, st);
+        strlcpy(name, st, sizeof(name));

Popis změny zní „fix potential stack overflow with modified upnp request“, tedy oprava možného přetečení zásobníku upraveným požadavkem UPnP. Předchozí verze toho řádku pocházela z revize 11589 – nikdo se ho mezitím ani nedotkl.

Oprava přišla dřív než oznámení

Chybu nahlásil nezávislý bezpečnostní výzkumník Selim Enes Karaduman programem SSD Secure Disclosure. Jeho oznámení je datované 24. března 2021, tedy víc než měsíc po opravě, kterou repozitář nese k 9. únoru 2021. Zasažené jsou podle něj všechny verze do změny 45723 včetně a za zranitelná se mají považovat i zařízení Buffalo, která s DD-WRT přicházejí z výroby.

Rozsah útoku je ale užší, než by se z popisu čekalo. UPnP je v DD-WRT ve výchozím nastavení vypnuté a i po zapnutí naslouchá jen na vnitřních rozhraních. Útočník tedy musí být v téže místní síti, nebo si cestu dovnitř musí obstarat jinak. Krátký popis v katalogu CISA tuhle podmínku nezmiňuje, popis v databázi NVD ano.

Pět let mezi opravou a záznamem

Označení CVE-2021-27137 bylo rezervované 10. února 2021, den po opravě. Zveřejněný záznam v databázi CVE ale vyšel až 16. července 2026. Samotné číslo se veřejně objevilo hned, uvádí ho oznámení SSD z března 2021. Pět let a pět měsíců tak platilo, že kdo o chybě věděl od nálezce, věděl o ní všechno, kdežto kdo se spoléhal na databáze zranitelností, nenašel nic.

NVD zranitelnosti přiřadila 8,1 z deseti podle stupnice CVSS 3.1 a označila ji za vysoce závažnou. Vektor počítá s útokem po síti, s vysokou složitostí a bez potřeby jakýchkoli práv, zato s úplným dopadem na důvěrnost, integritu i dostupnost. Za vysokou složitostí je podle nás právě to výchozí vypnutí UPnP; NVD důvod neuvádí.

Co s tou dírou dělá C0XMO

Že se chyba používá, doložila laboratoř FortiGuard firmy Fortinet. Podle rozboru, který 3. června 2026 zveřejnil Vincent Li, narazila laboratoř letos v březnu na novou odrůdu botnetu Gafgyt pojmenovanou C0XMO. Šíří se právě přes CVE-2021-27137: pošle na port 1900 dotaz M-SEARCH s přerostlou hodnotou v poli ST a do napadeného stroje si stáhne svůj kód do adresáře /tmp/.cache.

Fortinet popisuje jeden konkrétní případ – cílem byla japonská technologická firma, zdrojová adresa útoku vedla do Německa. Vzorky škodlivého kódu byly přeložené pro sedm procesorových architektur od ARM a MIPS přes PowerPC a Motorolu 68000 až po x86 a AMD64, což odpovídá tomu, na čem všem routery a podobná zařízení běží.

Na napadeném stroji se C0XMO zabydlí důkladně. Zkopíruje se do skrytých souborů /tmp/.sys, /var/tmp/.sys/dev/shm/.sys, založí si úlohu v cronu, která ho každých patnáct minut spustí znovu, a připíše si spouštěcí příkaz do souborů ~/.profile, ~/.bashrc~/.bash_profile. Pak projde seznam běžících procesů a ty, které má na vlastním seznamu, ukončí – konkurenční škodlivý kód na stejném stroji nechce. Dál zkouší hádat slabá hesla k Telnetu a SSH a umí několik způsobů zahlcovacích útoků.

Kdo si má co opravit

CISA zapsala zranitelnost do katalogu 21. července 2026 a federálním civilním úřadům dala lhůtu do 24. července, tedy tři dny. Kolonku o nasazení ransomwaru nechala nevyplněnou. K záznamu připojila poznámku, která platí i mimo americkou státní správu: jde o obecnou součást otevřeného softwaru a stav opravy je potřeba zjistit u konkrétního výrobce zařízení.

To je u náhradního firmwaru na routeru zapeklitější, než to zní. Verze DD-WRT se nečíslují datem, ale číslem změny v repozitáři, a kdo si ho nahrál před pěti lety, obvykle nemá důvod to řešit znovu. Rychlejší kontrola než hledání čísla verze je podívat se, jestli je vůbec zapnuté UPnP – když ne, tahle konkrétní cesta dovnitř nevede.

Diskuse

Zatím tu nikdo nediskutuje. Můžete být první.

Napsat příspěvek

Diskutovat můžete i bez účtu. S registrací se ale příspěvek zveřejní hned a nemusíte pokaždé vyplňovat jméno. Účet už máte? Přihlaste se.

Nezveřejňujeme ho, slouží jen redakci.

Podporuje zápis Texy: **tučně**, *kurzíva*, odrážky, odkazy.

Dál k tématu

Bezpečnost

GNOME zkracuje lhůtu na zveřejnění zranitelností na 30 dní a shání nástupce

Michael Catanzaro oznámil 20. července dvě změny v tom, jak se u GNOME zachází s hlášenými zranitelnostmi. Od 1. srpna se lhůta, po které se chyba zveřejní, zkracuje z devadesáti dnů na třicet. A k 1. listopadu přestane nová hlášení evidovat – dělá to sám od listopadu 2020 a nástupce zatím není. Část přetisků obě změny slila do jedné příčiny, jenže originál je odděluje.

Bezpečnost

npm 12 přestal spouštět instalační skripty, útočníci se přesunuli k importu

GitHub vydal 8. července npm 12. Instalace balíčku už sama od sebe nespustí žádný cizí skript, což zavírá nejčastěji zneužívanou cestu k počítači vývojáře. Dva útoky ze stejného týdne ale ukázaly, kam obrana nedosáhne: škodlivý kód se v obou případech spouštěl až ve chvíli, kdy program napadený balíček načetl.