[BUG] Vodafone.it - Passaggio in chiaro di username e password tramite metodo GET

[Alessandro Romani]

Ciao a tutta la lista,
per purissimo caso, mi sono accorto di questo:

GET
https://www.vodafone.it/190/trilogy/jsp/user.do?password=TUA_PASSWORD&username=TUO_USERNAME&method=login&ty_skip_md=true
HTTP/1.1
Host: www.vodafone.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it-IT)
AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7
Paros/3.2.13
Referer:
https://registrazione.vodafone.it/190/regu/chooseReminder.do?from=login&externalCall=true
Origin: https://registrazione.vodafone.it
Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-IT
Connection: keep-alive
Proxy-Connection: keep-alive
Content-length: 0

Mi vengono in mente parecchie cose, ma una in particolare:
a che serve mettere l'HTTPS se poi passi il mio username e la mia
password in chiaro e in GET nella URL?

Ho notato, comunque, che questa URL viene "generata" soltanto quando si
fa il login dalla pagina

https://registrazione.vodafone.it/190/regu/chooseReminder.do?from=login&externalCall=true


che è la pagina a cui si viene rimandati dopo aver sbagliato il login
dalla pagina principale del sito.
Aggiungo inoltre che, se si inseriscono username e password corrette
nelle rispettive querystring della URL, viene, di fatto, permesso
l'accesso e pare che venga eseguita la procedura di autenticazione. Non
ho testato se, con un pò di caparbietà, si possa riuscire a bypassare il
login ed entrare nel profilo di qualsiasi utente solamente inserendo uno
username valido.

Spero che da Vodafone correggano questo bug il più sollecitamente possibile.

Alessandro Romani
Security Analyst

[Marco Ermini]

Post by Alessandro Romani
Ciao a tutta la lista,
GET
https://www.vodafone.it/190/trilogy/jsp/user.do?password=TUA_PASSWORD&username=TUO_USERNAME&method=login&ty_skip_md=true
HTTP/1.1

[...]

Post by Alessandro Romani
a che serve mettere l'HTTPS se poi passi il mio username e la mia password
in chiaro e in GET nella URL?

In che senso? sta viaggiando dentro un tunnel HTTPS, quindi in chiaro non è.

A me non risulta passato in chiaro, questo è quello che vedo con
Firefox e Tamper data:

URL=https://www.vodafone.it/190/trilogy/jsp/user.do?password=userpasswd&username=usertest&method=login&ty_skip_md=true

Loading Image...

Puoi specificare meglio quale sarebbe questo bug?


Cordiali saluti

[Stefano Sasso]

Post by Marco Ermini
Puoi specificare meglio quale sarebbe questo bug?

non credo si riferisse a un vero e proprio bug in senso stretto.
ma se da un computer "pubblico" che non pulisce cache e history di
navigazione io facessi login su vodafone, l'utente smaliziato che lo
userà dopo di me potrebbe recuperare le mie credenziali di accesso.

ciao,

[Marcello Magnifico]

Post by Marco Ermini
Puoi specificare meglio quale sarebbe questo bug?

In generale username e password nella URL, cioe' in GET, sono una
pessima idea ("bug umano", chiamalo come vuoi). Per cominciare, chiunque
passa dietro le spalle di chi naviga le puo' vedere nel browser e
annotare, potendo addirittura farlo in un momento qualsiasi della
sessione, vanificando del tutto anche l'uso ormai scontato dei campi
HTML di tipo password (a input nascosto) nei form di ingresso.
Tali dati, poi, possono anche finire inavvertitamente in una stampa
(magari fatta a uso di qualcun altro) di una "vista" interna
all'applicativo (indipendentemente dall'applicativo e dal suo scopo),
noto il modo in cui si comportano molti browser quando producono le
intestazioni dell'output.

L'HTTPS c'entra relativamente poco, ma il problema e' comunque reale e
di una certa importanza. Sarebbe stato anche piu' grave, certo, l'HTTP
normale, magari in presenza di un qualche proxy (aziendale? personale?)
che finirebbe per registrare le credenziali d'accesso nei propri log
assieme al resto dell'URL, innalzando artificiosamente il livello di
rischio, ovvero il danno in caso di compromissione di quel sistema. Con
l'HTTP normale ma col POST, problematiche del genere si sarebbero un po'
ristrette, ad esempio alla possibilita' di sniffing a bordo proxy, che
e' la piu' ovvia e "di moda" ma, come si puo' capire, non l'unica, ne'
la piu' facile o la meno pericolosa.

Auguro, percio', a tutti quanti che non siano gestite in questo modo
anche eventuali web application ad uso esclusivo degli operatori della
compagnia, ad esempio nei negozi, dove una sbirciata allo schermo sul
bancone, da parte di chiunque, puo' sempre scappare.

Forse e' proprio vero che la sicurezza, prima ancora che essere una
serie di contromisure tecniche, e' un modo di pensare e di agire, un
atteggiamento. E' anche vero, per fortuna, che tutto si impara e che una
profonda sensibilita' verso quella faccia dei problemi la si puo'
guadagnare perfino rilassandosi. Il metodo che consiglio di solito e' un
testo "per tutti": quello di Dan Verton sul cyberterrorismo. Aiuta molto
a "pensare sistema", cioe' a capire le conseguenze dei collegamenti
naturali tra infrastrutture, sistemi, persone.


un saluto
Marcello Magnifico

[Marco Ermini]

Post by Marcello Magnifico

Post by Marco Ermini
Puoi specificare meglio quale sarebbe questo bug?

In generale username e password nella URL, cioe' in GET, sono una
pessima idea ("bug umano", chiamalo come vuoi).

[...]

Capisco, ma Alessandro ha parlato di un "bug". Io non ne ho trovati...

Quello che ho capito è che se non ripulisci la cache del browser, o se
qualcuno fa "shoulder surfing" può leggere l'username/password
dall'URL. Ma francamente, la situazione non migliorerebbe moltissimo
se fosse usato POST - posso ripescare il cookie dell'autenticazione
comunque - nemmeno mi serve scoprire la password... - ed username e
password posso leggerli mentre l'utente li batte sulla tastiera.

Insomma forse il sito potrebbe essere fatto meglio, ma non mi sembra
che ci siano scenari che verrebbero significativamente migliorati
cambiando il GET in un POST. Correggetemi se sbaglio.


Cordiali saluti

[ascii]

Post by Marco Ermini
Insomma forse il sito potrebbe essere fatto meglio, ma non mi sembra
che ci siano scenari che verrebbero significativamente migliorati
cambiando il GET in un POST. Correggetemi se sbaglio.

Considera anche i log del web/application server che se non ripuliti
contengono piu' o meno le credenziali di tutti gli utenti attivi.

Visto che e' una ML di sicurezza si cerca di dare buoni consigli :)

Poi ognuno implementa come meglio crede.

Ciao,
Francesco `ascii` Ongaro
http://www.ush.it/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Marco Ermini]

Post by ascii

Post by Marco Ermini
Insomma forse il sito potrebbe essere fatto meglio, ma non mi sembra
che ci siano scenari che verrebbero significativamente migliorati
cambiando il GET in un POST. Correggetemi se sbaglio.

Considera anche i log del web/application server che se non ripuliti
contengono piu' o meno le credenziali di tutti gli utenti attivi.
Visto che e' una ML di sicurezza si cerca di dare buoni consigli :)

