Executarea codului la distanță (RCE), explicată: ce este și cum să o preveniți

executarea codului la distanță (RCE) este o clasă de defecte/vulnerabilități de securitate software. Vulnerabilitățile RCE vor permite unui actor rău intenționat să execute orice cod la alegere pe o mașină la distanță prin LAN, WAN sau internet. RCE aparține clasei mai largi de vulnerabilități de execuție a codului arbitrar (ACE). Cu Internetul devenind omniprezent, totuși, impactul vulnerabilităților RCE crește rapid. Deci, RCEs sunt acum probabil cel mai important tip de vulnerabilitate ACE.

așa cum este cazul, am vrut să aruncăm o privire mai detaliată asupra diferitelor tipuri de vulnerabilități RCE și a posibilelor contramăsuri.

clasificarea RCE după origine

majoritatea, dacă nu toate, vulnerabilităților RCE cunoscute au un număr mic de cauze subiacente.

executarea codului dinamic

executarea codului dinamic tinde să fie cel mai comun vector de atac care duce la RCE. Majoritatea limbajelor de programare au o modalitate de a genera cod cu cod și de a-l executa la fața locului. Acesta este un concept foarte puternic care ajută la rezolvarea multor probleme complexe. Cu toate acestea, o terță parte rău intenționată o poate abuza cu ușurință pentru a obține capabilități RCE.

adesea, codul generat în timpul rulării se bazează pe unele date introduse de utilizator. De cele mai multe ori, Codul include acea intrare într-o anumită formă. Un actor rău intenționat, realizând că generarea dinamică de cod va folosi o intrare dată, ar putea furniza un cod valid ca intrare pentru a ataca aplicația dvs. Dacă intrările utilizatorului nu sunt verificate, atunci acel cod va fi executat pe mașina țintă.

în linii mari, executarea dinamică a codului provoacă două clase majore de vulnerabilități RCE: directe și indirecte.

Direct

în cazul executării directe a codului dinamic, actorul rău intenționat este conștient de faptul că intrarea lor va fi utilizată în generarea de coduri.

Indirect

un caz indirect, din nou, se reduce la generarea de cod dinamic, inclusiv intrările utilizatorului. Cu toate acestea, intrarea utilizatorului trece prin unul sau mai multe straturi. Unele dintre straturi ar putea chiar transforma acea intrare înainte de a ajunge la generarea de cod dinamic. De asemenea, generarea de cod dinamic ar putea fi un efect secundar și nu utilizarea primară a intrării. Ca atare, nu este cu adevărat evident pentru utilizatorul care furnizează intrarea că intrarea va fi utilizată ca bloc de construcție într-un fragment de cod care va fi executat pe o mașină la distanță.

deserializarea

deserializarea este un foarte bun exemplu al acestui scenariu. Aparent nici o generație de cod dinamic ar trebui să se întâmple pe deserializare. Acesta este de fapt cazul când obiectul serializat conține doar câmpuri de date de tipuri primitive sau alte obiecte de acest fel. Cu toate acestea, lucrurile se complică atunci când metodele/funcțiile unui obiect sunt serializate. Deserializarea va include, de obicei, o formă de generare dinamică a codului.

s-ar putea să credeți că limbile dinamice sunt singurul loc în care serializarea funcțiilor are sens. Problema va avea un domeniu de aplicare limitat atunci. Dar este un scenariu util și în limbaje statice. Este ceva mai greu de realizat într-un limbaj static, dar de departe nu imposibil.

destul de des, implementarea constă în obiecte/funcții proxy generate de deserializare. Generarea obiectelor / funcțiilor în timpul rulării este un caz de generare dinamică a codului. Deci, dacă datele care urmează să fie deserializate provin dintr-o solicitare făcută de o mașină la distanță, un actor rău intenționat ar putea să o modifice. Fragmente de cod serializate cu atenție artizanale pot fi injectate care păcălesc generarea de cod dinamic pentru a le executa atunci când sunt invocate ca parte a deserializării.

siguranța memoriei

o altă cauză a vulnerabilităților RCE are legătură cu siguranța memoriei. Siguranța memoriei înseamnă prevenirea accesului codului la părți ale memoriei pe care nu le-a inițializat sau nu le-a primit ca intrare. Intuitiv, s-ar putea să vă așteptați ca o lipsă de siguranță a memoriei să ducă la accesul neautorizat la date. Cu toate acestea, sistemul de operare și hardware-ul de bază utilizează memoria pentru a stoca codul executabil real. Metadatele despre executarea codului sunt, de asemenea, stocate în memorie. Obținerea accesului la acest tip de memorie ar putea duce la ACE și, eventual, RCE. Deci, care sunt principalele motive din spatele problemelor de siguranță a memoriei?

defecte de proiectare Software

defectele de proiectare Software sunt un tip de vulnerabilitate de siguranță a memoriei în care există o eroare de proiectare în unele componente subiacente. De cele mai multe ori, acesta ar fi un compilator, interpret sau mașină virtuală sau, eventual, nucleul sau bibliotecile sistemului de operare. Există o serie de defecte diferite care aparțin acestei clase. Vom arunca o privire mai detaliată asupra a ceea ce este, fără îndoială, cel mai comun.

Buffer overflow sau buffer overread

