A cura di: Alessandro Molinari ( Team hackerhood)
Di seguito ci serviremo di una piattaforma totalmente gratuita offerta da “PortSwigger” creatori di “Burp” il celebre programma per web app app pentesting, in modo da dare al lettore la possibilità di seguire passo a passo le dimostrazioni pratiche delle vulnerabilità illustrate poc’anzi ma anche ad approfondire ulteriormente l’argomento.
Dopo la creazione del proprio account su https://portswigger.net/ , apriremo la sezione “Access Control” ed il laboratorio “User ID controlled by request parameter” e vedremo la seguente spiegazione:
Questo laboratorio presenta una vulnerabilità Horizontal Access Control nella pagina dell’account utente, descrizione dell’obiettivo:
Laboratorio Horizontal Access Control
Per risolvere il laboratorio, è necessario ottenere la chiave API dell’utente carlos e inviarla come soluzione.
È possibile accedere al proprio account utilizzando le seguenti credenziali: wiener:peter
La piattaforma e’ ottima poiché fornisce la possibilità di effettuare pentesting come nel mondo reale accade spesso, cioè con la modalità “graybox” : ci vengono dati di un account utente regolare e ci chiedono di estrapolare i dati di altri account utente, ed e’ proprio così che questo laboratorio è strutturato.
Accediamo quindi al laboratorio dopo aver installato ed avviato Burp Suite, la “Community Edition” sarà più che sufficiente al nostro scopo: Burp o Burp Suite è un insieme di strumenti utilizzati per pentest delle applicazioni web. È sviluppato dalla società Portswigger, che è anche lo pseudonimo del suo fondatore Dafydd Stuttard.
BurpSuite mira a essere un insieme di strumenti completo e le sue capacità possono essere migliorate installando dei componenti aggiuntivi chiamati BApps.
È lo strumento più popolare tra i ricercatori professionisti della sicurezza delle applicazioni web e i cacciatori di bug. La sua facilità d’uso lo rende una scelta più adatta rispetto ad alternative gratuite come OWASP ZAP. Burp Suite è disponibile in un’edizione comunitaria gratuita, in un’edizione professionale che costa 399 dollari all’anno e in un’edizione aziendale che costa 399 dollari all’anno.
In pratica è un “man in the middle” proxy che ci consentirà di modificare a piacimento parametri,richieste o qualsiasi altra informazione venga scambiata tra le due entità altrimenti invisibile.
Laboratorio Horizontal Access Control
Selezioniamo “Proxy” ed avviamo “Intercept” : stiamo di fatto mettendoci “nel mezzo” tra la webapp ed il browser:
Facciamo quindi il login con le credenziali che ci sono state fornite e andiamo ad analizzare la “request” , la richiesta che viene effettuata al server :
Vediamo che il nome utente viene inviato tramite il parametro “id”:
GET /my-account?id=wiener HTTP/1.1
E che a tale utente corrisponde una determinata API key.
La webabb utilizzerà tale ID per controllare l’accesso quindi basterà alterarlo per ottenere la API key di un altro utente
Tramite il tasto destro del mouse clicchiamo su “send to repeater” al fine di poter modificare la richiesta e sostituire come tale parametro con l’id “carlos” :
E clicchiamo su “send” per inviare la richiesta alterata, l’app credera di aver ricevuto un richiesta leggittima dell’utente “Carlos” e ne mostrerà i dati o in questo caso la API key :
Mitigazione
Il problema principale in questo caso e che l’input che il client fornisce viene usato per effettuare una decisione di controllo di accesso e questo è la causa principale della maggior parte delle vulnerabilità delle webapp attualmente in circolazione. In alcuni casi questo tipo di vulnerabilità si trova a livello API , altre volte nei metodi utilizzati che possono essere anch’essi essere modificati con strumenti come Burp, altre volte invece come abbiamo visto sono dei parametri passati dal client.
Per mitigare questo tipo di vulnerabilità è imprescindibile trattare qualsiasi input proveniente dal client come potenzialmente dannoso e pericoloso e inoltre non deve essere usato per determinare una decisione o regole controllo degli accessi.
Laboratorio Vertical Privilege Escalation
Come abbiamo visto la VPE verifica quando un attaccante può accedere a funzionalità a cui non è autorizzato ad accedere.
Alcune applicazioni determinano i diritti di accesso o il ruolo dell’utente al momento dell’accesso e poi memorizzano queste informazioni in una posizione controllabile dall’utente, come un campo nascosto, un cookie o un parametro preimpostato della stringa di query. L’applicazione prende le successive decisioni di controllo dell’accesso in base al valore inviato. Ad esempio:
Questo approccio è fondamentalmente insicuro perché un utente può semplicemente modificare il valore e ottenere l’accesso a funzionalità a cui non è autorizzato, come le funzioni amministrative.
Accediamo quindi alla sezione dei laboratori chiamata “User role controlled by request parameter”.
Questo laboratorio ha un pannello di amministrazione in “ /admin”, che identifica gli amministratori usando un cookie falsificabile.
Risolvete il laboratorio accedendo al pannello di amministrazione e utilizzandolo per eliminare l’utente carlos.
È possibile accedere al proprio account utilizzando le seguenti credenziali: wiener:peter
Accediamo quindi con le credenziali fornite, e proviamo subito ad accedere alla pagina di amministrazione alterando l’url:
Ovviamente non ci riusciremo:
Al momento non conosciamo come funzioni internamente la webapp e quindi neanche come essa compia il controllo degli accessi, quindi la prima cosa da fare é cercare di scoprire come ciò avvenga:
Analizziamo nella sezione HTTP history la richiesta, dapprima selezionando “login” e in seguito “my account” , sezioni in cui troviamo molte informazioni utili:
Notiamo come vi siano due cookies, quello di sessione che come abbiamo visto evita che ci vengano richieste le credenziali ad ogni cambio di pagina e che potrebbe essere utilizzato per impersonare l’utente ed il cookie Admin con parametro “false”.
Ricordiamoci che anche i cookies sono input forniti dai client e che vanno trattati come potenzialmente malevoli o pericolosi.
Basterà quindi cambiari il valore del parametro Admin in “true” dopo aver inviato la richiesta alla sezione “repeater” con il tasto destro:
E cambiamo ora il valore nel anche cookies jar (sezione che contiene i nostri cookies):
Ed ecco che selezionando “my account” potremo accedere alla sezione dedicata agli amministratori con abilitate le funzioni a loro peculiari, cancellando quindi l’utente “wiener” completeremo quindi il laboratorio con successo.
Nuovamente quindi, un input inviato dal client non è stato considerato come potenzialmente dannoso o pericoloso.
Laboratorio Multi-step process with no access control on one step
(Vulnerabilita Access Control in processi multi step)
Come spiegato questo tipo di vulnerabilità potrebbe avere gravi conseguenze per qualsiasi entità che non effettui nella maniera corretta i controlli che sono coinvolti in processi che devono necessariamente rispettare un ordine preciso.
Merita inoltre di essere menzionata un altro tipo di vulnerabilità molto comune che potrebbe essere sfruttata: XSRF (cross-site request forgery). In quest’ultimo caso programmatore si aspetta che i passi per concludere correttamente un processo (nel nostro caso l’acquisto di un prodotto) siano necessariamente condotti uno dopo l’altro: selezione prodotto, aggiunta al carrello, pagamento. Nel caso questo processo però sia vulnerabile, per un attore malevolo sarebbe possibile aggiungere altri articoli al carrello anche dopo aver pagato, questo principio ovviamente anche ad altri processi in cui siano coinvolte procedure multi-step come stiamo per vedere.
Accediamo al laboratorio ed esaminiamone la spiegazione:
Questo laboratorio dispone di un pannello di amministrazione con un processo imperfetto in più fasi per cambiare il ruolo di un utente. È possibile familiarizzare con il pannello di amministrazione accedendo con le credenziali administrator:admin.
Per risolvere il laboratorio, accedete utilizzando le credenziali wiener:peter e sfruttate i controlli di accesso difettosi per promuovervi ad amministratore.
Inizialmente dovremo quindi cercare conoscere come funziona la webapp (mapping) per determinare, loggati come admin, le funzioni alle quali tale utente e in grado di accedere e successivamente proveremo ad accedere alle stesse funzioni ma partendo da un account utente ordinario.
Il pannello di amministrazione come vediamo ci da possibilità di promuovere l’utente ordinario ad un livello superiore od il contrario.
Nel momento in cui cerchiamo di compiere la suddetta azione sull’utente carlos (clic su “upgrade user” e poi “yes”)
notiamo che viene eseguita una richiesta di tipo POST all’endpoint /admin-roles contenente i seguenti parametri=valore:
username=carlos&action=upgrade
Cerchiamo di scoprire in seguito quale sia il passaggio successivo inviando la richiesta HTTP alla sezione repeater, e cliccando su “send”.
Scopriamo che viene eseguita una seconda richiesta allo stesso endpoint /admin-roles con i seguenti parametri:
action=upgrade&confirmed=true&username=carlos
Inviamo quindi la nuova richiesta a “repeater” ed effettivamente notiamo che l’utente carlos è stato promosso ad amministratore.
Nominiamo quindi i due tab in repeater “passo1” e “passo2”:
Qui é da notare come questo processo può essere automatizzato con altri strumenti ed estensioni di Burp, noi stiamo eseguendo la procedura manualmente a fini didattici.
In una web-app moderna vi sono infatti molti endpoint e testarli tutti manualmente sarebbe poco efficiente e monotono e sicuramente noioso, “Authorize” é per esempio un’estensione di Burp che viene usata per visitare la app con un account utente privilegiato ma utilizzando il cookies di sessione di utente ordinario, invia quindi ogni richiesta dal browser come tale utente ed a seconda della lunghezza o delle differenze nel codice delle risposte determina se vi sia o meno una vulnerabilità BAC.
Quello che faremo manualmente e esattamente questo:
Ora che abbiamo compreso almeno in parte come funziona la webapp, usciamo dall’account amministratore e rifacciamo il login con l’account utente regolare aprendo poi la sezione “cookies” dalla console del browser per esaminare il cookie di sessione.
Copiamo quindi tale cookie che ci identifica come utente agli occhi della webapp e lo sostituiamo a quello del coocke di sessione di admin all’interno di Burp nel “passo1” effettuando poi la richiesta con esso ed esaminandone la risposta:
“Unauthorized” ci indica che non siamo ovviamente autorizzati a compiere tale azione, poiché siamo utenti ordinari, qui il controllo dell’accesso é effettuato correttamente, il programmatore non si aspetta che si possa intervenire sul passaggio successivo poiche il precedente non puo essere compiuto ma gli endpoint di una webapp possono essere chiamati in qualsiasi ordine, ed i controlli vanno implementati su ognuno di essi, se eseguiamo infatti la stessa procedura sul passo 2 :
L’utente “carlos” era gia stato promosso quindi modifichiamo e cerchiamo di eseguire l’upgrade su “wiener”.
Ecco che l’utente regolare wiener può accedere al pannello di amministrazione, e risolviamo il laboratorio.
PREVENZIONE
Abbiamo esaminato la teoria ed ne abbiamo messo in pratica gli insegnamenti ma come evitare pero che si manifestino tale vulnerabilità?
- Usare un approccio security-centric, ossia che metta al centro del design la sicurezza, in cui gli accessi vengano sempre verificati e che si assicuri inoltre che tutte le richieste passino attraverso un controllo di accesso.
- Eccetto per le risorse pubbliche, negare l’accesso come opzione di default: cioè nessuno deve avere accesso ad una pagina se non le entità espressamente incluse nei controllo degli accessi, di modo che nel momento in cui una pagina viene messa in produzione, automaticamente nessuno che non sia stato espressamente autorizzato a farlo, non vi abbia accesso.
- Applicare il principio di least privilege sull’intera applicazione: dare agli utenti l’accesso alle sole risorse di cui hanno bisogno.
- Loggare qualsiasi evento di accesso.
- I controlli sugli accessi devono essere fatti server-side e mai client-side, come abbiamo visto.
Comments are closed