Sono d'accordissimo. Contestavo soltanto l'approccio ed il fatto di
chiamarlo "bug".

L'accesso ai log è ovviamente in ogni caso controllato e soggetto ad
autorizzazione... comunque ottimo punto a favore.


Cordiali saluti

[Dario Lombardo]

Post by Marco Ermini
Quello che ho capito è che se non ripulisci la cache del browser, o se
qualcuno fa "shoulder surfing" può leggere l'username/password
dall'URL. Ma francamente, la situazione non migliorerebbe moltissimo
se fosse usato POST - posso ripescare il cookie dell'autenticazione
comunque - nemmeno mi serve scoprire la password... - ed username e
password posso leggerli mentre l'utente li batte sulla tastiera.
Insomma forse il sito potrebbe essere fatto meglio, ma non mi sembra
che ci siano scenari che verrebbero significativamente migliorati
cambiando il GET in un POST. Correggetemi se sbaglio.

Diciamo che cambiare la get in post riduce il problema del shoulder
surfing, che peralto e' un problema marginale. Ritengo piu' utile usare
un hash piuttosto che la pwd in chiaro, come qualcuno ha gia' suggerito.
In questo caso il furto della credenziale porta al possesso del suo hash
e non del segreto vero e proprio: non puoi mettere l'hash direttamente
nel form di autenticazione ma devi ancora cracckarlo.
Concordo che non sia un BUG in senso stretto ma una debolezza di
progettazione, ma che secondo me e' piu' opportuno risolvere...
quantomeno per una questione di immagine.
Ciao
Dario.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Elettrico]

Post by Marco Ermini
dall'URL. Ma francamente, la situazione non migliorerebbe moltissimo
se fosse usato POST - posso ripescare il cookie dell'autenticazione

sempre che si usi un cookie.

Post by Marco Ermini
Insomma forse il sito potrebbe essere fatto meglio, ma non mi sembra
che ci siano scenari che verrebbero significativamente migliorati
cambiando il GET in un POST. Correggetemi se sbaglio.

è che la password non deve passare in chiaro.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Alessandro Romani]

Marco,
hanno chiarificato ampiamente Stefano e Marcello ciò che io ritengo un
bug in senso allargato o, per essere più precisi, una pessima scelta
implementativa.
Dal mio punto di vista "paranoico" avrei preferito una scelta molto più
restrittiva:

1) Form inviato in POST (come, d'altronde, si insegna sulla guida base
di HTML).
2) Hash della password sempre e comunque, a prescindere dalla presenza
di un certificato SSL.

Questo per il semplice motivo che preferisco avere più livelli di
protezione piuttosto che un unico point of failure. D'altra parte sono
già noti, in the wild, attacchi man in the middle in cui colui che sta
nel mezzo può dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare
la richiesta al sito leggittimo comportandosi, di fatto, da proxy.

Alessandro Romani
Security Analyst

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Giuseppe "Gippa" Paterno']

per essere più precisi, una pessima scelta implementativa.

Rispondo velocemente sul thread. Finche' da remoto non riesci a prendere
dati sensibili, non e' un bug. Certo che se "piglio" la cache locale nel
browser delle URL visitate, vedo in chiaro username e password ;-)
IMHO non e' una buona una scelta implementativa: se fossi stato il PM
del progetto avrei usato un gatto a nove code sui programmatori :), ma
secondo me siamo alla solita applicazione "vittima" del "tot al kilo".
Ciao ciao,
Gippa
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Marco Ermini]

Post by Alessandro Romani
Marco,
hanno chiarificato ampiamente Stefano e Marcello ciò che io ritengo un bug
in senso allargato o, per essere più precisi, una pessima scelta
implementativa.

Beh, all'inizio era un bug, e dopo aver chiarito che non lo è, adesso
lo chiamiamo "bug in senso allargato" o "pessima scelta
implementativa".

Sono contento che abbiamo precisato: le parole sono importanti quando
descrivono il mondo reale.

Post by Alessandro Romani
Dal mio punto di vista "paranoico" avrei preferito una scelta molto più
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base di
HTML).

Lo abbiamo capito che lo preferisci, ma l'HTML consente entrambi,
quindi se non ci sono stringenti motivi (che non sono stati portati
fin'ora) non vedo perché spendere soldi per farlo cambiare

Post by Alessandro Romani
2) Hash della password sempre e comunque, a prescindere dalla presenza di un
certificato SSL.

Ovvero, dove lo creeresti l'hash? client side con un JavaScript?

Post by Alessandro Romani
Questo per il semplice motivo che preferisco avere più livelli di protezione
piuttosto che un unico point of failure.

Sono d'accordo, ma per adesso non vedo "unici point of failure"

Post by Alessandro Romani
D'altra parte sono già noti, in the
wild, attacchi man in the middle in cui colui che sta nel mezzo può
dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare la richiesta al
sito leggittimo comportandosi, di fatto, da proxy.

Quali? senza che il browser se ne accorga e ti avverta? Se stai
probabilmente parlando della serie di attacchi descritta da Moxie
Marlinspike, sappi che per funzionare 1) devi stare su una rete
corporate (a meno che tu non riesca a fare un improbabile man in the
middle nella open Internet) 2) richiedono comunque un phishing/social
engineering, l'utente deve essere stato intercettato e rediretto
_prima_ dell'inizio della sessione SSL), e 3) richiedono la produzione
di un certificato formato in modo particolare (con null-string al suo
interno eccetera) e sono per la gran parte già fissati sia lato
certification authority sia sui browser moderni.

Se non stai parlando di questo dimmi di cosa parli, perché ignoro
altri attacchi simili.

Giudizio: fattibile, ma molto, molto improbabile, ed in ogni caso, non
ha assolutamente NULLA a che vedere col la "pessima scelta
implementativa"... è un topic completamente diverso, che non si
applica certo soltanto a questo sito!



Cordiali saluti

[Marcello Magnifico]

Post by Marco Ermini

Dal mio punto di vista "paranoico" avrei preferito una scelta molto più
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base di
HTML).

