Stala se mi taková hodně nemilá věc. Můj VPS server byl hacknut, do složky s weby se vtipálkům podařilo nahrát nejrůznější PHP soubory, které začaly rozesílat hromadu SPAMu. V tomto článku vám krok po kroku poradím, jak se z této nemilé situace dostat. Začnu však poněkud obšírněji a popíši, jak se u mě celý problém projevil. Pokud hledáte samotný návod na vyčištění WordPressu, možná budete chtít úvodní povídání přeskočit a podívat se rovnou na něj.

Poznámka: termín hacknutí zde používám ve stejném významu jako redaktoři jedné nejmenované oblíbené české televize.

Přestalo fungovat CSS

Vše začalo poněkud nenápadně, a to přímo na tomto webu. Z ničeho nic se místo úvodní stránky načítala šedá plocha. V HTML přitom vše vypadalo v pořádku. Okamžitě jsem z tohoto problému obvinil plugin W3 Total Cache. Zkoušel jsem pročistit cache, vypnout celý plugin i kompletní odinstalaci. Nic z toho nepomohlo. Řekl jsem si, že se nějak rozhodila šablona. Zkusil jsem aktivovat jinou. To naštěstí pomohlo a já problém dál neřešil.

ZaBANování VPS

Jednu neděli jsem úplně čirou náhodou zjistil, že mi už 22 hodin neběží VPS s většinou mých webů a projektů. Neděle už najednou tak hezká nebyla. Moje VPS se nachází v zahraničí, započala tedy komunikace s tamější podporou, aby mé VPS bylo opětovně nahozeno. Z logu jsem se dozvěděl, že důvod pro suspendování serveru bylo tisíc SMTP spojení a rozesílání SPAMU. Než můj VPS server zase běžel, trvalo to celý den. Opětovně po jeho spuštění jej totiž automatický skript poskytovatele ihned zablokoval, opět pro rozesílání SPAMu. Bylo třeba přidat výjimku, aby VPS šlo vůbec spustit.

Open relay

Nejprve jsem myslel, že jsem na serveru nezakázal open relay (to znamená, že by se kdokoliv mohl na server připojit a přes STMP posílat kamkoliv email). Jak však ukázal jeden z mnoha online testů, tímto to nebylo. Rozhodl jsem se tedy alespoň omezit počet souběžných SMTP připojení. Pro Postfix je nutno v souboru /etc/postfix/master.cf najít tento řádek:

smtp inet n – – – – smtpd

Poslední pomlčku lze nahradit za konkrétní číslo. To udává maximální počet souběžných procesů, které budou obsluhovat SMTP:

smtp inet n – – – 3 smtpd

Když už jsem byl v tom nastavování, rozhodl jsem se ztížit robotům pokusy o přihlášení. Do souboru /etc/postfix/main.cf (klidně např. na konec) stačí přidat následující 3 řádky:

smtpd_error_sleep_time = 1s

smtpd_soft_error_limit = 10

smtpd_hard_error_limit = 20

I když jsem však provedl všechna výše zmíněná opatření, ničemu to nepomohlo — v mailové frontě na serveru se stále objevoval nový SPAM. Začaly mi docházet nápady. Neodesílá emaily náhodou nějaký skript na serveru? Letmo jsem se podíval do adresářové struktury jednoho webu běžícího na WordPressu a skutečně — byly tu soubory, co zde na první pohled nemají co dělat.

Jak vyčistit hacknutý WordPress

Než začnete cokoliv dělat, udělejte si zálohu všech souborů (ano, těch hacknutých) i databáze. Možná to zní zvláštně, ale vyplatí se to. Pravděpodobně totiž budete ve stresu a může se stát, že uděláte něco, čeho budete později litovat.

V mém případě složka s WordPressem obsahovala řadu podivných souborů. Namátkou uvedu některá jména:

• wpconfig-new.php
• options.php
• defines.phps
• gallery.php
• view.php
• exec__root.php — obzvláště tento soubor zní dost podivně

Takže, co je vlastně cílem? Smazat všechny soubory, co zde nemají co dělat. Důležité je, že se nesmí zapomenout ani na jeden. Stačí jeden infikovaný PHP soubor na serveru zanechat a útočník stále bude schopný se serverem provádět řadu věcí. K nalezení zmíněných souborů jsem použil plugin Sucuri Security, který mohu jen doporučit. Tato pomůcka proskenuje adresářovou strukturu a zobrazí změněné i nově přidané soubory. My přitom prahneme po těch nově přidaných. Vžijme se do role útočníka. Přece chceme, aby naše infekce přežila případnou přeinstalaci/aktualizaci WordPressu. Proto nemůžeme modifikovat stávající soubory, ale musíme škodlivý kód uchovávat v těch nově přidaných. Sucuri Security všechny soubory zobrazí v přehledém seznamu. Obzvláště podivné je PHP ve složkách wp-admin, wp-includes, přímo narušení bezpečnosti je poté PHP v wp-content/uploads.

Než nalezené soubory smažete, raději zkontrolujte jejich obsah, zda-li náhodou nemáte v úmyslu odstranit něco důležitého. Pokud soubor obsahuje jeden řádek s hashem (můj případ), okamžitě jej smažte, to zde nemá co dělat. Druhý trik co útočníci u mě použili, byl rádoby prázdný soubor. Respektive na jednom řádku bylo milión mezer a až poté škodlivý kód. Na první pohled to tedy vypadalo, že je soubor prázdný.

Jakmile smažete vše, co na vašem serveru nemá být, vůbec není vyhráno. Útočníci totiž přístup nějakým způsobem získali a je nutno tuto díru záplatovat. Určitě musíte aktualizovat WordPress, pluginy i šablony na nejnovější verzi. Já bohužel používal starou verzi WordPressu, a dopadlo to hackem…

Dále vám doporučím zavítat do nastavení pluginu Sucuri Security a v záložce Hardening povolit vše, co budete moci. Efektivně tím zakážete spouštění PHP souborů zvnějšku serveru. I kdyby se útočníkovi nějak podařilo nahrát na server zákeřný kód, relativně se nic neděje, protože jej nemá jak spustit.

Analýza hacku

Jako programátorovi mi to samozřejmě nedalo a lehce jsem zákeřný kód prostudoval. Uvažoval jsem, že bych zde kódy zveřejnil, nerad bych ovšem, aby si Google myslel, že tento web obsahuje malware.

Infekce začíná spuštěním exec__root.php, což ostatně evokuje i samotný název souboru. Tento skript proskenuje celou adresářovou strukturu a hledá složky, které typicky budou přístupné z webu (např. css, js apod.). Dále bezpečně umí rozpoznat CMS WordPress i Joomla a vyhledává v nich opět přístupné složky. Do každého umístění je poté nakopírován jeden ze souborů s nenápadným názvem (např. wpconfig-new.php, options.php, defines.php apod.). Na konci skriptu je vtipná podmínka, která kontroluje, zda-li server dokáže přes cURL komunikovat s okolním světem. Za tímto účelem se netestuje žádný ze serverů útočníka, ale toto video na YouTube. To je rusky, takže si podle toho možná můžeme udělat obrázek o původu oněch vtipálků. V krátkém pětivteřinovém videu pán říká: „Vy jste kdo? Já vás nezval. Jděte pryč!“. Jak trefné :-D.

Každý z nakopírovaných souborů v mém případě obsahoval kód prohnaný nějakým PHP obfuscatorem, nestudoval jsem jej tedy (ani jsem se nesnažil jej deobfuscatorovat (to je slovo ). Při načtení z webu se zobrazí jednoduchý formulář, který chce jediné — zadat heslo. Po správném zadání se hádám útočníkům zobrazí nějaká administrace , která jim umožní provádět, co se jim zrovna zamane.

Poučení pro příště

Závěrem uvedu stručný výčet několika pravidel, u kterých mi vychází, že je webmaster musí mít na paměti, pokud používá WordPress a chce v noci v klidu spát:

• pokud používám WordPress, musím jej pravidelně aktualizovat včetně pluginů a šablon
• uživatelé s vyššími právy musí používat delší/složitější heslo
• je více než vhodné používat nějaký auditovací nástroj (třeba už zmíněný plugin Sucuri Security)
• logy pak ovšem někdo musí prohlížet !