Semnal de alarmă: serverul web pornește un shell

Pe scurt: Dacă PHP-FPM, Apache sau alt proces al serverului web pornește un shell precum sh sau bash, este unul dintre cele mai puternice semnale de alarmă pentru o intruziune prin site. Verificați arborele de procese, linia de comandă și directorul de lucru al shell-ului înainte de a închide ceva. Shell-uri scurte, izolate, pot fi legitime; shell-urile cu rulare lungă și instrumente de rețea aproape niciodată.

De ce spune acest tipar atât de mult

Un server web răspunde la cereri. PHP-FPM, adică administratorul de procese care execută scripturile PHP pentru serverul web, nu pornește în mod normal alte programe pentru aceasta. Un shell sub serverul web înseamnă că un cod PHP a apelat deliberat un program. Fie aplicația face aceasta intenționat, fie altcineva a introdus cod.

Pentru PHP2Shell nu există Indicators of Compromise publicate și confirmate, adică nicio listă de semne fixe de recunoaștere. Detectarea se bazează pe comportament. Conform rapoartelor de care dispunem, procesele de server web sau PHP-FPM care pornesc un shell se numără printre cele mai puternice semnale generale de alarmă. Aceasta se aplică oricărei vulnerabilități prin care atacatorii pot executa cod pe server. O privire de ansamblu asupra altor semne oferă Sunt deja compromis?.

De ce este shell-ul atât de important pentru un atacator? Cu o vulnerabilitate poate, la început, trimite doar comenzi individuale prin procesul PHP. Un shell transformă aceasta într-un loc de muncă confortabil: se poate uita în jur, poate încărca instrumente, poate citi date de acces din fișierele de configurare și se poate instala permanent. Cine recunoaște shell-ul îl recunoaște deci adesea pe atacator chiar în momentul în care trece de la primul acces la adevăratul său plan.

PHP-FPM pornește bash: citirea arborelui de procese

Fiecare proces din Linux are un proces părinte. Întrebarea este dacă un shell rulează ca descendent al unui proces de server web. Comenzile următoare doar citesc:

# Arborele de procese cu utilizator, PID-ul părinte și ora de pornire
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shell-uri care rulează sub utilizatorii tipici ai serverului web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Arborele începând de la cel mai vechi proces PHP-FPM
pstree -alp "$(pgrep -o php-fpm)"

Dacă ați găsit un shell suspect, intrările din /proc oferă alte indicii, de asemenea doar prin citire:

PID=12345   # PID-ul shell-ului suspect
tr '\0' ' ' < /proc/$PID/cmdline; echo        # linia de comandă completă
ls -l /proc/$PID/cwd /proc/$PID/exe            # directorul de lucru și fișierul programului
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # conexiuni de rețea deschise

Numele proceselor pe Debian și Ubuntu sunt adesea php8.3-fpm sau similare; adaptați tiparele de căutare. Directoarele de lucru în /tmp, /dev/shm sau în directoare de upload sunt un semn clar.

Excepții legitime și semne de alarmă reale

Unele aplicații apelează programe prin PHP. Astfel poate apărea scurt un shell, de exemplu când PHP transmite e-mailuri prin sendmail_path sau o aplicație prelucrează imagini cu o unealtă externă. Astfel de shell-uri trăiesc doar secunde și apelează întotdeauna același program. Documentați aceste cazuri așteptate o dată, curat; apoi orice abatere de la ele iese imediat în evidență, în loc să se piardă într-un val de mesaje cunoscute.

Dacă nu știți dacă aplicația dumneavoastră apelează programe, întrebați dezvoltatorul sau căutați în cod funcții precum exec, shell_exec, system, passthru, proc_open și popen. Potrivirile în propriul cod sunt normale, cele din fișiere necunoscute nu.

Monitorizare permanentă în loc de o singură privire

O instantanee cu ps prinde doar shell-urile care rulează chiar acum. Procesele de scurtă durată scapă. Mai de încredere este să înregistrați permanent pornirile de programe de către utilizatorul serverului web. Pe Linux, aceasta o face serviciul de audit auditd cu o regulă pentru pornirile de programe ale utilizatorului serverului web. Evaluarea se face prin citire:

# Afișarea pornirilor de programe înregistrate sub o cheie de regulă (cheia ca exemplu)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="

Cum arată regula depinde de distribuție și de ID-ul utilizatorului; testați-o mai întâi, deoarece pe serverele puternic încărcate apar multe intrări.

Două completări fac monitorizarea solidă. Prima: jurnalele ar trebui trimise suplimentar către un sistem central, deoarece un atacator cu drepturi de root poate șterge logurile locale. A doua: este nevoie de alertare. O pornire de program de către utilizatorul serverului web care nu se află pe o listă scurtă de programe așteptate ar trebui să declanșeze o notificare, nu doar o intrare în jurnal. Cine folosește deja o soluție de detectare pe dispozitive finale sau servere poate reproduce aceeași regulă acolo. Preventiv, cu disable_functions se poate bloca ceea ce aplicația nu are nevoie. Aceasta nu închide o vulnerabilitate din interpretor, dar îngreunează pasul următor al unui atacator. Detalii la Utilizarea corectă a disable_functions.

Ce faceți dacă găsiți un shell sub serverul web

1. Documentați: Salvați într-un fișier din afara directorului web rezultatul ps, linia de comandă, directorul de lucru și conexiunile deschise.
2. Nu faceți curat: Nu ștergeți fișiere și nu încheiați procese înainte ca urmele să fie păstrate.
3. Izolați: Scoateți serverul din rețea sau restrângeți puternic accesul.
4. Căutați cauza: Verificați logurile, fișierele noi și persistența, precum cronjob-urile, vezi Găsirea proceselor suspecte pe serverele Linux.
5. Schimbați accesurile: Toate parolele și cheile care se aflau pe server se consideră cunoscute.

Dacă aplicația rulează în containere, același principiu se aplică la scară mică. Un shell în containerul PHP este la fel de suspect ca pe un server clasic, iar imaginile de container îl conțin adesea doar pentru că imaginea de bază îl aduce. Păstrați înainte de repornirea containerului starea lui, deoarece odată cu containerul dispar și urmele din sistemul de fișiere volatil.

Verificați în plus vecinătatea. Un atacator cu shell pe un server web încearcă adesea să ajungă de acolo la alte sisteme, de exemplu baza de date, spațiul de backup sau interfețele interne de administrare. Datele de acces din fișierele de configurare ale aplicației îi ușurează aceasta.

Cum ajută PHP SOS concret?

• Încadrarea constatării: Verificăm arborele de procese, liniile de comandă și conexiunile și separăm comportamentul aplicației de urmele unei intruziuni.
• Păstrarea urmelor: Păstrăm starea sistemului în mod urmăribil înainte de a modifica ceva.
• Tratarea incidentului: Prin răspunsul la incidente vă conducem de la izolare până la încheierea documentată.
• Securizare permanentă: Configurăm înregistrarea pornirilor de programe și limităm funcțiile PHP la ceea ce este necesar. Cum funcționează intern PHP-FPM explică PHP-FPM explicat.

Întrebări frecvente

Surse

• BSI: Oficiul Federal German pentru Securitatea Informației
• OWASP Cheat Sheet Series
• php.net: anunțuri de securitate