Lo abbiamo capito che lo preferisci, ma l'HTML consente entrambi,
quindi se non ci sono stringenti motivi (che non sono stati portati
fin'ora) non vedo perché spendere soldi per farlo cambiare

Il semplice shoulder surfing dovrebbe essere molto meno facile (e
infatti di solito lo e') se uno e' svelto a sufficienza sulla tastiera e
sceglie password complicate; che pero' in questo caso non servono piu' a
niente. Anzi, il rischio che qualcuno che non deve avere la password la
veda, magari per caso, durante la sessione o da una stampa, viene
moltiplicato a dismisura, al punto che non importa piu' nemmeno il modo
in cui ci si arriva (sotto ne indico comunque uno gia' meno banale),
perche' quando ci si arriva il danno e' totale.
Questo e' il motivo numero uno per "cassare" in partenza una scelta del
genere: in una web agency mediamente skillata, infatti, un programmatore
si beccherebbe una moderata tirata d'orecchi per questo, alla prima demo
interna; con l'obbligo effettivo di implementare, e alla svelta,
un'autenticazione un po' meno ingenua.

Se poi si insiste proprio nel voler considerare la cosa da un punto di
vista puramente software/remoto, come mi sembra si voglia fare, quel che
mi viene in mente sul momento e' che da un keylogger di certo non ci si
salva, ma da un serverino VNC installato all'insaputa dell'utente (giuro
che nel vario orrore su cui sono inciampato negli anni mi e' capitato di
vedere perfino questo) invece si'.

Rimane il fatto che tra il semplice vedere la sessione di qualcuno che
lavora in un applicativo e il disporre automaticamente, per questo, del
suo account c'e' una differenza notevole e sostanziale: mi sfugge come e
perche' passi cosi' facilmente sottovalutata. Non servivano proprio a
impedire questo, in origine, le password e i campi di inserimento
"ciechi"?


un saluto
Marcello

[Perego Paolo Franco]

Hello todos, quello che non ho ancora capito se è stata fatta una disclosure
responsabile per questo "bug", quindi si sia avvisata Vodafone in qualche
maniera e si sia in qualche modo concordata la tempistica dell'annuncio.

Ogni tanto ho nostalgia di come si fa disclosure da altre parti...

Indeed...

Post by Alessandro Romani
Dal mio punto di vista "paranoico" avrei preferito una scelta molto più

Attenzione, questa scelta implementativa potrebbe (non conosco i dettagli
quindi ipotizzo) essere a valle di un'attività di threat model. Ipotizziamo
non lo sia, quindi diciamo che effettivamente la scelta possa essere
discutibile.

Post by Alessandro Romani
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base
di HTML).

Questo ti cautela dallo shoulder surfing, non se l'attaccante compie un
attacco di phishing.

In questo caso che sia una POST o una GET nn ti importa molto perché tanto sei
riuscito a fare una mail perfettamente identica a quella di vodafone, tirar su
un sito forgiando il certificato di vodafone... insomma l'attaccante ha
dimostrato un po' di skill, che vuoi che sia una POST o una GET, si è già
guadagnato la pagnotta :-)

Post by Alessandro Romani
2) Hash della password sempre e comunque, a prescindere dalla presenza
di un certificato SSL.

Per evitare che qualche lettore usi md5 o sha1 e si senta al riparo da un
attacco criptoanalitico, sarebbe meglio parlare di cifratura del dato
piuttosto che di hashing banale. Oppure consigliare direttamente SHA256. Il
tutto IMHO.

Post by Alessandro Romani
Questo per il semplice motivo che preferisco avere più livelli di
protezione piuttosto che un unico point of failure. D'altra parte sono
già noti, in the wild, attacchi man in the middle in cui colui che sta
nel mezzo può dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare
la richiesta al sito leggittimo comportandosi, di fatto, da proxy.

Ci passi qualche link?

Ciao ciao
Paolo
--

thesp0nge // application security foo

--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[nicola mondinelli]

Post by Alessandro Romani
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base
di HTML).
2) Hash della password sempre e comunque, a prescindere dalla presenza
di un certificato SSL.

è cmq poco SANO mandare in GET (nonostante SSL/TLS) la coppia id/pw
- shoulder surfing
- qualunque javascript residente sulla pagina chiamata ha accesso a tale info, nel caso specifico Vodafone.it include in fondo un bellissimo js firmato:

* SiteCatalyst code version: H.21.
Copyright 1996-2010 Adobe, Inc. All Rights Reserved
More info available at http://www.omniture.com

Immagino che un sistema per statistiche delle visite sito tenga traccia delle url no?
per fortuna non è google analytics altrimenti vodafone regalava tutte le credenziali a google. Chissà dove è quel db... e chissà chi ci ha accesso, dopotutto è un semplice db di statistiche no? innocuo, no?

Non sono utente vodafone e non posso controllare, ma se sono presenti link a siti esterni allora tramite il campo "HTTP referrer" si divulga al mondo i dati.
Oppure tramite la history del browser che mi pare sia accedibile tramite javascript... ma potrei sbagliare.

Fare un POST quindi e' ESTREMENTE UTILE. I dati in POST vengono loggati molto meno dei get.

Secondo -> fare un hash della password è inutile: diventerebbe l'hash la credenziale e non la password, e sarebbe vulnerabile al replay attack nella stessa maniera della password.

E' utile se invece si implenta anche una nonce per evitare il replay attack:

1) Server genera nonce=rnd();
2) Server genera un hash con un hmac usando la nonce come chiave e (utente concat password) come argomento.
3) Server manda a client nonce
4) client genera l'hash usando nonce come chiave e utente concat password come argomento.
5) client spedisce risultato a server
6) server confronta

il punto 2 per i più puristi spostatelo pure dopo il 5)

In questo modo è implementato un sistema resistente ai replay attack (ovviamente lo spazio delle chiavi rnd() deve essere ragionevolmente grande, 32bit basta? 48? 64?), resistente alla cattura dell'url, del POST o da quello che volete.

Dato che Ermini lavora in vodafone ed è il Network Security Manager saprà contattare chi di dovere.


NM

[Stefano Zanero]

Considerando che questa cosa viene gia' implementata da SSL nella busta
attorno, non si vede in che modo migliorerebbe la sicurezza. O contro
quale threat model sia stata pensata questa cosa.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[nicola mondinelli]

Post by Stefano Zanero
Considerando che questa cosa viene gia' implementata da SSL nella busta
attorno, non si vede in che modo migliorerebbe la sicurezza. O contro
quale threat model sia stata pensata questa cosa.

SSL non è l'eldorado della sicurezza...

nel mio per replay attack intendo:
-----------------------------------------------

Post by Stefano Zanero
https://www.vodafone.it/190/trilogy/jsp/user.do?password=TUA_PASSWORD&username=TUO_USERNAME&method=login&ty_skip_md=true

la copio e incollo (chiamiamolo cut&paste attack, non so, ma di fatto è un replay attack in tutto e per tutto) e mi loggo.

Come faccio ad avere quell'URL:
-------------------------------------------------
SSL protegge dallo spoofing lungo il percorso, ma come detto prima da me e dopo anche da Matteo Flora ci sono tante bei sistemi che hanno accesso a questa url IN CHIARO:
- il javascript che ho segnalato prima e che segnala anche Flora di Omniture aka Adobe.
- la browser history (adesso vado sul pc di mio fratello che ha vodafone e gli guardo la history...)
- javascript che accedono alla history del browser
- HTTP referrer -> La url viene consegnata alla pagina successiva... mitico!!!

Se avessi portato, a suo tempo, un sistema di autenticazione del genere all'esame di "sicurezza nelle TCL" mi avrebbero terminato sul posto!!!

utilizzare il sistema banale da me descritto (un semplice HMAC) evita che spoofando la URL (o il POST, dato che VODAFONE.IT adesso ha modificato da GET a POST!!! almeno questo dopotutto hanno capito...)
si ottengono le tutte informazioni per accedere, con un CUT&PASTE ATTACK :).

SSL usato così mi ricorda l'RC4 usato in WEP: ottimi sistemi ma implementazione bieca.
Non si può pensare che SSL sia la soluzione a ogni problema.

la mitica soluzione tanto al kilo che si diceva prima :-)

NM.

ps.
Qualcuno ha accesso ai DB di omniture che ho perso la password? :-)

[Marcello Magnifico]

Post by nicola mondinelli
- il javascript che ho segnalato prima e che segnala anche Flora di Omniture aka Adobe.
- la browser history (adesso vado sul pc di mio fratello che ha vodafone e gli guardo la history...)
- javascript che accedono alla history del browser
- HTTP referrer -> La url viene consegnata alla pagina successiva...

