Cybermonth: despre supply chain attacks
Cybermonth: despre supply chain attacks
Decembrie - luna dedicată securității.
Cu acest articol, deschid o serie pe tema securității. Le voi posta preponderent în ultima lună din an. Pentru că securitatea este foarte importantă, iar în decembrie știu că lumea - inclusiv eu - face planuri pentru la anul.
Supply chain attacks cum sunt denumite, sunt o serie de atacuri cibernetice care, spre deosebire de alte tipuri de atacuri - viruși, malware, ROP - nu au ca țintă directă software-ul. Ținta este dezvoltatorul și ecosistemul utilizat pentru dezvoltarea programelor.
Pachete și librării third-party
Aproape 99.99% dintre toate programele utilizate azi folosesc librării third-party, adică cod scris sau compilat de către alte persoane și organizații care nu sunt implicate direct în dezvoltarea respectivului program. De exemplu dacă eu dezvolt o aplicație pentru comerț pe internet, voi instala o librărie care să mă ajute să criptez datele pe care le trimit către procesatorul de plăți, deoarece ar fi un efort prea mare să scriu acea librărie de la zero. Și desigur, de aceea foarte multe limbaje de programare oferă unelte ca managere de pachete - care te ajută să cauți, instalezi și în unele cazuri să și auditezi o librărie externă.
Când folosești o librărie externă, toate datele pe care le procesează acea librărie pot fi subiectul unui atac, de aceea în funcție de importanța și impactul proiectului pe care lucrezi, reputația și măsurile de securitate pe care la adoptă dezvoltatorii și organizațiile care dezvoltă librării externe pot fi foarte importante.
Scenarii de atac
Cum am menționat mai sus adoptarea unor măsuri de securitate și analiză a codului sunt necesare, mai ales pentru librăriile care sunt folosite în sisteme de operare sau programe care fac tranzacții monetare. Scenariile de atac se înscriu de obicei în patru categorii:
Lipsa unei evaluări de securitate de rutină
O librărie externă care are o vulnerabilitate. Dezvoltatorul fixează această vulnerabilitate și anunță public, însă organizații care dezvoltă software care include această librărie amână actualizarea. Pe această amânare s-au bazat atacatorii care au ex-filtrat datele clienților companiei Equifax în 20171 .
Publicarea unei librării cu nume similar
Deși cu impact mai mic, profitând de bună-voința și politica permisivă a hub-urilor de pachete cu sursă deschisă, atacatorii încarcă copii ale unor pachete extrem de populare, la care adaugă cod malițios - dar cu o literă schimbată - de exemplu în loc de jQuery, jQwery. Mulți dezvoltatori, mai ales juniori, vor trece cu vederea diferența de literă, sau de multe ori acestea se prezintă ca având funcționalități extra față de original.
Acest tip de atac se numește typosquatting și cel mai relevant exemplu este cel al pachetului crossenv2, care a ajuns să fie descărcat de aproape 1000 de ori, în detrimentul pachetului original cross-env.
Compromiterea contului dezvoltatorului librăriei
De multe ori, unele librării populare sunt dezvoltate de oameni foarte pasionați, dar în același timp fac asta ca un hobby. Deși în majoritatea cazurilor își iau măsuri de securitate, se poate întâmpla ca, contul lor să fie compromis. Acest tip de atac este mai dificil de executat, deoarece persoana compromisă va anunța imediat pe alte canale că este o problemă. Așadar atacatorii sunt nevoiți să evite acest lucru și mai apoi să publice o versiune nouă a librăriei cu codul malițios - pe care dacă alți membrii îl auditează are șanse foarte mici să ajungă publicat.
În acest caz librăriile dezvoltate de o singură persoană sunt mai expuse, deoarece este nevoie de compromiterea unui singur actor. Dar mai ales codul pentru versiuni poate fi publicat fără un audit. Însă și companiile mari sunt expuse, iar măsurile de securitate luate sau evitate de angajați pot avea consecințe nefaste. Iar un exemplu notoriu este breach-ul suferit de compania SolarWinds prin compromiterea furnizorului FireEye3.
Utilizarea la scară globală a unei singure librării
Știți cum multe soluții software se laudă cu standarde înalte de securitate pentru că adoptă soluții recunoscute și aplicate și în cadrul altor sisteme. Una dintre punctele slabe provine tocmai din tendința dezvoltatorilor de software de a folosi cele mai populare soluții. Deși pe de o parte, șansa ca aceste librării să fie și cele mai sigure este mai mare, când 90% din infrastructura de internet folosește o anumită librărie, se dovedește că pariem prea mult pe aceste soluții, în ciuda faptului că există și alte soluții cu aceleași caracteristici. Un astfel de pariu, l-am pierdut în 2014, când a fost anunțată o vulnerabilitate în OpenSSL4, o librărie care criptează datele a peste 90% din traficul de pe internet.
Cum ne protejăm
Acest subiect ar merita un articol dedicat, dar ca dezvoltatori putem să aplicăm un minim de măsuri de securitate pentru proiectele și infrastructura pe care rulează:
actualizări și audit-uri periodice de securitate
audit pentru codul scris de dezvoltatori - pull requests și reviews
folosirea metodelor de autentificare sigure: ssh keys, 2 factor authentication.
servicii care scanează periodic codul și dependințele pentru vulnerabilități
Pentru companii, cele enumerate mai sus desigur, însă merită menționate și folosirea unui VPN și standarde de autentificare ca Fido și Passkeys. Alte resurse găsiți în lista de mai jos: