Hoiatusmärk: veebiserver käivitab shelli

Lühidalt: Kui PHP-FPM, Apache või mõni muu veebiserveri protsess käivitab shelli nagu sh või bash, on see üks tugevamaid hoiatusmärke sissemurdmise kohta veebisaidi kaudu. Kontrollige enne mis tahes lõpetamist shelli protsessipuud, käsurida ja töökataloogi. Üksikud lühikesed shellid võivad olla legitiimsed; kaua töötavad shellid võrgutööriistadega on seda peaaegu mitte kunagi.

Miks see muster nii palju ütleb

Veebiserver vastab päringutele. PHP-FPM, protsessihaldur, mis käitab veebiserveri jaoks PHP skripte, ei käivita selleks tavaliselt muid programme. Shell veebiserveri all tähendab, et PHP kood on teadlikult programmi kutsunud. Kas rakendus teeb seda tahtlikult või on keegi teine koodi sisse toonud.

PHP2Shelli kohta ei ole avaldatud ja kinnitatud kompromiteerimistunnuseid (Indicators of Compromise), see tähendab kindlate tunnuste nimekirja. Tuvastus põhineb käitumisel. Meie käsutuses olevate aruannete kohaselt kuuluvad shelli käivitavad veebiserveri või PHP-FPM-i protsessid üldiste hoiatusmärkide hulka. See kehtib iga turvaaugu kohta, mille kaudu ründajad saavad serveris koodi käivitada. Ülevaate muudest tunnustest annab Kas olen juba kompromiteeritud?.

Miks on shell ründajale nii oluline? Turvaauguga saab ta alguses PHP protsessi kaudu anda vaid üksikuid käske. Shell teeb sellest mugava töökoha: ta saab ringi vaadata, tööriistu juurde laadida, seadistusfailidest ligipääsuandmeid lugeda ja end püsivalt sisse seada. Kes shelli ära tunneb, tunneb ründaja sageli ära just hetkel, mil ta liigub esimeselt ligipääsult tegeliku plaani juurde.

PHP-FPM käivitab bashi: protsessipuu lugemine

Igal Linuxi protsessil on vanemprotsess. Küsimus on, kas shell töötab veebiserveri protsessi lapsena. Järgmised käsud ainult loevad:

# Protsessipuu kasutaja, vanema PID ja käivitusajaga
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shellid, mis töötavad tüüpiliste veebiserveri kasutajate all
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Puu vanimast PHP-FPM-i protsessist alates
pstree -alp "$(pgrep -o php-fpm)"

Kui olete leidnud kahtlase shelli, annavad kirjed kataloogis /proc lisavihjeid, samuti ainult lugevalt:

PID=12345   # kahtlase shelli PID
tr '\0' ' ' < /proc/$PID/cmdline; echo        # täielik käsurida
ls -l /proc/$PID/cwd /proc/$PID/exe            # töökataloog ja programmifail
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # avatud võrguühendused

Protsessinimed Debianis ja Ubuntus on sageli php8.3-fpm või sarnased; kohandage otsingumustrid. Töökataloogid asukohtades /tmp, /dev/shm või üleslaadimiskataloogides on selge märk.

Legitiimsed erandid ja tegelikud hoiatusmärgid

Mõned rakendused kutsuvad PHP kaudu programme. Seejuures võib korraks tekkida shell, näiteks kui PHP annab kirjad üle sendmail_path kaudu või rakendus töötleb pilte välise tööriistaga. Sellised shellid elavad vaid sekundeid ja kutsuvad alati sama programmi. Dokumenteerige need oodatud juhtumid üks kord korralikult; siis torkab iga kõrvalekalle kohe silma, mitte ei upu teadaolevate teadete tulva.

Kui te ei tea, kas teie rakendus programme kutsub, küsige arendajalt või otsige koodist funktsioone nagu exec, shell_exec, system, passthru, proc_open ja popen. Leiud omas koodis on normaalsed, leiud tundmatutes failides mitte.

Püsiv jälgimine, mitte ühekordne pilk

Hetktõmmis käsuga ps tabab ainult shelle, mis parajasti töötavad. Lühiealised protsessid lipsavad läbi. Usaldusväärsem on veebiserveri kasutaja programmikäivitusi püsivalt logida. Linuxis teeb seda auditi teenus auditd reegliga veebiserveri kasutaja programmikäivituste jaoks. Hindamine toimub lugevalt:

# Logitud programmikäivituste kuvamine reegli võtme all (võti näitena)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="

Kuidas reegel välja näeb, sõltub distributsioonist ja kasutaja ID-st; testige seda esmalt, sest tugevalt koormatud serverites tekib palju kirjeid.

Kaks täiendust teevad jälgimise töökindlaks. Esiteks peaksid logid minema lisaks kesksüsteemi, sest root-õigustega ründaja saab kohalikke logisid kustutada. Teiseks on vaja häiret: veebiserveri kasutaja programmikäivitus, mis ei ole lühikesel oodatud programmide nimekirjal, peaks käivitama teate, mitte ainult logikirje. Kes juba kasutab lahendust lõppseadmete või serverite tuvastuseks, saab sama reegli seal ära kujutada. Ennetavalt saab direktiiviga disable_functions blokeerida, mida rakendus ei vaja. See ei sulge turvaauku interpretaatoris, kuid raskendab ründaja järgmist sammu. Üksikasjad on lehel disable_functions õige kasutamine.

Mida teha, kui leiate veebiserveri all shelli

1. Dokumenteerige: kindlustage käsu ps väljund, käsurida, töökataloog ja avatud ühendused veebikataloogist väljaspool asuvasse faili.
2. Ärge koristage: ärge kustutage faile ega lõpetage protsesse enne, kui jäljed on kindlustatud.
3. Isoleerige: eemaldage server võrgust või piirake ligipääsu tugevalt.
4. Otsige põhjust: kontrollige logisid, uusi faile ja püsivust, nagu cron-tööd, vt Kahtlaste protsesside leidmine Linuxi serverites.
5. Vahetage ligipääsud: kõik paroolid ja võtmed, mis serveris asusid, loetakse teadaolevaks.

Kui rakendus töötab konteinerites, kehtib sama põhimõte väiksemas mastaabis. Shell PHP konteineris on sama kahtlane kui klassikalises serveris ning konteineripildid sisaldavad seda sageli ainult seetõttu, et baaspilt selle kaasa toob. Kindlustage enne konteineri taaskäivitamist selle seis, sest konteineriga kaovad ka jäljed muutlikus failisüsteemis.

Kontrollige lisaks naabruskonda. Ründaja, kellel on veebiserveris shell, üritab sageli sealt jõuda teiste süsteemideni, näiteks andmebaasi, varukoopiate salvestusruumi või sisemiste haldusliideseni. Rakenduse seadistusfailides olevad ligipääsuandmed teevad selle talle lihtsaks.

Kuidas PHP SOS konkreetselt aitab?

• Leiu hindamine: Kontrollime protsessipuud, käsurida ja ühendusi ning eristame rakenduse käitumist sissemurdmisjälgedest.
• Jälgede kindlustamine: Kindlustame süsteemi seisu jälgitavalt enne, kui midagi muudetakse.
• Intsidendi käsitlemine: Intsidendile reageerimisega juhime piiramisest dokumenteeritud lõpetamiseni.
• Püsiv kaitse: Seadistame programmikäivituste logimise ja piirame PHP funktsioonid vajalikuga. Kuidas PHP-FPM sisemiselt töötab, selgitab PHP-FPM selgitatud.

Korduma kippuvad küsimused

Allikad

• BSI: Saksamaa föderaalne infoturbeamet
• OWASP Cheat Sheet Series
• php.net: turvateated