(o a un provider di contenuti esterni, se ce ne sono, come e' stato
fatto notare ipotizzando uno scenario con banner provider, dove una
informazione di questo tipo non solo viene utilizzata ma e' essenziale
per distinguere quale sito clicca di piu' i banner e come ricompensare
chi li ospita).

Altro modo per mettere in evidenza il rischio legato al metodo seguito:

-Un server VNC nascosto, installato all'insaputa dell'utente (mi e'
capitato di scoprirne uno presso chi non sapeva nemmeno cosa fosse),
magari addirittura da lui stesso (tramite un trojan). Ovviamente, col
passaggio al POST, da un keylogger non ci si difende; ma almeno da
questo si', ed e' gia' qualcosa. Paradossalmente, un VNC nascosto, o un
equivalente "geneticamente modificato" :-) per essere lui a "chiamare
casa", rischia di "carpire" perfino i dati da un metodo di inserimento
molto differente che ho visto in giro e che era venduto come piu' sicuro
di altri: vi era stata implementata a video una tastiera (in AJAX, Flash
o altro: non lo so perche' non ho avuto modo di esaminarlo da vicino) da
azionare col mouse.

Credo si possa riformulare lo scopo di questa discussione, nata come
PASSWORD GET vs. POST over HTTPS ma di natura molto generale, domandando
e domandandosi: e' sufficiente assumere che un servizio/applicativo di
rete sia ben protetto "solo" perche' usa qualche buon layer
crittografico nella connessione di rete? Secondo me non del tutto, dato
che la crittografia protegge, appunto, la connessione soltanto,
lasciando fuori tutto il resto. Nel caso scatenante, ci sono dati assai
vitali "disclosed", e molto piu' a lungo, rispetto a numerose altre
applicazioni che pure girano in HTTPS; il che comporta certamente una
vulnerabilita' maggiore, a prescindere dal modo in cui un attaccante
puo' arrivare a sfruttarla. L'assunzione che il client sia sicuro sotto
qualsiasi punto di vista, fisico e non, sembra il tallone d'Achille, in
questo caso.

Il suggerimento piu' valido, nell'immediato, e' senz'altro l'uso del
POST, come da inizio del thread.

Un suggerimento anche migliore, per un futuro piu' lontano, e'
senz'altro l'impiego di un metodo di autenticazione basato sulla
gestione della sessione, nel quale i dati inseriti dall'utente per
identificarsi siano utilizzati solo al momento di iniziarla, e non in
maniera persistente durante tutta la sessione stessa. Cio' implica una
buona sicurezza nel caso si usi un identificatore di sessione one-time
gestito lato server e utilizzato "al volo" dal browser, quindi reso non
valido quando non serve piu'. Se si preferisce non lasciare tracce
sull'hard disk del client, come risulta con un sito in HTTPS, per il
quale i browser non dovrebbero tenere alcuna disk cache, e' possibile
non mettere il Session-ID in un cookie (che e' anche lui un file
sull'hard disk) e passarlo in POST (campo hidden nell'HTML ritrasmesso
di pagina in pagina dopo il login); possibilmente, non in GET,
altrimenti si finirebbe ancora piuttosto vicini al punto dal quale si e'
partiti.
Se, infatti, qualcuno "leggesse" il session-ID in GET da una URL mentre
una sessione ha luogo (e sono io il primo ad ammettere che bisognerebbe
essere proprio svelti e/o avere una fortuna sfacciata), si potrebbe
comunque arrivare a usare l'applicativo e la sessione "rubata". In una
tale situazione, si potrebbe comunque cambiare (se non viene richiesta
daccapo quella corrente) la password dell'utente legittimo, allo scopo
di tagliarlo fuori dal suo account (se ne accorgerebbe, certo; ma
sarebbe anche tardi). Col POST, un modo che mi viene in mente, sul
momento, per "esporre" quei dati sarebbe che l'utente stesso aprisse il
sorgente della pagina per andare a vedere dove sono i campi hidden...
cioe' che li andasse a cercare, di proposito, e proprio mentre viene
spiato. Questo e' effettivamente meno probabile. Vale anche per username
e password, ma con un Session-ID il rischio, cioe' l'ammontare del danno
se/quando non e' piu' potenziale ma reale, e' gia' piu' basso.


saluti,
Marcello Magnifico

[Stefano Zanero]

Post by Marcello Magnifico
-Un server VNC nascosto, installato all'insaputa dell'utente

Di nuovo, risk assessment failure.

Se la macchina ha un VNC trojan installato, il fatto che l'URL compaia
sulla barra del browser e' l'ultimo dei problemi, cavoli. Perche' dove
installo un VNC ci posso installare anche un benedettissimo keylogger!

Post by Marcello Magnifico
magari addirittura da lui stesso (tramite un trojan). Ovviamente, col
passaggio al POST, da un keylogger non ci si difende; ma almeno da
questo si', ed e' gia' qualcosa.

No, e' nulla (perche' riduci la vulnerabilita' su una minaccia
infinitesima di una minaccia molto maggiore)

Post by Marcello Magnifico
e domandandosi: e' sufficiente assumere che un servizio/applicativo di
rete sia ben protetto "solo" perche' usa qualche buon layer
crittografico nella connessione di rete?

No, non e' sufficiente.

Post by Marcello Magnifico
Un suggerimento anche migliore, per un futuro piu' lontano, e'
senz'altro l'impiego di un metodo di autenticazione basato sulla
gestione della sessione, nel quale i dati inseriti dall'utente per
identificarsi siano utilizzati solo al momento di iniziarla, e non in
maniera persistente durante tutta la sessione stessa.

Non mi pare che il problema fosse questo (il problema era il passaggio
via GET dei dati alla prima chiamata dopo la form di autenticazione, non
per tutta la sessione...).

Il resto della mail e' da manuale, ma non rilevante alla discussione.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[Stefano Zanero]

Post by nicola mondinelli
ci sono tante bei sistemi che hanno accesso a questa url

Se ci sono componenti non-SSL importati in una pagina SSL, quello e' il
problema ed eliminarli la soluzione, non improbabili nonce via HTTP e
Javascript.

Post by nicola mondinelli
- la browser history (adesso vado sul pc

Se hai accesso al PC di una persona, SSL e le URL sono l'ultimo dei tuoi
problemi.

Post by nicola mondinelli
utilizzare il sistema banale da me descritto (un semplice HMAC) evita
che spoofando la URL (o il POST, dato che VODAFONE.IT adesso ha
modificato da GET a POST!!! almeno questo dopotutto hanno capito...)
si ottengono le tutte informazioni per accedere, con un CUT&PASTE ATTACK :).

Non diciamo termini a caso, per favore. Che significa "spoofando la URL" ?

Post by nicola mondinelli
SSL usato così mi ricorda l'RC4 usato in WEP

Ma non diciamo cose che non stanno ne' in cielo ne' in terra, per cortesia.

Post by nicola mondinelli
implementazione bieca. Non si può pensare che SSL sia la soluzione a
ogni problema.

No, ma nemmeno inventarsi problemi assurdi, quando i problemi di
sicurezza delle transazioni di oggi si chiamano drive-by download.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[nicola mondinelli]

Post by Stefano Zanero

Post by nicola mondinelli
ci sono tante bei sistemi che hanno accesso a questa url

Se ci sono componenti non-SSL importati in una pagina SSL, quello e' il
problema ed eliminarli la soluzione,

