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:

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:

Î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:

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.

Gaură de securitate în PHP-CGI

Se pare că PHP rulat peste CGI suferă de o serioasă gaură de securitate, vezi: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/http://threatpost.com/en_us/blogs/serious-remote-php-bug-accidentally-disclosed-050312 .

Dacă adaugi „?-s” ca parametru la un script php, cumva acesta transmite parametrul „-S” compilatorului, care în loc să mai compileze și ruleze scriptul afișează  codul sursă al acestuia.

Instanțele de PHP rulate peste FastCGI sau DSO nu sunt afectate de această vulnerabilitate.

Phishing la PayPal de pe domeniul spiceit.ro

Mailul este foarte bine simulat, folosind chiar imagini de pe saitul PayPal, și chiar un link în footer către PayPal.com. În schimb oferă un link către către un fqdn camuflat sub prefixul paypal.com, cu textul ”Relogin to your account now”.  Subdomeniul la care direcționează link-ul aparține de domeniul spiceit.ro.

Mail-ul arată așa:

Iar FQDN-ul despre care vorbeam: