Hacking delle applicazioni Web: tecniche di attacco e contromisure

I siti, le piattaforme, le applicazioni Web costituiscono, nella società digitale, importanti asset per il perseguimento e la realizzazione degli obiettivi di business di un’organizzazione.

La caratteristica peculiare di queste risorse, peraltro, è costituita dal fatto che sono poste in uno spazio, come quello Web, intrinsecamente “pubblico”, visibile ed esposto ad una molteplicità di soggetti, anche malintenzionati.

Hacking delle applicazioni Web: i pattern di attacco

Il vertice aziendale dovrà dunque prestare un’attenzione particolare alla sicurezza del sito o dell’applicazione Web, anche con riferimento al nuovo quadro regolamentare in materia di data protection.

Di fronte ad un cyberspace invisibile, dematerializzato, denso di pericoli che minacciano la confidenzialità, l’integrità e la disponibilità dei dati e delle informazioni che transitano nelle Web application, quali strategie di difesa mettere in atto? Quali contromisure?

Per mettere in campo misure efficaci bisogna comprendere innanzitutto i pattern di attacco.

L’azione che un cyber criminale compie prima di colpire il suo target è quella di scoprire su di esso quante più informazioni possibili, cercando di svelare l’impronta, il cosiddetto “footprint” dell’applicazione.

Attraverso tool e servizi più o meno “intelligenti” e automatizzati (dal wpscan a Maltego), grazie anche all’osservazione delle URL generate dal sito e allo studio dei risultati da motori di ricerca pubblici (uno fra tutti, Whois), il criminal hacker riesce facilmente a ricostruirne le tecnologie utilizzate, la versione del server, i linguaggi di programmazione del front end e del back end, l’eventuale release del CMS implementato.

Se è bravo o fortunato può anche arrivare a collezionare abbastanza materiale per creare un pretext (cioè uno scenario) credibile e prepararsi ad impersonificare l’hosting provider in un eventuale attacco di social engineering.

Dopo questa prima “occhiata” in perlustrazione, passerà a una breve analisi del front end, ponendosi una serie di domande, tra cui:

1. Come vengono validati gli input immessi nei form? Se il processo di validazione degli input è solo lato client, sarà possibile intercettare il traffico usando il proprio browser come proxy (oppure tool come Burbsuite) e modificare a mano le stringhe inserite prima di mandarle al server.
2. Esiste un’interazione con un database? Se esiste, inizierà ad iniettare sequenze sintattiche in uno dei linguaggi di query (ad esempio l’SQL) in modo tale da “confondere” la logica dell’interrogazione e ottenere in risposta dalla base dati non solo il consenso al login ma tutta una serie di informazioni, potenzialmente devastante per il titolare della base informativa.
3. Esiste un form di accesso ad un’area riservata? Nel caso esista, intenterà un attacco alle password di tipo brute force (con Hydra per dirne uno, ma anche Cain & Abel), provando tutte le possibili combinazioni, oppure, se ha poco tempo, generando i tentativi tramite “dizionari” precompilati e acquistabili a pochi euro, nello spazio grigio del Deep Web.
4. Come viene gestita l’autenticazione al sito? Attraverso sessione? Se il time out di sessione si estende abbastanza nel tempo, potrebbe tentare di predire lo schema di generazione della sequenza del token, violandola. Attraverso cookie? In questo caso, con i giusti “strumenti del mestiere”, come ZAP o Burb Suite, potrà tentare di intercettare proprio il cookie contenente l’ID di autenticazione.
5. Come funziona il passaggio delle variabili tra una pagina e l’altra dell’applicazione? Se il passaggio avviene tramite query string, dunque nell’URL generata sono presenti contenuti interessanti, sarà possibile manipolare i parametri per accedere a zone riservate del perimetro dell’applicazione.

Se dovesse riuscire a trovare, a questo livello, il punto debole dell’applicazione, probabilmente l’attacco lo avrà tenuto impegnato per non più di un paio d’ore, senza nemmeno scomodare le proprie conoscenze psico-antropologiche per violare il sistema attraverso raffinate metodologie di ingegneria sociale; magari impiegherà il tempo restante a condividere i suoi successi a scopo dimostrativo, con effetti devastanti per l’organizzazione vittima, sia dal punto di vista economico che reputazionale.

Hacking delle applicazioni Web: le contromisure per proteggerci

Non mancano, per fortuna, le possibilità di difesa di fronte ad un attacco mirato alle nostre applicazioni Web. Ecco una breve check list utile per realizzare un efficace piano di difesa

