ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 101
Abonament PDF

Puterea Open-Source Software în securitatea cibernetică

Gustavo Silva
Security Engineer @ Paddy Power Betfair



PROGRAMARE


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ă.

Ce este Shhgit?

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.

De ce să folosim un scaner pentru secrete?

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.

Avantaje și dezavantaje ale instrumentelor de scanare - cum am ajuns la versiunea blue team?

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.

Cum funcționează?

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.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects