Internet a sítě

Únos části adres Hetzneru prošel kontrolou RPKI, protože ROA dovolovala i prefixy /24

Od 28. do 30. srpna 2026 mířil provoz na aktualizační server firmy Softaculous k cizímu stroji. Útočník ohlásil do světových směrovacích tabulek kus adresního prostoru poskytovatele Hetzner Online, opatřil si na dotčené domény platný certifikát a části zákazníků podstrčil upravený balík aktualizace Virtualizoru. Kontrola původu tras přitom po celou dobu hlásila, že je ta trasa v pořádku.

15. září 2026 · 8 zhlédnutí

Mezi 28. a 30. srpnem 2026 se provoz mířící na aktualizační server firmy Softaculous sléval k cizímu stroji. Útočník ohlásil do světových směrovacích tabulek kus adresního prostoru poskytovatele Hetzner Online, opatřil si na dotčené domény platný certifikát a části zákazníků podstrčil upravený balík aktualizace Virtualizoru, tedy nástroje na správu virtuálních serverů. Provozovatel to popsal v rozboru z 31. srpna i s minutovou časovou osou; jak útok vypadal ve směrování, rozebral o dva dny později Doug Madory z firmy Kentik.

Optický propojovací panel se svazkem žlutých kabelů — Optický propojovací panel v amsterodamském propojovacím uzlu AMS-IX; každý ze žlutých jednovidových kabelů s ručně psaným štítkem vede k jedné připojené síti. Foto: Fabienne Serriere, Wikimedia Commons (CC BY-SA 3.0)

Dvě vlny za třiatřicet hodin

Útok začal 28. srpna ve 20:57 UTC. Do tabulek vstoupil prefix 162.55.80.0/24, tedy 256 adres, na kterých stál aktualizační koncový bod Softaculousu a k tomu zákaznický a fakturační web. Cesta k němu vedla přes AS6204 (Zet.net) a AS62390 (NexonHost) a na konci nesla AS24940, tedy Hetzner. Jenže ten rozsah je užší výřez ze 162.55.0.0/16, který Hetzner ohlašuje běžně, a směrovače dávají přednost delšímu prefixu. Nová trasa proto vyhrála všude, kam dosáhla.

Hetzner začal /24 ohlašovat sám krátce před devátou ráno UTC 29. srpna, tedy po zhruba dvanácti hodinách, a odklon během minut spadl na nulu. Pak ale svou opravnou trasu stáhl. V 19:55 UTC se únos vrátil a druhá vlna běžela dalších deset hodin, do 05:45 UTC 30. srpna. Dohromady 33 hodin.

Jak daleko to doletělo, spočítal provozovatel z veřejných dat služby RIPE RIS, která sbírá směrovací tabulky od 368 partnerských sítí. Ve chvílích, kdy vlna běžela, mělo cestu přes útočníka prakticky 100 procent těch partnerů, kteří k prefixu vůbec nějakou trasu drželi, v počtech medián 266 z 368. Průměr vážený časem přes celé okno vychází na 28 procent všech partnerů. Trasa přitom bublala: za těch 33 hodin ji směrovače stáhly asi 10 600krát, takže odklon byl pro jednotlivý server přerušovaný a mezi vlnami stál jedenáct hodin úplně.

Kontrola původu tras neměla co zahodit

Proti únosům adres existuje RPKI a jeho kontrola původu trasy. Držitel adres podepíše záznam ROA, ve kterém stojí, které číslo autonomního systému smí rozsah ohlašovat a jak úzké prefixy z něj smí vzniknout. Sítě, které kontrolu zapnou, zahodí každou trasu, jež se záznamu neodpovídá.

Tady zahodit nebylo co. Útočník nechal na konci cesty pravé číslo Hetzneru, takže původ seděl, a ROA pro 162.55.0.0/16 v té době dovolovala prefixy až do délky 24. Únos tím vyhověl oběma podmínkám naráz a sítě s kontrolou ho přijaly stejně ochotně jako ty bez ní. Úprava cesty AS_PATH je přitom jedna ze tříd útoků, proti kterým kryptografická obrana zatím není. Madory k tomu podotýká, že přísný záznam by hijack úplně nezastavil, ale srazil by jeho dosah natolik, že by na něj nenavázal ten další krok.