Mi rendo conto di parlare arabo:
Non è un problema di SSL. SSL da tutte le garanzie del mondo(autenticazione, confidenzialità, intergrità, non ripudio ecc...), ma solo tra i due endpoint.
Non garantisce nulla al di fuori di quel link. Indi se la url è trasmessa sicura all'interno del canale SSL ma poi, sul server viene consegnata a destra e a manca allora è come chiudere la porta a chiave e lasciare la finestra aperta.
Capisci che non è un problema di componenti non-SSL in pagine SSL?

Post by Stefano Zanero
non improbabili nonce via HTTP e
Javascript.

capisco il tuo disprezzo, ma se non porti argomentazioni a riguardo è un po inutile alla discussione.

Post by Stefano Zanero

Post by nicola mondinelli
- la browser history (adesso vado sul pc

Se hai accesso al PC di una persona, SSL e le URL sono l'ultimo dei tuoi
problemi.

Certo, perchè la browser history la puoi accedere solo se se fisicamente sul PC!!!
il primo controesempio che mi viene in mente:
http://docs.sun.com/source/816-6408-10/history.htm

Post by Stefano Zanero

Post by nicola mondinelli
utilizzare il sistema banale da me descritto (un semplice HMAC) evita
che spoofando la URL (o il POST, dato che VODAFONE.IT adesso ha
modificato da GET a POST!!! almeno questo dopotutto hanno capito...)
si ottengono le tutte informazioni per accedere, con un CUT&PASTE ATTACK :).

Non diciamo termini a caso, per favore. Che significa "spoofando la URL" ?

... scusate lo slang!!!
Intendevo: "venuti in possesso della URL", cmq mi aspettavo una riposta nel merito e non sulla terminologia.

Post by Stefano Zanero

Post by nicola mondinelli
SSL usato così mi ricorda l'RC4 usato in WEP

Ma non diciamo cose che non stanno ne' in cielo ne' in terra, per cortesia.

non volevo farti arrabbiare!
C'è una ragione ben specifica per quella frase, come tu ben sai nel WEP viene utilizzato RC4. I problemi di sicurezza subito ('99) nati nel WEP (non le weakness scoperte nel 2004) erano riguardanti non RC4 in se' ma l'adozione di un IV-space troppo piccolo per il suo uso (24bit). Quindi RC4 era relativamente sicuro ma il WEP no. Ne ho fatto la similitudine con il processo di autenticazione di vodafone.it -> SSL è sicuro ma il sistema che lo implementa ha fatto delle scelte bieche (uid e pw in chiaro nella URL) che introducono altre falle. Ripeto:
Chiudo la porta a chiave con un lucchetto indistruttibile e poi esco lasciando la finestra a piano terra spalancata??

Post by Stefano Zanero

Post by nicola mondinelli
implementazione bieca. Non si può pensare che SSL sia la soluzione a
ogni problema.

No, ma nemmeno inventarsi problemi assurdi, quando i problemi di
sicurezza delle transazioni di oggi si chiamano drive-by download.

Cioè stai dicendo "il mondo ha ben altri problemi che questo"? certo, ma possiamo cmq discuterne, e il fatto che vodafone.it sia passato da GET a POST è indice che qualcosa dopotutto è servito. Poi magari cambieranno anche la pw in chiaro.

ma: Quale sarebbe il "problema assurdo inventato" ?

Post by Stefano Zanero
--
Cordiali saluti,
Stefano Zanero
Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Magari invece sono io che mi spiego male: ci riprovo.

Post by nicola mondinelli
Non è un problema di SSL. SSL da
tutte le garanzie del mondo(autenticazione, confidenzialità,
intergrità, non ripudio ecc...), ma solo tra i due endpoint.

Oh, e fino a qui ci siamo.

Post by nicola mondinelli
sicura all'interno del canale SSL ma poi, sul server viene consegnata
a destra e a manca

Ma se io ho accesso al server SU CUI ti stai autenticando (e da cui, fin
troppo spesso, hai accesso al DB degli utenti in chiaro...), il modello
di minaccia e' un altro. Non sto dicendo che non sia sbagliato usare una
get (l'ho detto nella prima mail: la soluzione e' passare a una post).
Sto dicendo che generalizzare questo a "allora faccio l'hash e lo passo
all'indietro, con l'uso di un nonce come challenge" e' una cosa
completamente inutile :-)

Post by nicola mondinelli

non improbabili nonce via HTTP e Javascript.

capisco il tuo disprezzo, ma se non porti argomentazioni a riguardo è
un po inutile alla discussione.

Non e' disprezzo: e' una constatazione, un javascript client side non
protegge niente di piu' di cio' che e' protetto da SSL.

Post by nicola mondinelli

Se hai accesso al PC di una persona, SSL e le URL sono l'ultimo dei
tuoi problemi.

Certo, perchè la browser history la puoi accedere solo se se
http://docs.sun.com/source/816-6408-10/history.htm

Non penso tu abbia ben compreso limitazioni e vincoli dell'usare quella
funzione per leggere da remoto la history (hint: non puoi ottenerla
tutta, puoi fare domande e avere risposte. E quindi, non ti aiuta per
quello di cui stiamo discutendo).

Post by nicola mondinelli
... scusate lo slang!!! Intendevo: "venuti in possesso della URL",

Siccome "spoofing" significa il simmetrico di "sniffing", non e' slang:
e' sbagliato.

Post by nicola mondinelli
cmq mi aspettavo una riposta nel merito e non sulla terminologia.

Ti ho risposto nel merito in un altro messaggio. Se la comunicazione non
e' protetta da SSL, il tuo metodo non serve a nulla (giacche' tutto cio'
che accade lato javascript puo' a sua volta essere fatto saltare). Se la
comunicazione e' protetta da SSL, il tuo metodo non serve a nulla, a
meno che l'aggressore a) controlli il server (e allora non serve a nulla
per altre ragioni), oppure b) controlli il client (e allora non serve a
nulla per altre ragioni).

Post by nicola mondinelli
GET a POST è indice che qualcosa dopotutto è servito. Poi magari
cambieranno anche la pw in chiaro.

Che non e' in chiaro da nessuna parte (specie avendo cambiato da GET a
POST), ma vabbe', inutile ripetersi ulteriormente.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[nicola mondinelli]

Post by Stefano Zanero
Ma se io ho accesso al server SU CUI ti stai autenticando (e da cui, fin
troppo spesso, hai accesso al DB degli utenti in chiaro...), il modello
di minaccia e' un altro.

si ,vero ma pensavo anche al seguente fatto:
L'accesso al db delle utenze sarà rigorosamente controllato, ma l'accesso al db delle statistiche o altro che memorizza le url magari non è così controllato come il db delle utente, proprio perchè _si crede_ che dopotutto sono _solo_ URL.

Post by Stefano Zanero
e' sbagliato.

Sad but True. Ho detto una vaccata.

Post by Stefano Zanero

Post by nicola mondinelli
cmq mi aspettavo una riposta nel merito e non sulla terminologia.

Ti ho risposto nel merito in un altro messaggio. Se la comunicazione non
e' protetta da SSL, il tuo metodo non serve a nulla (giacche' tutto cio'
che accade lato javascript puo' a sua volta essere fatto saltare). Se la
comunicazione e' protetta da SSL, il tuo metodo non serve a nulla, a
meno che l'aggressore a) controlli il server (e allora non serve a nulla
per altre ragioni), oppure b) controlli il client (e allora non serve a
nulla per altre ragioni).

