Waarschuwingssignaal: de webserver start een shell

Kort gezegd: Als PHP-FPM, Apache of een ander webserverproces een shell zoals sh of bash start, is dat een van de sterkste waarschuwingssignalen voor een inbraak via de website. Controleer de procesboom, de opdrachtregel en de werkmap van de shell voordat u iets beëindigt. Enkele korte shells kunnen legitiem zijn; lang draaiende shells met netwerkhulpmiddelen zijn het bijna nooit.

Waarom dit patroon zoveel zegt

Een webserver beantwoordt verzoeken. PHP-FPM, de procesbeheerder die PHP-scripts voor de webserver uitvoert, start daarvoor normaal geen andere programma's. Een shell onder de webserver betekent dat PHP-code bewust een programma heeft aangeroepen. Ofwel doet de toepassing dat opzettelijk, ofwel heeft iemand anders code ingebracht.

Voor PHP2Shell bestaan geen gepubliceerde, bevestigde Indicators of Compromise, dus geen lijst met vaste herkenningskenmerken. De detectie berust op gedrag. Volgens de ons beschikbare berichten behoren webserver- of PHP-FPM-processen die een shell starten tot de sterkste algemene waarschuwingssignalen. Dat geldt voor elk lek waarmee aanvallers code op de server uitvoeren. Een overzicht van verdere tekenen geeft Ben ik al gecompromitteerd?.

Waarom is de shell voor een aanvaller zo belangrijk? Met een lek kan hij aanvankelijk alleen losse opdrachten via het PHP-proces geven. Een shell maakt daarvan een gemakkelijke werkplek: hij kan rondkijken, hulpmiddelen naladen, toegangsgegevens uit configuratiebestanden lezen en zich blijvend nestelen. Wie de shell herkent, herkent de aanvaller dus vaak op het moment waarop hij van de eerste toegang overgaat naar het eigenlijke doel.

PHP-FPM start bash: de procesboom lezen

Elk proces onder Linux heeft een ouderproces. De vraag is of een shell als kind van een webserverproces draait. De volgende opdrachten lezen alleen:

# Procesboom met gebruiker, ouder-PID en starttijd
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shells die onder typische webservergebruikers draaien
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Boom vanaf het oudste PHP-FPM-proces
pstree -alp "$(pgrep -o php-fpm)"

Hebt u een verdachte shell gevonden, dan leveren de vermeldingen onder /proc verdere aanwijzingen, eveneens alleen lezend:

PID=12345   # PID van de verdachte shell
tr '\0' ' ' < /proc/$PID/cmdline; echo        # volledige opdrachtregel
ls -l /proc/$PID/cwd /proc/$PID/exe            # werkmap en programmabestand
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # open netwerkverbindingen

Procesnamen op Debian en Ubuntu luiden vaak php8.3-fpm of vergelijkbaar; pas de zoekpatronen aan. Werkmappen in /tmp, /dev/shm of in uploadmappen zijn een duidelijk teken.

Legitieme uitzonderingen en echte waarschuwingstekens

Sommige toepassingen roepen via PHP programma's aan. Daarbij kan kort een shell ontstaan, bijvoorbeeld wanneer PHP via sendmail_path mails overdraagt of een toepassing afbeeldingen met een extern hulpmiddel verwerkt. Zulke shells leven slechts seconden en roepen steeds hetzelfde programma aan. Documenteer deze verwachte gevallen één keer netjes; dan valt elke afwijking meteen op in plaats van onder te gaan in een stroom bekende meldingen.

Weet u niet of uw toepassing programma's aanroept, vraag het dan de ontwikkelaar of zoek in de code naar functies zoals exec, shell_exec, system, passthru, proc_open en popen. Treffers in de eigen code zijn normaal, treffers in onbekende bestanden niet.

Blijvend bewaken in plaats van één keer kijken

Een momentopname met ps pakt alleen shells die op dat moment draaien. Kortlevende processen glippen erdoor. Betrouwbaarder is het programmastarts door de webservergebruiker blijvend te loggen. Onder Linux doet dat de auditservice auditd met een regel voor programmastarts van de webservergebruiker. Uitgelezen wordt lezend:

# Gelogde programmastarts onder een regelsleutel tonen (sleutel als voorbeeld)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="

Hoe de regel eruitziet, hangt af van distributie en gebruikers-ID; test hem eerst, want op zwaar belaste servers ontstaan veel vermeldingen.

Twee aanvullingen maken de bewaking robuust. Ten eerste moeten de logs bovendien naar een centraal systeem gaan, want een aanvaller met rootrechten kan lokale logs wissen. Ten tweede is er alarmering nodig: een programmastart door de webservergebruiker die niet op een korte lijst van verwachte programma's staat, moet een melding veroorzaken, niet alleen een logregel. Wie al een oplossing voor detectie op eindapparaten of servers gebruikt, kan dezelfde regel daar nabootsen. Preventief kunt u met disable_functions blokkeren wat de toepassing niet nodig heeft. Dat dicht geen lek in de interpreter, maar bemoeilijkt de volgende stap van een aanvaller. Details staan onder disable_functions correct gebruiken.

Wat te doen als u een shell onder de webserver vindt

1. Documenteren: Uitvoer van ps, opdrachtregel, werkmap en open verbindingen in een bestand buiten de webmap veiligstellen.
2. Niet opruimen: Geen bestanden wissen en geen processen beëindigen voordat de sporen zijn veiliggesteld.
3. Isoleren: De server van het net halen of de toegang sterk beperken.
4. Oorzaak zoeken: Logs, nieuwe bestanden en persistentie zoals cronjobs controleren, zie Verdachte processen op Linux-servers vinden.
5. Toegangen wijzigen: Alle wachtwoorden en sleutels die op de server stonden, gelden als bekend.

Draait de toepassing in containers, dan geldt hetzelfde principe in het klein. Een shell in de PHP-container is even verdacht als op een klassieke server, en containerimages bevatten haar vaak alleen omdat de basisimage haar meebrengt. Bewaar vóór het herstarten van de container zijn toestand, want met de container verdwijnen ook de sporen in het vluchtige bestandssysteem.

Controleer bovendien de omgeving. Een aanvaller met een shell op een webserver probeert vanaf daar vaak andere systemen te bereiken, zoals de database, back-upopslag of interne beheerinterfaces. Toegangsgegevens in configuratiebestanden van de toepassing maken hem dat gemakkelijk.

Hoe helpt PHP SOS concreet?

• Bevinding plaatsen: Wij controleren procesboom, opdrachtregels en verbindingen en scheiden toepassingsgedrag van sporen van inbraak.
• Sporen veiligstellen: Wij stellen de systeemtoestand navolgbaar veilig voordat er iets wordt gewijzigd.
• Incident afhandelen: Met de incident response begeleiden wij van de beheersing tot de gedocumenteerde afronding.
• Blijvend beveiligen: Wij richten de logging van programmastarts in en beperken de PHP-functies tot het noodzakelijke. Hoe PHP-FPM intern werkt, legt PHP-FPM uitgelegd uit.

Veelgestelde vragen

Bronnen

• BSI: Duitse federale dienst voor informatiebeveiliging
• OWASP Cheat Sheet Series
• php.net: beveiligingsmeldingen