Rejtett cron-feladatok felismerése hátsó kapuként

Röviden: A rejtett cron-feladat a Linux-szerverek egyik leggyakoribb hátsó kapuja: rendszeresen kártékony kódot tölt le, vagy újraindít folyamatokat, PHP-frissítés után is. Ellenőrizze az ütemezett feladatok összes helyét, ne csak a crontab -l parancsot: az összes felhasználó crontabját, az /etc/crontab fájlt, az /etc/cron.d könyvtárat, a cron-mappákat, a systemd-időzítőket és az at-feladatokat. A leleteket mentse el, mielőtt eltávolítaná őket.

Miért olyan népszerűek a cron-feladatok hátsó kapuként

Egy sikeres behatolás után a támadónak van egy problémája: a hozzáférése törékeny. Egy frissítés bezárja a rést, egy admin törli a webshellt, egy újraindítás befejezi a folyamatot. Egy cron-feladat megoldja ezt a problémát. Rögzített időpontokban parancsokat indít, anélkül hogy bárki beavatkozna, és így helyreállítja az elveszett hozzáféréseket.

A PHP2Shellre nincsenek megerősített Indicators of Compromise. Az új cron-feladatok azonban a rendelkezésünkre álló beszámolók szerint a webalkalmazásokon keresztüli behatolások utáni általános figyelmeztető jelek közé tartoznak. Aki már keresett webshelleket, az ütemezett feladatokat is ellenőrizze egyúttal. Az utómunka további lépéseit a Ellenőrzőlista feltörés után sorolja fel.

Hol rejtőzhetnek az ütemezett feladatok

A Linux több mechanizmust ismer az ütemezett feladatokra. Sok ellenőrzés azon bukik, hogy csak az egyiket nézik meg.

Webszerverek esetén fontos: a webszerver-felhasználó általában root jogosultság nélkül létrehozhatja a saját crontabját. Egy www-data jogaival rendelkező támadónak ehhez tehát nincs szüksége további résre. Az /etc/cron.d vagy a systemd-unitok bejegyzései ezzel szemben arra utalnak, hogy root jogosultságot szerzett.

A tárhelypanelek, például a Plesk vagy a cPanel, saját felületet kínálnak az ütemezett feladatokhoz. Mögöttük általában szintén az érintett rendszerfelhasználók crontabjai állnak. Aki csak a felületen néz utána, ezért nem ismer fel minden bejegyzést, amelyet közvetlenül a szerveren hoztak létre. Kétség esetén ellenőrizze mindkettőt.

Így ellenőrzi teljesen az összes helyet

A következő parancsok csak olvasnak. Futtassa őket rootként, és a kimeneteket mentse dátummal.

# Az összes felhasználó crontabjának kiírása
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Rendszerszintű bejegyzések és módosítási idők
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# systemd-időzítők és at-feladatok
systemctl list-timers --all
atq 2>/dev/null

# Tipikus minták keresése az összes cron-fájlban
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Két trükk különös figyelmet érdemel. Egyes bejegyzések a parancsokat sok szóköz mögé rejtik, így azok a szerkesztőben jobbra kifutnak a képből. Mások vezérlőkaraktereket használnak, amelyek megjelenítéskor felülírják a szöveget. A cat -A láthatóvá teszi az ilyen karaktereket:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

A második nézőpont a cron-szolgáltatás naplója. Sok rendszeren a cron minden végrehajtást rögzít a felhasználóval és a paranccsal. Így azokat a bejegyzéseket is látja, amelyeket a támadó időközben eltávolított, és felismeri, mióta fut egy gyanús parancs:

# A webszerver-felhasználó végrehajtott cron-parancsai (Debian/Ubuntu, illetve systemd-napló)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Miről ismeri fel a cron-feladat hátsó kaput

