Stručne: Ak chcete skontrolovať jadrové súbory CMS, porovnajte nainštalované súbory s čistým originálom rovnakej verzie: pri WordPresse cez oficiálne kontrolné súčty, pri iných systémoch cez čerstvé stiahnutie alebo zostavenie z composer.lock. Každá odchýlka je úlohou na preskúmanie. Porovnanie nájde aj neznámy škodlivý kód, pokrýva však len súbory, pre ktoré originál existuje.
Prečo porovnanie nájde viac než akákoľvek signatúra
Skenery malvéru hľadajú známe vzory. Čo nepoznajú, prehliadnu. Porovnanie s originálom pracuje opačne: nepýta sa, či súbor vyzerá podozrivo, ale či presne zodpovedá tomu, čo výrobca dodal. Každá odchýlka vyniká, či už sleduje známy vzor, alebo nie.
Po PHP2Shell je to obzvlášť cenné. Pre zraniteľnosti CVE-2026-109618 a CVE-2026-109619 neexistujú zverejnené, potvrdené indikátory kompromitácie (Indicators of Compromise). Skenery preto nemôžu cielene hľadať stopy PHP2Shell. Porovnanie s originálom naopak nájde každú zmenu v jadre, bez ohľadu na to, ako vznikla. Prečo samotné skenery nestačia, vysvetľuje príspevok Skenery malvéru pre weby: čo nájdu a čo nie.
Princíp: rovnaká verzia, čistý zdroj
Porovnanie je také dobré ako jeho referencia. Musia byť splnené tri podmienky:
- Presne rovnaká verzia: porovnanie s novšou verziou ukáže stovky neškodných rozdielov. Nainštalovanú verziu zistite z aplikácie alebo zo súboru
composer.lock. - Oficiálny zdroj: originál pochádza od výrobcu, z oficiálneho adresára balíkov alebo z vášho vlastného systému správy verzií. Nie zo starej zálohy dotknutého servera.
- Porovnanie na kópii: pracujte na zabezpečenej kópii webového adresára, aby zostali zachované časové pečiatky a stopy.
| Systém | Referencia | Nástroj |
|---|---|---|
| Jadro WordPressu a pluginy z adresára | kontrolné súčty z WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Projekty Composer (napr. Shopware 6, Laravel, Symfony, Drupal, TYPO3 v režime Composer) | zostavenie z composer.lock |
composer install v prázdnom adresári, potom diff |
| CMS so sťahovateľným balíkom | balík rovnakej verzie od výrobcu | diff -rq |
| Vlastné projekty s Git | posledný známy commit | git status, git diff |
| Systémové balíky servera | databáza balíkov distribúcie | dpkg --verify, rpm -Va |
WordPress: viac než verify-checksums
Ako jadro a pluginy skontrolovať pomocou WP-CLI, uvádza sprievodca Hľadanie zadných vrátok vo WordPresse. Oplatí sa jedno doplnenie: podľa dokumentácie WP-CLI voľba --include-root kontroluje všetky súbory a priečinky v hlavnom adresári a upozorňuje na položky, ktoré k WordPressu nepatria. Tam útočníci radi ukladajú súbory, ktorých názvy pripomínajú jadrové súbory.
# Jadro proti oficiálnym kontrolným súčtom, vrátane cudzích súborov v hlavnom adresári
wp core verify-checksums --include-root
Komerčné pluginy a témy táto cesta nezachytí. Pre ne stiahnete originálny balík rovnakej verzie od poskytovateľa a porovnáte pomocou diff.
Kontrola jadrových súborov CMS pri projektoch Composer
Mnohé moderné aplikácie PHP pozostávajú prevažne z balíkov, ktoré inštaluje Composer, správca balíkov pre PHP. Ako funguje, vysvetľuje stránka Composer: správca balíkov pre PHP. Súbor composer.lock určuje, ktoré verzie sú presne nainštalované. Podľa dokumentácie Composeru composer install používa presne tieto verzie. Tak sa dá dodaný stav zostaviť znova:
# Na čistom systéme, nie na dotknutom serveri
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Vypísať rozdiely v priečinku vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Voľby --no-scripts a --no-plugins bránia tomu, aby sa pri zostavovaní spúšťali skripty z balíkov. Ak bola produkcia nainštalovaná s --no-dev, použite túto voľbu aj pri zostavovaní, inak sa vývojové balíky zobrazia ako rozdiel. Dávajte pozor na dva druhy výsledkov: súbory, ktoré sa líšia, a súbory, ktoré existujú len na serveri. Druhá skupina je často zaujímavejšia. Ako nainštalované balíky navyše skontrolovať na známe zraniteľnosti, opisuje sprievodca Kontrola závislostí Composer na zraniteľnosti.
Porovnať aj operačný systém
Ak mal útočník práva root, mohol nahradiť aj systémové programy. Správcovia balíkov prinášajú vlastné porovnanie:
# Debian, Ubuntu: súbory, ktorých obsah sa odlišuje od balíka
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: skontrolovať všetky balíky
sudo rpm -Va
Číslica 5 na treťom mieste výstupu znamená, že sa zmenil obsah súboru. Podľa príručky dpkg je porovnanie obsahu tam v súčasnosti jedinou účinnou kontrolou. Zmenené konfiguračné súbory sú normálne a sú označené c. Zmenený program v /usr/bin je naopak vážnym výstražným znamením. Pozor: útočník s právami root môže manipulovať aj s databázou balíkov. Pri podozrení na prístup root je nová inštalácia spoľahlivejšia než akékoľvek porovnanie.
Systém správy verzií pre kód aplikácie robí budúce porovnania záležitosťou sekúnd. git status potom ukáže každú odchýlku od schváleného stavu.
Vyhodnotiť odchýlky a poznať hranice
Nie každá odchýlka je útok. Niektoré agentúry v minulosti upravovali jadrové súbory priamo, namiesto toho, aby využívali rozšírenia. Rozdiely vytvárajú aj jazykové balíky, zakončenia riadkov po prenose cez FTP alebo dodatočne nasadené opravy. Rozhodujúce je, či zmenu vie niekto vysvetliť.
Prejdite každú odchýlku osobitne a výsledok zapíšte: známa a zdokumentovaná, neškodne vysvetliteľná alebo nejasná. Nejasné súbory otvárajte len ako text na kópii a nahraďte ich z čistého zdroja. Pri súboroch, ktoré existujú len na serveri, je otázka jednoduchšia: kto ich nepozná, mal by ich zabezpečiť a po preverení ich obsahu nechať odstrániť.
Uploady, konfiguračné súbory ako wp-config.php alebo .env, vlastné úpravy a cache originál nemajú. Musia sa kontrolovať cielene, rovnako ako databáza, cronjoby, používateľské účty a kľúče SSH. Čisté porovnanie je preto dôležitým stavebným prvkom, nie však oslobodením celého servera.
Ako konkrétne pomáha PHP SOS?
- Zistíme nainštalované verzie a zostavíme čistú referenciu z oficiálnych zdrojov.
- Porovnáme jadro, rozšírenia, balíky Composer a systémové programy a vyhodnotíme každú odchýlku.
- Oblasti bez originálu preveríme cielene a zmenené súbory v rámci odstránenia malvéru nahradíme z čistého zdroja.
- Na želanie nastavíme verzionovaný stav, proti ktorému budú bežať budúce kontroly.
Časté otázky
Ako zistím, či boli jadrové súbory WordPressu zmenené?
Pomocou WP-CLI a príkazu wp core verify-checksums. Súbory porovná s kontrolnými súčtami, ktoré WordPress.org zverejňuje pre nainštalovanú verziu. S voľbou --include-root WP-CLI navyše upozorní na súbory v hlavnom adresári, ktoré k WordPressu nepatria.
Čo robiť pri CMS bez vstavanej kontrolnej funkcie?
Stiahnete presne rovnakú verziu z oficiálneho zdroja výrobcu a oba adresáre porovnáte pomocou diff. Pri projektoch Composer zostavíte stav z composer.lock v prázdnom adresári a porovnáte priečinok vendor.
Nájde porovnanie aj škodlivý kód v pluginoch a témach?
Len ak pre ne existuje čistý originál, napríklad z oficiálneho adresára alebo od poskytovateľa. Vlastné úpravy, uploady a konfiguračné súbory originál nemajú a musia sa kontrolovať osobitne.
Nahrádza porovnanie skener malvéru?
Dopĺňa ho. Porovnanie nájde každú zmenu na známych súboroch, aj neznámy škodlivý kód. Nehovorí však nič o súboroch bez originálu, o databáze, cronjoboch ani o prístupoch.