Il blog sull'informatica

Stamattina, come ogni lunedì, ho ricevuto via email i report relativi alla scansione rootkit eseguita sui miei server mediante chkrookit.

Una di queste email riportava la seguente entry:

Checking `lkm'... You have 2 process hidden for readdir command

You have 2 process hidden for ps command

chkproc: Warning: Possible LKM Trojan installed

Avranno bucato la macchina oppure si tratta di un falso positivo?

Mi accingo dunque ad effettuare ulteriori controlli, tra cui una nuova scansione mediante un altro tool per l'individuazione dei rootkit, ovvero rkhunter:

nightfly@nightbox:/var/log$ sudo rkhunter -c

Inutile dire che tale scansione ha avuto esito negativo. Indi per cui sono quasi certo che si tratta di un falso positivo. La conferma arriva da una nuova scansione eseguita con chkrootkit, che non ha segnalato nessuna anomalia.

Sono sicuro che quel falso positivo presente nel report fosse dovuto ad un restart di qualche processo avvenuto proprio durante la scansione schedulata.

Morale della favola: prima di pensare al peggio assicuratevi che la macchina sia stata effettivamente bucata.

A presto.

Recentemente ho avuto la necessità di creare due action diverse per un unico form, le quali puntano rispettivamente a 2 iframe separati (in cui visualizzare i risultati di una query eseguita mediante PHP/SQL).

Per fare una cosa di questo tipo è stato necessario utilizzare due pulsanti di submit, ad ognuno dei quali, mediante javascript, è stata assegnata una action ed un target specifico.

Ma bando alle ciance ed ecco il codice:

<form name="filtro" id="filtro" method="post">

<strong>da:</strong><input class="bordotar" type="text" name="datain" tabindex="1" id="datain"/>

<strong>a:</strong> <input class="bordotar" type="text" name="datafin" tabindex="2" id="datafin"/>

<p align="center"><input type="submit" name="filtra" id="filtra" value="Filtra i ricavi" onclick="javascript:filtro.action='ris_ricavi.php'; filtro.target='frame1'" tabindex="3" /></p>

<p align="center"><input type="submit" name="filtra" id="filtra" value="Filtra i costi" onclick="javascript:filtro.action='ris_costi.php'; filtro.target='frame2'" tabindex="4" /></p>

<iframe name="frame1" id="frame1" src ="ris_ricavi.php" align="middle" width="750" height="300">

<iframe name="frame2" id="frame2" src ="ris_costi.php" align="middle" width="750" height="300">

</form>

Per qualunque chiarimento contattatemi.

A presto.

Recentemente ho dovuto modificare parzialmente uno dei CRM che ho sviluppato. Non volendo inficiare il DB in produzione ho dovuto "clonarlo", in modo da poter fare i miei esperimenti in assoluta libertà.

Poichè volevo essere sicuro che ciascuna pagina utilizzasse effettivamente il database "clone" (avendo a disposizione un solo server), ho implementato un controllo in PHP che mi restituisse il nome del DB in uso all'apertura della pagina.

Ecco lo script:

$db = $mysqli -> query("SELECT DATABASE()");

while($riga1 = $db -> fetch_assoc())
{
    echo $riga1["DATABASE()"];
}

La chiave di lettura delle righe di codice sopra riportate sta proprio nella funzione DATABASE() di MySQL, la quale consente di individuare il nome del DB in uso.

Da riga di comando avremo una situazione simile alla seguente:

mysql> SELECT DATABASE();
+------------+
| DATABASE() |
+------------+
| prova        |
+------------+
1 row in set (0.00 sec)

mysql>

Il post termina qui, a presto.

In questo post ho spiegato come effettuare un tuning minimale dei preprocessori di cui si avvale snort 2.9.0.5. Ora, invece, vedremo come disabilitare tutte quelle regole che potrebbero generare dei falsi positivi.

Per prima cosa posizioniamoci nella directory /etc/snort/rules:

nightfly@nightbox:~$ cd /etc/snort/rules

Lanciamo un ls per visualizzare il contenuto della dir:

nightfly@nightbox:/etc/snort/rules$ ls

il cui outuput sarà simile al seguente:

attack-responses.rules  misc.rules           snmp.rules
backdoor.rules          multimedia.rules     specific-threats.rules
bad-traffic.rules       mysql.rules          spyware-put.rules
blacklist.rules         netbios.rules        sql.rules

ecc.

Come è facile intuire, esiste un file *.rules per ogni possibile minaccia, dove ciascun file contiene tutta una serie di regole che identificano i tentativi di attacco. Ad esempio, analizzando il file attack-responses.rules, noteremo delle entry del tipo:

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory listing"; flow:established; content:"Volume Serial Number"; classtype:bad-unknown; sid:1292; rev:9;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command completed"; flow:established; content:"Command completed"; nocase; metadata:policy balanced-ips drop, policy security-ips drop, service http; reference:bugtraq,1806; classtype:bad-unknown; sid:494; rev:13;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command error"; flow:established; content:"Bad command or filename"; nocase; classtype:bad-unknown; sid:495; rev:10;)

E' possibile disabilitare una qualunque entry semplicemente commentandola (ovvero inserendo un # ad inizio riga). Però, per evitare che tale entry ritorni attiva dopo l'aggiornamento delle regole mediante oinkmaster, dobbiamo operare direttamente sul file /etc/oinkmaster.conf:

nightfly@nightbox:/etc/snort/rules$ sudo nano /etc/oinkmaster.conf

aggiungendo la direttiva disablesid seguita dal sid dell'alert che ci interessa (ad esempio 1292 per ATTACK-RESPONSES directory listing):

disablesid 1292

Salviamo il file, riavviamo snort con un sudo service snort restart ed abbiamo finito.

A presto.

In questo post abbiamo visto come aggiornare snort alla versione 2.0.9.5 su piattaforma *buntu. Adesso vedremo come effettuare del tuning minimale per evitare tutta una serie di falsi positivi (base rate fallacy), che possono distogliere la nostra attenzione dalle reali minacce.

Personalmente credo che sui sistemi che vengono utilizzati per la semplice navigazione Web (o che fungono da GW verso la rete esterna) e su cui è presente un qualunque applicativo p2p occorre disabilitare le seguenti regole, inserendo le seguenti direttive nel file /etc/snort/threshold.conf:

suppress gen_id 119, sig_id 2
suppress gen_id 129, sig_id 12
suppress gen_id 129, sig_id 19
suppress gen_id 119, sig_id 15
suppress gen_id 120, sig_id 3
suppress gen_id 129, sig_id 14
suppress gen_id 129, sig_id 15
suppress gen_id 129, sig_id 5
suppress gen_id 129, sig_id 4

Tutte le regole riportate in precedenza sono identificate mediante un gen_id ed un sig_id, dove per gen_id si intende l'ID del preprocessore, mentre per sig_id si intende l'alert generato dal preprocessore coinvolto. Per avere un'idea più chiara di cosa sto parlando basta aprire in lettura il file /etc/snort/gen-msg.map. Così facendo potremo notare come al gen_id 119 ed al sig_id 2 corrisponde l'alert http_inspect: DOUBLE DECODING ATTACK, al gen_id 129 ed al sig_id 12 corrisponde l'alert stream5: TCP Small Segment Threshold Exceeded, e così via.

Nello specifico, ecco come appariranno le entry del file gen-msg.map:

126 || 2 || telnet_pp: Telnet data encrypted
126 || 3 || telnet_pp: Subnegotiation Begin without matching Subnegotiation End
128 || 1 || ssh: Gobbles exploit
128 || 2 || ssh: SSH1 CRC32 exploit
128 || 3 || ssh: Server version string overflow
128 || 4 || ssh: Protocol mismatch
128 || 5 || ssh: Bad message direction
128 || 6 || ssh: Payload size incorrect for the given payload
128 || 7 || ssh: Failed to detect SSH version string

ecc.

Riavviate snort per rendere effettive tali modifiche:

nightfly@nightbox:~$ sudo service snort restart

ed il gioco è fatto.

A presto.

L'installazione di snort 2.9.0.5 su *buntu non è affatto banale. Infatti, occorre installare delle specifiche librerie e degli specifici strumenti per poter compilare il codice sorgente dell'IDS in questione.

Per prima cosa scarichiamo la tarball mediante CLI usando wget:

nightfly@nightbox:~$ wget -O snort-2.9.0.5.tar.gz http://www.snort.org/downloads/867

Scompattiamola e posizioniamoci nella dir appena creata:

nightfly@nightbox:~$ tar -xzvf snort-2.9.0.5.tar.gz
nightfly@nightbox:~$ cd snort-2.9.0.5/

Stoppiamo la versione obsoleta di snort presente sulla nostra macchina:

nightfly@nightbox:~$ sudo service snort stop

Installiamo adesso alcune librerie necessarie per la compilazione di snort:

nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libpcap0.8-dev
nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libpcre3 libpcre3-dev
nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libdumbnet-dev libdnet libdnet-dev

Creiamo quindi un link simbolico all'header dumbnet.h poichè il file configure di snort va alla ricerca del file dnet.h:

nightfly@nightbox:~/snort-2.9.0.5/$ sudo ln -s /usr/include/dumbnet.h /usr/include/dnet.h

Installiamo l'ultima libreria che ci occorre, ovvero daq-0.5, disponibile direttamente sul sito www.snort.org:

nightfly@nightbox:~/snort-2.9.0.5/$ wget -O daq-0.5.tar.gz http://www.snort.org/downloads/860

nightfly@nightbox:~/snort-2.9.0.5/$ tar -xzvf daq-0.5.tar.gz
nightfly@nightbox:~/snort-2.9.0.5/$ cd daq-0.5/

Per compilare questa libreria è necessario utilizzare l'accoppiata flex/bison. Dunque procediamo con la loro installazione:

nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo apt-get install flex bison

Possiamo ora compilare la libreria daq-0.5:

nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ ./configure
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo make
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo make install
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ cd ..

Adesso passiamo alla compilazione di snort e successivamente sostituiamo il file di configurazione delle versioni precedenti con quello della release in questione:

nightfly@nightbox:~/snort-2.9.0.5$ sudo make
nightfly@nightbox:~/snort-2.9.0.5$ sudo make install
nightfly@nightbox:~/snort-2.9.0.5$ cd etc
nightfly@nightbox:~/snort-2.9.0.5/etc$ sudo cp snort.conf /etc/snort

Posizioniamoci nella dir /etc/snort ed apriamo il file snort.conf in scrittura:

nightfly@nightbox:~/snort-2.9.0.5/etc$ cd /etc/snort
nightfly@nightbox:/etc/snort$ sudo nano snort.conf

ed effettuiamo le seguenti sostituzioni:

1) ipvar con var (poichè non abbiamo compilato snort con la flag --enable-ipv6)

2) var RULE_PATH ../rules
     var SO_RULE_PATH ../so_rules
     var PREPROC_RULE_PATH ../preproc_rules

     con

     var RULE_PATH /rules
     var SO_RULE_PATH /so_rules
     var PREPROC_RULE_PATH /preproc_rules

3) Commentiamo le seguenti direttive:

    #dynamicdetection directory /usr/local/lib/snort_dynamicrules
    #include $RULE_PATH/local.rules
    #inspect_gzip
    #unlimited_decompress
    #preprocessor normalize_ip4
    #preprocessor normalize_tcp: ips ecn stream
    #preprocessor normalize_icmp4
    #preprocessor normalize_ip6
    #preprocessor normalize_icmp6

4) Rimuoviamo le direttive:

     compress_depth 65535 decompress_depth 65535
  

Ora occorre eliminare tutte le vecchie rules di snort ed installare quelle nuove. Per fare ciò digitiamo i seguenti comandi:

nightfly@nightbox:/etc/snort$ cd rules
nightfly@nightbox:/etc/snort/rules$ sudo rm *

Successivamente installiamo le nuove regole mediante oinkmaster, configurandolo opportunamente affinchè possa scaricare le rules della versione 2.0.9.5:

nightfly@nightbox:/etc/snort/rules$ sudo nano /etc/oinkmaster.conf

ed inseriamo la stringa:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/<vostro oinkcode>/snortrules-snapshot-2905.tar.gz

Adesso possiamo procedere con l'installazione vera e propria delle regole:

nightfly@nightbox:/etc/snort/rules$ sudo oinkmaster -o /etc/snort/rules

Ad installazione completata, prima di lanciare snort, modifichiamo il file /etc/ld.so.conf aggiungendo la direttiva:

include /usr/local/lib

Infine, rendiamo effettiva tale modifica lanciando il comando:

nightfly@nightbox:/etc/snort/rules$ sudo ldconfig

A questo punto lanciamo uno snort -V il cui output dovrebbe essere:

 ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.0.5 (Build 135)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
           Copyright (C) 1998-2011 Sourcefire, Inc., et al.
           Using libpcap version 1.0.0
           Using PCRE version: 7.8 2008-09-05

Copiamo l'eseguibile presente in /usr/local/bin/snort all'interno della dir /usr/sbin/snort:

nightfly@nightbox:/etc/snort/rules$ sudo cp /usr/sbin/snort /usr/local/bin/snort

Verifichiamo che la configurazione di snort non contenga errori digitando:

nightfly@nightbox:/etc/snort/rules$ sudo snort -T -c /etc/snort/snort.conf

Se l'output visualizzato è il seguente:

Snort successfully validated the configuration!

allora possiamo lanciare un sudo service snort start ed iniziare ad avvalerci di questo potentissimo IDS.

A presto.

Circa un mese fa è stata individuata una backdoor all'interno del sorgente di vsftpd, famoso demone FTP server.

Questa backdoor consente l'accesso alla shell semplicemente digitando come username "X:)", lasciando il campo password vuoto (maggiori dettagli sulla tarball compromessa li trovate qui).

Avendo aggiornato vsftp alla versione 2.3.4 poco dopo il suo rilascio (orientativamente durante gli ultimi giorni di giugno), ho voluto verificare che il demone installato sui miei server non fosse infetto.

Ho quindi cercato qualche tool che mi permettesse di effettuare tale controllo, trovando uno script per nmap che fa proprio al caso mio.

Lo script in questione lo potete scaricare da qui. Una volta scaricato, modificatelo ed aggiungete una description, ad esempio:

description = "check vsftpd 2.3.4 backdoor vulnerability"

da inserire subito dopo categories.

Ora assicuratevi che all'interno della directory /usr/share/nmap/nselib/ sia presente la libreria ftp.lua (in caso contrario potete scaricarla da qui).

Infine, lanciate lo script seguendo la sintassi:

nmap --script ftp-vsftpd-backdoor -p 21 <host>

Se l'output di tale script sarà simile al seguente:

PORT   STATE SERVICE
21/tcp open  ftp
| ftp-vsftpd-backdoor:
|   This installation has been backdoored (CVE-2011-2523): VULNERABLE
|     Shell command: id
|_    Results: uid=0(root) gid=0(root) groups=0(root)

dovrete correre ai ripari sostituendo la versione "bucata" di vsftpd con quella corretta (che potete scaricare da qui).

A presto.

PS: ho avuto fortuna, in quanto nessuno dei demoni vsftpd presenti sui miei server conteneva backdoor.

In questo post vi ho parlato del lamer che si ostinava a bombardare i miei server sulla porta SSH standard. Essendo che la maggior parte degli attacchi proveniva da IP appartenenti a KoreaNET, ho deciso di impostare delle opportune ACL direttamente sul router.

Il tizio, però, accortosi di quanto accaduto, ha cominciato ad utilizzare altre shell su provider diversi, soprattutto africani. Poichè non ho intenzione di blacklistare tutto il mondo, ho pensato di correre ai ripari in modo diverso.

Per prima cosa, analizzando il fail auth.log ho notato che tutti i tentativi di accesso venivano effettuati utilizzando come username root:

Jul 31 11:31:20 nightbox sshd[26506]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.132.225.70  user=root

Jul 31 11:31:22 nightbox sshd[26508]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=14.45.203.1  user=root

Jul 31 11:31:22 nightbox sshd[26511]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=41.236.232.32  user=root

Ho quindi disabilitato l'accesso root, agendo direttamente sul file sshd_config presente in /etc/ssh:

PermitRootLogin no

Adesso potrà provare tutti i dizionari che vuole, ma ogni tentativo di login come root gli risponderà picche.

Inoltre, poichè mi secca ricevere miliardi di mail da fail2ban perchè questo tizio ha deciso che il suo nuovo hobby è bombardare i range di IP italiani (tra cui quelli dei miei server) ho messo in ascolto il servizio SSH su una porta non standard (compresa tra 1024 e 65535). Non credo sia tanto skillato da fare un nmap per individuare la nuova porta su cui SSH è in listening.

Vi terrò comunque aggiornati sugli ulteriori sviluppi.

A presto.

Da circa una settimana fail2ban mi segnala tutta una serie di attacchi bruteforce diretti al servizio SSH in ascolto sui miei server. Questi attacchi si verificano sempre agli stessi orari, ovvero verso le 11 di mattina e verso le 23 di sera. Inoltre, provengono da diversi indirizzi IP, soprattutto coreani, il che mi fa sospettare che vengano pilotati da uno dei tanti lamer di turno in possesso di una piccola botnet composta da zombie.

Facendo un nmap su 3 dei PC da cui proviene l'attacco, ho notato la presenza della porta 20000 TCP aperta, la quale accetta connessioni SSH in ingresso mediante scambio delle chiavi. Ecco come il lamerozzo pilota la sua botnet...

Interesting ports on 222.117.21.18:
Not shown: 992 closed ports
PORT      STATE    SERVICE
111/tcp   open     rpcbind
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
1234/tcp  open     hotline
2869/tcp  filtered unknown
4444/tcp  filtered krb524
20000/tcp open     unknown

Ma come fare per contrastare questi attacchi? Semplice, basta impostare delle opportune ACL deirettamente sul router (sempre che il vostro router sia Cisco).

Nella fattispecie, ecco l'ACL che sto utilizzando:

access-list 101 deny ip host 127.0.0.1 any log
access-list 101 deny ip host 255.255.255.255 any log
access-list 101 deny ip 10.0.0.0 0.255.255.255 any log
access-list 101 deny ip 172.16.0.0 0.15.255.255 any log
access-list 101 deny ip 224.0.0.0 15.255.255.255 any log
access-list 101 permit icmp any any echo-reply
access-list 101 deny icmp any any
access-list 101 deny ip 121.128.0.0 0.31.255.255 any log
access-list 101 deny ip 121.160.0.0 0.31.255.255 any log
access-list 101 deny ip 118.32.0.0 0.31.255.255 any log
access-list 101 deny ip 59.0.0.0 0.31.255.255 any log
access-list 101 deny ip 61.76.0.0 0.3.255.255 any log
access-list 101 deny ip 119.192.0.0 0.31.255.255 any log
access-list 101 deny ip 61.72.0.0 0.3.255.255 any log
access-list 101 deny ip 221.144.0.0 0.15.255.255 any log
access-list 101 deny ip 222.96.0.0 0.15.255.255 any log
access-list 101 deny ip 115.0.0.0 0.15.255.255 any log
access-list 101 deny ip 220.92.0.0 0.3.255.255 any log
access-list 101 deny ip 221.163.0.0 0.15.255.255 any log
access-list 101 deny ip 220.116.0.0 0.15.255.255 any log 
access-list 101 deny ip 112.160.0.0 0.31.255.255 any log
access-list 101 deny ip 175.192.0.0 0.63.255.255 any log
access-list 101 permit ip any any

Per lo più si tratta di blocchi di indirizzi /11, /12, /13 e /14. E' stato facile per me individuare la wildcard da utilizzare nelle regole dell'ACL poichè fail2ban fornisce il CIDR degli indirizzi, riportandolo nelle mail di notifica:

# ENGLISH

KRNIC is not an ISP but a National Internet Registry similar to APNIC.

[ Network Information ]

IPv4 Address : 115.0.0.0 - 115.23.255.255 (/12+/13)

Service Name : KORNET

Organization Name : Korea Telecom

Organization ID : ORG1600

Address : 206, Jungja-dong, Bundang-gu, Sungnam-ci

Zip Code : 463-711

Registration Date : 20080703

ecc.

Adesso il lamer potrà sfruttare PC connessi ad altri provider, ma non quelli di KORNET.

A presto.

Poco tempo fa un cliente mi ha chiesto di aggiungere all'interno della sua homepage l'addon like-box di Facebook. Purtroppo però, tale addon non è validato W3C per XHTML 1.0 (sia Strict che Transational), quindi ho dovuto fare un giro sul Web per cercare qualche soluzione alternativa.

Ed ecco il risultato della mia ricerca:

<script type="text/javascript">
//<![CDATA[
(function() {
    document.write('<fb:like-box href="http://www.facebook.com/pages/Rooms-2-Rent-Bed-Breakfast-Relax/183795715015987" width="200" height="100" show_faces="false" border_color="" stream="false" header="true"></fb:like-box>');
    var s = document.createElement('SCRIPT'), s1 = document.getElementsByTagName('SCRIPT')[0];
    s.type = 'text/javascript';
    s.async = true;
    s.src = 'http://connect.facebook.net/en_US/all.js#xfbml=1';
    s1.parentNode.insertBefore(s, s1);
})();
//]]>
</script>

Grazie a questo script è possibile aggirare la validazione W3C poichè non si tratta di codice XHTML. Il suo funzionamento è abbastanza semplice: viene creato un elemento, il cui nome è SCRIPT, nel quale viene inserito il tag <fb:like-box> con i relativi attributi.

Spero di esservi stato utile.

A presto.