[s3web] Traduzione/sintesi slide2
- From: Alberto Campanile <alberto.campanile@xxxxxxxxx>
- To: s3web@xxxxxxxxxxxxx
- Date: Thu, 18 Jun 2009 15:51:32 +0200
Ciao ragazzi,
vi allego la seconda traduzione/sintesi delle slide....
Ciaoo
Configuration Testing
Spesso l'analisi dell'infrastruttura e della topologia di una web application
può rilevare preziose informazioni. OWASP per questa fase prevede otto tipi di
test (OWASP-CM-001/8) che servono a determinare la conoscenza dei metodi HTTP
permessi, di codice sorgente, di funzionalità di amministrazione, di modalità
di autenticazione, etc.
OWASP-CM-001 (test di verifica SSL/TLS) : Questa fase verifica l'utilizzo di
appropriati algoritmi di cifratura e controlla la consistenza dei certificati a
chiave pubblica (PKI certificates). SSL e TLS sono due protocolli che
forniscono canali di comunicazione tali da garantire l'integrità,
confidenzialità e autenticazione delle informazioni trasmesse.
Nella fase iniziale della connessione SSL, il client manda al server un
messaggio (hello message) contente le indicazioni su quali suite di cifratura
può gestire. Una suite di cifratura è composta da:
* Un protocollo di criptazione (DES, RC4, AES)
* La lunghezza della chiave di criptazione (es. 40, 56, 128 bit)
* Algoritmo di hash utilizzato per il controllo di integrità (SHA, MD5)
Dopo che il server riceve l'hello message sceglie quale suite di cifratura
utilizzare per questa sessione.
Il servizio di autenticazione basato su certificati a chiave pubblica (PKI
certificates) funziona come segue:
* Ogni browser è provvisto di una lista di certificati autorizzati
(trusted CAs) che vengono confrontati (mediante firma) con il certificato in
esame;
* Durante la fase di negoziazione iniziale con il server HTTPS, se il
certificato risulta sconosciuto al browser, allora quest ultimo mostra
all'utente un messeggio di allerta;
* I certificati hanno un periodo di validità terminato il quale esso
scade. Ancora una volta il browser segnala l'utente in merito;
* Il browser inoltre informa l'utente anche nel caso in cui il nome del
sito non corrisponde al quello riportanto nel certificato.
A causa di restrizioni imposte dal governo americano (contro alcuni governi
ostili), non è sempre possibile utilizzare cifrature forti (cioè con chiavi
superiori a 40 bit). Per tale motivo i web server devono essere in grado di
gestire cifrature deboli (chiavi inferiori a 40 bit). Nel caso di
configurazioni errate del server, è possibile forzare l'utilizzo di cifrature
deboli. In più, configurazioni improprie e gestione inaccurata dei certificati
a chiave pubblica, possono scoraggiare l'utente all'accesso del servizio e
possono esporlo ad un attacco di tipo Manin-the-Middle (MIM).
Tool utilizzato : Nessus Vulnerability Scanner. Questo stumento permette di
identificare i servizi basati su SSL su una determinata porta e di effettuare
dei test di vulnerabilità. Esso prevede un plugin per il controllo di :
* Certificati scaduti o che scadono nell'arco di 60 giorni;
* Cifrature deboli.
SessionLab05. Utilizzando "Nessus" analizzare i risultati relativi ad
un sito a scelta mediante l'utilizzo di plugin relativi ai test SSL (si trovano
nella categoria "General")
OWASP-CM-002 (ORACLE DB LISTENER TESTING) : Questo test è relativo al Data base
listener (DB), un demone network che hanno solo i DB Oracle. Il DB listner è un
punto di ingresso per le connessioni remote ai DB Oracle. Tale componente resta
in ascolto e gestisce le richieste di connessione. Questo test può essere
effettuato da internet. La porta di default del listener è la 1521. Aree di
attacco potenziali al DB listener sono:
* Fermare il listener - DoS attack (Denial of service - Negazione di
servizio);
* Inserire una password e negare altri controlli dal listener
(DBHijacking);
* Ottenere informazioni dettagliate dal listener, database e
configurazione dell'applicazione (furto di informazioni).
OWASP-CM-003 (Infrastructure Configuration Management Testing) : La complessità
intrinseca delle interconnessioni tra diverse tecnologie che interagiscono
nell'infrastruttura di un web server, rende la gestione della configurazione ed
il testing uno step fondamentale per il rilascio di una applicazione web.
Infatti, ogni singola vulnerabilità contenuta in una delle centinaia di
applicazioni presenti, può compromettere l'intera infrastruttura presente sullo
stesso server. Se elementi come un software web server, server database o altre
tipologie di server non sono messi in sicurezza in maniera appropriata, possono
essere introdotti rischi o lasciare aperte vulnerabilità che (se sfruttuate)
possono compromettere l'applicazione stessa.
In questo task il tester cerca di studiare ed analizzare il più possibile
l'infrastruttura di una applicazione web. Lo studio dell'architettura di una
applicazione può essere semplice se questa informazione è prevista (ed
accessibile) nella documentazione o nel caso in cui sia possibile effettuare
interviste al team di sviluppo, ma può essere molto difficoltoso se si effettua
un blind penetration test.
In questa fase il tester si pone domande ed effettua i relativi test in modo da
rispodere a questioni del tipo :
* C'e' un sistema di firewall a proteggere il sistema?
* Com è configurato?
* Può essere bypassato?
* è presente un reverse proxy?
OWASP-CM-004 (Application Configuration Management Testing) : Questo task
prevede il controllo che dati (o altri tipi di informazioni) siano nascosti
nella fase successiva all'installazione e configurazione dell'applicazione.
In questa fase sono analizzati :
* FILE DI ESEMPIO - Molti web server e applicazioni web sono forniti
(dopo l'installazione di default) di esempi d'uso ed altri file che agevolano
il lavoro dello sviluppatore e che servono a testare se l'installazione è
andata a buon fine. Esistono scanner CGI che includono una lista dettagliata di
file e directory d'esempio note (fornite a web server e applicazioni web) e che
determinano velocemente la presenza di questi file.
* COMMENTI - Altre informazioni facilmente reperibili sono
rappresentate dai commenti inseriti nelle pagine HTML dal
programmatore/sviluppatore dell'applicazione web e che potrebbero essere
utilizzate da un potenziale attaccante (spesso i commenti sono utilizzati dallo
sviluppatore per eliminare/isolare porzioni di codice non più utilizzate).
* LOG - L'ultima componente analizzata in questa fase è rappresentata
dai file di LOG. Tali file possono contenere informazioni sensibili ed è
pertanto necessaria una corretta gestione.
TOOL UTILIZZATO : NIKTO (web vulnerability scanner)
SessionLab06. Utilizzando "nikto" analizzare i risultati relativi ad
uno o più webmail.
es. nikto -host [sito_web] -output [file_risultati.txt]
OWASP-CM-005 (Testing for File Extensions Handling) : Questo task prevede il
controllo delle estensioni di file supportati dall'applicazione web. Tali
informazioni sono utilizzate per determinare quali tecnologie, linguaggi o
plugin sono utilizzati.
Problemi:
* I file ".asa" e ".inc" non dovrebbero mai essere accessibili, in
quanto questi tipo di file possono contenere informazioni sensibili;
* I file ".zip", ".tar", ".gz", ".tgz", ".rar", ".txt", ".pdf", quando
selezionati, vengono mostrati a video o scaricati dal browser. Per tale motivo
devono essere controllati e non devono contenere informazioni sensibili.
* I file ".java" contengono codice sorgente e non dovrebbero mai essere
accessibili.
Per poter identificare i file supportati esistono varie tecniche tra cui:
* Utilizzo di vulnerability scanner;
* Tool per lo spidering e mirroring;
* Ispezione manuale dell'applicazione (tale tecnica aggira le
limitazioni dello spidering automatico);
* Utilizzo di motori di ricerca.
OWASP-CM-006 (File obsoleti, di backup e non referenziati) : Questo task
prevede il controllo dell'esistenza di file obsoleti, di backup e non
referenziati, i quali possono rilevare informazioni. Non è inusuale la presenza
di file obsoleti rinominati o di archivi di backup (effettuati in alcuni casi
in maniera automatica).
Questi tipi di file possono presentare varie tipi di minaccia alla sicurezza
dell'applicazione web:
* File non referenziati : Possono contenere informazioni sensibili che
possono facilitare l'area di attacco di un'applicazione (p.e. file contenenti
le credenziali di accesso al database, file di configurazione possono contenere
riferimenti a contenuti nascosti, etc.)
* File obsoleti : Possono contenere vulnerabilità corrette nelle
versioni più recenti (p.e. viewdoc.old.jsp può contenere vulnerabilita
(corrette nel file viewdoc.jsp) e se trovato può essere sfruttato da un
potenziale attaccante).
* File di backup : Possono contenere codice sorgente progettato per
essere eseguito sul server (p.e. La richiesta del file "viewdoc.bak" può
contenere il codice sorgente di "viewdoc.jsp"). Archivi di backup possono
contenere anche copie di tutti i file contenuti nella webroot.
OWASP-CM-007 (Infrastructure and Application Admin Interfaces) : Questo task ha
come obiettivo quello di trovare l'interfacca di amministratore e capire se è
possibile l'accesso alle funzionalità di tale interfaccia. Se l'applicazione
web è stata rilasciata (deployed) con la configurazione di default, è possibile
reperire facilmente le credenziali d'accesso dalla documentazione di aiuto.
OWASP-CM-008 (Testing for HTTP Methods and XST) : Questo task prevede il
controllo che il web server non sia configurato in modo da permettere
potenziali comandi (metodi) HTTP dannosi e che non siano possibili Cross Site
Tracing (XST).
Il documento RFC 2616 (che descrive la versione 1.1 dell'HTTP, cioè lo standard
attuale) definisce i seguenti otto metodi:
HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT.
Alcuni di questi metodi permettono al potenziale attaccante di modificare i
file conservati sul web server ed in alcuni casi di rubare le credenziali del
legittimo proprietario. Es. :
* PUT: Permette al client di fare l'upload di nuovi file sul web
server. Un attaccante può inserire file maliziosi (p.e.: Un file "asp" che
esegue comandi invocando "cmd.exe"), o semplicemente utilizzando il server
della vittima come deposito di file (file repository).
* DELETE: Permette al client di cancellare un file dal web server. In
questo modo l'attaccante può effettuare facilmente defacciamenti del sito o
definire un attacco di tipo DoS (Denial of service - Negazione di servizio).
* CONNECT: Questo metodo permette ad un client di utilizzare un web
server come proxy;
* TRACE: Questo metodo ritona indietro (echoes back) al client le
stringhe spedite dal server, e dovrebbe essere usato solo in fase di debug.
Questo metodo può essere utilizzato per attacchi di tipo Cross Site Tracing.
Strumento utilizzato per verificare i metodi supportati : nc
es. nc [sito_web] [porta]
risultato di "nc www.victim.com 80"
OPTIONS / HTTP/1.1
Host: www.victim.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0
Other related posts:
- » [s3web] Traduzione/sintesi slide2 - Alberto Campanile