1. Richiedere alla software house l’applicazione di metodologie e di standard di sviluppo di un codice di programmazione sicuro, come quella divulgata da OWASP.
2. Richiedere una costante interfaccia con le fonti istituzionali (ad esempio attraverso i bollettini del CERT-IT) per tenersi aggiornati sulle nuove vulnerabilità identificate dalla comunità di cyber security.
3. Verificare un costante aggiornamento del software e contrattualizzare un soggetto deputato alla manutenzione delle risorse tecniche di trattamento.
4. Eseguire periodici Web application pentest, anche attraverso tool automatizzati, come OWASP ZAP; questi programmi, anche se non arrivano a rilevare vulnerabilità “di nicchia” per cui sarebbe necessaria una furbizia “umana” o tecniche raffinate, possono dare il loro contributo per contrastare macro-criticità e orientare le software house nella soluzione di problematiche comuni.
5. Prima del deploy o in fase di test, effettuare un Fuzz Test, un’operazione che “stressa” l’applicazione, inviando input casuali, sbagliati, abnormi, per testare la reazione del sistema progettato. Una prova di questo genere è molto utile per rilevare, oltre ai bug, vulnerabilità di tipo Buffer Overflow ed evitare che, in caso di input non controllati, il back end reagisca dando il controllo all’attaccante.
6. Controllare, manualmente o in modo automatizzato, il codice sorgente, con particolare attenzione alla gestione della sessione, e alla validazione dei dati di input dai form. Dobbiamo garantire che non ci sia alcuna pagina contenente informazioni riservate o strategiche, collocata fuori dal perimetro della sessione di autenticazione.
7. Mappare le funzionalità dell’applicazione che sono realizzate con plugin o software di terze parti, per estendere a questi soggetti la verifica dei requisiti di sicurezza e di conformità alla normativa applicabile (ad esempio quella europea sulla protezione dei dati, il GDPR, anche con particolare riguardo al trasferimento eventuale di dati fuori dall’UE).
8. Contro le injection, siano esse “iniezioni” di comandi per la shell del server, o di sintassi SQL o LDAP per interagire con basi informative sottese all’applicazione, è importante:
   1. parametrizzare le query, cioè comporle con le richieste che l’utente inserisce dal form, considerate come parametri di una funzione (e dunque, opportunamente validate e sanificate) e non come “pezzi” di stringa semplicemente da concatenare;
   2. disabilitare la versione “verbosa” delle risposte del database la quale, se avesse un ruolo legittimo nel debug in fase di sviluppo del codice, darebbe all’attaccante informazioni cruciali per la costruzione sintattica di stringhe in grado di violare il sistema;
   3. non passare le variabili tramite metodo GET (per cui sarebbero visibili in query string) ma utilizzare il metodo POST;
   4. utilizzare funzioni per depotenziare i comandi attraverso l’escape dei caratteri pericolosi i quali, se non neutralizzati, potrebbero essere eseguiti dall’applicazione o dalla riga di comando del server perché “taggati” come script;
   5. disabilitare, lato back end, le funzioni, presenti in alcuni linguaggi di programmazione, che permettono l’apertura di URL in automatico o l’inclusione di URL nel codice sorgente (ad esempio, in php, allow_url_open() o allow_url_include()), o l’esecuzione da shell di un comando (shell_exec()).
9. Se l’hosting è “in house”, isolare il Web server, o il database, in un segmento di rete separato (DMZ);
10. Configurare il Web server con il minimo footprint, cioè disabilitando tutti i servizi non necessari e facendo interagire il database con un privilegio minimo sul sistema.
11. Se possibile, abilitare la cifratura del database (a livello server o a livello DBMS);
12. Migrare l’applicazione su protocollo sicuro https, che “impacchetta” il layer http in un canale basato su protocollo di trasporto, garantito da certificato TLS.
13. Se il sito o l’applicazione Web utilizza a qualsiasi livello il linguaggio XML, disabilitare dal parser la funzionalità che accetta entità esterne per l’elaborazione degli schemi.
14. Se il sito è in hosting, verificare la compatibilità dei tempi di ripristino garantiti dal provider rispetto al margine di tollerabilità dell’organizzazione (BIA): se è il caso, negoziare economicamente tempi minori, per evitare di essere esposti ad impatti conseguenti la perdita di disponibilità dei dati.
15. Se il sito o l’applicazione Web agisce su (e veicola) dati particolarmente impattanti, valutare l’utilizzo di un Web application firewall (ad esempio Bitninja), che consente il monitoraggio di eventi anomali sull’applicazione.

Conclusioni

Le applicazioni Web rappresentano dunque, nell’odierna società dematerializzata, uno dei principali veicoli di comunicazione, una vetrina verso potenziali customer e un canale privilegiato di azione finalizzata ad obiettivi di business.

Non dimentichiamo tuttavia che, quanto più raggiungono diffusione e popolarità, tanto più diventano un appetibile bersaglio per i criminali informatici, intenti si, ad ottenere un facile guadagno economico, ma anche semplicemente a screditare la vittima sotto un profilo reputazionale con attacchi dimostrativi, che spesso generano, nell’organizzazione violata, impatti economici indiretti; sarà dunque compito del titolare dell’organizzazione (e del trattamento) diligente, quello di mettere in atto tutte le misure di sicurezza adeguate a proteggere non solo le informazioni rilevanti per il suo business ma anche i dati personali degli interessati che a qualsiasi titolo detiene.