Jurnalul de securitate – Pagina 2

Securitatea HTTPS, avem sau n-avem?

HTTPS este un protocol foarte cunoscut și totodată foarte utilizat. Traficul cu serverul este criptat, așa că se elimină posibilitatea unui atac man-in-the-middle. Până aici toate bune, practic cu o conexiune https putem fi siguri că parola noastră este ascunsă. Însă, și aici este un mare ”însă”, sesiunile și identificatorii lor sunt stocate ușor ”la vedere”, în cookie-uri. Adică folosind un script malițios și câteva șmecherii pentru a păcăli navigatorul un atacator le-ar putea extrage, și fără să știe datele de autentificare să obțină acces la contul utilizatorului, în care tocmai s-a autentificat.

Desigur ca să reușească atacul, inițiatorul trebuie să aibă câțiva ași în mânecă: să fie bine plasat în rețea pentru a putea ”asculta” cererile sau să aibă control asupra proxy-ului prin care trece traficul.

Prima dată s-a discutat de BEAST, care exploata o vulnerabilitate cunoscută a TLS, însă clasificată ca ”teoretică”. Acum discutăm de CRIME, care exploatează de data aceasta direct navigatorul utilizatorului. Și desigur dacă serverul urmărit are și el câteva scăpări deschide mai multe posibilități.

Ca utilizator, te poți proteja de aceste tentative prin folosirea unui navigator actualizat la zi (personal recomand Firefox sau Chrome) în modul privat sau incognito (CTRL+SHIFT+N – pe Chrome), prin conectarea la rețele de încredere (nb. evitați cele ”de cartier”), și desigur printr-un antivirus actualizat și ce are și module de scanare a traficului prin rețea. Nu știu cât protejează ultima opțiune dar în cazul în care vă conectați la o rețea ne-securizată, acesta din urmă ar trebui să fie primul care vă atenționează.

Istoria SPAM-ului (video)

Vulnerabilitate RCE în Java 1.7

Versiunea curenta a codului mașinii virtuale Java și pluginurilor browser suferă de o vulnerabilitate RCE (Remote Code Execution). Aceasta permite unui atacator de la distanță, printr-o pagină web special construită, să descarce și să execute un fișier executabil pe mașina victimei. Fișierul nu este necesar să fie o aplicația Java, poate să fie un EXE sau un BAT.

Cum metoda de intruziune este prin intermediul unei pagini web, cea mai bună metodă de a vă proteja este să dezactivați Java pe toate navigatoarele web pe care le folosiți. Cel puțin până pe la jumătatea lui octombrie, când se anunță un update la Java.

DeepEnd Research au propus o soluție intermediară în timp ce Rapid7 au testat deja cu succes un modul pentru Metasploit.

Nu sunt informații dacă această vulnerabilitate poate să afecteze și aplicațiile desktop care rulează Java, dar aplicațiile web sunt expuse.

Adobe avertizează asupra unor găuri de securitate în produsul Reader

Adobe a lansat azi un buletin de securitate în care avertizează asupra câtorva găuri serioase (citez ”critical”) de securitate în Adobe Reader. Anunțul poate fi găsit aici: http://www.adobe.com/support/security/bulletins/apsb12-16.html și deși nu dă detalii despre posibilele implicații, se pare că aceste vulnerabilități ar permite execuția de cod neautorizat pe computerele infectate.

Update-ul pentru ameliorarea problemelor a fost anunțat pentru data de 14 august a.c.
Așa că până pe 15, când veți putea face update, vă sfătuiesc să evitați să folosiți Adobe Reader versiunile 10.1.3 sau mai vechi.

Yours truly, security advisor.

Sfaturi pentru un web mai sigur (I)

Cred că ați observat de o vreme la mine pe blog că a apărut o categorie nouă – Jurnalul de securitate, unde postez mai ales avertizări și notificări de securitate.

Dar m-am gândit să postez și câteva sfaturi și șmecherii din experiența proprie pentru utilizatorii și dezvoltatorii de aplicații și saituri web. Așa că am început seria asta de articole, care sper să contribuie măcar cu cu 0, (mulți de 0) 1 la sută la un web mai sigur și mai bun.

Ahoi, MD5!

Care ar fi problemele cu MD5? Păi cei care fac aplicații pe web, știu probabil că e o funcție de hashing. Nu, nu e funcție de criptare cum zic unii, pentru că o funcție de criptare are o funcție complementară de decriptare, iar md5 nu poate fi decriptată. Tocmai de aceea este modalitatea preferată de multe aplicații web, și nu numai de a stoca parolele în baza de date.

Problema cu md5 e că e că e ”bătrân” . A fost inventat în 1991 și de atunci au început să se facă dicționare pentru el. Dicționarele sunt cuvinte și combinații de cuvinte gata trecute printr-un md5() pe care un hacker le poate folosi într-un brute force attack.

