ce este un atac RCE (Remote Code Execution)?
executarea codului la distanță este utilizată pentru a expune o formă de vulnerabilitate care poate fi exploatată atunci când intrarea utilizatorului este injectată într-un fișier sau șir și întregul pachet este rulat pe parserul limbajului de programare. Acesta nu este tipul de comportament expus de dezvoltatorul aplicației web. Un atac de executare a Codului la distanță poate duce la un atac la scară largă care ar compromite o întreagă aplicație web și serverul web. De asemenea, trebuie să rețineți că practic toate limbajele de programare au funcții diferite de evaluare a codului.
o evaluare a codului poate apărea, de asemenea, dacă permiteți intrărilor utilizatorului să obțină acces la funcții care evaluează codul în același limbaj de programare. Acest tip de măsură poate fi implementat în mod intenționat pentru a avea acces la funcțiile matematice ale limbajului de programare sau accidental, deoarece intrarea controlată de utilizator este proiectată de dezvoltator pentru a se afla în oricare dintre aceste funcții. Nu este recomandabil să efectuați această linie de acțiune. Mulți oameni consideră că este rău intenționat să folosească chiar și evaluarea codului.
exemplu de cod
să aruncăm o privire la un exemplu de atac de evaluare a codului.
poate părea o idee mai bună să aveți nume de variabile generate dinamic pentru fiecare utilizator și să stocați data de înregistrare a acestora. Acesta este un exemplu de modul în care puteți face este făcut în PHP
eval("$$user = '$regdate');As long as the username is controlled by the user's input, an attacker may create a name like this:x = 'y';phpinfo();//codul PHP generat ar semăna cu acesta:
$x = 'y';phpinfo();// = 2016';acum Puteți vedea că variabila este denumită x, dar are valoarea y. când atacatorul poate atribui o altă valoare variabilei, el va putea crea o nouă comandă utilizând un punct și virgulă (;). El poate umple acum în restul F șir. În acest fel, el nu va primi erori de sintaxă în lucrarea sa. De îndată ce execută acest cod, ieșirea phpinfo va fi afișată pe pagină. Trebuie să vă amintiți întotdeauna că este posibil în PHP și în alte limbi cu caracteristici care pot evalua intrarea.
aranjarea executării codului la distanță după origine
majoritatea punctelor slabe RCE distinse se datorează anumitor cauze de bază care pot fi urmărite până la punctul său de plecare. Gruparea executării codului la distanță după început este examinată după cum urmează.
executarea codului dinamic
executarea codului dinamic este de către toate conturile cel mai recunoscut motiv de bază care solicită un atac de execuție a codului. Multe dialecte de programare sunt planificate într-o asemenea măsură încât pot produce cod cu un alt cod și îl pot executa imediat. Această idee este una uimitoare care se ocupă de diverse probleme complexe. Oricum ar fi, un atacator răuvoitor poate controla această idee pentru a dobândi acces și capacități RCE.
în mod obișnuit, codul produs rapid depinde de anumite intrări ale clientului. În mod obișnuit, codul încorporează informațiile care au fost amintite pentru o anumită structură. Atunci când un agresor malign înțelege că vârsta puternică a codului va utiliza anumite informații, ar putea face un cod substanțial ca tip de acces pentru a separa aplicația. În cazul în care contribuțiile clienților nu sunt examinate, codul va fi executat pe obiectivul său.
în momentul în care alegeți să priviți cu atenție, executarea dinamică a codului este răspunzătoare pentru două tipuri de atacuri bazate pe RCE; imediată și circuitată.
Direct
când gestionează o ilustrare a execuției tributului unic direct, agresorul își dă seama că feedback-ul lor ar fi utilizat pentru a produce cod.
Indirect
într-un mod aberant, este îngrijorat de vârsta puternică a Codului cu intrările clientului. Intrarea clientului este de obicei supusă cel puțin unui strat. O parte din straturi ar putea fi răspunzătoare pentru schimbarea contribuției înainte de a ajunge la vârsta dinamică a codului. În plus, vârsta dinamică a codului ar putea fi un impact ulterior și nu utilizarea imediată a informațiilor. Acesta este motivul pentru care nu poate fi clar pentru client care oferă informațiile care se vor completa ca un bloc de structură într-o resturi de cod care ar fi executate la distanță.
deserializarea
deserializarea este un ghid incredibil pentru a descrie circumstanțele actuale. Nici o vârstă cod puternic ar trebui să apară în timpul deserializare. Intermitent, aceasta este situația care se întâmplă atunci când obiectul serializat conține câmpuri de informații brute sau obiecte de un fel comparabil. Lucrurile devin mai confuze atunci când elementele articolului sunt serializate. Deserializarea ar include, de asemenea, un anumit grad de vârstă dinamică a codului.
s-ar putea părea că dialectele puternice sunt singurele influențate de serializarea muncii. Cu condiția ca acest lucru să fie adevărat, problema ar fi foarte restrânsă. Oricum ar fi, această situație este foarte utilă și în dialectele statice. Este mai greu de realizat cu limbajul static, dar cu siguranță nu este fezabil.
intermitent, executarea acestei idei gestionează capacitățile intermediare produse de deserializare. Obiectele de vârstă în timpul rulării sunt doar imaginabile cu Dynamic code age. Acest lucru implică faptul că, dacă informațiile care vor fi deserializate sunt făcute într-o solicitare făcută la distanță, un atacator răuvoitor ar putea să o rechiziționeze și să o ajusteze. În jurul valorii de biți de cod planificate ar putea fi, de asemenea, familiarizat cu stunt vârsta cod puternic pentru a executa capacitatea atunci când este încorporat ca o bucată de deserializare.
siguranța memoriei
încă un motiv de bază pentru atacurile RCE se identifică cu securitatea memoriei sau securitatea API. Starea de bine a memoriei face aluzie la contracararea codului de la a ajunge la bucăți fundamentale de memorie pe care nu le-a instalat. Este obișnuit să ne așteptăm ca o lipsă de securitate a memoriei să ducă la accesul neautorizat la informații. În orice caz, cadrul de lucru și echipamentul depind de memorie pentru a stoca codul executabil. Metadatele care se identifică cu executarea codului sunt păstrate în memorie. Accesarea acestei bucăți de memorie ar putea solicita ACE și RCE. În acest fel, care sunt o parte din motivele problemelor de bunăstare a memoriei?
imperfecțiunile planului produsului
imperfecțiunile din configurația produsului sunt un tip de slăbiciune a bunăstării memoriei care se întâmplă acolo unde există o greșeală de planificare într-o anumită parte ascunsă. Intermitent, partea neajuns ar putea fi un compilator, traducător, mașină virtuală, sau chiar porțiunea cadru de lucru sau bibliotecă. Există diverse pete în această clasă. O parte din încorporare;
Buffer Overflow
Buffer overflow în plus, a făcut aluzie ca tampon overread, pot fi utilizate pentru a face aluzie la o metodă de bază și celebru, care este utilizat pentru a rupe starea de bine de memorie. Acest asalt profită de un cusur plan specific sau un bug pentru a păstra legătura cu celulele de memorie care sunt situate spre finisajul pernei de memorie. Sprijinul ar fi primit înapoi de la un apel autentic la API-ul public. Cu toate acestea, cradle face aluzie doar la un loc de pornire amenințarea este utilizată pentru a înregistra locațiile reale de memorie ale unui anumit articol sau contor de programe. Separarea lor de leagăn este notabilă sau poate fi, fără îndoială, speculată. Investigarea codului ori de câte ori este accesibilă sau depanarea întregii execuții a programului în timpul rulării poate ajunge să fie utilă unui agresor care trebuie să analizeze pozițiile relative.
aceasta implică faptul că o inundație a leagănului ar permite modificarea memoriei indisponibile într-o oarecare măsură. Leagănul ar putea fi găsit în spațiul de locație de o mașină mai mult și va fi schimbat prin apelarea unui API îndepărtat. Acest lucru va face admiterea în memoria mașinii la distanță. Există numeroase abordări pentru a utiliza acest tip de acces în a face un dublu-dealing RCE. Există o suspiciune generală că presupunând că există o slăbiciune a inundațiilor de pernă, un atac bazat pe RCE nu este în afara cărților. Acest lucru implică faptul că proprietarii de coduri se bazează pe remedierea promptă a inundațiilor de sprijin înainte de apariția unui atac RCE.
defecte de proiectare a echipamentului
atacurile de bunăstare a memoriei pot fi, de asemenea, din cauza defectelor de configurare a echipamentului. Nu sunt la fel de normale ca atacurile de programare și sunt mult mai greu de recunoscut. Cu toate acestea, acest tip de atac afectează enorm cadrul.
impactul vulnerabilității de evaluare a Codului la distanță
un atacator care poate executa un atac bazat pe cod la distanță asupra unui sistem cu succes ar putea executa alte comenzi profitând de limbajul de programare sau de serverul web. În multe limbaje de programare, atacatorul ar putea comanda sistemului să scrie, să citească sau să șteargă fișiere. Poate fi chiar posibil să vă conectați la diferite baze de date cu sistemul atacat.
de ce atacatorii lansează atacuri RCE?
deși nu există niciun motiv special pentru care atacatorii aleg să utilizeze exploatarea RCE pentru a ataca o aplicație web, nu există niciun motiv special. Doar că unora rău intenționați le este ușor să profite de această execuție de cod pentru a avea acces la sistemele dvs.
Cum Preveniți Atacurile De Execuție A Codului La Distanță?
pentru a începe cu, ar trebui să evite utilizarea de intrare de utilizator în interiorul Cod evaluat. Cea mai bună opțiune în această situație ar fi evitarea completă a utilizării funcțiilor precum eval. Este considerată a fi o formă de practică proastă și poate fi ușor evitată. De asemenea, este recomandat să nu lăsați niciodată un utilizator să editeze conținutul fișierelor care ar fi putut fi analizate de limbajul de programare în cauză. Adesea, aceasta include permiterea unui utilizator să creeze numele și extensiile de fișiere pe care dorește să le încarce sau să le creeze în aplicația web.
acestea sunt câteva dintre lucrurile pe care nu ar trebui să le faceți pentru a evita atacurile bazate pe RCE. Acestea includ:
- igienizarea de intrare de utilizator. Adesea, acest lucru este dificil de realizat, deoarece există o cantitate mare de ocoliri și restricții preinstalate.
- permiteți unui utilizator să decidă sau să creeze extensia sau conținutul fișierelor care vor fi utilizate pe serverul web. El / ea trebuie să folosească multe practici sigure atunci când manipulează încărcările de fișiere sau riscă să cadă informații vitale în mâinile greșite.
- treceți orice intrare controlată de utilizator în callback-uri de sistem sau funcții de evaluare
- pe lista neagră activă a oricăror caractere speciale sau nume de funcții. Acest lucru ar trebui evitat la fel ca igienizarea intrării utilizatorului. Dar este incredibil de dificil de implementat.