Mi-am petrecut sfârșitul de săptămână încercând să “deparazitez” niște servere. Cei care lucrează în domeniu au auzit, desigur de această vulnerabilitate . Pentru ceilalți, pe scurt, este vorba de un bug descoperit într-o aplicație CMS ( aplicații folosite ca platformă, sau bază, pentru site-uri de web) care permite unui atacator să execute cod pe serverul respectiv fără a avea nevoie de vreun cont sau alt fel de drepturi de acces.
Genul acesta de probleme sunt mai degrabă comune și afectează periodic cam toate CMS-urile majore de pe piață. Teoretic lucrurile sunt simple: cum sunt abonat la diverse liste de discuții și buletine de securitate, aflu de problemă suficient de repede pentru a putea acționa, în afară de cazul nefericit în care există deja un exploit “pe piață” înainte ca problema să fie descoperită de “băieții buni”.
Ca să fiu suficient de clar pentru cititorii care nu au prea multă tangență cu domeniul, lucrurile stau cam așa: cineva descoperă o vulnerabilitate. Dacă este dintre “băieții buni”, trimite un mail la producătorul softului; acesta rezolvă problema, emite un patch ( un fel de corectură) pe care îl face public. Dacă este de cealaltă parte, probabil va ataca un site sau mai multe; una dintre victime va descoperi problema, va scrie producătorului softului și în continuare se continuă ciclul.
Este de așteptat ca în câteva zile să apară “de partea gri a Internetului” diverse “exploit-uri”, adică programe mai mult sau mai puțin automate care vor ataca nu unul sau două, ci sute, mii de site-uri. Ele sunt suficient de simple pentru a putea fi folosite de puștii descriși în articolul meu mai vechi.
Este deci o diferență între atacurile anterioare descoperirii bug-ului sau imediat următoare descoperirii acestuia, care de obicei sunt realizate de profesioniști și probabil vor viza un număr mic de mașini, pentru a nu trezi suspiciuni, și cele de mai târziu. Între timp administratorul ar fi trebuit să aibă destul timp să updateze produsul, deci în afară de cazul în care ai ghinionul să fii pe “lista scurtă” a unui hacker profesionist, lucrurile sunt destul de simple.
Asta însă doar în teorie. Răspândirea CMS-urilor a făcut ca realizarea site-urilor web să devină o operație mai mult sau mai puțin de rutină, unde latura tehnică este minimală, primând aspectele de design, marketing etc. Clientul apelează la o firmă, aceasta îi produce site-ul dorit, el este hostat undeva… și aici ciclul se încheie. Beneficiarul consideră că a plătit pentru produs, sarcina lui s-a încheiat. Prestatorul de asemeni și-a făcut treaba, a închis contractul, nu mai are responsabilități. Ar mai rămâne administratorul serverului de hosting, dar pe acest server sunt probabil zeci de site-uri, fiecare cu tehnologia lui. Mai rău încă, în domeniul ăsta nu ai nici o garanție că dacă faci un update la CMS, mai ales dacă e foarte vechi, site-ul va mai funcționa ca înainte. Ori unele site-uri rămân neschimbate ani de zile, timp în care multe din componentele pe care le folosesc se modifică. Deci chiar dacă ai considera că update-ul e în sarcina administratorului, acesta își va asuma un risc cu efecte (comercial vorbind) necontrolabile.
Intrăm deci într-o zonă unde, vorba politicienilor, există un fel de vid legislativ. Practic CMS-urile au devenit un fel de “al optulea layer” (referindu-mă la celebrul model ISO) între nivelul aplicație și utilizator. În această zonă toată lumea și nimeni precis avem responsabilități. Nu este un nivel care ține doar de tehnologie; sunt implicate constrângeri bugetare, legale ( cum aș putea face eu ca hoster modificări în site-ul clientului? ) și tehnice. La acest al optulea layer lucrează împreună designeri, “creativi”, finanțiști, programatori și administratori de sistem. Iar accentul se deplasează cu încetul spre primele categorii enumerate, pe măsură ce produsele devin mai ușor de folosit și mai complexe, transformându-se într-un fel de “cutie neagră”. Nu vreau să spun că este rău, mi se pare că e un proces firesc, în definitiv la final ar trebui să îi spunem serverului ce să afișeze iar el va afișa. Cel puțin așa e în Star Track.
Problema e că noi traim în zilele noastre, în care cutiile negre mai au nevoie uneori de câte o revizie, și asta ne ocupă tot timpul.
Aikido cu mintea si corpul coordonate. Invatati cum sa va relaxati si cum sa va pastrati calmul in conditii de stress. 
Lucrurile nu stau chiar atat de rau cu cutiile astea negre. Cum fiecare nu e decat o „impachetare” dedicata construita intr-un limbaj cunoscut (pentru mine e valabil orice CMS bazat pe PHP/MySQL), vulerabilitatile nu pot fi altele decat cele ale limbajelor de baza, ori ele sunt cunoscute si exista destule mecanisme de protectie. Ceea ce presupune, insa, ca echipa care implementeaza un site folosind un CMS sa cunoasca foarte bine aceste limbaje si testeze aceste vulnerabilitati, urmand ca, la nevoie, sa modifice sau sa adauge eventualele coduri de protectie. E un proces migalos, uneori, dar perfect posibil si in lipsa unui patch de protectie oferit de dezvoltatorul CMS-ului.
Problema nu e ca nu știm care sunt problemele. Problema e ca nu e clar cine sa o rezolve (și deci sa iși asume riscurile și costurile) iar copilul cu multe moașe știți ce pățește.
Ar mai fi și aspectul financiar al problemei. Sunt nenumărate site-uri mici pentru care abonarea la un serviciu de mentenanță specializat este foarte costisitor. Și atunci se merge pe ideea: doar nu o să fiu eu atât de ghinionist. Și oare câți dintre deținătorii de site-uri din România știu exact ce implică service-ul pentru ele?