Ukratko: Da biste provjerili jezgrene datoteke CMS-a, instalirane datoteke usporedite s čistim originalom iste verzije: kod WordPressa putem službenih kontrolnih zbrojeva, kod drugih sustava putem svježeg preuzimanja ili ponovne izgradnje iz datoteke composer.lock. Svako je odstupanje zadatak za provjeru. Usporedba pronalazi i nepoznati zlonamjerni kod, ali pokriva samo datoteke za koje postoji original.
Zašto usporedba pronalazi više od bilo kojeg potpisa
Skeneri zlonamjernog softvera traže poznate obrasce. Što ne poznaju, previđaju. Usporedba s originalom radi obrnuto: ne pita izgleda li datoteka sumnjivo, nego odgovara li točno onome što je proizvođač isporučio. Svako odstupanje upada u oči, slijedilo ono poznati obrazac ili ne.
To je nakon PHP2Shella osobito vrijedno. Za ranjivosti CVE-2026-109618 i CVE-2026-109619 nema objavljenih, potvrđenih Indicators of Compromise. Skeneri stoga ne mogu ciljano tražiti tragove PHP2Shella. Usporedba s originalom, nasuprot tome, pronalazi svaku izmjenu jezgre, neovisno o tome kako je nastala. Zašto skeneri sami nisu dovoljni, objašnjava članak Skeneri zlonamjernog softvera za web-stranice: što pronalaze, a što ne.
Načelo: ista verzija, čist izvor
Usporedba vrijedi koliko i njezina referenca. Moraju biti ispunjena tri uvjeta:
- Točno ista verzija: usporedba s novijom verzijom pokazuje stotine bezazlenih razlika. Instaliranu verziju utvrdite iz aplikacije ili iz
composer.lock. - Službeni izvor: original potječe od proizvođača, iz službenog direktorija paketa ili iz Vašeg vlastitog sustava za kontrolu verzija. Ne iz starog backupa pogođenog poslužitelja.
- Usporedba na kopiji: radite na osiguranoj kopiji web-direktorija kako bi vremenski žigovi i tragovi ostali sačuvani.
| Sustav | Referenca | Alat |
|---|---|---|
| Jezgra WordPressa i dodaci iz direktorija | kontrolni zbrojevi s WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer projekti (npr. Shopware 6, Laravel, Symfony, Drupal, TYPO3 u Composer načinu) | ponovna izgradnja iz composer.lock |
composer install u praznom direktoriju, zatim diff |
| CMS s paketom za preuzimanje | paket iste verzije od proizvođača | diff -rq |
| Vlastiti projekti s Gitom | zadnji poznati commit | git status, git diff |
| Sistemski paketi poslužitelja | baza paketa distribucije | dpkg --verify, rpm -Va |
WordPress: više od verify-checksums
Kako jezgru i dodatke provjeriti pomoću WP-CLI-ja, piše u vodiču Pronaći stražnja vrata u WordPressu. Isplati se jedna dopuna: prema dokumentaciji WP-CLI-ja opcija --include-root provjerava sve datoteke i mape u glavnom direktoriju i upozorava na unose koji ne pripadaju WordPressu. Tamo napadači rado odlažu datoteke čiji nazivi podsjećaju na jezgrene datoteke.
# Jezgra prema službenim kontrolnim zbrojevima, uključujući tuđe datoteke u glavnom direktoriju
wp core verify-checksums --include-root
Komercijalne dodatke i teme ovaj put ne obuhvaća. Za njih preuzmite izvorni paket iste verzije od pružatelja i usporedite ga naredbom diff.
Provjera jezgrenih datoteka CMS-a kod Composer projekata
Mnoge moderne PHP aplikacije većim se dijelom sastoje od paketa koje instalira Composer, upravitelj paketa za PHP. Kako radi, objašnjava stranica Composer: upravitelj paketa za PHP. Datoteka composer.lock bilježi koje su točno verzije instalirane. Prema dokumentaciji Composera composer install koristi upravo te verzije. Tako se može ponovno izgraditi isporučeno stanje:
# Na čistom sustavu, ne na pogođenom poslužitelju
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
# Ispisati razlike u mapi vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Opcije --no-scripts i --no-plugins sprječavaju da se pri ponovnoj izgradnji izvršavaju skripte iz paketa. Ako je produkcija instalirana s --no-dev, tu opciju koristite i pri ponovnoj izgradnji, inače se razvojni paketi pojavljuju kao razlika. Pazite na dvije vrste rezultata: datoteke koje se razlikuju i datoteke koje postoje samo na poslužitelju. Druga je skupina često zanimljivija. Kako instalirane pakete dodatno provjeriti na poznate ranjivosti, opisuje vodič Provjera Composer ovisnosti na ranjivosti.
Usporedite i operacijski sustav
Ako je napadač imao root prava, mogao je zamijeniti i sistemske programe. Upravitelji paketa donose vlastitu usporedbu:
# Debian, Ubuntu: datoteke čiji se sadržaj razlikuje od paketa
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: provjeriti sve pakete
sudo rpm -Va
5 na trećem mjestu ispisa znači da se sadržaj datoteke promijenio. Prema priručniku za dpkg usporedba sadržaja tamo je trenutačno jedina učinkovita provjera. Izmijenjene konfiguracijske datoteke su normalne i označene s c. Izmijenjen program u /usr/bin, nasuprot tome, ozbiljan je znak upozorenja. Imajte na umu: napadač s root pravima može manipulirati i bazom paketa. Kod sumnje na root pristup ponovna je izgradnja pouzdanija od svake usporedbe.
Sustav za kontrolu verzija za kod aplikacije buduće usporedbe svodi na stvar sekundi. git status tada pokazuje svako odstupanje od odobrenog stanja.
Procijeniti odstupanja i poznavati granice
Nije svako odstupanje napad. Neke su agencije ranije izravno prilagođavale jezgrene datoteke umjesto da koriste proširenja. Jezični paketi, završeci redaka nakon prijenosa putem FTP-a ili naknadno ugrađeni ispravci također izazivaju razlike. Odlučujuće je može li netko objasniti izmjenu.
Prođite kroz svako odstupanje pojedinačno i zabilježite rezultat: poznato i dokumentirano, bezazleno objašnjivo ili nejasno. Nejasne datoteke otvarajte samo kao tekst na kopiji i zamijenite ih iz čistog izvora. Kod datoteka koje postoje samo na poslužitelju pitanje je jednostavnije: tko ih ne poznaje, trebao bi ih osigurati i dati ukloniti nakon što se provjeri njihov sadržaj.
Prijenosi, konfiguracijske datoteke poput wp-config.php ili .env, vlastite prilagodbe i predmemorije nemaju original. Moraju se provjeriti ciljano, kao i baza podataka, cron poslovi, korisnički računi i SSH ključevi. Čista usporedba stoga je važan dio slagalice, ali ne oslobađa cijeli poslužitelj sumnje.
Kako PHP SOS konkretno pomaže?
- Utvrđujemo instalirane verzije i gradimo čistu referencu iz službenih izvora.
- Uspoređujemo jezgru, proširenja, Composer pakete i sistemske programe te procjenjujemo svako odstupanje.
- Područja bez originala provjeravamo ciljano, a izmijenjene datoteke u sklopu uklanjanja zlonamjernog softvera zamjenjujemo iz čistog izvora.
- Na želju postavljamo stanje verzije prema kojem se provode buduće provjere.
Česta pitanja
Kako provjeriti jesu li jezgrene datoteke WordPressa izmijenjene?
Pomoću WP-CLI-ja i naredbe wp core verify-checksums. Ona uspoređuje datoteke s kontrolnim zbrojevima koje WordPress.org objavljuje za instaliranu verziju. S opcijom --include-root WP-CLI dodatno upozorava na datoteke u glavnom direktoriju koje ne pripadaju WordPressu.
Što učiniti kod CMS-a bez ugrađene funkcije provjere?
Preuzmite točno istu verziju iz službenog izvora proizvođača i usporedite oba direktorija naredbom diff. Kod Composer projekata stanje iz datoteke composer.lock ponovno izgradite u praznom direktoriju i usporedite mapu vendor.
Pronalazi li usporedba i zlonamjerni kod u dodacima i temama?
Samo ako za njih postoji čisti original, primjerice iz službenog direktorija ili od pružatelja. Vlastite prilagodbe, prijenosi i konfiguracijske datoteke nemaju original i moraju se provjeravati zasebno.
Zamjenjuje li usporedba skener zlonamjernog softvera?
Dopunjuje ga. Usporedba pronalazi svaku izmjenu poznatih datoteka, pa i nepoznati zlonamjerni kod. Ali ne govori ništa o datotekama bez originala, bazi podataka, cron poslovima ni pristupima.