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.
DES: critiche, NSA e S-Box. Come nasce un algoritmo vincente
Lo schema di crittografia più utilizzato si basa sullo standard DES (Data Encryption Standard) adottato nel 1977 dal National Bureau of Standards, oggi NIST (National Institute of Standards and Technology), come FIPS PUB 46 (Federal Information Processing Standard 46). L'algoritmo è però chiamato DEA (Data Encryption Algorithm). In DES i dati vengono crittografati in blocchi di 64bit utilizzando una chiave di 56bit. L'algoritmo in una serie di passi di 64 bit in un output di 64bit.
Gli stessi passi, con la stessa chiave consentono invece di invertire la crittografia.
L'algoritmo DES è ampiamente utilizzato ed è stato il soggetto di molte controversie riguardanti la sua sicurezza. Per comprendere la natura di queste controversie, è opportuno introdurre brevemente la storia di DES. Alla fine degli anni 60, IBM diede origine a un progetto di ricerca nel campo della crittografia condotto da Horst Feistel. Il progetto porta nel 1971 allo sviluppo di un algoritmo chiamato LUCIFER, che venne venduto ai Lloyd di Londra per l'utilizzo nei sistemi di prelievo di costante, anch'essi sviluppati da IBM. LUCIFER è una cifratura a blocchi di Feistel che opera su blocchi di 64bit utilizzando chiavi di 128bit. Dati i risultati promettenti prodotti dal progetto LUCIFER, IBM pensò di sviluppare un prodotto di crittografia commerciale che potesse essere implementato su un chip. Questa operazione venne diretta da Walter Tuchman e Carl Meyer e coinvolse non solo i ricercatori IBM ma anche consulenti esterni e il personale tecnico della NSA. Il risultato di questo tentativo fu una versione raffinata di LUCIFER che era più resistente all'analisi crittografica ma utilizzava chiavi di 56bit per poter entrare in un chip.
Nel 1973, l'NBS (National Bureau of Standards) emise un bando di gara per proporre uno standard di cifratura a livello nazionale. IBM inviò i risultati del progetto Tuchman-Meyer. Questo era di gran lunga il migliore algoritmo proposto e nel 1977 fu adottato con il nome di Data Encryption Standard.
Prima della sua adozione come standard, la proposta di DES fu soggetta ad ampie critiche che non si sono ancora spente. Due elementi in particolare fecero sorgere molte critiche. Innanzitutto la lunghezza della chiave nell'algoritmo LUCIFER originale di IBM era di 128bit mentre quella del sistema proposto era di soli 56bit con una riduzione (enorme) pari a 72(!!!)bit. La seconda area problematica era il fatto che i criteri progettuali della struttura interna di DES, ovvero le S-box, erano segreti. Pertanto gli utenti non potevano sapere se la struttura interna di DES fosse esente da punti deboli nascosti che potessero consentire alla NSA di decifrare i messaggi senza utilizzare la chiave. I successivi eventi, in particolare i recenti lavori di analisi crittografica differenziale, sembrano indicare che DES ha una struttura interna molto resistente. Inoltre, secondo IBM, le sole modifiche apportate alla proposta riguardavano le S-box; tali modifiche, suggerite dalla NSA, hanno eliminato i punti deboli identificati nel corso del processo di valutazione.
In ogni caso, DES si è molto sviluppato ed è ampiamente utilizzato specialmente nella applicazioni finanziarie. Nel 1994, il NIST confermò DES per l'utilizzo a livello Federale per altri cinque anni sebben non per applicazioni relative alla protezione di informazioni militare segrete. Nel 1999, NIST emise una nuova versione dello standard che indicava che DES doveva essere utilizzato solo per i sistemi preesistenti e che venisse invece adottata la versione triple DES. TripleDES non è altro che DES applicato 3 volte sul testo in chiaro con due o tre chiavi differenti.
Tecniche di trasposizione
La maggior parte delle tecniche di crittografia classica si basa sul concetto della sostituzione di un simbolo di testo cifrato con un simbolo di testo in chiaro. Ma è interessante sapere che si può ottenere un mapping molto differente eseguendo una permutazione delle lettere del testo in chiaro. Questa tecnica è chiamata cifratura a trasposizione.
La tecnica puù semplice è chiamata Rail Fence (staccionata) in cui il testo in chiaro viene scritto come una squenza di diagonali e poi letta come una sequenza di righe. Per esempio, la staccionata del messaggio "ciao a tutti" sarà:
c a a u t i o t t i
andando ad avere un messaggio cifrato pari a:
caautiotti
Questo tipo di tecnica è estramemente facile da analizzare. Uno schema più complesso consiste nello scrivere il messaggio in un rettangolo, riga per riga e poi leggerlo colonna per colonna permutando l'ordine delle colonne. L'ordine delle colonne diviene quindi la chiave dell'algoritmo. Ecco un esempio:
plaintext: "messaggio segreto"
chiave : 3 2 1 5 4
m e s s a
g g i o s
e g r e t
o
cipher: sireggmgeoastsoe
Una cifratura a trasposizione pura è facile da riconoscere poichè presenta la stessa frequenza delle lettere del testo in chiaro originario. Per il tipo di trasposizione a colonne appena illustrato, l'analisi crittografica è piuttosto semplice e prevede la disposizione del testo cifrato in una matrice, giocando poi sulla posizione delle colonne. Può essere utile anche impiegare tabelle di frequenze di diagrammi e trigrammi.
La cifratura a trasposizione può essere resa significativamente più sicura eseguendo la trasposizione in più fasi. Il risultato è una permutazione più complessa che risulta difficile da ricostruire. Pertanto, se il messaggio precedente viene ri-crittografato utilizzando lo stesso algoritmo si avrà:
chiave : 3 2 1 5 4
S I R E G
G M G E O
A S T S O
Ecipher: rgtimssgaegooees
Per visualizzare il risultato di questa trasposizione, si designano le lettere del messaggio in chiaro originario con i numeri che indicano la loro posizione. Pertanto, con un messaggio di 16 lettere, la sequenza di lettere originaria sarà
01 02 03 04 05 06 07 08
09 10 11 12 13 14 15 16
Dopo la prima trasposizione si avrà
03 08 13 02 07 12 01 06
11 16 05 10 15 04 09 14
il quale presenta una struttura ancora troppo regolare. Ma dopo la seconda trasposizione si avrà una struttura molto meno strutturata e di conseguenza sarà più difficile da analizzare/attaccare.
Cifratura PlayFair
Una delle cifrature più note è chiamata PlayFair e tratta i diagrammi del testo in chiaro come singole unità traducendoli in diagrammi cifrati. L'algoritmo PlayFair si basa sull'uso di una matrice 5x5 costruita utilizzando una parola chiave.
M O N A R
C H Y B D
E F G I/J K
L P Q S T
U V W X Z
In questo caso la parola chiave è monarchy. La matrice è costruita introducendo le lettere della parola chiave (esclusi i duplicati) da sinistra a destra e dell'alto al basso e poi completando la parte rimanente della matrice con le altre lettere specificate in ordine alfabetico. Le lettere I e J contano come una sola lettera. Il testo in chiaro viene crittografato due lettere alla volta, in base alle seguenti regole.
La cifratura PlayFair rappresenta già un notevole miglioramento rispetto alla semplice cifratura monoalfabetica. Per esempio, mentre vi sono solo 26 lettere, vi sono 26 x 26 = 676 diagrammi e dunque l'identificazione dei singoli diagrammi è più difficoltosa. Inoltre le frequenze relative delle singole lettere hanno un intervallo molto più ampio di quello dei diagrammi, complicando lulteriormente l'analisi della frequenza. Per questi motivi, la cifratura PlayFair è stata considerata per lungo tempo inviolabile. In particolare è stata utilizzata come sistema di comunicazione sul campo dall'esercito inglese nella prima guerra mondiale ed era ancora diffusamente utilizzata dall'esercito americano e dalle forze alleate durante la seconda guerra mondiale.
Nonostante questo livello di fiducia nella sua sicurezza, la cifratura PlayFair risulta comunque relativamente facile da violare perché conserva ancora molta della struttura del linguaggio in chiaro. In generale bastano poche centinaia di lettere di testo cifrato per poterla violare.
Curiosità : Questa cifratura è stata in realtà inventata dallo scienziato inglese Sir Charles Wheatstone nel 1854 ma porta il nome del suo amico Playfair Barone di St. Andrews, che ha depositato la cifratura al Foreign Office Britannico.
Su Internet : A questo link del Liceo Foscarini è possibile testare e provare (tramite questo script Javascript) l'algoritmo appena descritto.
Intelligence Gathering
Prima di effettuare una operazione di hacking è necessario conoscere il più possibile il sistema target. Nel secondo articolo pubblicato su questo sito è stato dimostrato come raccogliere informazioni utili relative alla macchina target; ma come bisogna comportarsi nel caso in cui la macchina target non sia conosciuta?
Le operazioni atte a fornire informazioni relative all'ambiente viene definita "Reconnaissance", ovvero l'arte di recuperare le informazioni".
Prima d'iniziare bisogna effettuare un ragionamento abbastanza semplice da ricordare:
I sistemi informatici sono ideati, costruiti e mantenuti da "persone", più si conosce la persona che usa il computer che si vuole attaccare più probabilità di successo si avranno.
Le operazioni di Reconnaisance si dividono in quattro macro categorie:
In questo post ci focalizzeremo sul primo aspetto, ovvero la Intelligence Gathering. Gli obiettivi che si aspettano di ottenere sono definibili nella seguente frase:
Recuperare più informazioni possibili relativi al modello di business dell'azienda target, la sua struttura e la sua dislocazione geografica
Come risultato si otterrà
Una lista di DNS la quale riflette l'intera lista delle macchine target dell'azienda includendo la lista delle sue eventuali divisioni etc"
I tools che vengono utilizzati per questa operazionei sono
Come abbiamo detto il nostro obiettivo finale è una lista di DNS che sono legati all'azienda target. Vista l'impossibilità di automatizzare il processo, la Intelligence Gathering può risultare come una delle più difficili parti da svolgere in una attività di penetration testing. Ma non solo, l'intelligence Gathering si suddivide in ulteriori quattro sub-categorie, che sono:
Definiamo i concetti esposti:
Real World Intelligence
In questa fase del processo cercheremo di capire il più possibile la struttura dell'organizzazione che stiamo attaccando, la sua posizione logica, le sue relazioni di business e così via. La maggior parte di questo lavoro si svolge navigando all'interno del sito principale, lavorando con i motori di ricerca, leggendo le ultime press-releases, rapporti annuali etc etc. A questo livello di lavoro non ci sono regole, lavorando con queste informazioni è necessario collezionare i DNS domain names da queste fonti non per forza gli hostnames.
HTTP link analysis
Per link analysis s'intende la ricerca di automatizzare il processo al fine di risparmiare tempo. Avendo a disposizione un DNS domain name , utilizeremo i motori di ricerca per enumerare tutti i possibili link che collegano in modo bidirezionali due entità : (target-x). Un collegamento bidirezionale molto spesso comporta un risultato "rilevante" nel mondo dell'intelligence.
Per questo tipo di operazioni andremo ad utilizzare BiLe il quale richiede HTTrack per funzionare
Domain name expansion
Recuperato un DNS domain name che consideriamo rilevante per il nostro target, cerchiamo automaticamente di recuperare maggiori informazioni facendo due principali supposizioni:
Capire e sfruttare questi ragionamenti può portare la nostra "lista" a crescere e fornire maggiori informazioni utili.
Vet Domains found (controllo dei dati ricavati)
La più semplice delle fasi di Intelligence Gathering si compone dal necessario bisogno di "pulire" la nostra lista dai falsi positivi. Non tutti i domini rilevati avranno "veramente" a che fare con il nostro target. Per fare questo è necessario verificare alcuni valori ricevuti da questi domini ed effettuare quattro principali test
.
Per le fasi di vet(ting) è possibile utilizzare alcuni script perl che vengono rilasciati dalla sensepost. Si trovano nell'archivio BibleSuite. I software adatti a questo scopo sono : vet-mx.pl e vet-IPrange.pl
Alla fine di tutte queste operazioni avremo una lista di DNS contenenti informazioni "preziose" le quali saranno fonte di studio per "capire" chi e cosa stiamo attaccando.
Nota: I software sopra descritti sono tutti liberamente scaricabili da Internet in forma di sorgenti. Chi lavora nel settore e/o ha la possibilità di spendere un abbonamento annuale di 1.600$ l'anno può provare la killer-app della sensepost chiamata BiBleBlah. La quale "gira" in ambienti Win32.
