Případová studie · PrestaShop
Napadený PrestaShop: jak obnovit důvěru v celý e‑shop
Anonymizovaný incident ukázal změny legitimních souborů, několik cest pro návrat útočníka, pokus o získání přístupů do administrace i falešný platební formulář. Vysvětlujeme, proč nestačí smazat první nalezený soubor a jak připravit bezpečný návrat obchodu do provozu.
Co je skutečný nález a co doporučený postup
Popsané známky napadení a závěry auditu vycházejí ze skutečného, anonymizovaného incidentu. Část o čistém sestavení a návratu do provozu představuje náš doporučený postup pro podobně rozsáhlé napadení. Není to tvrzení, že všechny uvedené kroky proběhly v rámci jedné konkrétní zakázky.
Incident v kostce
Výchozí stav
Starší PrestaShop 1.7.x vykazoval neobvyklé chování administrace a objednávky. První kontrola ukázala, že nejde o jedinou chybu ani jeden škodlivý soubor.
Rozsah nálezu
Více než deset změněných legitimních souborů, několik způsobů skrytého návratu, pokus o získání přístupů a podvržený platební formulář.
Hlavní závěr
Důvěra v běžící soubory byla ztracená. Bezpečný návrat proto nemůže stát jen na smazání nálezu; potřebuje čistý základ, kontrolu databáze a ověření celé objednávky.
První pravidlo: nic nemažeme naslepo
Nejdřív zachovat podklady
První posouzení má proběhnout bez spouštění podezřelého kódu a bez přepisování stop. Porovnáváme soubory, protokoly, verze, účty a stav databáze. Teprve jejich souvislost ukáže, odkud útok pravděpodobně přišel a kam se dostal.
- zachování časové osy a serverových protokolů,
- otisky souborů a porovnání se správnou čistou verzí,
- kontrola administrátorů, webových služeb, modulů a konfigurace,
- oddělení potvrzeného nálezu od pouhého podezření.
Pak rozhodnout o provozu
Pokud může objednávka odesílat platební nebo přihlašovací údaje útočníkovi, přednost má ochrana zákazníků. Podle rozsahu se omezí checkout, zápisy nebo celý e‑shop. Informační část může zůstat dostupná jen tehdy, pokud je to bezpečné.
- rychlé posouzení rizika objednávkového procesu,
- omezení dalšího úniku nebo změn,
- záloha důkazů i současného obchodního stavu,
- plán opravy s návratovou variantou.
Co technický audit odhalil
Pravděpodobným vstupem byl veřejně dostupný a zastaralý modul. Po spuštění vlastního kódu si útočník nevytvořil jen jedno zadní vrátko. Změnil několik částí aplikace tak, aby se mohl vrátit i po odstranění prvního nálezu.
1. Vstup přes modul
Zranitelná veřejná část zastaralého modulu pravděpodobně umožnila spustit cizí kód.
2. Skrytý návrat
Škodlivý kód se objevil v samostatných souborech i uvnitř legitimních částí jádra a knihoven.
3. Přístupy do správy
Jedna z úprav zachytávala přihlašovací údaje do administrace a pokoušela se je odeslat mimo e‑shop.
4. Zásah do platby
V objednávce byl vložen skimmer napodobující legitimní platební formulář.
Databáze neobsahovala zjevně přidaného správce ani nový účet webové služby. To ale neznamenalo, že je e‑shop v pořádku. Čistě vypadající databáze nemůže potvrdit důvěryhodnost napadených souborů.
Proč nestačí smazat nález nebo vrátit poslední zálohu
Skener nevidí všechno
Nový nebo upravený škodlivý kód může být vložený do legitimního PHP souboru. Nulový počet signaturních nálezů proto není důkazem čistoty.
Záloha může obsahovat původní chybu
Starší kopie může předcházet viditelnému napadení, ale stále obsahovat zranitelný modul, historické zásahy do jádra nebo dosud neodhalená zadní vrátka.
Úplná obnova může zahodit objednávky
Vrácení celé databáze může odstranit legitimní objednávky, registrace a změny vzniklé po záloze. Obchodní data je potřeba oddělit od bezpečnostních změn.
Doporučený postup bezpečné nápravy
U podobně široké kompromitace dáváme přednost paralelní přípravě čistého prostředí. Napadená instalace zůstává zdrojem důkazů a obchodních dat, ne zdrojem spustitelných souborů pro nový provoz.
Omezit další škodu
Podle rizika omezit checkout nebo zápisy, uchovat protokoly, vytvořit databázový bod obnovy a zajistit potvrzené nálezy.
Postavit čistý základ
Připravit nové prostředí z ověřeného jádra PrestaShopu a důvěryhodných instalačních balíčků modulů a šablony.
Prověřit vlastní úpravy a databázi
Vlastní kód převést až po ručním porovnání. V databázi zkontrolovat účty, moduly, napojení a nevysvětlené bezpečnostní změny.
Odstranit vstup a vyměnit přístupy
Opravit nebo odstranit zranitelnou komponentu a změnit hesla, klíče, relace, databázové, e-mailové, platební a další integrační přístupy.
Ověřit celý obchod
Projít administraci, katalog, přihlášení, košík, objednávku, platbu, e-maily, naplánované úlohy a čerstvé serverové protokoly.
Řízeně přepnout a sledovat změny
Po krátkém omezení zápisů přenést poslední legitimní změny, přepnout provoz a sledovat integritu souborů, odchozí komunikaci a chyby.
Jak vypadá ověřitelný cílový stav
Před nápravou
- nedůvěryhodné provozní soubory,
- několik cest pro návrat útočníka,
- objednávka s vloženým skimmerem,
- nejistý stav přístupů a relací,
- nevysvětlené změny jádra a modulů,
- obnova jako jediný nepřipravený plán.
Po modelové opravě
- nové sestavení z ověřených zdrojů,
- žádné známé ukazatele útoku v kontrolovaném rozsahu,
- otestovaný checkout bez neznámé komunikace,
- zneplatněné relace a vyměněné přístupy,
- schválený soupis souborů a řízené změny,
- průběžné upozornění na změny i výpadek kontroly.
Správný závěr není „e‑shop je navždy čistý“. Výsledek se vztahuje k vymezenému rozsahu kontrol a konkrétnímu okamžiku. Důvěru udržují až další aktualizace, kontrola změn, sledování provozu a reakce na nové chyby.
Co od nás při podobném incidentu dostanete
Výstupem není pouze seznam souborů, které skener označil. Potřebujete podklady pro rozhodnutí, co je bezpečné ponechat, co nahradit a za jakých podmínek lze znovu přijímat objednávky.
Technický obraz incidentu
Potvrzené nálezy, pravděpodobný vstup, rozsah zasažených částí a jasné rozlišení mezi důkazem, podezřením a legitimní úpravou.
Bezpečný plán změny
Pořadí kroků, omezení provozu, ochrana nových objednávek, návratová varianta a podmínky, které musí e‑shop splnit před přepnutím.
Kontrolu po opravě
Test administrace i nákupu, kontrolu čerstvých protokolů a návrh sledování změn, které upozorní také na výpadek samotné kontroly.
Zkušenost s PrestaShopem nestavíme jen na hostingu. Na zCommerce vyvíjíme a udržujeme moduly pro reálné e-shopy, řešíme jejich napojení, kompatibilitu, objednávkový proces i vlastní úpravy. Při incidentu proto umíme rozlišit běžné chování platformy od změny, která do instalace nepatří.
Související návody a kontroly
- Jak bezpečně spravovat a optimalizovat databázi PrestaShopu, pokud potřebujete rozlišit běžný růst dat od problému.
- Co kontrolovat po upozornění na digital skimmer v PrestaShopu a proč časově omezená kontrola není trvalou zárukou.
Časté otázky při napadení PrestaShopu
Může e‑shop během analýzy zůstat v provozu?
Záleží na tom, které části jsou zasažené. Pokud nelze vyloučit odcizení přístupů nebo platebních údajů, je bezpečnější objednávku dočasně omezit. Rozhodnutí má vycházet z prvního posouzení rizika, ne z přání zachovat provoz za každou cenu.
Stačí obnovit poslední zálohu?
Pouze pokud lze doložit, že záloha předchází napadení, a zároveň se odstraní původní cesta útoku. Poslední záloha může být už napadená nebo může vrátit zranitelný modul.
Lze zachovat nové objednávky a zákaznická data?
Často ano, ale bez znalosti rozsahu to nelze slíbit. Databázové změny se musí porovnat, aby se zachovaly legitimní objednávky a současně se nepřenesly cizí účty, změny konfigurace nebo jiné stopy útoku.
Jak dlouho vyčištění a obnova trvají?
Rozsah určí až první audit. Jinou práci vyžaduje jeden napadený modul s bezpečnou zálohou a jinou vícevrstvá kompromitace vlastního kódu, objednávky a přístupů. Předem proto neslibujeme univerzální dobu bez znalosti instalace.
Co potřebujete pro první posouzení?
Popis příznaků, verzi PrestaShopu, informaci o posledních změnách a bezpečný přístup k souborům, databázi, protokolům a dostupným zálohám. První audit vedeme tak, aby do napadené instalace zbytečně nezapisoval.
Máte podezření, že je váš PrestaShop napadený?
Začneme technickým posouzením v režimu pouze pro čtení. Nejdřív určíme riziko a rozsah, potom navrhneme opravu, způsob ověření a bezpečnou návratovou variantu.
