OWASP Top 10 2013 – A7 Funzione di controllo dell'accesso mancante

Tempo di lettura: 7 minuti

L’Open Web Application Security Project (OWASP) è una community online, un progetto open-source che offre consigli, guide, articoli e software nell’ambito della sicurezza delle applicazioni. L’OWASP Top 10 include una lista delle maggiori vulnerabilità che un’applicazione web può avere, e l’obbiettivo è quello di educare sulle conseguenze che possono avere delle implementazioni errate e facilmente vulnerabili. Altri progetti degni di nota dalla stessa community sono i Cheat Sheets, una pagina completa di guide approfondite per le maggiori vulnerabilità conosciute, e l’OWASP testing guide. In questa serie di articoli andrò ad analizzare e testare ogni vulnerabilità con esempi pratici, utilizzando Mutillidae.

Per chi si fosse perso i precedenti articoli:

A7 Funzione di controllo dell’accesso mancante

owasp7index
owasp7index

Questo tipo di vulnerabilità affligge applicazioni web mal programmate, che non controllano i permessi delle risorse o pagine richieste. Solitamente, ogni utente che ha accesso al sito può inviare richieste al server in diversi modi, come

www.sitovulnerabile.it/id=pagina

Se provassi ad accedere ad una pagina di amministrazione, l’url sarebbe ad esempio

www.sitovulnerabile.it/id=amministrazione

Nel caso l’applicazione non sia vulnerabile, verrà ritornato un errore di autorizzazione, altrimenti si avranno i permessi e si potrà entrare.

L’autorizzazione assicura quindi che solo alcuni utenti autenticati possano accedere a determinate pagine, in base ai permessi disponibili. Essa permette:

  • Certe operazioni possono essere effettuate solo dagli utenti autorizzati;
  • Il controllo dell’accesso a risorse protette;
  • Prevenzione contro la Privilege Escalation.

Le problematiche principali durante la programmazione di funzioni di controllo dell’accesso sono:

  1. Rendere un percorso nascosto sperando che nessuno lo trovi;
  2. Rendere eguali tutti gli utenti, con gli stessi privilegi;
  3. Autenticazione debole degli amministratori;
  4. Interfaccia di amministrazione debole e non protetta.

Per chi volesse vedere un esempio reale della vulnerabilità, trovata in Twitter due anni fa, è possibile leggerlo su Hackerone.

I più comuni attacchi con la funzione mancante sono:

  • Controllo dell’accesso verticale;
  • Controllo dell’accesso orizzontale;
  • Controllo dell’accesso del login.

Controllo dell’accesso verticale

In questo caso un qualsiasi utente può accedere alle funzionalità di amministrazione, senza nessun controllo sul tipo di utenza a cui appartiene. Un esempio possiamo trovarlo in Mutillidae, andando nella pagina “127.0.0.1/index.php?page=robots.txt”.

Pagina robots.txt
Pagina robots.txt

Possiamo notare che le pagine qui elencate sono accessbili a chiunque, senza nessun controllo dell’utenza e dei loro permessi. Provando ad andare nella pagina “http://127.0.0.1/phpmyadmin/" notiamo infatti che senza nessun login possiamo visualizzare tutti i database, aggiornarli o addirittura eliminarli.

Interfaccia phpmyadmin
Interfaccia phpmyadmin

Ovviamente sarà poco probabile che al giorno d’oggi un’applicazione permetta tutto ciò, ma è un chiaro esempio di cosa potrebbe accadere.

Controllo dell’accesso orizzontale

In questo caso è presente un controllo di login per verificare i permessi dell’utente loggato e se può accedere alla risorsa.

www.sitovulnerabile.it/admin/userID=1234

Se l’applicazione fosse vulnerabile, basterebbe una semplice modifica alla richiesta per ottenere i permessi di un utente che li possiede.

www.sitovulnerabile.it/admin/userID=1111

Se l’autorizzazione è solamente in quel punto, l’utente che ha cambiato il parametro avrà ora i permessi necessari per entrare nelle pagine protette.

Controllo dell’accesso del login

La pagina di login deve sempre essere protetta, visto che è la porta di accesso a tutte le funzionalità dell’applicazione. In altri articoli abbiamo visto che attaccarla con attacchi di forza bruta o con semplici comandi di SQL Injection.

In questo caso, Mutillidae si scopre vulnerabile nella pagina http://127.0.0.1/index.php?page=dns-lookup.php, la quale permette di eseguire comandi direttamente sul server

Comando ifconfig nel form
Comando ifconfig nel form
Comando ls
Comando ls

Sebbene non si possa modificare o eliminare i file, abbiamo i permessi di lettura. Girovagando, trovo una cartella molto interessante, la quale contiene tutti gli account dell’applicazione, in chiaro e ben visibili da tutti

Account degli utenti
Account degli utenti

Conclusioni

I metodi per determinare se un sito è vulnerabile quindi sono:

  1. Provare ad accedere a componenti di amministrazione dal proprio account;
  2. Utilizzare un proxy, come Burp Suite, per navigare nel sito e modificare i parametri degli url richiesti;
  3. Scoprire come vengono autenticati gli amministratori e provare a “rompere” il controllo.

Suggerisco di vedere questo video, dove viene aggirato il login creando una nuova connessione telnet per entrare nel server. Purtroppo è stato eseguito con una macchina Windows, per cui i comandi su linux saranno ovviamente diversi.