Web Shells in Action - Rilevazione e prevenzione - parte 5

09/07/20 CoreTech Blog

Nella parte 4  di questa serie, abbiamo esaminato le shell Web in azione usando Weevely come esempio. Nella parte finale di questa serie, esamineremo il rilevamento della shell Web e come prevenirne l'uso.

Rivelazione

Se un amministratore sospetta che sia presente una shell Web sul proprio sistema o stia semplicemente effettuando un controllo di routine, è necessario esaminare alcuni aspetti seguenti.

Innanzitutto, è necessario filtrare l'accesso al server e i log degli errori per le parole chiave comuni utilizzate dalle shell Web. Ciò include nomi di file e / o nomi di parametri. L'esempio seguente consente di cercare il file di stringa negli URL nel registro di accesso del server HTTP Apache.

root@secureserver:/var/www/html# cat /var/log/apache2/access.log | awk -F\" ' { print $1,$2 } ' | grep "file"

--> 192.168.5.26 - - [30/Feb/2020:08:30:53 +0100] GET /demo/shell.php?file=/etc/passwd

Il filesystem (di solito il root del web server) deve essere cercato per stringhe comuni in file o nomi di file.

root@secureserver:/var/www/html/demo# grep -RPn "(passthru|exec|eval|shell_exec|assert|str_rot13|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\("

--> Shell.php:8: eval($string);

eval.php:1:?php system($_SERVER['HTTP_USER_AGENT']); ?>

Ad.php:9: eval($string);

Cerca stringhe molto lunghe, che possono indicare la codifica. Alcune backdoor hanno migliaia di righe di codice.

root@secureserver:/var/www/html/demo# awk 'length($0)>100' *.php

--> eval(gzinflate(base64_decode('HJ3HkqNQEkU/ZzqCBd4t8V4YAQI2E3jvPV8/1Gw6orsVFLyXefMcFUL5EXf/yqceii7e8n9JvOYE9t8sT8cs//cfWUXldLpKsQ2LCH7EcnuYdrqeqDHEDz+4uJYWH3YLflGUnDJ40DjU/AL1miwEJPpBWlsAxTrgB46jRW/00XpggW00yDI/H1kD7UqxI/3qjQZ4vz7HLsfNVW1BeQKiVH2VTrXtoiaKYdkT4o/p1E8W/n5eVhagV7GanBn0U7OCfD7zPbCQyO0N/QGtstthqJBia5QJsR6xCgkHpBo1kQMlLt6u++SBvtw5KSMwtG4R2yctd0mBNrlB3QQo4aQKGRgRjTa0xYFw1vVM9ySOMd44sSrPe…

Cerca i file che sono stati modificati negli ultimi X giorni. Nel seguente esempio, abbiamo cercato i *.php file modificati nell'ultimo giorno, ma si consiglia di cercare qualsiasi modifica ai file poiché una shell Web può anche essere incorporata in un'immagine o in qualsiasi altro file.

root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls

--> root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls

2885788 4 drwxrwxr-x 2 secuser secuser 4096 Apr 30 06:590 /demo/shell.php

2886629 4 -rw-rw-r-- 1 secuser secuser 260 Apr 29 11:25 /demo/b.php

2897510 4 -rw-r--r-- 1 root root 35 Apr 29 13:46 /demo/source.php

2883635 4 -rw-r--r-- 1 www-data www-data 1332 Apr 29 12:09 ./ma.php

Monitorare la rete per traffico e connessioni di rete insoliti.

root@secureserver:/var/www/html/demo# netstat -nputw

--> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 192.168.5.25:37040 192.168.5.26:8181 ESTABLISHED 2150/nc

tcp 0 0 192.168.5.25:22 192.168.5.1:52455 ESTABLISHED 2001/sshd: secuser

tcp6 1 0 ::1:46672 ::1:631 CLOSE_WAIT 918/cups-browsed

tcp6 0 0 192.168.5.25:80 192.168.5.26:39470 ESTABLISHED 1766/apache2

tcp6 1 0 ::1:46674 ::1:631 CLOSE_WAIT 918/cups-browsed

Analizza i .htaccess file per le modifiche. Di seguito sono riportati esempi di modifiche che un utente malintenzionato potrebbe apportare ai .htaccess file.

# The AddType directive maps the given filename extensions onto the specified content type

AddType application/x-httpd-php .htaccess

AddType application/x-httpd-php .jpg

Prevenzione

Di seguito è riportato un elenco non esaustivo di misure preventive da adottare in relazione alle shell web.

1. Se non utilizzato, disattivare funzioni PHP potenzialmente pericolosi quali exec(), shell_exec(), passthru(), system(), show_source(), proc_open(), pcntl_exec(), eval(), eassert()
2. Se è assolutamente necessario abilitare tali comandi, assicurarsi che gli utenti non autorizzati non abbiano accesso a questi script. Inoltre, utilizzare escapeshellarg() e escapeshellcmd() per assicurarsi che l'input dell'utente non possa essere iniettato nei comandi della shell, causando vulnerabilità nell'esecuzione dei comandi.
3. Se l'applicazione Web utilizza moduli di caricamento, assicurarsi che siano sicuri e che consentano solo il caricamento di tipi di file autorizzati.
4. Non fidarti mai dell'input dell'utente.
5. Non utilizzare ciecamente il codice che potresti trovare su forum o siti Web online.
6. Nel caso di WordPress, cerca di evitare l'installazione di plugin di terze parti se non ti servono. Se è necessario utilizzare un plug-in, assicurarsi che sia affidabile e aggiornato frequentemente.
7. Disabilita l'esecuzione di PHP in directory sensibili come immagini o caricamenti.
8. Bloccare le autorizzazioni utente del server Web.

Osservazioni finali

Come abbiamo visto, codificare e utilizzare una shell Web non è difficile. Sfortunatamente, molti server Web sono impostati in modo tale che anche un semplice script è sufficiente per causare danni significativi. Questo è il motivo principale per cui ci sono migliaia di shell Web disponibili al pubblico. Il fatto che esistano così tante variazioni rende difficile il rilevamento di sistemi di rilevamento e prevenzione delle intrusioni (IDS / IPS), soprattutto se utilizzano firme per rilevare tali shell Web. Alcune web shell sono molto sofisticate e sono quasi impossibili da rilevare, anche con analisi comportamentali.

Detto questo, all'inizio di questa serie di articoli abbiamo stabilito che le shell Web sono strumenti post-sfruttamento. Ciò significa che il modo migliore per impedire lo sfruttamento è impedire che vengano caricati in primo luogo.

Poiché lo scanner delle vulnerabilità di Acunetix testa siti Web e applicazioni Web per migliaia di vulnerabilità, tra cui l'esecuzione di codice e vulnerabilità di upload di file arbitrari, è in grado di trovare punti di accesso che potrebbero consentire agli aggressori di caricare shell web.

Inoltre, quando si utilizza la tecnologia AcuSensor , poiché un sensore è distribuito all'interno dell'applicazione Web, lo scanner può recuperare un elenco di file sul back-end del server, il che significa che lo scanner è in grado di rilevare shell Web e altri script dannosi anche se sepolti in profondità all'interno delle directory.