Že je volná horní mez riziko, není nový poznatek. Doporučený postup RFC 9319 z října 2022 má větu o únosech s podvrženým původem rovnou v abstraktu a radí atribut maxLength až na výjimky vynechat; záznam pak odpovídá přesně té délce prefixu, která se ohlašuje.

Certifikát prošel, protože kvórum drželi útočníci

Samotný odklon provozu by k podstrčení aktualizace nestačil. Klient by narazil na neplatný certifikát a spojení by odmítl. Útočník si ale certifikát obstaral u Let's Encrypt, a to zcela řádnou cestou: automatické ověření, že doménu opravdu ovládá, šlo po síti, a síť v tu chvíli vedla k němu.

Právě proti tomu zavedla certifikační autorita ověřování z více stanovišť. Místo jednoho místa se doména kontroluje z několika zeměpisně i topologicky vzdálených bodů a certifikát se vydá, jen když se shodnou. Místní únos takovou kontrolu neobejde, protože ostatní stanoviště uvidí něco jiného. Tenhle únos ale nebyl místní. Prošel tak daleko, že se na útočníkův stroj dostala všechna stanoviště, a shoda byla dokonalá. Stejný postup uspěl v roce 2022 proti jihokorejské burze KLAYswap; rozbor týmu z Princetonu tehdy napsal, že se nezneužila chyba v TLS, ale důvěra, kterou TLS vkládá do směrování.

Klient aktualizací podpis nekontroloval

Zbývala poslední pojistka a ta chyběla. Aktualizační klient Virtualizoru podle rozboru výrobce v té době neověřoval balíky kryptografickým podpisem, takže upravený soubor neměl na čem padnout. Firma potvrdila, že škodlivý balík dostal malý počet instalací, které se o aktualizaci pokusily v nevhodnou chvíli.

Definitivní seznam zasažených serverů výrobce sestavit nedokáže: odpovědi posílal útočníkův stroj a do logů Softaculousu se nikdy nedostaly. Proto vyzval všechny provozovatele Virtualizoru, aby si stroje prošli podle návodu v tom rozboru, bez ohledu na to, jestli si na nic nevzpomínají.

Hetzner utáhl tři záznamy, u zbytku zůstala mez volná

Po zveřejnění rozboru Hetzner ROA pro 162.55.0.0/16 opravil a horní mez srovnal s délkou prefixu. Totéž udělal u 213.133.96.0/19 a 213.239.192.0/18. Madory k tomu dodal, že je to oprava tří záznamů z mnoha a že u zbytku adresního prostoru zůstává rozestup stejný jako předtím.

Ověřili jsme si, jak to vypadá teď. Rozhraní RIPE Stat vydalo 15. září 2026 pro AS24940 celkem 83 záznamů ROA, z toho 72 pro IPv4 a 11 pro IPv6. Horní mez delší než vlastní prefix má 55 z nich, tedy 52 záznamů pro IPv4 a tři pro IPv6; u dvaatřiceti je ten rozestup rovných osm bitů. Kritérium je prosté porovnání pole maxLength s délkou prefixu v témž záznamu. Tři opravené rozsahy skutečně sedí přesně, kdežto 78.46.0.0/15 dovoluje dál prefixy až do /24.

Vedle toho Hetzner zapsal záznam ASPA, tedy podepsaný seznam sítí, které jeho provoz smějí přenášet. Je v něm devět poskytovatelů a NexonHost mezi nimi není, takže sítě, které ASPA kontrolují, by cestu z tohoto útoku odmítly rovnou. Kontrola ASPA se ale zatím nasazuje pomalu a útok z konce srpna by ji musela mít zapnutá druhá strana, ne Hetzner.

Z incidentu plyne pro provozovatele něco, co se dá udělat za odpoledne a bez cizí součinnosti: srovnat vlastní ROA na přesnou délku ohlašovaných prefixů a podepisovat balíky aktualizací klíčem, který klient zná předem. Ani jedno není náhrada toho druhého. Přísné ROA snižují pravděpodobnost, že se k zákazníkovi vůbec dostane cizí stroj; podpis balíku rozhoduje o tom, co se stane, když se to přesto povede.

Zdroje

Internet a sítě

BGP RPKI certifikáty Hetzner Dodavatelský řetězec

Generováno AI