Cum reactionezi atunci cand cineva iti raporteaza o vulnerabilitate?

In securitatea informatiei, o vulnerabilitate este o slabiciune ce permite unui atacator sa reduca asigurarea informatiei. Vulnerabilitatea este intersectia a trei elemente: susceptibilitatea unui sistem sau defectul, accesul atacatorului la defect si capacitatea atacatorului de a exploata defectul.

Conform CERT, Identificarea si adresarea prompta a vulnerabilitatilor a devenit extrem de importanta in societatea digitala actuala in care concurenta si avansul tehnologic rapid reduc timpul alocat testarii, sub presiunea lansarii de noi produse si servicii pe piata, iar complexitatea produselor face imposibila testarea exhaustiva, indiferent de resursele alocate.

Exploatarea de catre entitati rau-intentionate a vulnerabilitatilor are consecinte negative importante pe plan economic si social, putând insemna pentru companii, compromiterea afacerii, pierderi financiare si chiar faliment, pentru institutii imposibilitatea indeplinirii misiunii, compromiterea activitatii si datelor cetatenilor iar pentru utilizatori si cetateni pierderea increderii in serviciile digitale si in capacitatea statului de a-i ajuta si proteja.

Divulgarea coordonata si responsabila a vulnerabilitatilor este forma de cooperare dintre detinatorii sau producatorii de servicii, sisteme si programe informatice si raportorii de vulnerabilitati (terte persoane care identifica si/sau raporteaza vulnerabilitati ale serviciilor, programelor si sistemelor informatice) prin care cele doua parti se coordoneaza in remedierea vulnerabilitatilor, inainte de divulgarea publica a informatiilor care ar permite comunitatii largi de utilizatori, producatori si cercetatori in securitate informatica sa adopte masurile necesare eliminarii riscurilor de securitate.

In absenta unui cadru juridic dedicat,  metodele concrete utilizate pentru cooperare se bazeaza pe stabilirea unei relatii de incredere intre webmasteri si raportori. In stabilirea relatiei de incredere pot contribui si terte parti (neutre) in vederea sprijinirii derularii in bune conditii a procesului de divulgare a vulnerabilitatilor identificate, cum poate fi CERT. Totusi, daca incerci sa contactezi direct webmasterul sau ownerul unei aplicatii software (app mobile, website etc), gandurile trebuie asezate foarte bine si clar in raportul vulnerabilitatii. Webmasterii, in general, sunt niste fiinte delicate care se supara destul de repede si nu intotdeauna au vorbele la ei. Astfel ca e posibil sa intri intr-o contradictie fara sens si o teoreie a conspiratiei de ajungi sa iti para rau ca ai pierdut timpul. Alteori este o adevarata placere sa sprijini la deszvoltarea unui sistem sigur si sa stii ca un gram de informatie de la fiecare a sprijinit protejarea unor date sensibile.

In continuare voi prezenta cateva scenarii in care raportorul a avut acces la informatii sensibile, informatii cu caracter confidential sau chiar la intreg sistemul informatic, nu vorbim de kinderi cu XSS sau lipsa unei chei CSRF.

Scenariu: Raportorul a reusit sa aiba acces pe baza unui dork din Google la baza de date a unei sali de fitness care are si magazin online.

Actiunea intreprinsa de catre raportor a fost sa contacteze ownerul siteului la singura adresa disponibila pe site unde a prezentat in detaliu modul in care orice persoana cu minime cunostinte despre ce ar trebui sa caute pe Google, ar putea accesa baza de date deja autentificat, tokenul fiind salvat deja in URL.

Raspunsul salii de fitness a fost ca nu ii intereseaza cine la ce date are acces, ei se pregatesc de lansarea a inca o sala si ei au succes oricum in offline deci nu ii intereseaza ce se intampla online. Siteul a fost facut de un fost angajat si este operat de catre o studenta angajata part time sa impacheteze produsele.

Scenariu: O banca trimite un newsletter prin care prezinta beneficiile economisirii lunar a unei sume de bani si faptul ca au dezvoltat un sistem prin care printr-un simplu click te duce intr-o interfata unde esti deja autentificat / recunoscut de catre aplicatie si doar alegi cat sa economisesti lunar. Din pacate, chiar daca banca a incercat sa protejeze autentificarea neautorizata, solutia de trimitere a emailurilor catre clienti avea incrementat parametrul de redirectionare in linkul de tracking si prin simpla incrementare a UID-ului, te puteai autentifica in contul altui client si sa ii setezi sumele de bani ce sa fie transferate lunar din contul curent in contul de economii. Nu puteai sa vezi datele personale (in afara de nume si prenume), nu puteai sa retragi bani dar puteai sa ii dai batai de cap lunar atunci cand vedea ca ii dispar banii din contul curent si trebuia sa ii caute in cel de economii.

