Jak opravit nakažený Drupal? Uzdravení nejenom po Drupalgeddon 2

Celé řadě klientů, kterým jsem vyrobil web, se starám i o pravidelné bezpečnostní aktualizace. Weby kontroluji, instaluji aktualizace, opravuji potřebné. Ale pak jsou klienti, kteří po mě tuto službu nechtějí.

Důvody jsou různé. Někdy je to prostě cena, byť je to zlomek ceny celého webu. Jindy jakási podivná laxnost. Uznávám, že někdy i moje neschopnost jim jako laikům takovou investici do pravidelné kontroly webu vysvětlit a obhájit. Nejčastěji zmiňuji aktualizace v telefonech a operačních systémech jako příklad, že se tomu člověk dnes nevyhne nikde. Vlastně ani u webu napsaného na míru, pokud používá knihovny třetích stran.

Po aktualizacích na Drupal 7.58 a 7.59, resp. poté, co je někteří klienti nechtěli ani přes moje důrazné varování, je samozřejmě většina neošetřených webů nakažena. Řadu napadených webů jsem v minulosti léčil, ale tady mě zaráží, jak moc je to lidem jedno. Ona vlastně těžba kryptoměny nebo posílání spamu není bezprostřední projev a není při návštěvě webu na očích, takže asi proč se tím zabývat.

Nicméně dnes jsme na jednom takovém firemním webu „vyhráli“ v neexistující soutěži mobilní telefon. To už by mohl být projev nákazy, který klienta chladným nenechá. Žel bohu oprava je o dost pracnější a tím pádem dražší než prevence. Jako u člověka se špatnou životosprávou.

Léčíme nakažený Drupal

Jestliže jste se také dostali, možná ne svou vinou, do situace, kdy je váš Drupal nakažený, mohly by vám pomoci následující řádky. Chtěl bych se podělit o postup opravy napadeného Drupalu, který obvykle praktikuji. Budiž inspirací pro ty z vás, kdo se do toho chtějí pustit svépomocí.

Jak poznáte napadený Drupal? Nejčastěji je změněn index.php, často se objeví v kořenové složce a jednotlivých podsložkách řada PHP souborů navíc, které tam nepatří. Někdy mají nesmyslný název, jindy naopak dostatečně nenápadný (admin.php, users.php). Vždy ale obsahují škodlivý kód, nejčastěji zakomponovaný pomocí funkce base64_decode().

Když se musím s takovou nákazou poprat, volím následující postup:

1. Projdu kořenovou složku webu. Smažu vše, co tam nepatří, ponechám jenom složky Drupalu, které jsou i v základní instalaci. Totéž provedu se soubory, navíc už řadu let odstraňuji všechny TXT soubory z kořenové složky, s výjimkou robots.txt.
2. Stáhnu si čistý Drupal. Smažu vše kromě složky sites a Drupal nakopíruju. Mám tak jistotu, že tato část bude komplet čistá. Složku sites samozřejmě nepřepisuju.
3. Ve složce sites jsou obvykle moduly (sites/all/modules). Všechny si opět stáhnu z Drupal.org, původní složky smažu a nahraji nové. Pokud je tam někde vlastní modul napsaný pro daný web, musím jeho kód zkontrolovat ručně.
4. Podobně je nutné ručně zkontrolovat téma vzhledu (sites/all/themes). I zde bývá nákaza. Jde-li o šablonu z Drupal.org, je nejrychlejší ji přepsat čistou, pokud jde o vlastní, musí následovat kompletní kontrola všech souborů s kódem PHP a JavaScriptu.
5. Obvykle tu máte ještě knihovny (sites/all/libraries). Editor, colorboxy a podobné věci. Opět je nejlepší je smazat a nakopírovat čisté instalačky.
6. Po pročištění kódu se dívám na složku se soubory (sites/default/files). Je nutné smazat všechny PHP soubory, které se přímo v ní nebo v jejích podsložkách vyskytují. Totéž platí pro obsah dočasné složky. Pozor, někdy jsou nakažené soubory nastraženy i přímo ve složce sites/default.
7. Jakmile pročistíte kódovou a souborovou základnu webu, svádí to říci si, že jste vyhráli. Já ale pokračuji dále. Zkontroluji, zda není zapnutý modul PHP filter, který dovoluje spustit PHP kód z databáze. Často je zde nenápadná nákaza ve starém předělaném obsahu či zapomenutém bloku. Ideální je tento modul vůbec nepoužívat. Pokud jej máte, projděte všechny bloky, které formát vstupu s PHP filtrem používají a vyhledejte případný škodlivý kód, který smažete. Totéž s obsahem. Můžete si pomoci Views rychle vyfiltrovat seznam všech obsahových uzlů spolu s jejich formáty textu a zjistit, kde by se PHP mohlo vyskytovat.
8. Pozor, spouštění PHP z databáze dovolují i jiné moduly. Zatím jsem takovou nákazu neviděl, ale třeba v Display Suite lze definovat vlastní políčka nebo i formát textu, který PHP interpretuje. Umí to i Rules. I toto musíte na webu zkontrolovat.
9. Předchozí nákazy před letošním Drupalgeddonem 2 měnily uživatelské účty. Další v řadě musíte ověřit je. Změňte hesla všem administrátorům a lidem s jakýmkoli editačním oprávněním. Zkontrolujte, zda nedošlo ke změně jejich e-mailů. Nové podezřelé účty odstraňte.
10. Promažte cache a doufejte, že vše výše uvedené by mělo na straně Drupalu stačit k tomu, že bude nyní zase sloužit bez problémů.

Poctivě zkontrolujte a projděte všechny body. Stačí jeden zapomenutý PHP soubor s nenápadným názvem a útočník si pro sebe opět otevře cestičku.

Možná vás napadne, proč všechno zbytečně mažu a přepisuji, místo toho, abychom jenom odstranil nepatřičné či změněné soubory. Smazání je prostě jednodušší a rychlejší cesta. A pozor. Nestačí jen přepis. Některé programy pro přenos souborů totiž při přepisu složky nesmažou její původní obsah, ale jenom jednotlivé soubory, přičemž v cílovém umístění ponechávají ty nepřepisované. A obvykle nakažené.

A jak se léčí Drupal 8?

Zasvěcení asi pochopili, že výše popsaný postup se týká hlavně Drupalu 7. S jeho nákazou kvůli nepravidelným aktualizacím se setkávám nejčastěji. Pro Drupal 8 platí podobná pravidla. Jen samozřejmě složky jsou jiné.

Moduly a témata vzhledu máme přímo v kořenové složce. Věci z jádra jsou ve složce core. Navíc je tu složka vendor, která obsahuje doplňkové PHP knihovny. Tu byste rovněž měli zkontrolovat, resp. smazat stávající a nakopírovat pro jistotu znovu stažené projekty. Ručně, či přes composer.

Nezapomínejte na server

Držím vám palce, aby výše uvedený postup pomohl. Pokud přijdete na něco, co by bylo ještě dobré provést, přidejte tip i pro ostatní do komentářů pod článkem. Napadá mě například kontrola webu nějaký nástrojem typu Sucuri SiteCheck.

Při léčbě webu s Drupalem nezapomínejte ani na další vlivy. Někdo se může urputně věnovat opravě webu, ale přitom má na serveru řadu bezpečnostních trhlin v jeho programovém vybavení.

Párkrát se mi stalo, že jsme opakovaně opravovali napadený Drupal a nákaza se vždy objevila znovu. Na vině nakonec byla chyba v PHP na Debianu. Stačilo spustit aktualizaci systému, web znovu vyléčit a tentokrát byla léčba definitivní.

Je to přitom poměrně častá záležitost. Spousta serverů má z různých důvodů neaktualizované verze PHP (a bez záplat). Schválně, znáte tabulku životnosti jednotlivých verzí PHP? Jak je na tom ta vaše?