1. Letöltés az internetről: Egy letöltés, amelynek eredményét közvetlenül egy shellnek adják át.
2. Kódolt tartalmak: Hosszú karakterláncok, amelyeket csak futásidőben dekódolnak.
3. Szokatlan útvonalak: Programok a /tmp, a /dev/shm, rejtett mappák vagy feltöltési könyvtárak alatt.
4. Rossz felhasználó: A webszerver-felhasználó alatti feladatok, noha az alkalmazásnak nincs rájuk szüksége.
5. Feltűnő ütem: Percenkénti végrehajtás, vagy minden újraindításnál az @reboot révén.
6. Nem odaillő időbélyegek: Olyan időszakban módosított fájl, amikor senki sem dolgozott a szerveren, például október 17. után.

Ne feledje: az alkalmazásoknak is vannak saját ütemterveik. A WordPress például az ütemezett feladatokat az adatbázisban kezeli. Hogyan ellenőrzi ott, azt a Hátsó kapuk keresése a WordPressben írja le.

A lelet mentése, megértése, majd eltávolítása

Egy rosszindulatú cron-feladat értékes bizonyíték. Megmutatja a letöltési címet, a létrehozás időpontját és gyakran azt a felhasználót, amelyen keresztül a támadó bejutott. Az eltávolítás előtt mentse a fájlt ellenőrző összeggel és időbélyegekkel. Az időbélyeg később segít rekonstruálni a lefolyást; hogyan, azt a Egy incidens idővonalának elkészítése mutatja. Egy esetleges adatvédelmi felügyeleti hatóságnak szóló bejelentéshez vagy a biztosítóhoz is fontos bizonyíték arra, mióta fért hozzá a támadó.

Az eltávolítás önmagában nem elég. Ha még fut egy folyamat, amely újraírja a bejegyzést, a következő percben visszatér. És amíg az eredeti rés nyitva van, a támadó bármikor újra próbálkozhat. A sorrend ezért: mentés, az ok lezárása, az összes összetevő eltávolítása, hozzáférések cseréje, figyelés.

A cron-feladatok megelőző védelme

Hogy egy cron-feladat hátsó kapu egyáltalán ne keletkezhessen, vagy gyorsan feltűnjön, három intézkedés segít. Először: megadható, mely felhasználók hozhatnak létre egyáltalán crontabot. Ha létezik az /etc/cron.allow fájl, csak az ott megnevezett felhasználók használhatják a crontab parancsot. Ha az alkalmazásának nincs szüksége cron-feladatra a webszerver-felhasználó alatt, ez a felhasználó ne kerüljön a listára. Előtte ellenőrizze, mely feladatokra van ténylegesen szüksége az alkalmazásnak, és ezeket tudatosan egy saját felhasználó alatt hozza létre.

Másodszor: megéri a fájlok figyelése. Az integritásellenőrző eszköz jelez, ha a cron-könyvtárakban vagy az /var/spool/cron alatt egy fájl megváltozik. Harmadszor: az ütemezett feladatoknak a szerver dokumentációjába kell kerülniük. Aki tudja, milyen bejegyzéseknek kell lenniük, azonnal felismeri az idegent.

Hogyan segít konkrétan a PHP SOS?

• Teljes ellenőrzés: Az ütemezett feladatok összes mechanizmusát megvizsgáljuk, a systemd-időzítőket, az at-feladatokat és az alkalmazások ütemterveit is.
• A leletek besorolása: A gyanús bejegyzéseket végrehajtásuk nélkül értékeljük ki, és további nyomokat vezetünk le belőlük.
• Tiszta eltávolítás: A kártevő-eltávolítással eltávolítjuk az összes összetevőt, és lezárjuk az okot.
• A visszatérés felismerése: Beállítunk egy figyelést, amely jelzi az új vagy módosított ütemezett feladatokat.

Gyakori kérdések

Források

• BSI: a német szövetségi információbiztonsági hivatal
• BSI IT-Grundschutz
• OWASP Cheat Sheet Series