Spacciarsi per qualcun altro: session hijacking - I

Non è remota la possibilità che un cracker - nel caso appunto in cui non sussistano altri meccanismi di sicurezza - possa impersonificare l'identità di altri utenti riuscendo in qualche modo ad ottenerne il SID, rubandolo, a sessione dell'utente vittima già iniziata ed attiva, ed usandolo di conseguenza.

Session hijacking - attacchi brute force

Indovinare per tentativi, con attacchi di tipo brute force, una stringa così complessa non è nemmeno proponibile, pensiamo che le combinazioni possibili di una stringa composta di lettere minuscole dell'alfabeto inglese (che sono 26) e numeri (10), lunga 32 caratteri, qual'è il SID, è 36^32, cioè circa 6*10^49. Impronunciabile. E tanti dovrebbero essere i cicli da eseguire (nella quantificazione della complessità di un algoritmo si parla sempre di caso peggiore) per un attacco di forza bruta, sempre che ogni stringa in uscita dall'algoritmo sia equiprobabile.

Ed al riguardo si dice appunto che la "randomizzazione" della stringa che il PHP compie sia molto buona (ci mancherebbe altro, dati gli algoritmi usati!), ovvero PHP non "insiste" maggiormente su alcune stringhe a scapito di altre e non dà quindi appiglio nell'utilizzazione di tali stringhe più probabili.

Session hijacking - steal

Lasciando da parte l'idea di indovinare un SID valido, al fine di rubare in senso stretto tale SID si hanno più metodologie, alcune delle quali introdotte e rese possibili da exploit su vulnerabilità già discusse. Chiameremo Sito_A (sito attaccato) il sito sul quale l'utente_A (utente attaccato) ha una sessione valida e Sito_hack il sito remoto del cracker.

Cross site Scripting

È possibile ottenere il SID di un utente tramite XSS: se Sito_A è esposto a falle sugli XSS e il cracker (che ha anch'egli un login valido su Sito_A) ha inserito il codice di cui sotto in una pagina dello stesso sito, pagina che l'utente_A andrà a visualizzare:

allora il cracker entrerà in possesso del SID valido.

Che il cracker inserisca codice "staticamente" nel sito è sia improbabile (immaginabile solo per applicazioni quali forum o blog bacati) che pericoloso per lui - l'indirizzo del sito in suo controllo è comunque visibile, codificato o meno. Ed inoltre è una "scocciatura" per il cracker dover avere un login valido sullo stesso sito attaccato.

La soluzione è inviare ad utente_A un link (o simile) di modo che l'utente stesso visualizzi sul suo browser la pagina affetta da XSS puntata dal link.

Tale pagina sarà richiesta tramite i seguenti parametri in GET (che diventeranno codice eseguito dal client) - torniamo a pensare al campo ricerca che ripete quanto in esso immesso nella pagina dei risultati seguente.

Salvo log del server il cracker non è rintracciabile, né deve avere login su Sito_A. Certamente, se prima l'utente era incolpevole (o quasi), qui ha la colpa di seguire un link fornitogli da chissà chi e chissà in che modo.

Vulnerabilità su include dinamici

Tramite un include ad hoc e di facilissima implementazione, il cracker può riuscire a visualizzare i file di sessione direttamente dal server e quindi ottenere il SID di tutti gli utenti! Con ogni probabilità, la metodologia di salvare le sessioni su db non può nulla contro questo attacco. Siamo di fronte al massimo grado di pericolosità.

Brevemente, per sessioni "tradizionali": se Sito_A ha una pagina contenente il seguente codice:

il cracker (che anche qui è in possesso di login valido anch'egli) richiama quella pagina come già discusso, con l'esito di riuscire ad includere il seguente codice (valido per SO Windows):

Ebbene, l'output risulta drammatico (per lo staff di Sito_A per lo meno):

Nella cartella temporanea ci saranno sicuramente file di varia natura, ma quelli di sessione sono effettivamente riconoscibili.