Jak chráníme weby našich zákazníků před backdoor a dalšími nebezpečnými soubory

[gtranslate]

Před dvěma týdny jsme, spíše pro zajímavost, publikovali detektivku Jak jsme chránili weby našich zákazníků před kritickou chybou ve WordPress pluginu ThemeGrill Demo Importer. Nečekali jsme, že to vzbudí takový ohlas a dostaneme tolik dotazů. Proto jsme se rozhodli napsat další příklad práce našeho bezpečnostního týmu.

27. ledna a 27. února 2020 zveřejnil bezpečnostní tým Sucuri Labs varování před backdoory, které se maskovaly jako bezpečnostní pluginy blnmrpb a wpdefault.

Co je backdoor

Pokud útočník získá prostřednictvím bezpečnostní díry anebo odcizených hesel přístup do vaší instalace WordPress, nemusí hned provést nějakou neplechu. V některých případech jen umístí zadní vrátka (backdoor), přes které může v budoucnu celou vaší instalaci WordPress ovládat. Například rozesílat spam, stahovat si data o vašich uživatelích, provádět útoky, těžit kryptoměny atd.

Umístění nenápadného backdoor místo okamžitého útoku má pro útočníka hned několik výhod. Například, že se backdoor nahraje i do záloh webu, a pak obnova ze zálohy nepomůže, anebo že může zneužít web až se mu to bude hodit. Backdoor totiž funguje i pokud je bezpečnostní díra opravena anebo je změněno heslo, přes které se tam dostal.

Jak backdoor hledáme

Pokud víme o existenci backdoor jako v tomto případě, tak můžeme okamžitě aktivně hledat v provozu, zdali tyto konkrétní soubory někdo nevolá. Je to nejrychlejší řešení, ovšem ne zcela účinné. Naše ochrany totiž vidí pouze provoz přes HTTP, takže uživatelé se šifrovaným provozem (HTTPS) mají zatím smůlu. Pracujeme na vylepšení naší ochrany, která bude umět filtrovat i šifrovaný provoz.

Další způsob jak hledáme backdoor, je přes CML. Centrální Monitor Logů je náš systém, který sbírá naprosto všechna myslitelná data ze všech serverů a třídí je na jednom místě a to v reálném čase. Denně se jedná téměř o 700 GB sesbíraných textových dat. CML nám poskytuje přístup například k access logům všech webhostingů, v kterých můžeme najít i volání backdoor.

Jenomže co když nikdo backdoor nevolá? Prostě jej umístí na server a dále se o něj nestará. V tomto případě máme k dispozici staré dobré vyhledávání souborů. Problém je v tom, že musíme projít neskutečně velké množství souborů na všech serverech a to tak, aby to neomezovalo služby zákazníků.

To není nic jednoduchého. Staráme se téměř o 105 tisíc webhostingů, na kterých je zhruba 137 tisíc webů na doménách druhého řádu. Z toho desítky tisíc jsou redakční systémy, z nichž většina využívá cachovací pluginy. Velké aktivní weby s cachovaním vytváří tisíce souborů, které průběžně přibývají, přepisují a mažou se.

Za ty roky na to už máme své metody a odladěné skripty, ale projít vše i tak může trvat dny. Záleží co a jak dobře schované hledáme.

Co děláme, když najdeme podezřelé soubory

Pokud se jedná o podezřelé soubory, tak technici upozorní majitele e-mailem, ať situaci prověří. To že soubor vypadá jako napadený nemusí nutně znamenat, že tomu tak je. Navíc majitel už může pracovat na odstranění a mít situaci pod kontrolou.

V případě backdoor, jako v této situaci, je to o dost jednoduší. Nastalou událost řeší technik z bezpečnostního týmu, který je s konkrétní hrozbou obeznámen. Víme, co hrozba dělá a co si můžeme dovolit, tak aby to ideálně neovlivnilo službu zákazníka.

Bezpečnostní technik zablokuje úpravou práv přístup k souboru tak, aby nemohl nijak škodit. Následně je zákazník informován e-mailem, kde jsou také tipy, jak má situaci řešit.

Tento postup se nám osvědčil z dlouhodobého hlediska nejvíce. Například když soubory rovnou smažeme, tak přes nezalátanou bezpečnostní díru je tam útočník nahraje druhý den znovu.

Většinu útoků na dnešní redakční systémy provádí automatizované skripty v obřím měřítku. Dělají jedno a to samé. Když se jim nepodaří nahrát backdoor přes bezpečnostní díru, protože jim to práva neumožňuji anebo zjistí že tam už backdoor je, tak jdou dál.

Tohle se týká pouze napadených webů, které zatím nedělají neplechu. Samozřejmě když už je nějaký webhosting aktivně zneužíván, tak technici jednají důrazněji.

Jak to dopadlo?

Když jste dlouhé roky nejoblíbenější webhosting pro WordPress, také s nejvíce aktivními instalacemi, tak asi tušíte, že jsme pár napadených instalací našli. Majitelům jsme poslali upozornění a pár tipů jak problém řešit. Pomoc mohou také hledat na našem komunitním webu help.wedos.cz.

Ještě jedna zajímavost. Našli jsme instalace, kde backdoor byl schován v adresářích známých cachovacích pluginů. Je to celkem chytré, protože občas jsou tyto adresáře při procházení opomíjené z důvodu velkého množství souborů.

Závěr

Máme DDoS ochranu, IPS/IDS ochrany, detailně monitorujeme provoz, sledujeme aktuální bezpečnostní hrozby a dokonce aktivně hledáme nebezpečí na webech zákazníků. Dříve jsme to dělali hlavně kvůli komfortu zákazníků a abychom se něco nového naučili s technologiemi, které máme k dispozici. Dostali jsme se však do stavu, kdy se nám všechny tyto drahé technologie začaly dokonce vyplácet.

Zákazníci jsou spokojenější, klesla zátěž na zákaznickou podporu, technici se mohou věnovat vývoji, ubylo administrativy spojené s napadenými weby (zvláště právní) a snížily se náklady na provoz. Vždyť filtrujeme více jak polovinu provozu, který ve většině případů mířil na necachované stránky a výrazně zatěžoval servery.

Další investice do bezpečnosti (hardware, software, vývoj, vzdělávání) tak u nás nejsou problém. Právě naopak. Jediné co nám chybí jsou lidé 🙂

Máme dost dat, abychom dokázali odhalovat i nové útoky. Skrývají se v nich zero day útoky, které jsou často objeveny až za několik měsíců. Pokud bychom je dokázali najít a nahlásit vývojářům, mohlo by to zachránit spoustu webů. Jen nám chybí kolegové do bezpečnostního týmu, kteří by se ve dne v noci prohrabovali stovkami gigabajtů logů.