cucumberanorsncompany/sealsecurityassignmentRicerca sulla vulnerabilità CVE-2023-26136
Ricerca sulla vulnerabilità CVE-2023-26136
Le versioni del pacchetto tough-cookie precedenti alla 4.1.3 sono vulnerabili a Prototype Pollution a causa di una gestione impropria dei cookie quando si utilizza CookieJar in modalità rejectPublicSuffixes=false. Questo problema deriva dal modo in cui gli oggetti vengono inizializzati.
https://nvd.nist.gov/vuln/detail/CVE-2023-26136
JavaScript ha il concetto di oggetti, che è in qualche modo simile ai dizionari. Un oggetto può contenere un insieme di variabili di diversi tipi (es. stringa, booleano, intero, ecc.), il nome della variabile è una chiave e il suo valore è il valore, se continuiamo con l'analogia di dizionari e oggetti. Più precisamente, l'oggetto è analogo alla struttura dati del dizionario stesso, e ogni variabile è analoga a una coppia chiave-valore. Gli oggetti hanno anche la parola chiave proto che consente di aggiungere variabili aggiuntive a un oggetto modificandone il prototipo. Prototype Pollution è un attacco in cui l'attaccante inquina il suo oggetto, aggiungendovi variabili aggiuntive, tramite la parola chiave proto. L'interazione qui sotto con la console del browser dimostra l'attacco.
Come possiamo vedere, abbiamo due utenti: admin1 e user1. L'oggetto admin1 ha una variabile booleana: "isAdmin", impostata su true. User1 non ha affatto questa variabile. Alla riga 7, aggiungiamo la variabile isAdmin al prototipo di user1, e anche se è evidente dalla riga 10 che la variabile non è stata aggiunta all'oggetto user1 stesso, la console risponde positivamente, questa volta, quando controlliamo il valore di user1.isAdmin. Questo perché user1 eredita le proprietà del suo prototipo.
Vale anche la pena menzionare che il prototipo è a sua volta un oggetto, che a sua volta eredita proprietà e metodi dal suo prototipo, creando così una catena di prototipi. La catena termina con un prototipo nullo, quindi un approccio ragionevole per prevenire la Prototype Pollution è fare sì che l'oggetto con cui stiamo lavorando erediti esplicitamente da un prototipo nullo.
I cookie (spesso noti come cookie internet) sono file di testo con piccoli pezzi di dati — come nome utente e password — che vengono utilizzati per identificare il tuo computer mentre usi una rete. Cookie specifici vengono utilizzati per identificare utenti specifici e migliorare la loro esperienza di navigazione web.
Per gentile concessione di Kaspersky: https://www.kaspersky.com/resource-center/definitions/cookies
CookieJar è un oggetto per memorizzare i cookie.
Secondo la descrizione della vulnerabilità, essa deriva dal modo in cui Tough-Cookie inizializza i cookie. Poiché i cookie sono oggetti, sono teoricamente, almeno, vulnerabili alla Prototype Pollution.
Potendo manomettere gli oggetti e in particolare i cookie, tramite il prototipo dell'oggetto, l'attaccante può potenzialmente accedere a dati non autorizzati, eseguire codice remoto, causare un denial of service, dirottare la sessione se il sito web si affida ai cookie per la gestione della sessione ed estrarre dati sensibili dagli stessi cookie.
La patch è stata applicata al file: memstore.js. Secondo il tracciamento dei problemi così come la patch introdotta nella versione 4.1.3, per correggere la vulnerabilità, dobbiamo memorizzare i cookie in una mappa o creare l'oggetto this.idx. Creando this.idx usando: this.idx = Object.create(null); invece di this.idx = {}, mettiamo in pratica il mio suggerimento su come prevenire la Prototype Pollution nell'introduzione, ereditando da un prototipo nullo e tagliando la catena del prototipo.
Snyk ha pubblicato un Proof of Concept (PoC) per la vulnerabilità discussa. Ho costruito index.js basandomi su di esso. L'ho avvolto in una logica try-catch per catturare le eccezioni se si verificano, ho aggiunto output aggiuntivo per tenere traccia dell'avanzamento dei test e ho ottenuto l'output richiesto (es. "EXPLOITED SUCCESSFULLY" o "EXPLOITED FAILED"). Quando si esegue il comando: npm install [email protected] && node index.js Otteniamo il seguente output:
Quando si esegue il comando: npm install ./tough-cookie-2.5.0-PATCHED.tgz && node index.js Otteniamo il seguente output:
In entrambi gli scenari (esecuzione con la versione pubblicata 2.5.0 e con la mia versione patchata), siamo riusciti a impostare sia il cookie normale che il cookie sfruttato, ma nella versione patchata, non siamo riusciti ad accedere al cookie sfruttato.
In questa assegnazione ho imparato l'attacco di Prototype Pollution, ho imparato l'oggetto JavaScript e sono stato introdotto al pacchetto Tough-Cookie.
