Newsgroup: it.comp.sicurezza.varie
Titolo: FINECO - il sito non e` sicuro

Salve,
non so se qualcuno ha usato i servizi di fineco. Vi racconto quello che e` 
successo....
Il sito ha cambiato look (!)... ora mi chiedono di inserire login e 
password per
entrare da una pagina NON SICURA.
Ovviamente (pensano quei furbacchioni) la pagina manda i dati a una 
sessione https.
Solo che nessuno mi assicura che la pagina che che vedo scrivendo 
'
www.fineco.it
' e dove
inserisco login e password sia quella originale e che i dati vengano 
mandate effettivamente
al sito sicuro.... ovviamente senza ricontrollare ogni volta l'html....
Un maleintenzionato potrebbe fare in modo di farmi arrivare una pagina 
'finta' che punta
a un sito non fineco (che ne so ... in armenia !)
I possibili attacchi che mi sono venuti in mente sono
- un bel virus su misura (un file .bat e` sufficente) del tuo vicino di 
scrivania
    che modifica il file c:\windows\hosts o equivalente
- tutta la serie delle debolezze dei DNS per lo spoofing
    (
http://hq.mcafeeasap.com/vulnerabilities/vuln_data/17000.asp
)
- amministratore di rete aziendale disonesto e/o un server aziendale
    (dove ci sta il proxy 
p.es
) attaccato
Dopo 3 mail al centro di assistenza tecnica non sono riuscito a farmi dare
una spiegazione di questo comportamente idiota da parte di fineco.
(mi viene il sospetto che a rispondere sia un robot !!!)
Non parliamo deglio operatori telefonici che (poverini) non capiscono nulla....
Inoltre (ma magari non e` il posto piu` adeguato per dirlo) fineco e` una 
banca,
e sul sito (cioe` nelle comunicazioni al pubblico) hanno detto una cosa 
palesemente
falsa :
http://online.fineco.it/esplora_fineco/banking/sicurezza_protezioni.asp
dal link nella home page
-----
L'inserimento di tutti i dati sensibili (codice utente, password, PIN, dati 
personali,
informazioni sul conto, ordini di borsa) è criptato e sicuro.
In fase di login i codici sono trasmessi in SSL anche se la pagina
non è criptata, perché l'SSL scatta durante l'invio.
La sicurezza nella trasmissione di dati via internet non si ricava
dalla pagina di partenza dei dati ma di quella di destinazione: sono
la procedura e la pagina che riceve i dati sensibili che devono essere 
criptate.
Il login (accesso) a Fineco funziona proprio così: la home page pubblica
è "in chiaro", ma quando si preme il tasto "ENTRA" per inviare il codice u
tente e la password, il browser passa in modalità sicura (il lucchetto
non si vede: leggi più avanti).
Fineco ha criptato solo le pagine che ricevono dati sensibili perché sarebbe
inutile e dannoso per la rapidità della navigazione
porre l'intero sito in modalità sicura.
La criptazione delle pagine le rende infatti più pesanti e
lente da scaricare per l'utente che si connette.
----
La 3a affermazione e` falsa. Una trasmissione e` sicura se oltra a mandare
i dati in forma criptata li manda anche a chi ci si aspetta...
La 5a e` stupida.
Inoltre il protocollo SSL prevede anche la firma delle pagine,
o perlomeno basta mandare le pagine 'non sensibili' con pochi bit di 
criptatura.
Infine
caliamo un velo pietoso sull'uso dei frami misti ssl/non ssl che :
1) genera una sequenza ignobile di warning e finestre di avvertimento
2) non fa comparire sistematicamente il lucchetto chiuso
in riguardo all'ultimo punto mi hanno consigliato di fare 'proprieta` della 
pagina'
per verificare che il frame sia sotto ssl.
Ma ve lo immaginate .... a ogni pagina bisogna verificare a mano che vada 
tutto bene???
Che fare... questa e` la professionalita` di una banca che fa tanto 'new 
economy'.
Giorgio

criptate.
E' la prima volta che sento dolorosamente la mancanza di Figlet. :'-(
Leonardo
-- 
"Open Source programs are designed and developed.
 Our products are tested."
 Steve Lipner, manager, Microsoft Security Response Center

economy'.
tanto c'e' poco da fare: se uno usa IIS come web server significa che
della sicurezza se ne frega.
--
Tinto (Alessandro) - PPCSP
www.tinto.org

file HTML con
scusate mi correggo
<FORM NAME="login" METHOD="POST"
ACTION="
https://www.fineco.it/fineco/PortaleLogin
"  TARGET="f2">
<input type="text" name="LOGIN">
<input type="password" name="PASSWD">
<input type="submit" value="vai">
</form>
--


economy'.
tanto c'e' poco da fare: se uno usa IIS come web server significa che
della sicurezza se ne frega.
--


 essere sicuro di mandare i dati alla presona giusta.
non ho capito! Se non e' certificato a chi mandi i dati come fai ad essere
sicuro che tu non li stia mandanto puta caso a me?

2) non fa comparire sistematicamente il lucchetto chiuso
come gli ho appena scritto (non serve, ma se gli arrivano 1000 mail
....) era molto meglio, se c'erano problemi di velocita',
semplificare la struttura togliendo immagini superflue e compagnia
bella, togliendo i frame (ma chi li usa piu' oramai?) e criptando
tutto. 
L'utente medio guarda solo a una cosa: se c'e' il lucchetto. Se non
c'e' si preoccupa. E cambia banca.
Evidentemente chi decide in FINECO guarda ai fronzoli e non alla
sostanza.


 non l'avevo notato :(
E' falso, da quel che ricordo.
Ci sono parti non in ssl, ma non contengono alcun dato.
Stasera controllo, sniffer alla mano, per vedere esattamente
cosa transita in chiaro.
-- 
Inviato il gio 18 ott 2001 17:26:29 CEST da 212.177.57.193
[212.177.57.193]
http://www.neuromante.net/

 io
Come pensavo...se si avesse la compiacenza di leggere, di tanto in
tanto...
http://online.fineco.it/esplora_fineco/trading/sicurezza
.
(non ce l'ho con te, ma non vedo il messaggio che ha originato il thread)
Che poi usino IIS...beh, certo, su questo si potrebbe argomentare.
-- 
Inviato il gio 18 ott 2001 17:29:30 CEST da 212.177.57.193
[212.177.57.193]
http://www.neuromante.net/

...

Infatti.
-- 
Inviato il gio 18 ott 2001 17:22:27 CEST da 212.177.57.193
[212.177.57.193]
http://www.neuromante.net/



perche' nella action ci scrivo l'url di una pagina che e'
https://fineco.qualcosa.eccetera
 (presa dal loro form ovviamente)
quindi i dati vengono processati dallo script che, essendo in https,
si spera sia quello giusto. Come dici, cosi' si possono sniffare? Eh,
lo so :(((
In un modo o nell'altro non mi sento piu' sicuro :(


Ci sono parti non in ssl, ma non contengono alcun dato.
sicuro di riferirti alla versione nuova?


Che poi usino IIS...beh, certo, su questo si potrebbe argomentare.
Nimda cambiava il codice html di tutte le pagine sul server infetto:
questo mi fa temere che un opportuno attacco potrebbe riuscire a
inserire del codice malizioso che posta i dati sensibili anche a chi
non e' autorizzato a riceverli.


mi dice "not found"
http://online.fineco.it/clienti/news/sicurezza_2.html
questo e' l'url giusto


mi dice "not found"
http://online.fineco.it/clienti/news/sicurezza_2.html
questo forse e' l'url che intendevi


 
https://fineco.qualcosa.eccetera
 (presa dal loro form ovviamente)
eheh, ma cosi' non ti salvi.
Se avvelenano il DNS, i dati poi rischi di mandarli da qualche altra
parte...
IMHO e' meglio se ci metti direttamente l'indirizzo IP.
-- 
Keyboard not present or keyboard error
Press F1 to resume

 c'e' si preoccupa. E cambia banca.
davvero? non mi risulta. sarei curioso di sapere quanti utenti medii se ne
preoccupano. io conosco resp. ced che non lo fanno,
e probabibilmente nemmeno sanno che significa quel buffo simboletto.
un mayhem sara' la medaglietta del gatto arturo, che oggi ho ucciso tra le
lacrime della ragazza che lavora da noi. (*)
* l'assistente di office che dormiva sul suo desktop mentre io cercavo di
lavorare
--
"Se una cosa e' segreta e riservata ad un'elite non puo' essere buona."
The Skulls - 
http://www.gnu.org/

IMHO e' meglio se ci metti direttamente l'indirizzo IP.
ho provato a mettere nel browser l'IP che mi da' il mio dns associato
a 
www.fineco.it
. Non salta fuori nulla, segno direi che il web server
non ricevendo dal browser la richiesta di un url "in lettere" non sa
come gestirla, ovvero non sa quale "document root" scegliere.


 IMHO e' meglio se ci metti direttamente l'indirizzo IP.
Molto probabilmente non funzionerebbe: tantissimi server web, ormai, usano i
domini virtuali.
Una soluzione, comunque, è quella di tenersi la giusta riga nel file hosts.
Fabio

 come gestirla, ovvero non sa quale "document root" scegliere.
?!?!!
A parte il fatto che se nel browser tu chiedi 
http://pappappero.net
 il
browser ribalta la richiesta al web server 
pappappero.net
 (anzi, all'IP
che lui risolve) come "GET / HTTP/1.0", quanto meno se l'IIS dall'altra
parte non sapesse cosa fare risponderebbe quanto meno con un 404, un 500
e dispari (internal error), o 300qualcosa (redirect).
Da me (via telnet), funziona perfettamente (
www.fineco.it
 <->
193.193.183.251)
Byez


 Una soluzione, comunque, è quella di tenersi la giusta riga nel file hosts.
Si, mi pare la migliore.
Un HappyCactus ingenuo.


e probabibilmente nemmeno sanno che significa quel buffo simboletto.
beh, non ho detto l'uTonto ma l'utente medio, ovvero quello che usa
una banca online e che non e' ancora del tutto privo di timori visto
che li' ci sono tutti i 4 soldi che ha. Quello che legge l'articolo
sulla "sicurezza dell'uso delle carte di credito in internet" su una
rivista generalista e vede scritto "se vedete il lucchetto vuol dire
che la comunicazione e' sicura".
Quello che cliccando il pulsante di logout, come ho fatto io adesso,
vede l'avviso da parte del browser "stai per usare una connessione
sicura ...."  (allora prima non lo era, si chiede il nostro utente
medio).
Questo insomma e' quello che io intendo per utente medio: uno che
magari non e' in grado di seguire questa discussione ma un minimo di
informazione ce l'ha.


193.193.183.251)
per la precisione mi salta fuori una pagina con title giusto (fineco
etc etc) ma bianca e con errori javascript. Quindi non e' la home page
giusta.
I browser moderni mandano sempre nella richiesta l'url che richiedono,
altrimenti i "virtual host" [*] non si potrebbero usare.
[*] significa che lo stesso server che ha un unico IP 10.10.10.10 puo'
ospitare 
www.sito1.it
www.sito2.it
www. ........
i cui DNS pundano sempre a 10.10.10.10. Il web server sa che alla
richiesta 
www.sito1.it
 deve associare le pagine html contenute in una
cerca cartella ("document root" per apache), ma ovviamente il browser
gli deve appunto dire che desidera 
www.sito1.it
.
A seconda della config del web server, indicando solo l'IP si puo'
ottenere una pagina di errore oppure uno dei siti ospitati ....


 sbaglio?
Un cerificato viene fatto per 
www.fineco.it
. Se il browser chiede
una pagina 
www.fineco.it
 e gli spunta 
www.pippopippo.it
 ANCHE emesso
da verisign (!) non puo` metterti il lucchetto chiuso.
(a me su ns6 mi viene il lucchetto ROSSO... ho provato :-) )
Naturalmente verisign emette un solo certificato per fineco,
e lo emette (a mano!, per mezzo omino con valigetta fino a poco tempo fa)
al signor fineco .
cmq. Per ovviare allo smoofing dei dns, e` sufficente mettere in /etc/hosts o
c:\windows\hosts l'indirizzo IP corretto di fineco e non usare proxy.
dovrebbe bastare...
Giorgio

 
Non si parlava di mandare in chiaro o criptate le informazioni
si parlava che non sei sicuro di mandarle dove devi...
la prima pagina non e` in ssl, non e` firmata. Il metodo
del form potrebbe essere manomesso (per mezzo di spooging)
a puntare da un'altra parte....
Giorgio

e dispari (internal error), o 300qualcosa (redirect).
Figliuolo! Stiamo parlando di IIS!


tanto...
Ho provato adesso (in locale e dietro un firewall in acciaio piombato) ad
avvelenare il DNS che mi fornisce l'indirizzo 
www.fineco.it
 in modo che a
un tentativo di accesso su quel sito andassi su 192.168.12.1.
Poi ho fatto certe operazionucce sulla DocumentRoot di 192.168.12.1 :-)
Poi ho modificato un po' la configurazione (fortunatamente avevo gia' del
software appropriato, perche' - per motivi leciti - stavo sperimentando a
questo scopo... se qualche brigadiere di belle speranze volesse sapere il
perche' e il percome, sa come trovarmi: mi paga un caffe' e gli spiego la
faccenda, no messing).
E mi sono ritrovato con un bellissimo sito che copia e forwarda tutto via
SSL a 
ib.fineco.it
, dimodoche' l'eventuale vittima (in questo caso io) e'
impossibilitata ad accorgersi di alcunche'. C'e' il problema che cosi' la
Fineco vede il mio IP come originatore di una connessione truffaldyna.
Ma sono abbastanza sicuro che con un po' di JavaScript posso fare in modo
da generare un reload del login con i dati veri, per cui *neanche Fineco*
si puo' rendere conto che i dati siano stati intercettati (riceve infatti
il SECONDO login, ma non avendo visto il primo, per loro e' il primo; per
l'utente, che non sa che c'e' un secondo login, il prima rimane il primo;
e tutti quanti pensano di essere al PRIMO login, mentre il server pirata,
ridacchiando, si salva una copia di tutto).
Non ho provato, ma sono abbastanza sicuro che, se lo faccio da DUE pagine
https, l'una o l'altra si incazza duramente perche' il sito non e' quello
previsto dai certificati... e inoltre Fineco si accorge del trucco, visto
che non posso certo forwardare una connessione SSL [1] - ma, quand'anche,
la forwarderei con il MIO indirizzo IP visibile a Fineco - e non e' molto
sano.
Visto che vo di fretta - domani sveglia alle 5, 'nfamato 'ane! - prendete
tutto il post con beneficio d'inventario, potrei aver fatto una delle mie
classiche minchiate delle uimména-sono-le-venti-vedrai-fo-tardi-per-céna.
Leonardo
[1] mumble. O invece si'?


informazione ce l'ha.
Ma soprattutto che seguendo questa comunicazione si chiede se in
questi casi c'è una soluzione che sia valida per tutti i casi in cui
si debba accedere ad info riservate senza essere in una pagina
"lucchettata".
Una soluzione dettata step by step per chi è autodidatta (evoluto, ma
autodidatta) del PC.
Ciao!
  Faithrich & ST2 "gentlebike"
+Rally 50 (tender to gentlebike)
 
---- "Memento audere semper" ----

 altrimenti i "virtual host" [*] non si potrebbero usare.
...
Si, mi aveva gia' scritto Fabio Panigatti facendomelo notare.
Non ci avevo pensato.
Sorry!
:)


 Figliuolo! Stiamo parlando di IIS!
ARGH! e' vero!
Quindi anche la padronanza di tutte le RFC passate, presenti e future
non servono a nulla... :(
Ciao
HappyCactus


Strano, eh? :-)
io invece l'ho messo in hosts (uso NT4 in ufficio) e funziona ... anzi
se avessi approfondito 'sta cosa 4 mesi fa mi sarebbe stata utilissima
per altri scopi, mannaggia :=)
su windos 9x si puo' fare lo stesso?


 su windos 9x si puo' fare lo stesso?
in c:\windows\hosts
in nt4 sta in c:\winnt\ o in c:\winnt\system32 ?
(dove c:\winnt e` il path di istallazione di nt)
in windows 2000 dove sta? come nt4 ?
Giorgio

