Com'è andato il mio primo Pentest

Qualche tempo fa (ormai tanto tempo fa!) un mio cliente mi chiese un WAPT (Web Application Penetration Test) per la sua azienda: l’app in questione era stata sviluppata in ambiente Microsoft, pertanto era tutto ASP.NET e framework .NET, così cominciò la sfida.

Non avevo nessuna informazione né sul sistema né sulla web application, così è diventato ancora più stimolante. L’unica informazione che avevo era la versione del web server, il linguaggio in cui era scritta l’app e un account admin per testare anche le parti interne.
L’applicazione che stavo testando era in ambiente di pre-produzione, ma in realtà prod stava sullo stesso IP, quindi ho evitato di testarla contro attacchi DoS (Denial of Service) in quanto poteva diventare un problema (uff!).

Primo step: Recon

Non avendo idea di come fosse strutturata ho cominciato dalle basi: information gathering e reconnaissance.

DNS Lookup

Questa spesso è la mia prima mossa quando ho a che fare con una webapp. Un lookup DNS può darti molte informazioni su com’è strutturata l’azienda internamente, ma quella volta non fui così fortunato: l’unica info utile che recuperai era il nameserver, un provider estero, quindi mi fermai.

NMAP Scan

Un altro ottimo punto dal quale partire è uno scan con NMAP, anche se la natura dell’app (webapp in questo caso) non è il target per cui è nato questo strumento, le informazioni che possiamo ricavarne sono comunque utili: porte aperte, firewall, ids e compagnia cantante.

# Nmap 7.80 scan initiated Tue Aug  3 15:11:12 2021 as: nmap -sC -sV -p- -v -oN nmap-1-65535-sV-sC.txt ---OMISSIS---.com
Nmap scan report for ---OMISSIS---.com (xxx.xxx.xxx.xxx)
Host is up (0.042s latency).
Not shown: 65533 filtered ports
PORT    STATE SERVICE  VERSION
80/tcp  open  http     Microsoft IIS httpd 10.0
|_http-favicon: Unknown favicon MD5: 0F7EXXXXXXXXXXXXXXXXXXXXXXXX2C16
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Microsoft-IIS/10.0
| http-title:         ---OMISSIS---
|_Requested resource was http://---OMISSIS---.com/
443/tcp open  ssl/http Microsoft IIS httpd 10.0
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to http://---OMISSIS---.com/
| ssl-cert: Subject: commonName=---OMISSIS---.com/organizationName=---OMISSIS---./countryName=IE
| Subject Alternative Name: DNS:---OMISSIS---.com
| Issuer: commonName=GeoTrust EV RSA CA 2018/organizationName=DigiCert Inc/countryName=US
| Public Key type: rsa
| Public Key bits: 4096
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-05-26T00:00:00
| Not valid after:  2022-06-14T23:59:59
| MD5:   7bf5 XXXX XXXX XXXX XXXX XXXX XXXX 1149
|_SHA-1: bb2c XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX ce6c
|_ssl-date: 2021-08-03T13:13:37+00:00; 0s from scanner time.
| tls-alpn: 
|   h2
|_  http/1.1
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Aug  3 15:13:38 2021 -- 1 IP address (1 host up) scanned in 145.48 seconds

Niente da fare, ancora una volta non abbiamo nessuna informazione utile, dobbiamo andare avanti!

SSL Scan

Dopo NMAP ho voluto provare uno scan con sslscan, non che poi mi sarei spinto a fare un attacco sui cipher, però erano sempre informazioni in più:

sslscan ---OMISSIS---.com                                                                                                                                    1 ⨯
Version: 2.0.7-static
OpenSSL 1.1.1j-dev  xx XXX xxxx

Connected to xxx.xxx.xxx.xxx

Testing SSL server ---OMISSIS---.com on port 443 using SNI name ---OMISSIS---.com

SSL/TLS Protocols:
SSLv2     disabled
SSLv3     enabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   disabled

TLS Fallback SCSV:
Server does not support TLS Fallback SCSV

TLS renegotiation:
Secure session renegotiation supported

TLS Compression:
Compression disabled

Heartbleed:
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
Accepted  TLSv1.2  128 bits  RC4-SHA                      
Accepted  TLSv1.2  128 bits  RC4-MD5                      
Preferred TLSv1.1  128 bits  RC4-SHA                      
Accepted  TLSv1.1  128 bits  RC4-MD5                      
Preferred TLSv1.0  128 bits  RC4-SHA                      
Accepted  TLSv1.0  128 bits  RC4-MD5

SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    4096

Subject:  ---OMISSIS---.com
Altnames: DNS:---OMISSIS---.com
Issuer:   GeoTrust EV RSA CA 2018

Not valid before: May 26 00:00:00 2021 GMT
Not valid after:  Jun 14 23:59:59 2022 GMT

Questo, purtroppo, fu l’unico risultato rilevante della breve fase di ricognizione che avevo fatto: SSLv3 e TLSv1.0 abilitati (che sappiamo non essere più sicuri già da tempo). Per completare avevamo un bel TLSv1.2 ma con l’uso di RC4 e MD5, quindi non proprio il massimo.

Secondo step: Attacco

Una volta terminata la fase di reconnaissance, ho approfondito l’applicazione web da un altro punto di vista.

Static Code Analysis

Ovviamente non avevo il codice sorgente dell’applicazione, ma avevo l’HTML generato: questo significa molti script Javascript, librerie, risorse esterne e (se siete fortunati) qualche commento utile nel codice.

Ho iniziato a esaminare l’HTML e ho notato che venivano utilizzate molte librerie, alcune delle quali erano vulnerabili o non più mantenute.

Questa analisi mi ha aiutato nelle fasi successive.

Login form e Session Management

La prima analisi sulla pagina di login ha riguardato i cookie. L’applicazione web che ho testato non aggiorna l’ID di sessione dopo il login e nemmeno se la pagina viene aggiornata (quando l’utente non è autenticato), inoltre c’erano alcuni cookie che erano ancora validi dopo il logout.

In secondo luogo, l’input della password non è stato gestito correttamente, in quanto il tipo di input era “text” e non “password”: l’offuscamento è avvenuto tramite un font speciale applicato a questo input.

Inoltre questo input non riesce a gestire correttamente il carattere virgoletta singola ( ‘ ), infatti se inserito causava il crash del sistema di login che rimaneva in attesa, oltre al fatto di far scomparire l’offuscamento del campo. La causa era che la password veniva rispedita al client (dal server) in una funzione Javascript che utilizzava le virgolette singole per passare l’argomento (la password).

XSS

Dopo un po’ di lavoro ho scoperto alcuni campi che potevano essere riempiti con testo libero, ho provato quindi una XSS stupida:

<script>alert(1)</script>

Inaspettatamente, l’applicazione si è bloccata. Anche se il framework si è “accorto” del potenziale attacco, il nostro XSS ha generato un’eccezione non gestita, rivelando la versione del framework e lo stack trace.

Una volta ottenuta la versione utilizzata per costruire l’applicazione web, ho cercato un po’ su Google e ho trovato un modo per non far più crashare l’applicazione: utilizzare la codifica Unicode.

Ho costruito il nuovo XSS con parentesi angolari Unicode e finalmente ho ottenuto un XSS stored!

Fase di Reporting

Questa fase è la più importante e va iniziata quando si avvia il Penetration Test. In Kali troverete alcuni strumenti specifici per il pt reporting, ma potete usare anche il vim se volete.

Il report che ho scritto l’ho diviso in 5 sezione e 2 appendici:

Activity Overview — In questa sezione ho descritto l’attività, le regole di ingaggio, la metodologia utilizzata e gli strumenti.
Findings —Solitamente questa sezione contiene solo le evidenze di eventuali vulnerabilità trovate da scanner o vulnerability software vari.
Attack Narrative — Questa sezione invece descrive la fase di attacco: come è stato fatto l’attacco, con che vulnerabilità specifica, come è stata sfruttata e come rimediare.
Remediation Plan — La sezione di remediation contiene invece tutte le remediation suggerite (sia che riguardino il PT e quindi l’attacco in sé, sia le vulnerabilità meno rilevanti).
Conclusions — Qui invece si riportano un po’ di conclusioni per riassumere il report.

É bene descrivere efficacemente tutti gli step che si seguono o che si sono percorsi, ed è altrettanto importante riportare i propri contatti per poter eventualmente discutere i risultati con il cliente.

Risorse utili

Linee guida internazionali di Security

NIST 800–100 “Information Security Handbook” –
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-100.pdf
NIST 800–95 “Guide to Secure Web Services” –
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf
NIST 800–53 “Security and Privacy Controls for
Information Systems and Organizations” –
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
OWASP Web Security Testing Guide –
https://owasp.org/www-project-web-security-testing-guide/stable/
OSSTMM — https://www.isecom.org/OSSTMM.3.pdf

Secure Cipher Suites

Altri link:

Conclusioni

La webapp che ho analizzato era abbastanza sicura, ma c’erano ancora alcune misure tecniche da implementare per migliorare la sicurezza complessiva. Disattivare SSL v3 e TLS 1.0/1.1 e utilizzare suite di cifratura (cipher suite) sicure aumenta la sicurezza delle connessioni HTTPS, impedendo alcuni tipi di attacchi man-in-the-middle. Separare gli ambienti di sviluppo/staging da quelli di produzione è sempre un’ottima pratica di sviluppo, anche per evitare attacchi.
Una corretta gestione della sessione riduce drasticamente il rischio di attacchi Session Hijacking e CSRF (Cross-Site Request Forgery). L’inserimento della password nel modulo di login deve essere gestito correttamente e necessita di alcuni controlli aggiuntivi lato server. Gli XSS possono essere evitati effettuando controlli più approfonditi, utilizzando correttamente il framework di sviluppo, implementando una codifica adeguata e gestendo le eccezioni.
Limitare le informazioni divulgate (versione del server web, versione del framework e stack trace) potrebbe mettere in difficoltà l’attaccante e quindi aumentare il livello di sicurezza complessivo (seppur limitatamente). Assicurarsi di gestire correttamente tutte le eccezioni che potrebbero essere lanciate per evitare situazioni impreviste.

Seguire sempre le migliori best practice del settore: NIST, OWASP, ISECOM e tutta la comunità della sicurezza saranno i vostri migliori amici.

L’unico consiglio che posso darvi è di provare, provare e riprovare, perché ogni applicazione o sistema è diverso: nessuna applicazione è sicura al 100%, anche se siete dei n00b come me.