Inserări de cod rău intenționat de 35 în GitHub: atac sau efort de recompensare a erorilor?

Un hacker care a trecut de mâna „Pl0xP” a clonat un număr mare de depozite GitHub și a schimbat ușor numele depozitelor clonate, într-un efort de typosquatting de a uzurpa identitatea proiectelor legitime – astfel infectând orice software care a importat codul, au spus astăzi experții în software.

Clonarea pe scară largă a dus la peste 35,000 de inserări ale unui URL rău intenționat în diferite depozite de coduri, deși numărul exact de proiecte software afectate este probabil mult mai mic, a declarat inginerul de software Stephen Lacy într-o postare pe Twitter de dimineață. Atacul, o variantă a confuzie de dependență, ar fi putut cauza probleme dezvoltatorilor care folosesc depozitele false GitHub fără o verificare adecvată a sursei software, a spus el.

Dacă este importat, codul rău intenționat execută cod în sistem, conform lui Lacy. „Acest atac va trimite ÎNTREAGA ENV a scriptului, aplicației, laptopului (aplicații electronice), către serverul atacatorului! ENV-urile includ: chei de securitate; chei de acces AWS; Chei cripto... mult mai mult.” 

„ENV” sunt variabile de mediu, folosite pentru a stoca informații la care dezvoltatorii doresc să le facă referire în fluxurile lor de lucru.

Inginerul de software a găsit funcționalitatea rău intenționată atunci când a auditat o bibliotecă de software pe care a considerat să o încorporeze în propriul său proiect, a spus Lacy.

„Am descoperit exploit-ul în timp ce revizuiam un proiect pe care l-am găsit dintr-o căutare pe Google”, el a postat pe Twitter. „De aceea nu instalăm pachete aleatorii de pe internet!”

Clonarea – sau „furcăre” – nu este o tehnică rău intenționată nouă, dar este una dificilă.

„Actorii răi au fost deja cunoscuți în trecut pentru crearea de depozite populare clonate/furcate cu cod rău intenționat”, spune Mor Weinberg, inginer software Aqua Security. „Acest lucru poate deveni destul de dificil de detectat, deoarece depozitele clonate pot păstra comiterea codurilor cu numele de utilizator și adresele de e-mail ale autorilor inițiali, dând o impresie înșelătoare că comiterile mai noi au fost făcute și de autorii proiectului original. Angajările de cod sursă deschisă semnate cu cheile GPG ale autorilor de proiecte autentice reprezintă o modalitate de a verifica autenticitatea codului.”

„Acest lucru... era asemănător cu cineva care susține un site web „fals” sau trimite un e-mail de phishing”, adaugă Mark Lambert, vicepreședinte de produse la ArmorCode. „Acest lucru va prinde oameni care nu sunt atenți.”

Un atac sau o cercetare legitimă?

Este posibil ca această bifurcare în masă în GitHub să nu fi fost un atac real. O persoană care pretinde că are cunoștințe despre problemă a poziționat typosquatting pe scară largă ca un efort de cercetare legitim.

„Acesta este un simplu efort de recompensă. nici un rău făcut. Raportul va fi lansat,” a Utilizatorul Twitter numit „pl0x_plox_chiken_p0x” a postat pe Twitter pe 3 august.

În timp ce un proiect de cercetare prost conceput ar putea explica atacul, crearea a mii de modificări de cod pentru cercetare pare irațional riscantă. În plus, utilizatorul Twitter a înregistrat contul doar în ultimele trei zile - durata scurtă de viață a contului este adesea o caracteristică a persoanelor online frauduloase.

Afirmația conform căreia atacul face parte dintr-o recompensă pentru erori „așteaptă să fie dovedită, deoarece activitatea are caracteristicile unuia cu o intenție rău intenționată”, a spus Jossef Harush, șeful departamentului de inginerie de securitate a lanțului de aprovizionare la firma de securitate software Checkmarx, pentru Dark. Citind.

În orice caz, Michael Skelton, director senior al operațiunilor de securitate la platforma bug-bounty Bugcrowd, observă că cel puțin depozitele de coduri originale au rămas neafectate.