in windows 2000 dove sta? come nt4 ?
\system32\drivers\etc
uguale in w2k e nt


 entrare da una pagina NON SICURA.
Succede anche con Intesatrade e fundsworld (sempre gruppo intesa) e io
per entrare con il "lucchetto" o digito password e utente sbagliato (la
pagina passa in modalitą ssl) o al posto di http metto https.
Comunque ho tanti dubbi sui sistemi che usano le banche per quanto
riguarda la sicurezza, speriamo che non succeda niente di irreparabile.
ciao

 ciao
sei sicuro che sia sufficiente usare https per avere qualche sembianza di
sicurezza? pare fin troppo semplice... chiedo perche' stavo pensando
di aprire un conto su fineco ma in questo thread ho letto delle cose
 raccapriccianti sulla sicurezza del loro sito...
ciao, saluti a tutti,
Orzouei

 di sicurezza? 
cosi il lucchetto è chiuso,, comunque potrei sbagliarmi
-- 
powered by linux

 E' la prima volta che sento dolorosamente la mancanza di Figlet. :'-(
# rpm -i figlet.rpm
Si, lo so a quali implicazioni vado incontro, pero` non mi importa ;)))
Un Henryx ardimentoso
-- 
A Gennaio, in occasione dell'uscita del kernel 2.4.0, Linus Torvalds
disse: "Da ora in poi la versione stable del kernel sara` quella con il
minor number dispari"

E' cosi' o c'e' qualcosa d'altro?!?
E' cosi'.
E questo ti spiega come mai non puoi fare SSL con i virtual hosts: perche',
quando inizia la connessione SSL, lo header NON E' ANCORA STATO INVIATO, ed
il certificato di connessione deve contenere il nome dello host... e il tuo
server non sa quale certificato inviare. E invia quello del sito master.
("Non usate 
https://www.miosito.it
 ma 
http://www.miosito.it
": indice sicuro
che il marrano sta usando quella che credo sia una orrenda estensione di un
qualche web server - non faro' nomi - che usa la prima connessione HTTP per
tirare a indovinare il certificato per la connessione https).


"lucchettata".
Piuttosto orribile, ma:
- Salvi la pagina HTML non protetta in locale - magari su un floppy.
- La apri con NOTEPAD, cerchi il campo Login: e cerchi due tags HTML
  che devono essere, uno immediatamente prima, ed uno immediatamente
  dopo: <FORM ...> e </FORM>.
- Cancelli TUTTO, tranne quello che sta fra i due tags, poi aggiungi
  un preambolo e un postambolo HTML tanto per gradire:
  <HTML><BODY>
  <TT>PING 
www.pippo.com
 deve pingare 192.168.15.24</TT>
  <FORM ...>
	Login:...
	Pass: ...
  </FORM>
  </BODY>
  </HTML>
- A questo punto, quella pagina ti ricorda quale IP devi usare, e la
  form invia i dati proprio li'.
Per la prova PING:
	Avvio->Esegui->PING 
www.pippo.com
<invio>
appare
	Pinging 
www.pippo.com
 [192.168.15.24]


 server non sa quale certificato inviare. E invia quello del sito master.
Sorry, ma sto giusto giusto perdendo tempo dietro a mod_ssl
e mi era parso di capire che si possono gestire i virtual_host
assegnando ad ognuno un proprio certificato
quindi ho non ho capito una **** io oppure nella connessione SSL viene incluso il nome
dell'host che si vuole contattare...
appena ho un po' di tempo faccio un po' di prove
bye
-- 
David Mugnai
To err is human...to really foul up requires the root password.

Piuttosto orribile, ma:
cut.
Grazie per la comprensione (e per la spiegazione!)


assegnando ad ognuno un proprio certificato
Ho detto male io. Si puo' fare SSL con i virtual hosts, purche' abbiano IP
differenti. Quel che NON si puo' fare e' l'SSL usando i NAME BASED virtual
hosts, che sono poi gli unici cui frega qualche cosa dello header Host:.
Anche questa cosa si puo' aggirare, entro certi limiti: posso usare ad es.
un certificato intestato a "*.
pippo.com
", dopodiche' basta che i miei host
virtuali name based siano nel dominio *.
pippo.com
. Usero' un solo cert, il
primo (default), intestato al dominio.


 hosts, che sono poi gli unici cui frega qualche cosa dello header Host:.
Scusa se insisto, voglio capirci chiaro in questa faccenda,
nel capitolo 3 delle reference di mod_ssl 
le direttive SSLCertificateXXXFile hanno contesto sia server config, sia virtual host
quindi posso specificare diversi certificati a seconda del VH che uso (o capito male)
se poi si aggiuge che nel manuale NON ho trovato nessun riferimento a virtual host
IP based ne deduco che i VH che intendono loro siano anche NB.
Puo' darsi che il protocollo a cui fai riferimento sia ad esempi l'SSL 2 e dal con il 3
e il TSL abbiano risolto questa faccenda...
Ancora devo finire di studiare bene il protocollo SSL e non so quindi che implicazioni
avrebbe inviare l'header host con la richiesta SSL
ciao
-- 
David Mugnai
Real programmers don't document. If it was hard to write, it should be hard to understand

avrebbe inviare l'header host con la richiesta SSL
Non mi pare che farebbe grossi danni. In realta' la sicurezza e' *maggiore*
a parita' di traffico totale sui servers, connettendosi ad un NBVH rispetto
che ad un IPBVH: se sniffo l'IP di un IPBVH, prendo il traffico SOLO di uno
dei siti; quello che voglio; ma se sniffo l'IP di un NBVH, quel traffico lo
prendo, si'; ma in mezzo a gigatonnellate di cacca proveniente da TUTTI GLI
ALTRI NBVHs ATTESTATI SU QUEL MEDESIMO IP. Origlierei in un uragano :-) - o
mi ci vorrebbe uno $niffer a$$ai $ofi$ticato.
