Kontrola databázy na votknutý kód

Stručne: Ak chcete skontrolovať databázu na škodlivý kód, prehľadajte export alebo kópiu čítacími dopytmi na votknuté skripty, cudzie adresy a zahmlený kód v obsahu a nastaveniach. Skontrolujte aj triggery, plánované udalosti, uložené procedúry a používateľov databázy. Čistite až po vyhodnotení a nikdy nie slepým hľadaním a nahrádzaním, pretože sa tým poškodia serializované údaje.

Slepá škvrna mnohých vyčistení

Po vlámaní väčšina prevádzkovateľov kontroluje súbory. Nahradia jadro CMS, zmažú podozrivé súbory PHP a znova nainštalujú rozšírenia. Web potom vyzerá čisto a o týždeň zasa presmerúva na cudzie stránky. Dôvod je často v databáze, ktorá sa pri vyčistení prevzala nezmenená.

Pre útočníkov je databáza lákavou skrýšou. Skript vo widgete sa doručuje na každej stránke. Zmenené nastavenie adresy presmeruje všetkých návštevníkov. Ďalší účet administrátora otvára dvere na neskôr. Nič z toho nezaujme pri skene súborov.

Po PHP2Shell, teda po zraniteľnostiach CVE-2026-109618 a CVE-2026-109619 s vykonaním kódu bez prihlásenia, preto databáza patrí ku každej kontrole. Kto môže na serveri vykonávať kód, môže spravidla prečítať prístupové údaje k databáze z konfigurácie a zapisovať tam ľubovoľne. Ako aplikácia s databázou vôbec komunikuje, vysvetľuje PHP a databázy: PDO a mysqli.

Kde škodlivý kód v databáze sídli

Posledné tri riadky sa prehliadajú obzvlášť často, pretože neležia v tabuľkách CMS, ale v samotnom databázovom serveri.

Pri e-shopoch si jedno miesto nálezu zaslúži osobitnú pozornosť: nastavenia, cez ktoré sa do pokladne a dokončenia objednávky vkladajú dodatočné skripty. Cudzí skript na tomto mieste môže odpočúvať zadania zákazníkov skôr, než sa šifrované odošlú platobnej službe. Preto cielene skontrolujte všetky polia pre kód v hlavičke a päte, vloženia sledovacích kódov a nastavenia dizajnu, ktoré pôsobia na stránkach pokladne.

Myslite aj na ďalšie databázy na tom istom serveri. Testovacie a staging kópie, staré stavy projektov alebo databázy iných webov často ležia vedľa a sú dostupné s rovnakými prístupovými údajmi. Čo sa nájde v živej databáze, malo by sa skontrolovať aj tam, skôr než kópia neskôr znova poslúži ako základ.

Kontrola databázy na škodlivý kód: obsah a nastavenia

Pracujte na exporte. Je zároveň zabezpečením dôkazov aj základom vyhľadávania. Export sa dá prehľadávať ako textový súbor bez zaťaženia bežiacej databázy:

# Vytvoriť konzistentný export (prístupové údaje sa vypýtajú)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Spočítať typické vzory v exporte
grep -oiE '<script[^>]{0,80}' export.sql | sort | uniq -c | sort -rn | head -30
grep -oiE '(eval\(|base64_decode|fromCharCode|document\.write|atob\()' export.sql | sort | uniq -c
grep -oiE 'https?://[a-z0-9.-]+' export.sql | sort | uniq -c | sort -rn | head -50

Posledný dopyt vypíše všetky domény, ktoré sa v databáze vyskytujú, podľa početnosti. Cudzie domény, ktoré nikto v tíme nepozná, sú najdôležitejšími kandidátmi. Na cielené dopyty v samotnej databáze sa hodia príkazy SELECT. Príklad používa tabuľky WordPressu; predpona a názvy tabuliek iných systémov sú v ich dokumentácii:

-- Nastavenia so skriptami alebo podozrivými funkciami
SELECT option_name, LENGTH(option_value) AS laenge
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%base64_decode%'
ORDER BY laenge DESC;

Záznamy s veľmi veľkým obsahom si zaslúžia osobitnú pozornosť. Súvislosti k skrýšam špecifickým pre WordPress ponúka sprievodca Hľadanie zadných vrátok vo WordPresse.

Triggery, udalosti a databázové účty

Triggery a plánované udalosti sa v mnohých webových aplikáciách vôbec nepredpokladajú. Ak existujú, mal by niekto vedieť vysvetliť prečo. Tieto dopyty čítajú len zo systémových tabuliek MySQL a MariaDB:

-- Triggery vo všetkých databázach
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Plánované udalosti
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Uložené procedúry a funkcie
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Používatelia databázy
SELECT user, host FROM mysql.user ORDER BY user;

Ak vaša aplikácia používa PostgreSQL alebo iný databázový systém, systémové tabuľky a príkazy sa volajú inak; princíp ostáva rovnaký. Na analýzu sa odporúča samostatný používateľ databázy, ktorý smie len čítať. Tak ani preklep v dopyte nič nezmení a kontrola nezanechá stopy v údajoch.

Trigger, ktorý pri ukladaní príspevku pripája kód, vysvetľuje, prečo sa škodlivý kód po každom vyčistení vracia. Neznámi používatelia databázy patria ku kontrole účtov rovnako ako účty administrátorov v CMS; viac v článku Hľadanie cudzích administrátorských účtov v CMS a na serveri.

Čisto vyčistiť bez zničenia údajov

Vyčistenie je najcitlivejšia časť. Toto poradie sa osvedčilo:

1. Vyhodnotiť nálezy: každý nález sa zaradí ako známy, neškodne vysvetliteľný alebo cudzí. Sledovacie kódy a kódy máp sú často legitímne.
2. Uzavrieť vstupnú bránu: PHP uviesť na opravený stav (8.5.12, 8.4.27, 8.3.36, 8.2.35 alebo potvrdený backport), reštartovať všetkých workerov, aktualizovať aplikáciu.
3. Odstrániť cielene: cudzí obsah vyčistiť cez aplikáciu alebo nástrojmi, ktoré správne zaobchádzajú so serializovanými údajmi. Cudzie triggery, udalosti a účty zmazať.
4. Zmeniť prístupové údaje: nové heslo databázy, zapísať ho do konfigurácie aplikácie, práva používateľa aplikácie obmedziť na vlastnú databázu.
5. Skontrolovať znova: vyhľadávacie dopyty zopakovať po niekoľkých dňoch.

Presmerovania, ktoré sa vyskytujú aj pri čistej databáze, majú príčinu v inej vrstve. Pri zúžení pomáha príspevok Web presmerúva na cudzie stránky.

Ako konkrétne pomáha PHP SOS?

• Databázu zabezpečíme s kontrolným súčtom a export prehľadáme na skripty, cudzie domény a zahmlený kód.
• Skontrolujeme triggery, udalosti, procedúry a používateľov databázy, ktorí ležia mimo CMS.
• Nálezy vyčistíme v rámci odstránenia malvéru bez poškodenia serializovaných údajov.
• Obmedzíme práva používateľa aplikácie a po vyčistení kontrolu zopakujeme.

Časté otázky

Zdroje

• OWASP Top 10
• OWASP Cheat Sheets
• php.net: bezpečnostné správy