Pillole di #penetrationtest

Le vulnerabilità da File Inclusion, inclusione Locale o Remota che sia, dipendono (come molte vulnerabilità) da difetti di programmazione.

In sostanza in un il linguaggio che consenta l'inclusione dinamica di codice la programmazione tende a suddividere l'intero programma in moduli caricati secondo le necessità durante l'esecuzione. Questo semplifica la gestione della complessità ma apre la porta allo sfruttamento malevolo di questa tecnica quando si abbassi la soglia di controllo su cosa venga incluso dinamicamente, specialmente quando questo dipende da un input utente.

Il problema è il medesimo sia che la risorsa caricata sia locale al server erogante il servizio web (nel caso di applicazioni Web), sia che sia raggiunta via rete attraverso un qualche protocollo di comunicazione (tipicamente http).

L'esempio tipico è l'inclusione delle versioni localizzate linguisticamente delle applicazioni in ragione di una variabile CGI, un cookie o qualsivoglia ente dipendente dall'utente.
Tanto è diffuso il problema che il sistema di classificazione Common Weakness Enumeration del MITRE ha identificate alcune classi per questo problema.

Per il PHP, ad esempio, identifica la CWE-98 per il PHP: Improper Control of Filename for Include/Require Statement in PHP Program.
Ma il PHP non è l'unico linguaggio a subire le conseguenze di uno sfruttamento delle tecniche di file inclusion; ad esempio con la CWE-611 (Information Exposure Through XML External Entity Reference) e CWE-827 (Improper Control of Document Type Definition) il MITRE identifica i problemi derivanti dalla tecnica XML External Entity (XXE) Processing (che consente inclusione di porzioni di documento XML da risorse esterne) che sono alla base di alcune vulnerabilità note (per difetto di controllo sulla inclusione) di alcuni prodotti, come descritto da CVE-2019-3774 e CVE-2018-12463.

Questa vulnerabilità riguarda tutte quelle applicazioni Web e API che non proteggono adeguatamente i dati sensibili, come finanziari o sanitari. Gli aggressori possono rubare o modificare tali dati scarsamente protetti per condurre frodi con carte di credito, furti di identità o altri crimini.
La protezione del dato è intesa sia quando è a riposo, ad esempio all'interno di un db, che in movimento (quando viene trasmesso).
Un'applicazione che soffre di questa vulnerabilità potrebbe utilizzare protocolli di scambio non criptati come HTTP al posto di HTTPS, salvare dati sensibili in chiaro sul db, utilizzare meccanismi di crittografia deboli, oppure non applicare policy tali da proteggere i dati.
Un classico scenario è quello di un'applicazione che cripta i numeri di carta di credito quando li memorizza nel db. Tuttavia, questi dati vengono decrittografati automaticamente quando vengono recuperati, consentendo ad esempio, se vulnerabile ad una sql injection di recuperare i numeri di carta di credito in chiaro.
Certo che quest'ultima applicazione è stata proprio sviluppata con i piedi! ;-)

Avaddon: il ransomware che triplica le possibilità di estorsione
Come ho detto svariate volte i ransomware sono i malware che maggiormente si sono evoluti nelle capacità di attacco ma soprattutto di pressione nei confronti della vittima.
Se inizialmente WannaCry o NotPetya si limitavano a criptare i dati su disco e richiedere un riscatto per il rilascio delle chiavi di decrittografia in seguto questi malware hanno iniziato ad adottare il meccanismo della doppia estorsione.
"Se non ci paghi oltre a non ricevere le chiavi per decriptare i tuoi dati li esporremo on line"
Naturalmente questo mette molta pressione sulle vittima specie se sono stati trafugati dati sensibili.
Ma Avaddon è stato il primo ransomware ad andare oltre:
"Se non ci paghi non riceverai le chiavi, i tuoi dati verranno esposti sul web e subirai in attacco DDos alla tua infrastruttura!"
Ad oggi anche altri malware appartenenti a questa categoria utilizzano la tecnica della tripla estorsione e tra questi troviamo sia Egregor che SunCrypt.
Secondo voi i ransomware arriveranno alla estorsione quadrupla?
La risposta è che lo hanno già fatto, ma questo sarà oggetto di una prossima pillola

Continuiamo nel nostro viaggio nelle top ten #Owasp.
Oggi vi parlo della #BrokenAutenthication.
Con questo termine si definiscono quelle routine all'interno di ogni applicazione che sono demandate al processo di autenticazione e che essendo sviluppate male permettono ad un attaccante di ottenere l'accesso all'applicazione con privilegi maggiori di quelli previsti oppure addirittura quando non dovrebbero accedere affatto.
Lo sviluppo con poca attenzione alla sicurezza può permettere ad un attaccante l'accesso a password, chiavi di autenticazione, token di sessione consentendogli l'assunzione di un'identità non legittima.
Ogni routine demandata all'autenticazione dovrebbe implementare funzioni che non permettano il credential stuffing, l'utilizzo di attacchi brute force, l'implementazione di procedure di recovery password deboli o di password in chiaro, l'esposizione di session id negli url e (purtroppo) tanto altro.
Come proteggersi? Implementando routine di autenticazione con delay incrementali in caso di fallimento dell'autenticazione, implementazione di check per password deboli, utilizzo di routine di generazione dei sessioni ID con alta entropia, invalidazione dei session ID dopo il logout etc...