Actiunea intreprinsa de catre raportor a fost sa trimita un email catre adresa generica de webmaster unde a prezentat pe larg tehnica de manipulare a autentificarii, a adaugat capturi de ecran si a enumerat conturile afectate.

Raspunsul bancii a fost o multumire prin telefon si a inclus cazul in programul de bug bounty cu o recompensa de cateva sute de euro.

Scenariu: un operator de telefonie mobila avea o vulnerabilitate usor exploatabila prin care puteai descarca facturile altor clienti. Era mai greu insa pentru ca trebuia sa stii cum functioneaza sistemul si caile, dar pentru un fost angajat nu era complicat.

Ca si in cazul bancii, operatorul a inclus cazul in programul sau de bug bounty si a multumit raportorului pentru prezentarea vulnerabilitatii.

Scenariu: un site de carte permite autentificarea printr-un link trimis pe email ce are  un paramentru encodat in base64 dar o data decriptat poti compune cateva mii de parametri encodati si sigur gasesti cateva zeci de conturi folosite, cu date personale, adrese de livrare, email, telefon etc.

Dupa raportarea prin email unde au fost incluse printscreen-uri si a fost detaliata pe larg procedura folosita, singurul rapuns a fost de forma „multumim, am transmis mai departe catre departamentul IT”. Am apreciat ca am primit raspunsul a doua zi dimineata la prima ora, dar dupa o perioada lunga de timp, vulnerabilitatea este inca prezenta…

Acum, ori cineva a considerat ca nu exista riscul exploatarii vulnerabilitatii de catre persoane rau intentionate, ori departamentul IT era plecat in vacanta pe perioada nedeterminata (cum ni se spunea in armata ca e plecata femeia de servici in concediu un an si trebuie sa maturam noi in locul ei), ori raportul a ramas blocat undeva la o secretara draguta care nu a stiut ce sa faca mai departe,

Scenariu: un site care ofera ceva servicii de fulfillment are „la vedere” niste procese verbale unde sunt date personale ale unor persoane fizice. Nu intru in detalii cu privire la tehnica pentru a nu naste idei scripterilor.

Dupa ce a fost raportata vulnerabilitatea au fost puse in miscare departamente intregi, oamenii de la securitate incepusera sa caute profilul „atacatorului” pe linkedin, CEO-ul ii trimitea cerere de conectare pe linkedin, au urmat telefoane prin care sa afle mai multe informatii cu privire la tehnica folosita, stupida de altfel…O armata de omuleti s-a pus in miscare intelegand pericolul la care se pot expune si au remediat in timp record.

In concluzie, bunul samaritean functioneaza in cele mai multe cazuri, insa este important cum este prezentata divulgarea unei vulnerabilitati. In general, in companiile mici exista one man show care este un fel de semi-zeu cazut printre pamanteni si ori va ascunde gunoiul sub pres, ori riposteaza violent. In companiile mai mari unde exista departament de securitate informatica sau macar un developer cu capul pe umeri, oamenii inteleg ca au o problema si care sunt consecintele daca nu repara acea problema.

Parerea mea este ca cei care cred ca au un sistem impenetrabil sunt cel putin tampiti. Divulgarea responsabila a unei vulnerabilitati ar trebui sa bucure orice detinator sau producator de servicii, sisteme si programe informatice. Alternativa este publicarea si/sau exploatarea vulnerabilitatii iar comunitatile de kinderi in devenire sunt destul de mari si abia asteapta sa isi faca „scoala” pe vulnerabilitatea identificata de catre altcineva.

Nu zic acum sa stai cu F5 pe RST sau pe ZoneH dar uneori este bine sa ascultam si parerea celorlalti. Cateva zeci / sute de euro investite in repararea unei vulnerabilitati poate scuti compania de pierderi financiare imense (de la exploatarea vunerabilitatii pana la raportarea la dataprotection unde e cazul).

Distribuie articolul pe:
TwitterFacebookGoogle+
  1. Am avut acum doi ani o interacțiune cu o instituție apropo de niște posibile găuri în sistemul lor și musai să recunosc faptul că m-a impresionat flexibilitatea și rapiditatea cu care au implementat recomandările după raportare. Mă așteptam la un miserupism clasic precum întâlnesc adeseori la firmele private.

    Cristian Iosub