Napadený WordPress po wp2shell: opravit, nebo jít jinam?

V noci na 20. července přišel spoustě majitelů webů e-mail z bezpečnostního pluginu: na vašem webu vznikl nový administrátor. Řada lidí ale žádný e-mail nedostala a přišla na to jinak — ráno se prostě nedostali do administrace.

Jestli vám tohle v létě proběhlo, tak především: nešlo o cílený útok na vaši firmu ani o zanedbaný plugin. Díra byla přímo v jádru WordPressu a našel ji plošný sken, který jel po celém internetu. Hosting InMotion to ve svém rozboru dvou případů shrnul větou, kterou stojí za to číst dvakrát: nikdo tyhle firmy necílil, byl to jen skenovací provoz, který našel, co zůstalo nezáplatované.

Druhá věc, kterou je potřeba říct rovnou, je, že smazat cizího administrátora nestačí. A třetí, že tohle je přesně ten moment, kdy se vyplatí položit si jinou otázku než jak to zalepit. Projdeme, co se stalo, proč se tolik lidí nemohlo přihlásit, proč čištění často nezabere a jaké možnosti pak máte.

Co se v červenci stalo

Sedmnáctého července zveřejnila společnost Searchlight Cyber řetězec dvou chyb, kterému se začalo říkat wp2shell. První je záměna cesty v rozhraní REST, druhá je SQL injection v dotazovací vrstvě. Samostatně není ani jedna průlom. Zřetězené dávají útočníkovi bez přihlášení plnou kontrolu nad webem, se společným hodnocením závažnosti 9,8 z 10.

Podstatné je tohle: nepotřeboval k tomu žádný plugin, žádné přihlašovací údaje ani zvláštní nastavení. Stačila výchozí instalace WordPressu ve verzi 6.9.0 až 6.9.4 nebo 7.0.0 až 7.0.1.

WordPress vydal opravy 6.9.5, 7.0.2 a 6.8.6 tentýž den a vynutil automatické aktualizace. Americká agentura CISA zařadila obě chyby do katalogu aktivně zneužívaných zranitelností 21. července, tedy ještě dřív, než se objevil veřejný návod. Ten přišel 22. července a udělal z útoku záležitost, na kterou stačí umět spustit skript.

Rozhodující je rychlost. Bitdefender popisuje cestu od zneužití chyby k administrátorskému přístupu zhruba ve dvou minutách. InMotion u jednoho z vyšetřovaných webů naměřil 24 sekund od prvního požadavku po nainstalovaný škodlivý plugin, u druhého 28 sekund.

Tady je pointa pro vás: neselhala vaše údržba. Oprava existovala od prvního dne. Mezi ní a plošným skenem ale byly hodiny a u velké části webů automatická aktualizace tiše neproběhla.

Proč jste se nemohli přihlásit

Tohle byl nejčastější první příznak a má konkrétní vysvětlení.

Útočníkův skript nezaložil jen vlastního administrátora. Podle rozboru InMotion zároveň zničil přihlašovací relace ostatních uživatelů. Vás to vyhodilo ven, útočník zůstal uvnitř. Na jednom z vyšetřovaných webů narostl počet neoprávněných administrátorských účtů na 38, v souvislé řadě identifikátorů za sebou.

Nepříjemnější je druhá vrstva. Útočníci zakládali takzvaná aplikační hesla s názvy jako auto-bootstrap nebo bot-token. Ta fungují mimo přihlašovací formulář a přežijí změnu hesla. Většina majitelů webů tuhle obrazovku ve svém profilu nikdy neotevřela.

A do třetice: na jednom z webů ležel soubor, který četl hesla zadaná do přihlašovacího formuláře v čitelné podobě. Každé heslo, které tam v té době kdokoli napsal, je vyzrazené.

Proč „vyčistili jsme to“ tak často nezabere

InMotion napočítal devět nezávislých vrstev, kterými se útočník na webu udržel. Vlastní administrátory, škodlivé pluginy, takzvaný must-use plugin, který nejde z administrace vypnout, soubory PHP ve složce uploads pojmenované jako jádro systému, zakódované kusy kódu v databázi, načítací blok v konfiguračním souboru, který je umí obnovit, a úlohy, které to každých pár minut kontrolují.

Smažete plugin, zůstane úloha. Smažete úlohu, zůstane záznam v databázi. Smažete záznam a konfigurační soubor si ho vytvoří znovu.

První z webů byl 20. července vyčištěný, všechny čtyři cizí účty pryč, jádro aktualizované. O šest dní později byl napadený znovu. A zálohy, na které by se člověk rád vrátil, byly infikované také.

