Open source software poate fi asemuită până la un punct, cu frumusețea pe care o implică actul artistic, pentru că ambele ne dau posibilitatea să creăm, să experimentăm, să transformăm în vederea atingerii unui scop mai înalt. Dar ne menținem în registrul tehnic și menționăm că, după ce am descoperit și am analizat un instrument nou de scanare de securitate, cu ajutorul echipei de programatori, am dus acest tool la un alt nivel. Ceea ce inițial ar fi putut fi folosit pentru red-teaming, bug bounty hunting (vânăoare de defecte) sau hacking general a devenit un instrument ce poate ajuta blue teams în munca lor împotriva celor rău intenționați.
Acum aproape un an, echipa de Application Security de la Paddy Power Betfair a început un proiect de adaptare a unui scanner de secrete numit shhgit. Echipa noastră lucrează zilnic la crearea și implementarea instrumentelor necesare pentru ca aplicațiile noastre să aducă cel mai înalt standard de calitate. De îndată ce ne-am familiarizat cu acest instrument, am văzut cu toții potențialul său imens în creșterea nivelul de conștientizare a pericolelor cibernetice și în reducerea proactivă a posibilității ca tokenele sensibile și secretele să ajungă în codul sursă.
Shhgit este un instrument open source ce găsește secretele omise și fișierele sensibile din GitHub și Gist-urile aferente în timp real. Se folosește de componenta API a GitHub pentru a identifica repositories de cod public ce conțin secrete sau fișiere dezvăluite neintenționat. Instrumentul acesta a apărut pentru a scoate în evidență caracterul omniprezent al acestei probleme.
În spatele acestei definiții de nivel înalt, shhgit folosește un motor de regular expressions care identifică tipare pe care utilizatorul le poate defini pentru fiecare linie de cod din repository. Când un utilizator publică codul într-un repository public, aplicația face o scanare completă a acelei baze de date și ridică alerte. Configurația de bază conține peste 130 de semnături și include lucruri precum chei AWS, chei Google Cloud sau chei SSH. Le poate detecta pe toate acestea și multe altele. Unele din aceste secrete urmează un format specific (precum al celor menționate anterior), acesta fiind un mare avantaj în realizarea de instrumente ce poate detecta acest format.
Scurgerea de date este una din cele mai frecvente pericole din orice companie, din orice proiect. Dezvăluirea unui token secret în mediul public nu este neapărat o breșă de securitate, dar facilitează accesul atacatorilor la informație, când își aleg căile de atac. Problema este cu atât mai relevantă dacă luăm în calcul procesele de detecție și de alertă, când datele sensibile au fost dezvăluite. AWS GuardDuty de la Amazon este unul din cele mai bune exemple.
Deși acest instrument a oferit multă vizibilitate asupra informației sensibile expuse public, instrumentul a ridicat alerte doar când secretul era deja în mediul public. Mai mult, alertele erau efectuate printr-o aplicație web care nu era ușor de integrat cu sistemul nostru de notificări. Pe de altă parte, acest instrument open source nu era gata de a fi implementat per repository. Aceasta este o funcționalitate cheie pe care a trebuit să o abandonăm din cauza numeroaselor valori fals pozitive care ar fi rezultat. Dacă fiecare echipă de dezvoltare poate specifica tiparele relevante sau fișierele ce pot fi ignorate, instrumentul trimite notificări doar când problema este detectată. Acest nivel de customizare nu a fost posibil în shhgit și este greu de găsit în alte soluții similare.
Cu toate că aceste instrumente open source oferă informații despre potențiale date sensibile care au ajuns în mediul public, toate acestea sunt reactive… . Cel mai adesea, imposibilitatea de a face customizări face un instrument greu de adoptat la nivel de proiect sau companie.
Deși conceptul era bun, rezultatele ne-au determinat să înțelegem motorul central al instrumentului care s-a dovedit a fi foarte simplu: Regex și comparare de șiruri. Acest fișier cu configurație unică permite customizarea tuturor opțiunilor relevante pentru scaner. Mai mult, doream o configurație la nivel de repository, astfel încât instrumentul să poată fi adaptat la cerințele fiecărui proiect.
Astfel, am optimizat instrumentul pentru a deservi cel mai bine interesele unui blue team. Am creat un nou instrument de la zero, într-un alt limbaj, refolosind majoritatea conceptelor din shhgit, integrând îndeaproape toate sistemele și practicile noastre de dezvoltare.
Așa cum funcționează acum, instrumentul permite programatorilor să seteze un scaner de secrete direct în GitLab (la nivel de repository), instrumentul scanând fiecare bucată nouă de cod din toate operațiunile de tip Merge. Poate fi văzut ca un pas din cadrul pipeline-ului de integrare continuă (CI), fiind o încercare de a opri proactiv programatorii de la a dezvălui accidental credențiale, adrese email, chei AWS sau alte date sensibile în cadrul codului sursă. Configurația de bază conține formate pentru toate tokenele la care ne putem gândi, dar aici intervine marele plus al instrumentului: se poate modifica în conformitate cu nevoile voastre, include fișiere și căi (paths) ce trebuie ignorate - precum directoarele de test sau fișierele de test, la nivel de repository. Astfel, instrumentul se poate adapta proiectului vostru, nu invers (proiectul la instrument).
Când instrumentul începe o scanare nouă, (e.g, un nou Merge este inițiat), acesta caută în repository un fișier de configurare, iar dacă acest fișier există, îl va folosi pe acesta din urmă în loc de cel default. Vreți ca niciun email al companiei să nu ajungă în codul sursă? Adăugați un regular expression pentru domeniul companiei voastre și gata. Folosiți un instrument care are un format predictibil pentru tokenul de securitate, iar acesta nu se regăsește în fișierul de configurare? Adăugați-l în al vostru! Nu vreți ca scanările să ruleze pe fișierele de test? Nicio problemă - adăugați-le pe lista cu valori ce trebuie ignorate.
Momentan, avem un roadmap pentru funcționalitățile pe care vrem să le implementăm în viitorul apropriat. Sunt extensii ale ideii de bază ce poate ajuta oamenii să beneficieze mai mult de pe urma acestui proiect.
Primul pas este de a integra scanerul înapoi în GitHub. Platforma conține proiecte numeroase, atât private cât și publice, iar comunitatea tehnică este foarte bine reprezentată aici. Prin urmare, considerăm obligatorie integrarea cu GitHub. La nivel de eficiență și portabilitate, vrem să implementăm detecția nivelului de entropie a cheii (descoperirea secretului din entropia cuvântului, foarte relevantă pentru proiectele sensibile sau critice), customizări ale notificărilor (blocarea operațiunilor Merge sau alertarea programatorilor) și publicarea oficială a unei imagini docker a acestui proiect pentru a facilita integrarea sa în echipele de dezvoltare.
La Paddy Power Betfair ne îmbunătățim mereu produsele ca să obținem un ciclu sigur de dezvoltare software. Prin prisma experienței noastre, a cercetărilor noastre, a experimentelor deja efectuate, considerăm că acest instrument va acoperi o lipsă în domeniul securității. Din fericire, se încurajează și se permite echipelor să își antreneze curiozitatea, să construiască lucruri noi și să crească la nivel personal și de companie. Sunt extrem de recunoscător pentru acest lucru. Nu am fi găsit susținere pentru dezvoltarea și publicarea acestui software open source altundeva.
Deoarece originile acestui instrument sunt open source, am vrut să păstrăm rezultatul tot open source. Am văzut acest lucru drept o oportunitate de a oferi ceva înapoi comunității ce acordă atât de multe resurse programatorilor și echipelor.
Ne-ar bucura să primim păreri și alte contribuții din partea comunității tehnice. Așadar, vă invităm să vă implicați. Verificați în repository informațiile legate de modalitatea de a contribui.
de Ovidiu Mățan
de Gabriel Pop