Si verissimo. Ma io proponevo solo il meccanismo HMAC in seguito alla proposta di passare un HASH normale al posto della pw in chiaro.
Ovvio che se mettiamo in post il tutto siamo tutti felici, come tutti stiamo dicendo (e come hanno fatto).

Post by Stefano Zanero

Post by nicola mondinelli
GET a POST è indice che qualcosa dopotutto è servito. Poi magari
cambieranno anche la pw in chiaro.

Che non e' in chiaro da nessuna parte (specie avendo cambiato da GET a
POST), ma vabbe', inutile ripetersi ulteriormente.

vero.

NM

[Matteo G.P. Flora]

Post by Perego Paolo Franco

Post by Alessandro Romani
D'altra parte sono
già noti, in the wild, attacchi man in the middle in cui colui che sta
nel mezzo può dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare
la richiesta al sito leggittimo comportandosi, di fatto, da proxy.

Ci passi qualche link?

<http://www.f-secure.com/v-descs/dnschang.shtml>

Il sistema è semplice: cambi DNS e la macchina dall'altra parte fa da
Proxy e risponde per Vodafone (in questo caso).

Altra cosa carina che mi viene in mente è un rogue advertising che
recuperi tramite referrer il nome della pagina che lo ospita.

Un saluto.

M.

[Stefano Zanero]

Post by Matteo G.P. Flora

Post by Perego Paolo Franco

Post by Alessandro Romani
D'altra parte sono
già noti, in the wild, attacchi man in the middle in cui colui che sta
nel mezzo può dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare
la richiesta al sito leggittimo comportandosi, di fatto, da proxy.

Ci passi qualche link?

<http://www.f-secure.com/v-descs/dnschang.shtml>
Il sistema è semplice: cambi DNS e la macchina dall'altra parte fa da
Proxy e risponde per Vodafone (in questo caso).

Ed esattamente questo come romperebbe SSL ?

Post by Matteo G.P. Flora
Altra cosa carina che mi viene in mente è un rogue advertising che
recuperi tramite referrer il nome della pagina che lo ospita.

Un rogue advertising sul portale di un gestore di telefonia?

O, in generale: advertisement di terze parti sul portale di un gestore?
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Matteo G.P. Flora]

Post by Stefano Zanero

Post by Matteo G.P. Flora
<http://www.f-secure.com/v-descs/dnschang.shtml>
Il sistema è semplice: cambi DNS e la macchina dall'altra parte fa da
Proxy e risponde per Vodafone (in questo caso).

Ed esattamente questo come romperebbe SSL ?

Mi piaci tantissimo quando hai tutta questa fiducia nella popolazione
umana, ti eleva tantissimo ;)
Se agisce da Proxy durante del Phishing, pensi che _VERAMENTE_ la
persona che sta abboccando a phishing controlli lo strano avviso che
dice che il certificato SSL non corrisponde? :)
Perchè nel thread iniziale si parlava di quello, l'ipotesi phishing.

Che poi sia o meno una cazzata è un discorso differente, ma i DNS sono
un giocattolo più divertente di quanto comunemente pensato :)

Post by Stefano Zanero
Un rogue advertising sul portale di un gestore di telefonia?
O, in generale: advertisement di terze parti sul portale di un gestore?

Advertisiment di terze parti? Certo! E anche Cookie Tracker, Analytics,
Ghist-Pixels, CDN, Profiling Scripts, Iframe, Librerie Condivise... Una
selva di roba, se è per quello...

Ed è abbastanza semplicemente, se ci pensi un secondo. E' lo stesso
meccanismo con cui noi di FoolDNS andiamo a togliere l'advertising. E'
estremamente raro che tutte le risorse facenti capo ad una pagina web
siano OSPITATE sulo stesso dominio. Ci sono i counter, ci sono i
tracker, ci sono le CDN, ci sono gli AdvServer.

Nel caso di AreaProvati se dovessi io fare qualcosa di brutto credo
poisonerei http://vodafonegroup.122.2o7.net, chiamato in ogni pagina e
facente capo al Grande Occhio SempreVigile e Profilante di Omniture (aka
il tracker di omniture nella pagina).
Poisoning dello script che viene lanciato in OGNI pagina del sito,
inserimento simpatico js, grabbing URL.

Fuill, Total, Unconditioned Win.

In realtà il funzionamento dei DNS changer è ben più complesso ed
articolato di quanto si pensi di primo istinto.

My 2 eurocents.

M

[Stefano Zanero]

Post by Matteo G.P. Flora

Post by Stefano Zanero

Post by Matteo G.P. Flora
<http://www.f-secure.com/v-descs/dnschang.shtml>
Il sistema è semplice: cambi DNS e la macchina dall'altra parte fa da
Proxy e risponde per Vodafone (in questo caso).

Ed esattamente questo come romperebbe SSL ?

Mi piaci tantissimo quando hai tutta questa fiducia nella popolazione
umana, ti eleva tantissimo ;)

Non ho fiducia nella popolazione umana. Ma questo e' un problema
generale, e non c'entra nulla col fatto che tu passi i dati con GET o
con POST. Ne' e' un problema che consente di fare MITM su SSL. Consente
di fare MITM se viene violato SSL dall'utente ;-)

Post by Matteo G.P. Flora
estremamente raro che tutte le risorse facenti capo ad una pagina web
siano OSPITATE sulo stesso dominio.

Se questo accade su una pagina SSL di autenticazione, è un errore, a
prescindere (di nuovo) dal passaggio di roba su GET anziche' su POST
(che e' il topic originale del thread)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Post by Perego Paolo Franco
Hello todos, quello che non ho ancora capito se è stata fatta una disclosure
responsabile per questo "bug", quindi si sia avvisata Vodafone in qualche
maniera e si sia in qualche modo concordata la tempistica dell'annuncio.

ML in generale incoraggia la responsible disclosure.

In questo caso specifico, considerando che non si trattava di un bug con
un impatto diretto e alto sui sistemi, non ho chiesto all'autore se
l'avesse fatto.

Eventuali obiezioni o insulti sono i benvenuti in mail privata ;-)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Roberto Scaccia]

Scusami evidentemente mi sfugge il punto ma....

Il 30 maggio 2010 19.43, Alessandro Romani

Post by Alessandro Romani
Marco,
hanno chiarificato ampiamente Stefano e Marcello ciò che io ritengo un bug
in senso allargato o, per essere più precisi, una pessima scelta
implementativa.
Dal mio punto di vista "paranoico" avrei preferito una scelta molto più
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base di
HTML).

E questo mi sembra più che sensato.

Post by Alessandro Romani
2) Hash della password sempre e comunque, a prescindere dalla presenza di un
certificato SSL.

Scusa ma l'hash dove lo calcoli? Puoi fare un Javascript che si
calcola l'hash dei campi prima di inviare la GET/POST con l'hash
appunto. A quel punto fai un match dell'hash che ti è arrivato dal
client e l'hash memorizzato....Ma a questo punto la tua credenziale
diventa l'hash e non più la password. E allora basta sniffare l'hash!

Del resto se qualcuno può sniffare sulla tua macchina il traffico vuol
dire che con buona probabilità è un amministratore e allora sei già
nelle mani del nemico ;-)