„Deși nu este clar care ar fi natura descoperirii bug-bounty de către Pl0xP (deoarece ingineria socială nu este în domeniul de aplicare pentru aproape toate programele bug-bounty), se pare că au clonat o serie de depozite și au făcut modificări în acele clone. numai – în niciun caz această schimbare nu și-a făcut loc în depozitele originale care au fost clonate”, spune el. „Clonarea unui depozit este o acțiune standard care nu afectează depozitul original decât dacă proprietarul îmbină o modificare înapoi (solicitată printr-o cerere de extragere), ceea ce nu a fost făcut aici.”

Dependențe software rău intenționate abundă

GitHub a curățat aparent codurile rău intenționate și, în după-amiaza zilei de 3 august, o căutare a adresei URL greșite încorporate nu a dat rezultate. Cu toate acestea, atacul nu este prima dată când proiectele open source au de-a face cu atacatori. Numărul de atacuri împotriva lanțului de aprovizionare software a crescut cu 650% în 2021, determinate în principal de atacuri de dependență-confuzie, în care atacatorul folosește o versiune aproape identică a unui bloc de cod sursă deschis, în speranța ca dezvoltatorii să tasteze greșit numele unei biblioteci sau componente dorite sau să nu observe ușoară diferență de nomenclatură. 

Semănarea depozitelor cu proiecte rău intenționate, denumite greșit, necesită ca atacatorul să facă unele lucrări de bază. În iulie, firma de securitate software Checkmarx a dezvăluit o modalitate de a crea conturi de dezvoltator false pe GitHub, complet cu un istoric activ al comiterilor de cod pentru a le spori credibilitatea. Tehnica, împreună cu cel mai recent atac, subliniază faptul că întreținerii trebuie să ia măsuri pentru a accepta doar comenzile de cod semnate, spune Harush. Dezvoltatorii trebuie să „ai grijă de solicitările de extragere și de contribuțiile care au comiteri suspecte neverificate, [și trebuie să] examineze … conținutul contribuțiilor în comparație cu clauza de declinare a răspunderii din mesajul de confirmare și contribuțiile care adaugă sau modifică dependențe existente la dependențe denumite similare ca parte a contribuție”, adaugă el.

Nu aveți încredere, verificați

Pentru a evita ca proiectele lor să fie otrăvite, întreținerii și dezvoltatorii ar trebui să aibă încredere numai în acei contribuitori care sunt cunoscuți de ei și au un istoric de comitere extins și verificabil. De asemenea, ar trebui să folosească instrumentele disponibile - cum ar fi semnăturile digitale și autentificarea multifactorială - pentru a-și securiza conturile, spune Harush.

„Deoarece nu ar trebui să aveți încredere în bomboane de la străini, nu aveți încredere în codul de la străini”, spune el. „Utilizatorii pot fi păcăliți atunci când evaluează proiectul candidat și cred că sunt legitimi, [deci] îl folosesc în computerele lor locale de dezvoltare, construiesc medii, medii de producție și chiar construiesc software, [până când în cele din urmă execută ceva rău intenționat] pe clienții [ sisteme]”.

În avizul din iulie al Checkmarx cu privire la falsificarea informațiilor de identitate și a informațiilor de comitere în merge utilitar de linie de comandă, compania a subliniat riscurile pentru proiectele software atunci când autorii rău intenționați se deghizează în colaboratori cunoscuți. Acest lucru „fa ca proiectul să pară demn de încredere”, a declarat firma. „Ceea ce face această falsificare și mai alarmantă este faptul că utilizatorul care este falsificat nu este notificat și nu va ști că numele lui este folosit.”

GitHub a adăugat deja semnături digitale pentru comenzile de cod pentru a verifica identitatea contribuitorului, dar întreținerii proiectului ar trebui să activeze „modul vigilent”, o caracteristică a GitHub care afișează detalii despre starea de verificare a fiecărui comit și a contribuitorului lor, a declarat Checkmarx.

Cel puțin, dezvoltatorii și menținătorii de proiecte ar trebui să-și revizuiască ocazional jurnalul de comitere și să le ceară celorlalți menținători să activeze comitările semnate de GPG, spune Harush. „Obișnuirea cu un jurnal de comitere semnat vă va ajuta să acordați atenție contribuțiilor neverificate.”

GitHub nu a putut fi contactat imediat pentru comentarii.