Information Disclosure

L’impatto di questa vulnerabilità è variabile poichè dipende da quanto l’informazione acquisita è importante.  Alcuni impatti potrebbero essere i seguenti:

1. Attacchi su larga scala: se l’informazione ottenuta è, per esempio, una versione dell’applicativo o del web server nell’header della pagina, il rischio è quello di finire vittime di attacchi automatizzati su larga scala poichè, anche con una ricognizione di base e poche richieste, tali informazioni potrebbero essere rinvenute facilmente; inoltre, alcuni motori di ricerca specializzati (come Shodan e Censys) indicizzano le versioni rinvenute e le vulnerabilità presenti (se applicabili teoricamente) aumentando, di conseguenza, il fattore di rischio.
2. Brute Force: spesso nel sito web o anche in altri applicativi, potrebbero essere esposti usernames o nomi di risorse, queste informazioni potrebbero rivelarsi particolarmente utili per attacchi di tipo Brute Force, Credential Stuffing e/o Password Guessing.
3. Phishing mirato: molte di queste informazioni potrebbero essere importanti ad un attaccante per creare delle email mirate alle risorse umane della società.

Solitamente il CVSS (punteggio per categorizzare il livello di gravità delle vulnerabilità) è di livello medio/basso (salvo particolari casi).

Non esistono vere e proprie tipologie di attacco, esistono però diversi tipi di dati ottenibili:

• Information Disclosure attraverso misconfigurazioni di web server, modalità di debug attive, etc. Quindi l’esposizione involontaria di informazioni tecniche riguardanti il server o la struttura.
• Information Disclosure attraverso file di informazioni riguardanti il server e applicativi installati (per esempio: phpinfo.php)
• Information Disclosure attraverso documenti o foto condivise nel sito web o in altre fonti in cui non è stata eseguita una corretta pulizia dei metadati, andando così ad ottenere informazioni su software usati, sistemi operativi, percorsi del server e nomi utenti (queste verifiche solitamente si effettuano con l’analisi OSINT).

Questa tipologia di vulnerabilità, dunque, comprende al proprio interno varie altre sottocategorie come, ad esempio:

• Username Enumeration: ovverosia la possibilità di ottenere informazioni su quali siano gli username utilizzati per l’accesso ad una specifica piattaforma o applicativo.
• Directory Listing: la visualizzazione e l’accesso ad alcuni file e directory indicizzate; la maggior parte delle volte, questi file non dovrebbero essere accessibili ad un utente non autorizzato. Questa vulnerabilità è frutto di una misconfigurazione facilmente mitigabile attraverso una riconfigurazione dello stesso webserver/application server.
• Information Leaks: alcune CVE possono comportare l’ottenimento di alcune informazioni (tendenzialmente riservate). Per esempio, sfruttando la CVE-2000-0649, attraverso una semplice richiesta in HTTP 1.0 il server risponde nel body con l’indirizzo IP interno.

Alcuni esempi di questa tipologia di vulnerabilità potrebbero essere i seguenti:

1. Un esempio per ottenere le versioni dei web server o applicativi è quello di provocare appositamente diversi status codes HTTP, poiché alle volte la pagina di errore può contenere la versione del web server, alcuni esempi pratici per ottenere l’informazione potrebbero essere i seguenti:
• Aggiungere nell’url una pagina inesistente: “/thispagedoesntexists.php”, per generare un errore 404;
• Aggiungere nell’url caratteri speciali come apici o altri caratteri simili per innescare possibili errori nel server: /”> o /’, per generare errori 500;
• Cercare delle pagine le quali solitamente non dovrebbero essere accessibili da utenti non autenticati, per esempio, una di queste potrebbe essere: “/server-status”, per generare errori 403.





Qui sotto vedremo un esempio in cui andremo a inserire una pagina non esistente nella barra dell’URL, la pagina andrà in errore status code 404 mostrando la versione dell’applicativo:








2. Un altro esempio abbastanza comune è quello di ottenere la versione del CMS WordPress, qui sotto elencati alcuni dei modi per poter ottenerla:
• A volte è inserita come meta tag all’inizio del file HTML
• Spesso alcuni file di wordpress (come per esempio: wp-emoji) contengono nel link la versione di WordPress
• Nelle versioni precedenti di WordPress, la versione era presente nel file “/readme.html”
• Nel file all’interno del percorso “/feed” a volte potrebbe essere presente la versione di WordPress all’interno del tag “<generator>”.





3. Enumerare il web server è molto utile per ottenere vulnerabilità di tipo Information Disclosure. L’enumerazione può portare a rilevare pagine contenenti informazioni riguardo a versioni o path dell’applicativo.
   
   
   Di seguito vedremo un esempio di questo tipo di attacco: attraverso l’enumerazione dei file dell’applicativo si potrà accedere anche al file “phpinfo.php”, file di informazione di PHP che non dovrebbe assolutamente essere esposto alla rete poiché espone molteplici informazioni concernenti sia il webserver che informazioni inerenti ai software installati (per esempio: versione sistema operativo, versione del Kernel, versioni web server, versioni DBMS, etc.):
   
   
   





4. Un altro modo per poter “innescare” questa vulnerabilità è quella di provare a generare degli errori, inserendo nei campi o nei parametri (GET o POST) caratteri speciali o lettere/numeri che l’applicativo non si aspetta; così facendo l’applicazione potrebbe restituire all’interno della pagina errori di diverso tipo:
   • Errori SQL, esponendo la versione, nomi di database, tabelle, colonne e forma della query effettuata. In questo caso, innescare tale vulnerabilità può portare alla rilevazione di ulteriori vulnerabilità di tipo SQL Injection.
   • Errori PHP, esponendo il percorso assoluto o relativo del file, versione, tipologia di sistema operativo (la si può notare dal path del file, in caso ci fosse), funzioni PHP, possibili parametri in GET o in POST richiesti dalla pagina.
   • Versioni di applicativi o software: alcune volte, se la gestione di errori e/o le validazioni dell’input non sono state fatte ad hoc, il server potrebbe restituire versioni degli applicativi o dei software installati.

   
   
   Un attaccante potrebbe dunque intuire – in base alla tipologia di errore restituito dalla pagina – quale altra tipologia di vulnerabilità potrebbe sfruttare. (come per esempio: XSS, RCE, Buffer Overflow).
   
   
   Qui sotto vedremo un esempio dove l’input di un parametro in GET non è stato gestito correttamente, generando un errore SQL esponendo diverse informazioni, tra cui: il DBMS, query con nomi di tabelle e colonne, percorso assoluto del file PHP e una parte del contenuto di quest’ultimo:

   
   
   

Alcuni modi per difendersi da questa tipologia di vulnerabilità potrebbero essere i seguenti:

• Modifica della configurazione del web server o dell’applicativo in modo da non esporre – nell’header o nella risposta – informazioni riguardo alle versioni del web server o delle dipendenze.
• Disabilitazione della/e modalità di debug.
• Corretta configurazione degli accessi alle pagine web e directories degli applicativi.
• Porre una certa attenzione ai file pubblicati online e negli applicativi; evitare di esporre – se possibile – file di informazioni di dipendenze o README, mascherare o rimuovere l’head dei file delle dipendenze, i quali potrebbero contenere informazioni sulle versioni in uso.
• Gestire correttamente i possibili errori, quindi sanificare e validare gli input, in modo tale da non restituire nessun tipo di errore all’utente.

La prevenzione e le implementazioni delle mitigazioni rispetto a questa tipologia di vulnerabilità sono generalmente molto veloci.