Acum 10 ani să execuți un astfel de atac cu câteva zeci de mii ce cuvinte, date fiind limitările în puterea de procesare ar fi durat câteva luni, dar în ziua de azi, cu tehnologiile disponibile (enumăr aici cloud computing, remote code execution) și puterea de procesare a calculatoarelor acelaș atac se poate executa în câteva ore. Și vă mai informez că dicționarele de azi au milioane de combinații. NB: limba română are aproximativ 180 de mii de cuvinte, deci probabilitatea ca un cuvânt să se găsească deja într-un dicționar de md5 e de 1000% sau mai mare.

Alte neajunsuri ale md5

Alte neajunsuri în materie de securitate ale md5 sunt coliziunile. Adică două combinații diferite de caractere au acelaș hash. Sunt destul de rare, însă pot ușura clonarea sesiunilor și mai departe controlul asupra unei mașini sau a unui cont de utilizator. Sau chiar un atac de tip DoS, care să țintească direct compilatorul, interpretorul sau mașina virtuală din spatele unei aplicații web.

Un MD5 mai bun

Cred că e clar că md5 direct pentru a cripta parolele nu mai e o alternativă fiabilă. Dar îl putem face mai eficace folosind câteva artificii ușor de aplicat:

MD5 la pătrat

Sau md5 aplicat de 2 ori, sau de 3 ori. Așa în loc de un singur md5, facem md5 la parolă de mai multe ori. În majoritatea cazurilor md5 se execută foarte rapid, așa că nu se va observa diferența:

    $password = md5(md5("parola"));
    //sau
    $password = md5(md5(md5("parola")));

$password = md5(md5("parola"));

//sau

$password = md5(md5(md5("parola")));

Acest mod nu evită însă și coliziunile.

MD5 cu o cheie

Alt mod de a îmbunătăți MD5 este folosind o cheie e specifică aplicației noastre. De ex:

    $cheie = "::CHKSALT::";
    //sau
    $password = ("parola" . $cheie);
    $password = md5($password);

$cheie = "::CHKSALT::";

//sau

$password = ("parola" . $cheie);

$password = md5($password);

În acest mod se evită și coliziunile, iar dacă cheia poate fi personalizată de utilizator, sau se generează automat la instalarea aplicației oferă și mai multă securitate.

Combinarea metodelor

Pentru și mai multă securitate putem combina metodele de mai sus, sau chiar adăuga generatoare de chei pornind de la parolă și cheia originală. Câteva exemple de funcții, în Python:

    def rot_md(string, key):
        '''
        Rotește stringul, și apoi o aplică md5-ul cheii
        '''

        rot = string[::-1]
        kex= md5(key);
    
        final = rot + ":" + kex;
    
        return md5(final)


    def v12_md(string, key):
        '''
        Creează 12 combinații din stringul inițial folosind md5-ul cheii la care le aplică apoi individual câte un md5
        '''

        kex     = md5(key);
        final   = ""
    
        e = [string+kex[2], string+kex[4], string+kex[6], string+kex[8], string+kex[10], string+kex[12], string+kex[14], string+kex[16], string+kex[18], string+kex[20], string+kex[22], string+kex[24]]

        for s in e:
            final+= md5(s)
    
        return md5(final)

def rot_md(string, key):

'''

Rotește stringul, și apoi o aplică md5-ul cheii

'''

rot = string[::-1]

kex= md5(key);

final = rot + ":" + kex;

return md5(final)

def v12_md(string, key):

'''

Creează 12 combinații din stringul inițial folosind md5-ul cheii la care le aplică apoi individual câte un md5

'''

kex = md5(key);

final = ""

e = [string+kex[2], string+kex[4], string+kex[6], string+kex[8], string+kex[10], string+kex[12], string+kex[14], string+kex[16], string+kex[18], string+kex[20], string+kex[22], string+kex[24]]

for s in e:

final+= md5(s)

return md5(final)

Un md5 și mai bun

O soluție și mai bună de criptare a parolelor este renunțarea la md5, și folosirea unui algoritm cu mai puține vulnerabilități: SHA-256, SHA-512, RIPEMD, HAVAL, GOST, bcrypt sau PBKDF2.

PHP de la versiunea 5 încoace oferă cu funcția hash() o varietate mare de algoritme.

O idee pentru o criptare mai puternică este să utilizam un algoritm aleatoriu pentru criptarea parolei, la care îi putem asocia un nume intern specific aplicației noastre, stocat și în baza de date. Folosind combinații de chei sau funcții mai avansate personalizate per-aplicație putem asigura un nivel foarte înalt de securizare a parolelor.

Concluzie, cu gândul la viitor

Încă nu s-a inventat un algoritm 100% sigur care să nu poată fi spart printr-o metodă sau alta. Dar prima regulă de securitate este să-ți sfătuiești utilizatorii cum să-și protejeze datele. Mai ales să-i îndemni să-și schimbe parolele măcar o dată pe an.