Post by Alessandro Romani
Questo per il semplice motivo che preferisco avere più livelli di protezione
piuttosto che un unico point of failure. D'altra parte sono già noti, in the
wild, attacchi man in the middle in cui colui che sta nel mezzo può
dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare la richiesta al
sito leggittimo comportandosi, di fatto, da proxy.

Esistono gli Extended Certificate che sono ben visibili dagli utenti.
Se poi l'utente è talmente tonto da cascare in siti di phishing oppure
la rete è talmente bucata che piazzano sniffer ovunque o peggio fare
MTM, non è che lo puoi imputare al GET/POST :-)

Ma mi viene il dubbio che forse mi sono perso qualche cosa....
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Roberto Scaccia]

Scusami evidentemente mi sfugge il punto ma....

Il 30 maggio 2010 19.43, Alessandro Romani

Post by Alessandro Romani
Marco,
hanno chiarificato ampiamente Stefano e Marcello ciò che io ritengo un bug
in senso allargato o, per essere più precisi, una pessima scelta
implementativa.
Dal mio punto di vista "paranoico" avrei preferito una scelta molto più
1) Form inviato in POST (come, d'altronde, si insegna sulla guida base di
HTML).

E questo mi sembra più che sensato.

Post by Alessandro Romani
2) Hash della password sempre e comunque, a prescindere dalla presenza di un
certificato SSL.

Scusa ma l'hash dove lo calcoli? Puoi fare un Javascript che si
calcola l'hash dei campi prima di inviare la GET/POST con l'hash
appunto. A quel punto fai un match dell'hash che ti è arrivato dal
client e l'hash memorizzato....Ma a questo punto la tua credenziale
diventa l'hash e non più la password. E allora basta sniffare l'hash!

Del resto se qualcuno può sniffare sulla tua macchina il traffico vuol
dire che con buona probabilità è un amministratore e allora sei già
nelle mani del nemico ;-)

Post by Alessandro Romani
Questo per il semplice motivo che preferisco avere più livelli di protezione
piuttosto che un unico point of failure. D'altra parte sono già noti, in the
wild, attacchi man in the middle in cui colui che sta nel mezzo può
dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare la richiesta al
sito leggittimo comportandosi, di fatto, da proxy.

Esistono gli Extended Certificate che sono ben visibili dagli utenti.
Se poi l'utente è talmente tonto da cascare in siti di phishing oppure
la rete è talmente bucata che piazzano sniffer ovunque o peggio fare
MTM, non è che lo puoi imputare al GET/POST :-)

Ma mi viene il dubbio che forse mi sono perso qualche cosa....
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Pasqualetti, Fausto]

Concordo... Non capisco davvero il problema del GET o del POST.
Semmai avete controllato che la sessione utente sia stata aperta sul server e che sia difficilmente riproducibile o identificabile?

Come diceva Stefano il problema è drive-by download con tutte le conseguenze, quindi il tallone d'achille come giustamente si diceva nella discussione (anche se io preferisco dire l'anello debole della catena) è client side, per questo è opportuno prendere le opportune precauzioni server side:

1. Canale di comunicazione criptato (SSL va benissimo, fin quando non ci saranno i computer quantistici :P)

2. Meccanismo solido e sicuro di sessione lato server (non mi dilungo nella tipologia e topologia di secure session sharing in architetture web)

3. Eventuale criptazione (e.g. one time pad) per scambio informazioni client-server (cookie, stringhe sia in GET e in POST etc etc)

4. Utilizzo di strong authentication (e.g. two factor authentication) per le aree riservate del sito

5. Evitare tutti i controlli e i metodi client side, quali active-x, flash,javascript, ajax per lo scambio di informazioni che si vogliono mantenere riservate

Sicuramente mi è sfuggito qualcosa, ma l'ora è tarda
Buona Notte

Fausto




-----Original Message-----
Roberto Scaccia wrote:

Esistono gli Extended Certificate che sono ben visibili dagli utenti.
Se poi l'utente è talmente tonto da cascare in siti di phishing oppure la rete è talmente bucata che piazzano sniffer ovunque o peggio fare MTM, non è che lo puoi imputare al GET/POST :-)

Ma mi viene il dubbio che forse mi sono perso qualche cosa....

Stefano Zanero wrote:
No, ma nemmeno inventarsi problemi assurdi, quando i problemi di sicurezza delle transazioni di oggi si chiamano drive-by download.

--
Cordiali saluti,
Stefano Zanero________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Alessandro Romani]

Ciao a tutti,
scusate se forse sono stato un pò confuso e non ho spiegato approfonditamente il
mio punto di vista. Cercherò di approfondirlo e spiegarmi meglio.
Il discorso nasce tutto da una serie di esperienze che mi hanno portato a
sviluppare applicazioni "critiche" in vari linguaggi per il web su protocollo
HTTP senza alcun utilizzo di SSL.

Dato che sono stato abituato ad essere paranoico da quando ho iniziato ad
immergermi nella sicurezza, il mio contorto ragionamento mentale e relativo
approcio si basa sul postulato "Se rendi sicura, per quanto sicura sia una
parola abbastanza priva di significato, un'applicazione su protocollo HTTP
allora l'SSL aggiunge un grado di sicurezza UNO alla tua già raggiunta
sicurezza".

Penso che siamo tutti d'accordo che:

GET https://www.sito.it/pagina.do?user=user&password=password
POST https://www.sito.it/pagina.do?user=user&password=password

siano registrate sul log del webserver in questa maniera:

GET https://www.sito.it/pagina.do?user=user&password=password
POST https://www.sito.it/pagina.do

(su Apache, perlomeno, una richiesta GET è accompagnata dalle querystring mentre
una POST visualizza solo la pagina che è stata richiesta dalla POST senza dar
seguito alle querystring).

Usare una GET piuttosto che una POST, quindi, non è solo un mero aspetto
estetico per cui chi sta dietro le mie spalle non vedrà passare sulla barra
degli URL le mie querystring belle visibili, ma anche una questione di livello
di logging delle due richieste (a meno di configurare il catching delle
querystring passate in POST).

Mettendo che il webserver sia configurato per loggare *TUTTO*, un hash della
password con un random seed associato usando SHA-256 (usando Javascript alla
fonte) mi renderebbe relativamente più tranquillo dal punto di vista del
logging a livello webserver.

Immagino anche a degli scenari in cui, io utente medio, non ho la più pallida
idea di cosa voglia dire "Il certificato a qualche problema", premo lo stesso
su OK e trasferisco la mia richiesta ad un qualcosa in grado di intercettare e
reiniziare una richiesta SSL (sullo stampo dei local proxy come Paros o di
estensioni di Firefox come Tamper Data o come spiegato nel whitepaper
http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480);
anche qui un hash generato come spiegato sopra mi renderebbe relativamente più
tranquillo.

Ad esempio, mi è capitato di lavorare in realtà in cui server Windows serventi
applicazioni web non fossero hardenizzati perchè tanto Netbios era negato dal
firewall fin quando non arrivò un virus sulla LAN dove erano attestati tutti i
webserver Windows con le conseguenze che immagino intuiate. Per questo che mi
chiedo sempre: perchè applicare solamente un'unica strada quando posso
percorrerne due?

Prendendo un altro esempio indescrivibilmente più grave e calzante, quando
andavo alle superiori, il bus si fermava dalla parte opposta all'ingresso della
mia scuola e quindi dovevi attraversare la strada; c'erano le strisce pedonali,
ma, quando tre ragazzi sono finiti sotto delle auto, hanno pensato bene di
aggiungere anche un semaforo.