Buffer overread (cunoscut și sub numele de buffer overread) este o tehnică destul de simplă și bine cunoscută pentru a încălca siguranța memoriei. Exploatează un defect de proiectare sau un bug pentru a scrie celulelor de memorie care urmează sfârșitul real al unui tampon de memorie. Tamponul în sine se întoarce de la un apel legitim la API-ul public. Cu toate acestea, tamponul servește doar ca punct de origine pentru a calcula adresele de memorie fizică ale valorilor câmpului/membrilor privați ale unui obiect sau contor de programe. Poziția lor relativă față de tampon este fie bine cunoscută, fie poate fi ghicită. Cercetarea codului dacă este disponibil sau depanarea execuției programului în timpul rulării ar putea ajuta un actor rău intenționat să obțină poziții relative.

deci, o depășire a tamponului permite modificarea memoriei care ar trebui să fie inaccesibilă prin proiectare. Acest tampon ar putea locui în spațiul de adrese al unei alte mașini și poate fi modificat apelând un API la distanță. Acest lucru va permite accesul la memoria mașinii la distanță. În mod clar, există diferite modalități de a utiliza acest tip de acces în instrumentarea unui RCE. Presupunerea generală este că, dacă există o vulnerabilitate de depășire a tamponului, atunci este posibil un RCE. Deci, proprietarii de coduri ar trebui să remedieze revărsările tamponului cât mai curând posibil, cu mult înainte de apariția atacului RCE real.

domeniul de aplicare

de cele mai multe ori, depășirea tamponului vizează codul C/C++, deoarece aceste limbi nu au construit verificări de dimensiune tampon. O mulțime de alte cadre și tehnologii populare ajung să utilizeze bibliotecile C/C++ adânc sub suprafață, ceea ce le face automat vulnerabile la acest tip de atac.

nod.js este un bun exemplu în acest sens, deoarece, pe lângă faptul că se bazează pe C/C++, JavaScript runtime permite, de asemenea, suplimente native C/C++. Din acest motiv, un atacator poate crea cu atenție cererile către un nod.server js pentru a provoca buffer overflow și, astfel, modifica memoria sistemului de pe mașina afectată, provocând executarea de cod arbitrar.

defecte de proiectare Hardware

destul de interesant, încălcările de siguranță ale memoriei pot apărea și din cauza defectelor de proiectare a securității hardware. Deși sunt mai puțin frecvente și mai greu de găsit, astfel de vulnerabilități au de obicei un impact extrem de mare.

devierea atacurilor RCE

în timp ce rezultatul fiecărui atac RCE este același în ceea ce privește un atacator care execută codul, vectorii de atac sunt foarte diferiți în natură. Blocarea tuturor acestora necesită eforturi semnificative. Mai mult, efortul crește împreună cu stiva de tehnologie. Toți vectorii de atac descriși în acest post sunt agnostici tehnologici. Totuși, toate implementările sunt specifice tehnologiei, la fel și mecanismele de apărare.

deci, o abordare tradițională de economisire a timpului este de a monitoriza traficul de rețea pentru conținut suspect în loc să monitorizeze fiecare punct final cu tehnologia sa specifică. Un firewall pentru aplicații web (WAF) efectuează de obicei această lucrare. În timp ce acest lucru economisește timp, vine și la un preț—WAF este un blocaj al performanței rețelei și îi lipsesc toate informațiile de fundal disponibile la punctul final Real sau la nivelul aplicației și al utilizatorului. Prin urmare, analiza traficului WAF nu ar putea fi niciodată perfectă. Euristica este inevitabilă fără date complete, deci fie nu vor apărea toate amenințările, fie vor apărea falsuri pozitive, sau cel mai adesea ambele.

mutarea în interiorul aplicației: Abordarea sqreen

sqreen abordează aceste deficiențe WAF fără a crește costul de dezvoltare pentru utilizatorul final prin mutarea vizibilității în interiorul aplicației, aducând o protecție mai completă cu un RASP specific tehnologiei și WAF în aplicație. RASP și WAF Sqreen rulează în interiorul aplicației Web, API-ului sau microserviciului care primește trafic de rețea. Ea nu are nevoie de nici o modificare de cod, deși. Acesta utilizează puncte de instrumentație specifice pentru fiecare tehnologie (de exemplu, JVM API pentru Java, V8 API pentru Node.js, etc.) pentru a modifica codul înainte de execuție în timpul rulării. Astfel, este capabil să monitorizeze și să modifice evenimentele de sistem și de rețea, având în același timp contextul complet al tot ceea ce se întâmplă în interiorul aplicației.

astfel, Sqreen poate detecta că aplicația utilizează componente cu probleme cunoscute de siguranță a memoriei. De asemenea, poate detecta intrările reale ale utilizatorului care o fac la evenimentele dinamice de execuție a codului. Desigur, aceasta este o abordare superioară pentru detectarea și prevenirea RCEs în comparație cu un WAF tradițional care are acces doar la traficul de rețea.

înfășurarea

în mod clar, RCE este un vector de atac foarte puternic. Dar, din fericire, este posibil să vă apărați și împotriva atacurilor RCE. Informațiile de mai sus pot ajuta într-adevăr în construirea strategiei de apărare. Dacă sunteți interesat de alți vectori de atac și detalii, consultați postările noastre anterioare despre SQL injection, XXE și LFI.