Il blog sull'informatica

Qualche tempo fa, mentre provavo ad abilitare l'SSH sul mio PIX 501, ho cercato di visualizzare il fingerprint che viene generato dopo aver creato la coppia di chiavi RSA pubblica/privata.

Con mio enorme stupore, dopo una breve ricerca su Internet e diversi tentativi da console, ho constatato che tale fingerprint non è visualizzabile direttamente dalla CLI del PIX.

L'unico comando presente da linea di comando è il seguente:

NightFirewall# sh ca mypubkey rsa

che consente di visualizzare la chiave pubblica usata dal firewall in questione, ma non il suo fingerprint.

Inoltre, dando un'occhiata al file .ssh/known_host presente nella mia home, ho notato che il fingerprint salvato è diverso da quelli associati agli host SSHv2. Questo a mio avviso è imputabile a due fattori:

1) L'uso di RSA1 anzichè RSA2 per la generazione del fingerprint stesso;

2) La versione del protocollo SSH utilizzata dal firewall (ovvero la 1.5).

Un modo per visualizzare il fingerprint del PIX 501 però esiste, e si basa su nmap:

nightfly@nightbox:~$ sudo nmap -sS -A <IP PIX 501>

Starting Nmap 5.00 ( http://nmap.org ) at 2011-09-05 20:30 CEST
Interesting ports on *.*.*.*:
Not shown: 998 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      Cisco SSH 1.25 (protocol 1.5)
|_ ssh-hostkey: 1024 **:**:**:**:6f:62:05:dd:a6:3b:43:1f:**:**:**:** (RSA1)

Mistero svelato.

PS: i lameri che volessero fare dei tentativi di exploit verso la mia macchina (poichè l'SSH 1.5 è palesemente vulnerabile), sappiano che tale servizio non è pubblicato all'esterno ed accetta connessioni solo da determinati host della rete interna. Ergo abbandonate qualunque idea bellicosa.

A presto.

Qualche giorno fa sono rientrato dalle mie meritate ferie (che poi tanto ferie non erano) e mi sono ritrovato con uno un reverse proxy dell'ambiente di test spento.

Ho chiesto ai miei colleghi il perchè di questa cosa e mi è stato detto che proprio su quel proxy era stata pubblicata la porta 25 (SMTP) ed avevano paura che fosse stato ownato. Non chiedetemi per quale motivo è stato fatto questo accrocchio, ma qui i problemi erano altri, ovvero:

1) Essendo il reverse proxy basato su una distro che non viene aggiornata da illo tempore, c'era un'ampia probabilità (diventata certezza dopo ulteriore analisi) che il demone SMTP fosse bacato;

2) La porta 25 è stata lasciata in forwarding per circa una settimana, il che ha aumentato in modo esponenziale il rischio che la macchina venisse ownata da qualche lamer di turno.

Armato dunque di molta pazienza riaccendo la macchina ed effettuo una prima scansione con chkrootkit, che però non segnala nulla di anomalo. Non contento installo anche rkhunter (il cui rpm lo potete scaricare da qui), il quale, alla fine dell'analisi, mi riporta il seguente sommario all'interno del file di log:

[10:10:09] System checks summary
[10:10:09] =====================
[10:10:09]
[10:10:09] File properties checks...
[10:10:09] Required commands check failed
[10:10:09] Files checked: 141
[10:10:09] Suspect files: 6
[10:10:09]
[10:10:09] Rootkit checks...
[10:10:09] Rootkits checked : 253
[10:10:10] Possible rootkits: 1
[10:10:10] Rootkit names    : Xzibit Rootkit
[10:10:10]
[10:10:10] Applications checks...
[10:10:10] Applications checked: 7
[10:10:10] Suspect applications: 4
[10:10:10]
[10:10:10] The system checks took: 13 minutes and 25 seconds
[10:10:10]
[10:10:10] Info: End date is Wed Aug 31 10:10:10 CEST 2011

Uhm, possibile che sia stato installato il rootkit Xzibit? Spulcio ulteriormente il log, alla ricerca del file che ha fatto scattare l'allarme. Il risultato è il seguente:

Found string 'hdparm' in file '/etc/rc.d/init.d/vmware-tools'. Possible rootkit: Xzibit Rootkit

Ebbene, rkhunter ha interpretato come "sospetta" la stringa hdparm presente nei wmware-tools. Ma essendo una macchina virtuale è palese che si tratta di un falso positivo.

Dunque se la vostra macchina è virtuale e ci avete installato i wmware-tools è molto probabile che rkhunter generi questo allarme.

Stay tuned.

PS: per la cronaca, il reverse proxy è ok (o almeno così sembra).

Ormai è risaputo di quanto siano sicure alcune distribuzioni *nix, tra cui la celeberrima FreeBSD (un solo exploit da remoto in 10 anni). Eppure vi sono tante altre distribuzioni che non fanno della sicurezza il loro obiettivo primario. Tra queste vi è certamente DVL (Damn Vulnerable Linux - un nome una garanzia), appositamente forgiata per presentare numerosissime falle di sicurezza ed aiutare gli aspiranti "security consultant" durante la loro formazione. Effettivamente l'idea non è male, in quanto tale distribuzione potrebbe anche essere utilizzata come passatempo, per "testare" l'effetto dei vari exploit sui bug presenti.

Ovviamente trattasi di bug arcinoti e piuttosto datati, per cui le ultime versioni dei software dovrebbero esserne immuni (almeno spero). Comunque, bando alle ciance ed enjoy: http://www.damnvulnerablelinux.org/