Durante gli ultimi eventi “Blue Vs Red”, insieme a Rocco Sicilia , abbiamo discusso su come attaccare e difendere un sito WordPress semplice e all-in-one. Questo post serve come memorandum per ricordare tutti gli argomenti trattati e come abbiamo reagito a specifici attacchi.

Analisi della superficie d’attacco

Poiché lo scenario è stato costruito da zero, abbiamo discusso questo argomento in teoria. Abbiamo constatato che strumenti come Shodan, Censys e ZoomEye offrono una grande quantità di informazioni senza la necessità di sondare direttamente il target.

Questi probe Internet potrebbero essere filtrati da un firewall, integrando un feed IP aggiornato. Uno degli strumenti in grado di acquisire, arricchire e combinare feed esterni è MineMeld . I feed forniti da MineMeld possono essere ingeriti dai firewall per migliorare la protezione.

Analisi attiva

Nell’analisi attiva abbiamo utilizzato alcuni strumenti di web discovery , Nmap, dirbuster e WP WPScan Scan. In meno di due ore, il log di accesso di Apache ha riportato oltre 26.000 richieste.

Sarebbe possibile limitare il numero di connessioni utilizzando un firewall, ma un rate limit con iptables potrebbe portare a un DoS . I firewall aziendali o i WAF possono identificare gli scanner di rete e limitare il numero di connessioni per utente.

Per quanto riguarda WPScan, abbiamo notato che una semplice directory contenente un file README potrebbe essere segnalata come un plugin vulnerabile. Seguendo questo approccio, potremmo aggiungere numerosi plugin fittizi vulnerabili per confondere gli attaccanti e impedire loro di capire quali siano effettivamente installati.

Abbiamo inoltre deciso di ridurre il fingerprint di Apache con la seguente configurazione:

ServerSignature Off
ServerTokens Prod

Abbiamo installato anche WP fail2ban per rilevare gli attacchi brute-force al login di WordPress. Idealmente, questi log potrebbero essere ingeriti da un SIEM o da fail2ban .

Abbiamo discusso anche di come Apache dovrebbe gestire i virtual host di default. Sappiamo che gli strumenti di scansione di rete (Shodan, Censys, ZoomEye, ecc.) eseguono la scansione sugli indirizzi IP e non ancora sui domini. Se configuriamo il virtual host di default per restituire un HTTP 400 per tutte le richieste, riduciamo la quantità di informazioni facilmente accessibili a un attaccante.

Infine, da una prospettiva sia di performance che di sicurezza, dovremmo monitorare gli errori HTTP (40x, 50x) per rilevare anomalie. Un SIEM potrebbe eseguire questa operazione, ma anche una dashboard di performance può fornire indicazioni utili. Un sistema SOAR potrebbe aggiungere automaticamente gli indirizzi IP malevoli in un feed ingerito dal firewall.

Attacco Slowloris

Abbiamo discusso dell’attacco Slowloris, ma non lo abbiamo testato direttamente. In sostanza, un attacco Slowloris utilizza molte connessioni TCP stabilite con richieste HTTP incomplete. Anche con una connessione Internet lenta, un attaccante potrebbe mettere fuori servizio un web server potente. Questo attacco può essere mitigato da un WAF, ma può anche essere ridotto con la configurazione di Apache tramite il modulo reqtimeout:

RequestReadTimeout header=1,minrate=500
RequestReadTimeout body=1,minrate=500

La configurazione può essere validata con il seguente comando:

slowhttptest -c 400 -H -i 10 -r 200 -t GET -u http://Target_URL -x 24 -p 5

To Be Continued…

Riferimenti

• Attack and Defense: post-live del 21 settembre