Ještě jedna věc, na kterou se zapomíná. Jakmile měl útočník přístup ke konfiguračnímu souboru, viděl všechno, co v něm a v databázi je: hesla do administrace, hosting, FTP, SSH, databázi, SMTP, klíče k platební bráně i cizí rozhraní. Obě zprávy uvádějí výměnu těchhle přístupů jako povinnost, ne doporučení.

Takže co s tím dál

Odpověď nezní zahoďte WordPress. Je to rozhodnutí o tom, kolik údržby ten web ještě unese.

Když web něco opravdu umí

E-shop, členská sekce, rezervace, napojení na sklad. Tady je přechod jinam drahý a často nemožný, takže zůstaňte, ale zeštíhlete. Vyhoďte doplňky, které nikdo nepoužívá, nahraďte opuštěné projekty udržovanými a hlavně určete, kdo web sleduje. Ne kdo ho jednou za čas aktualizuje, ale kdo se do dvou hodin dozví, že na něm přibyl administrátor. Tuhle cestu pokrývá naše správa a rozvoj webů.

Když web hlavně informuje

Firemní prezentace, weby obcí, škol a institucí, produktové katalogy. Na hostované platformě typu Webflow neinstalujete cizí kód, protože není kam, a o aktualizace jádra se stará provozovatel. Červencový scénář na takovém webu nemá co zneužít, protože tam WordPress vůbec není. Na téhle cestě stojí většina webů, které stavíme.

Jen ať je to řečeno poctivě: hostovaná platforma není stříbrná kulka. Přesouvá odpovědnost, neruší ji. U webu, který nic neprodává, je ale tahle výměna obvykle výhodná, a hlavně předvídatelná.

Příklad z praxe

Modelový příklad, nejde o konkrétního zákazníka.

Obec provozuje informační web na WordPressu, aktualizace dvakrát ročně. Po červencovém incidentu vypadl rozpočet takhle:

• Zjištění a první diagnostika: 3 hodiny
• Čištění a kontrola všech vrstev: 16 hodin
• Opakované napadení o týden později a druhé kolo: dalších 8 hodin
• Výměna všech přístupů, tedy hosting, FTP, databáze i SMTP: 3 hodiny

Celkem 30 hodin. Při modelové sazbě 1 200 Kč za hodinu jde o 36 000 Kč za jediný incident. K tomu dva týdny, kdy nikdo z úřadu nevěřil tomu, co na webu zrovna stojí.

Přestavba stejného webu na platformu bez doplňků vyjde jednorázově řádově podobně. Rozdíl je, že příští červenec se neopakuje.

Jak na to krok za krokem

1. Ověřte, že aktualizace opravdu proběhla. Ne že je zapnutá, ale že proběhla. Najdete to v administraci v sekci Nástroje a Zdraví webu. Potřebujete verzi 6.9.5, 7.0.2 nebo 6.8.6 a vyšší.
2. Projděte seznam administrátorů. V sekci Uživatelé si vyfiltrujte roli administrátor a hledejte účty, které jste nezakládali. V praxi se objevovaly předpony wpsvc_ a wp2_, jméno wpenginebot a účty odvozené od názvu webu s příponami _dev nebo _editor.
3. Zkontrolujte aplikační hesla. U každého uživatele v jeho profilu. Tohle je krok, který se vynechává nejčastěji, a přitom právě on přežije změnu hesla.
4. Vyměňte všechny přístupy, ne jen heslo do administrace. Hosting, FTP, databázi, SMTP, platební bránu i klíče k cizím službám. A zrušte všechny přihlašovací relace.
5. Teprve teď se rozhodujte o budoucnosti. S vyčištěným webem a seznamem toho, co všechno se muselo měnit, vedete o dalších pěti letech úplně jiný rozhovor než v panice v červenci.

Pokud řešíte bezpečnost i mimo web, navazuje na tohle téma článek o zákonu o kybernetické bezpečnosti a jeho lhůtách.

Závěr

Na téhle kauze je nepříjemné hlavně to, že se nedalo nic zanedbat. Nebyl to zapomenutý plugin ani slabé heslo. Byla to chyba v jádru, oprava vyšla tentýž den a spoustě webů stejně nepomohla. Až se to stane podruhé, a ono se to stane, rozhodnou dvě věci: jak rychle se to dozvíte a kolik cizího kódu na tom webu vůbec může být. Obojí se dá ovlivnit teď, ne až příště.

Máte na webu administrátora, kterého jste nezaložili, nebo si po létě nejste jistí, jestli je web čistý? Napište nám. Projdeme ho a řekneme rovnou, co se stalo a jestli se vyplatí čistit, nebo přestavět.

‍