Ma magari sono castelli di carte che mi sto costruendo. Scusate se vi ho
annoiato.

--
Alessandro Romani
ICT Security Analyst

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Post by Alessandro Romani
approcio si basa sul postulato "Se rendi sicura, per quanto sicura sia una
parola abbastanza priva di significato, un'applicazione su protocollo HTTP
allora l'SSL aggiunge un grado di sicurezza UNO alla tua già raggiunta
sicurezza".

Siccome "sicura" non ha nessun significato, e siccome la sicurezza non
e' una variabile metrica, no, questo ragionamento non ha senso.

Nei casi che stai costruendo, l'aggressore ha accesso ai log del
webserver, e tu sei COSTRETTO a mandare la password via POST. Se questo
e' il tuo modello di minaccia, allora mandare una challenge e ottenere
all'indietro l'hash di (una challenge + l'hash salted della password
dell'utente) calcolato con un javascript lato client ha senso (perche
l'hash di (challenge + l'hash della password)? Perche' senno' devi
tenerti le password in chiaro lato server, che e' una cosa ben piu'
pericolosa di quella che stai risolvendo).

Siccome mi pare che questo modello di minaccia sia sostanzialmente
inesistente (dato che passare a POST + SSL risolve il problema da te
posto), continuo a ritenere la soluzione in attesa di un problema.

E si', certo, se l'utente viola la sicurezza di SSL per ignoranza, il
tuo meccanismo protegge la password. Ovviamente a quel punto
l'aggressore puo' fare tutte le transazioni che vuole facendo hijacking
della connessione, puo' cambiargli la password in qualcosa di noto a
lui, puo' sniffare tutto il traffico, fargli apparire un popup finto di
rinnovo della password, mandargli una finestra di login fittizia senza
il javascript lato client...

Pero' si', sicuramente il tuo sistema e' uno strato in piu'. Peccato che
la sicurezza non si calcoli a strati come le maglie di lana. Si calcola
sulla riduzione del RISCHIO, che e' basato sul prodotto di
vulnerabilita' e minacce. Ridurre una vulnerabilita' riduce sempre il
rischio, ma se la minaccia che insiste su quella vulnerabilita' e' un
infinitesimo di minacce piu' grandi, e' un sacco di lavoro buttato al vento.

Piu' chiaro ora?
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Marco Ermini]

2010/6/6 Stefano Zanero:
[...]

Post by Stefano Zanero
Peccato che
la sicurezza non si calcoli a strati come le maglie di lana. Si calcola
sulla riduzione del RISCHIO, che e' basato sul prodotto di
vulnerabilita' e minacce.

[...]

Post by Stefano Zanero
Ridurre una vulnerabilita' riduce sempre il
rischio, ma se la minaccia che insiste su quella vulnerabilita' e' un
infinitesimo di minacce piu' grandi, e' un sacco di lavoro buttato al vento.

Lavoro buttato al vento = €€ buttati al vento

...ovvero il famoso layer 8 OSI :-)

Post by Stefano Zanero
Piu' chiaro ora?

Si spera :-)


Cordiali saluti

[Claudio Telmon]

Post by Alessandro Romani
Prendendo un altro esempio indescrivibilmente più grave e calzante, quando
andavo alle superiori, il bus si fermava dalla parte opposta all'ingresso della
mia scuola e quindi dovevi attraversare la strada; c'erano le strisce pedonali,
ma, quando tre ragazzi sono finiti sotto delle auto, hanno pensato bene di
aggiungere anche un semaforo.
Ma magari sono castelli di carte che mi sto costruendo. Scusate se vi ho
annoiato.

No, stai descrivendo esattamente due concetti fondamentali della
sicurezza: la ridondanza delle protezioni e la valutazione del rischio.

Vorrei prescindere un po' dal problema specifico di Vodafone, che non ho
verificato e non intendo approfondire.
Uno dei problemi più grossi che vedo nella sicurezza informatica è c'è
troppa attenzione alla vulnerabilità "sfruttabile" sul momento e poca
all'architettura, in particolare alla ridondanza delle protezioni.
Prendendo il tuo esempio delle strisce, alla tua obiezione che secondo
te c'è un rischio significativo, avresti come risposta che "ora e
adesso" c'è una protezione (le strisce) e quindi la vulnerabilità non c'è.
Questo si vede anche nell'uso di molti modelli più o meno di moda, ad
esempio gli attack trees, in cui si suggerisce che tagliando un arco si
elimina una parte del grafo (e quindi di attacchi) trascurando qualsiasi
considerazione sulle vulnerabilità potenziali e la ridondanza.

Per quanto riguarda il rischio, vorrei entrare un po' più nel merito:
non credo che sia assolutamente la stessa cosa avere il problema dello
shoulder surfing con qualcuno che volutamente cerca di seguire la
battitura dei tasti mentre stai digitando una password, e avere la
password scritta in una URL. Per fortuna succede sempre più spesso che
nel momento delicato della scrittura chi scrive la password sia un po'
più attento a chi gli sta attorno, e che chi sta attorno abbia
l'educazione di guardare da un'altra parte, per non parlare del fatto
che seguire una battitura di tasti è più difficile che leggere una
parola sullo schermo. Viceversa, dopo aver inserito la password mi
aspetterei di poter invitare qualcuno a guardare il terminale con me
senza problemi.
Questo non per discutere il caso specifico (magari è una URL di transito
e non rimane mai veramente visibile sullo schermo), ma per dire che
spesso i "ma tanto allora si potrebbe anche..." perdono di vista
l'aspetto quantitativo che è l'essenza di una valutazione del rischio.
Infine, riguardo alle URL, è vero che le URL in generale "vanno in giro"
molto, molto più del contenuto di un post (qualche esempio è stato
fatto) e che quindi in termine di good practice e di politiche sarebbe
meglio evitare di metterci informazioni troppo delicate, e penso che
Paternò nel suo post si riferisse a questo. Questo naturalmente in
termini di linee guida in fase di progettazione, in un intervento a
posteriori può essere troppo oneroso, e magari nel caso specifico il
rischio e i vari casi in cui una URL può andare in giro sono stati
considerati ed epurati, almeno lato server.

ciao

- Claudio

[Alessandro Romani]

Ciao a tutti,
ho continuato a leggere tutti i thread con molto interesse e, a mio avviso, sono
uscite tante cose interessanti tra teorie, soluzioni, possibili scenari di
attacco e di sfruttamento di tali debolezze; si sono delineati anche vari
schieramenti. Questo è lo spirito di una ML: la condivisione.
Ringrazio tutti per aver dato vita a questa discussione da cui ho imparato e
preso spunto per approfondimenti futuri, tenendo in considerazione tutte le
vostre opinioni. Ovviamente, le opinioni possono cambiare o meno: è questo il
bello di averne, ma tutto quanto è utile per avere una crescita a riguardo.
Da alcune risposte che ho letto, pare che il mio punto di vista e quello di
altri sia una mera invenzione tecnica a cui basti applicare un bel certificato
SSL.
A questo punto, mi dispiace di aver allarmato tutti per una mia mera invenzione
tecnica.

Siamo tutti al sicuro, soprattutto su Vodafone.

Cordiali saluti,

Alessandro Romani
Security Analyst

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List