Su questo capitolo mi soffermero’ parecchio in quando voglio affiancare alla documentazione ufficiale del corso tutte le nozioni che sto acquisento grazie al libro “Attacking and Exploiting Modern Web Application” di cui abbiamo parlato in live con gli autori.
Nel contesto del PenTesting possiamo identificare tre macro tipologie di test: black-box, white-box, grey-box. Senza giranci troppo attorno si tratta di eseguire i test con accesso a diversi livelli di informazioni o con o senza particolari restrizioni. L’ambito white-box prevede un accesso totale alle componenti dell’applicazione, al codice ed alla documentazione; proprio grazie al citato libro su questo fronte faro’ approfondimenti specifici che escono dal contesto del Penetration Testing e toccano l’ambito del bug hunting. Va da se che l’ambito black-box e’ l’esatto opposto, ovvero non vengono condivide informazioni di nessun tipo con il team di PenTesting ma vengono definiti degli scope precisi. In mezzo abbiamo la zona grigia dove vengono condivise informazioni parziali per eseguire i test.
Una delle prime attivita’ riguarda l’individuazione e l’enumerazione delle applicazioni da esaminare. Analizzando i servizi http attivi sul sistema con tools come nmap e Burp Suite e’ possibile determinare la versione del web server attivo ed eventuali dettagli sull’applicazione oggetto del security test (rif. Web Application Attacks CheckList).
Anche la verifica delle directory esposte (tramite tools come gobuster o dirguster) puo’ rivelare informazioni interessanti:
In caso si stia lavorando su sistemi espotti ad internet esistono delle utility online che posso essere di supporto per la verifica delle componenti applicative di un determinato sito web. Molte certificazioni citano Wappalyzer come strumento utile che effettivamente da un ottimo resoconto di quanto esposto dal sito, suggerisco l’utilizzo anche di Shodan.io per lo stesso scopo e che in piu’ potrebbe fungere da passive scanner per eventuali vulnerabilita’ esposte.
Pensi sia altamente ridondante parlare di questa soluzione. E’ innegabilmente di enorme ausilio e suggerisco agli interessati di valutare l’accademy di PortSwigger per prendere confidenza con lo strumento e con l’analisi delle principali vulnerabilita’ del mondo web.
Analizzare il codice lato client dell’applicazione e’ fondamentale. Le moderne applicazioni fanno un uso intenso di Java Script per migliorare la UX. Le componenti dell’applicazione sono di fatto delle librerie che gli sviluppatori utilizzano per restituire delle funzionalita’ all’utente e si possono considerare dei moduli esterni dell’applicazione che, esattamente come i software di una infrastruttura, vanno gestiti ed aggiornati. Anche queste componenti possono presentare delle vulnerabilita’ note che, se trascurate, possono mettere a rischio l’intera applicazione ed i dati da questa gestiti.
Anche la verifica degli headers consente di accedere a diverse informazioni utili all’analisi come la presenza di tecnologie di detection/protection a livello web (es: WAF) o la presenza di specifiche tecnilogie e configurazioni sul sistema target.
Riprendendo un esempio su cui sto lavorando in questo periodo, analizzando la risposta del mio server di test di Zabbix e’ possibile vedere il contenuto di una specifica informazione: il SERVER dove e’ hosted l’applicazione di dichiara come un Apache/2.4.52 su sistema operativo Ubuntu.
Come ultimo spunto possiamo prendere in considerazione i file di supporto ai motori di ricerca come il famigerato robots.txt in cui possiamo individuare diverse directory del sito web che sono solitamente dichiarate come accessibili o inaccessibili dai crawler. L’ipotesi e’ che se una directory e’ dichiarata come inaccessibile dal crawler evidentemente esiste.
L’utilizzo di API per gestire integrazioni con altri sistemi e’ molto frequente e spesso queste funzionalita’ sono, almeno in parte, attive di default. Questa funzionalita’ rientra necessariamente tra le componenti da verificare durante un security test.
Anche per questa componente puo’ tornare utile gobuster per andare a caccia delle chiamate a livello URL supportate dalle API o, se possibile, ci si puo’ affidare alla documentazione delle stesse API che solitamente e’ ben strutturata per consentire agli sviluppatori di utilizzare la funzionalita’ al meglio.
Una volta mappate le API e’ possibile eseguire delle chiamate all’applicazione per analizzare nel dettaglio il comportamento e valitarme le risposte al fine di individuare eventuali anomalie.
In questo post mi sono limitato a fare una carrellata delle azioni di enumeration che possiamo eseguire su un target scassico come una web application. Nei prossimi post ci dedichiamo alla comprensioni dei tipici attacchi web.