Kort sagt: Når PHP-FPM, Apache eller en anden webserverproces starter en shell som sh eller bash, er det et af de stærkeste advarselstegn på et indbrud via websitet. Kontrollér procestræet, kommandolinjen og shellens arbejdsmappe, før I afslutter noget. Enkelte korte shells kan være legitime; længe kørende shells med netværksværktøjer er det næsten aldrig.
Hvorfor dette mønster siger så meget
En webserver besvarer forespørgsler. PHP-FPM, altså procesadministratoren, der udfører PHP-scripts for webserveren, starter normalt ingen yderligere programmer hertil. En shell under webserveren betyder, at PHP-kode bevidst har kaldt et program. Enten gør applikationen det med vilje, eller også har nogen anden smuglet kode ind.
For PHP2Shell findes der ingen offentliggjorte, bekræftede indicators of compromise, altså ingen liste over faste kendetegn. Opdagelsen beror på adfærd. Ifølge de rapporter, vi har foran os, hører webserver- eller PHP-FPM-processer, der starter en shell, til de stærkeste generelle advarselstegn. Det gælder for enhver sårbarhed, hvorigennem angribere kan udføre kode på serveren. Et overblik over yderligere tegn giver Er jeg allerede kompromitteret?.
Hvorfor er shellen så vigtig for en angriber? Med en sårbarhed kan han først kun afsætte enkelte kommandoer via PHP-processen. En shell gør det til en bekvem arbejdsplads: Han kan se sig om, hente værktøjer, læse adgangsdata fra konfigurationsfiler og indrette sig varigt. Den, der genkender shellen, genkender altså ofte angriberen i det øjeblik, hvor han går fra den første adgang til det egentlige forehavende.
PHP-FPM starter bash: læs procestræet
Hver proces under Linux har en forældreproces. Spørgsmålet er, om en shell kører som barn af en webserverproces. Følgende kommandoer læser kun:
# Procestræ med bruger, forælder-PID og starttidspunkt
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"
# Shells, der kører under typiske webserverbrugere
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"
# Træ fra den ældste PHP-FPM-proces
pstree -alp "$(pgrep -o php-fpm)"
Har I fundet en mistænkelig shell, giver posterne under /proc yderligere henvisninger, ligeledes kun læsende:
PID=12345 # PID for den mistænkelige shell
tr '\0' ' ' < /proc/$PID/cmdline; echo # fuldstændig kommandolinje
ls -l /proc/$PID/cwd /proc/$PID/exe # arbejdsmappe og programfil
ls -l /proc/$PID/fd 2>/dev/null | grep socket # åbne netværksforbindelser
Procesnavne på Debian og Ubuntu hedder ofte php8.3-fpm eller lignende; tilpas søgemønstrene. Arbejdsmapper i /tmp, /dev/shm eller i upload-mapper er et tydeligt tegn.
Legitime undtagelser og ægte advarselstegn
Nogle applikationer kalder programmer via PHP. Derved kan der kortvarigt opstå en shell, f.eks. når PHP afleverer mails via sendmail_path, eller en applikation behandler billeder med et eksternt værktøj. Sådanne shells lever kun sekunder og kalder altid det samme program. Dokumentér disse forventede tilfælde én gang ordentligt; så springer enhver afvigelse straks i øjnene i stedet for at drukne i en flod af kendte meddelelser.
| Observation | Snarere harmløs, hvis | Mistænkelig, hvis |
|---|---|---|
| Kort shell under PHP-FPM | den starter et kendt program i applikationen | mål og formål er uklare |
| Længere kørende shell | aldrig | den kører i minutter eller timer |
| Netværksværktøjer som barneproces | kendt opdaterings- eller API-forespørgsel fra applikationen | downloads til midlertidige mapper følger |
| Arbejdsmappe | applikationens projektmappe | /tmp, /dev/shm, upload-mapper |
| Tidspunkt | passer til en kendt handling, f.eks. mailafsendelse | om natten, uden brugeraktivitet, i klynger |
Ved I ikke, om jeres applikation kalder programmer, så spørg udvikleren, eller søg i koden efter funktioner som exec, shell_exec, system, passthru, proc_open og popen. Fund i egen kode er normale, fund i ukendte filer er det ikke.
Overvåg varigt i stedet for at kigge efter én gang
Et øjebliksbillede med ps fanger kun shells, der netop kører. Kortlivede processer slipper igennem. Mere pålideligt er det at logge programstarter fra webserverbrugeren varigt. Under Linux klarer det audit-tjenesten auditd med en regel for programstarter fra webserverbrugeren. Udlæsningen sker læsende:
# Vis loggede programstarter under en regelnøgle (nøglen er et eksempel)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
Hvordan reglen ser ud, afhænger af distribution og bruger-ID; test den først, for på stærkt belastede servere opstår der mange poster.
To tilføjelser gør overvågningen robust. For det første bør logs desuden gå til et centralt system, for en angriber med root-rettigheder kan slette lokale logs. For det andet er der brug for en alarmering: En programstart fra webserverbrugeren, der ikke står på en kort liste over forventede programmer, bør udløse en meddelelse, ikke blot en logpost. Den, der allerede bruger en løsning til detektion på endepunkter eller servere, kan afbilde den samme regel dér. Forebyggende kan det, applikationen ikke har brug for, spærres med disable_functions. Det lukker ingen sårbarhed i fortolkeren, men gør en angribers næste skridt sværere. Enkeltheder står under Brug disable_functions korrekt.
Hvad skal I gøre, hvis I finder en shell under webserveren
- Dokumentér: Sikr output fra
ps, kommandolinje, arbejdsmappe og åbne forbindelser i en fil uden for webmappen. - Ryd ikke op: Slet ingen filer og afslut ingen processer, før sporene er sikret.
- Isolér: Tag serveren af nettet, eller begræns adgangen kraftigt.
- Søg årsagen: Kontrollér logs, nye filer og persistens som cronjobs, se Find mistænkelige processer på Linux-servere.
- Skift adgange: Alle adgangskoder og nøgler, der lå på serveren, regnes som kendte.
Kører applikationen i containere, gælder det samme princip i det små. En shell i PHP-containeren er lige så mistænkelig som på en klassisk server, og container-images indeholder den ofte kun, fordi basisimaget medbringer den. Sikr containerens tilstand før genstarten, for med containeren forsvinder også sporene i det flygtige filsystem.
Kontrollér desuden nabolaget. En angriber med en shell på en webserver forsøger ofte derfra at nå andre systemer, f.eks. databasen, backup-lageret eller interne administrationsgrænseflader. Adgangsdata i applikationens konfigurationsfiler gør det let for ham.
En længe kørende shell under PHP-FPM på en server med kundedata er en sikkerhedshændelse. Behandl den som sådan: sikr, isolér, bearbejd struktureret, lad anmeldelsespligter kontrollere.
Hvordan hjælper PHP SOS konkret?
- Vurdér fundet: Vi kontrollerer procestræ, kommandolinjer og forbindelser og skiller applikationsadfærd fra spor af indbrud.
- Sikr spor: Vi sikrer systemets tilstand efterprøveligt, før noget ændres.
- Behandl hændelsen: Med incident response fører vi fra inddæmning til dokumenteret afslutning.
- Sikr varigt: Vi sætter logning af programstarter op og begrænser PHP-funktionerne til det nødvendige. Hvordan PHP-FPM arbejder internt, forklarer PHP-FPM forklaret.
Ofte stillede spørgsmål
Er enhver shell under PHP-FPM et angreb?
Ikke enhver. Nogle applikationer kalder bevidst programmer via PHP, f.eks. til billedbehandling eller mailafsendelse, og derved kan der kortvarigt opstå en shell. Mistænkeligt bliver det, hvis shellen kører længere, starter netværksværktøjer eller arbejder fra utypiske mapper.
Bør jeg afslutte den mistænkelige proces med det samme?
Først dokumentere, så handle. Notér procesdata, kommandolinje, arbejdsmappe og netværksforbindelser. Derefter isolerer I serveren. En overilet afslutning ødelægger spor og forhindrer ikke, at angriberen vender tilbage.
Findes der bekræftede kendetegn for PHP2Shell?
Nej. Der findes ingen offentliggjorte, bekræftede indicators of compromise. Shells under webserveren er et generelt advarselstegn på indbrud via webapplikationer, ikke specifikt for PHP2Shell.
Hvordan forhindrer jeg, at PHP overhovedet starter shells?
Via disable_functions kan funktioner som exec, shell_exec, system og proc_open spærres, hvis applikationen ikke har brug for dem. Det lukker ikke nogen sårbarhed i PHP-fortolkeren, men gør udnyttelsen sværere.