RELAZIONE SULL'HOME BANKING - di Francesco Parrella

RELAZIONE SULL’HOME BANKING
                               di Francesco Parrella

COS’E’
L'Home banking è un servizio delle banche rivolto in particolar modo alle famiglie.
Consiste nella possibilità di usufruire dei più svariati servizi bancari, senza doversi recare
appositamente in banca, ma utilizzando semplicemente il PC installato nella propria
abitazione.

PERCHE C’E’
Il sistema bancario internazionale è sempre vissuto in una sorta di relativa tranquillità
nell'area della competizione tra diversi istituti. La tipologia di servizi offerti non ha subito
evoluzioni profonde e lo stesso è da dirsi per la maniera di offrire gli stessi al pubblico.
Questa situazione sta lentamente evolvendo verso un ambiente più competitivo che pone
nuovi problemi agli istituti di credito e li obbliga a fare scelte strategiche nella gestione
interna.
La riduzione dei margini di profitto per le maggiori banche europee, è stata evidenziata già
da parecchio tempo ed è il primo segnale (se non addirittura il più importante) che pone un
problema di efficienza complessiva dei processi aziendali.

Inoltre il nostro paese è svantaggiato rispetto ai nostri partner europei per quanto riguarda
il costo del lavoro, sia diretto che indiretto; è opinione corrente che il settore bancario sia
uno dei più favoriti in questo campo.

Nel frattempo, vi è anche un'evoluzione nei comportamenti del cliente bancario, il ruolo
della filiale tradizionale sta perdendo lentamente una parte del predominio che ha nei
confronti degli altri canali distributivi. Le operazioni di banca non si fanno più
preferibilmente negli orari di apertura delle filiali ma al di fuori di questi.

                                 ALTRI METODI
Per far fronte a questi problemi, si è cercato di creare strumenti che fossero in grado di
ricreare le operazioni bancarie anche nelle case dei clienti, in modo da rendere meno
utilizzate le filiali permettendo così una diminuzione dei costi di gestione.
A tal fine sono stati utilizzati i seguenti mezzi:
• Televisione
• Pc
• Telefoni cellulari
Con il tv banking, viene stabilito un ponte di collegamento tra la TV tradizionale e il
computer. Vengono scambiate informazioni con un centro di controllo, mediante un piccolo
computer collegato con l'apparecchio televisivo. Il computer del centro di controllo, alle
richieste inviate dall'utente, reagisce cambiando le immagini sullo schermo televisivo.
In Svizzera sono stai investiti molti capitali in questo strumento e anche in Italia alcune
banche lo hanno fatto, però non ha avuto molto successo a causa della scomodità
nell’utilizzo (il telecomando è piuttosto macchinoso da usare), del costo degli apparecchi e
da altri fattori più o meno rilevanti.
La modalità di accesso più diffusa è quella attraverso un PC. Il contatto con la banca è
attivato dal cliente attraverso un personal computer dotato di modem e di un particolare
software, la natura di quest’ultimo, dipende da come la banca ha strutturato il contatto.
Essa ha, infatti, a disposizione due possibilità:
• utilizzare un network privato (PC Banking);
• usare una rete pubblica (Internet Banking).
Nel primo caso, il cliente potrà contattare la banca attraverso un particolare software,
richiesto dalla banca, come ad esempio applicativi commerciali quali Intuit Quicken,
Microsoft Money, etc. o, eventualmente, altri software sviluppati in proprio dalla banca.
La seconda possibilità consiste nell'utilizzo di una rete pubblica, quale è Internet, nel qual
caso, il cliente si interfaccia attraverso un software che non è un programma specifico per
applicazioni di tipo bancario bensì un software di gestione dei protocolli della rete pubblica;
tali sono ad esempio Netscape Navigator e Microsoft Internet Explorer.
L'evoluzione che ha caratterizzato il telefono cellulare negli ultimi anni ha reso possibile il
suo impiego quale vero e proprio terminale per richiedere e ricevere informazioni di
qualunque tipo, anche finanziario. Si prevede che in futuro sarà questo strumento il
metodo più utilizzato per accedere ai servizi di home banking.

TIPOLOGIA DI SERVIZI OFFERTI
La tipologia di servizi offerti, attraverso l’Internet banking, è stata, nel corso degli anni,
ampliata ed allo stato attuale, può essere ricondotta a quattro macro aree:
• servizi di tipo informativo (saldo del conto corrente, lista movimenti effettuati, situazione
   degli assegni, ecc.)
• servizi di incasso e pagamento (bonifici, giroconti, spedizione di assegni, pagamento
   effetti ed utenze, ecc.)
• servizi di investimento (compravendita di obbligazioni, azioni, ecc.)
• servizi finanziamento (a patto di riuscire ad avere le adeguate garanzie)

BANCHE ONLINE
Attualmente, quasi tutte le banche hanno offrono la possibilità di gestire un conto online.
Grazie alla diffusione di internet, è stata possibile la nascita di siti che confrontano i servizi
tra le varie banche e che permette ai clienti di scegliere quella più adatta alle sue
necessità.

STATISTICHE
In Inghilterra, 1 persona su 5 usa l’home banking. In Italia, la situazione non è ancora così
favorevole (5 milioni di conti aperti finora), ma si prevede una forte crescita (16 milioni di
conti aperti entro il 2006).
Attualmente, l’utente di home banking medio è un maschio (68%), ha un’età compresa tra
i 25 e 42 anni (62%) e ritiene che il limite dell’home banking sia legato alla sicurezza
(28%).

SICUREZZA
Attualmente, quasi tutte le banche online utilizzano il protocollo ssl a 128 bit, che permette
non solo il criptaggio dei dati, ma anche l’autenticazione delle due parti.
Ma è davvero così sicuro?

Cosa succede quando un client si connette al un server utilizzando Ssl? Semplificando un
po' le cose, i passi seguiti sono nella maggior parte dei casi i seguenti:
1. Il client (es.: user@user.com) contatta il server (es.: www.server.com), inviandogli un
"client hello" contenente una serie di dati quali la versione di Ssl utilizzata, i tipi di cifratura
e di compressione supportati, un session id, 32 bit con data e ora correnti e 28 byte
generati in maniera casuale.
2 Il server risponde inviando informazioni analoghe ("server hello"), cui segue il proprio
certificato (quasi sempre di tipo X.509) ed un "key exchange message", necessario per la
generazione di una chiave segreta qualora il certificato del server sia abilitato solo alla
firma e non alla cifratura. Esso conterrà informazioni quali modulo ed esponente di una
chiave rsa temporanea oppure parametri Diffie-Hellman. Infine, il server potrà richiedere a
sua volta un certificato al client.
3. Il client riceve il certificato, ne controlla la validità e spedisce il proprio al server, ove
questi ne abbia fatto richiesta.
4. Il server riceve l'eventuale certificato del client e a sua volta ne controlla la validità.
5. A questo punto, comincia la generazione delle chiavi segrete con cui verranno cifrate le
comunicazioni successive.
6. Client e server generano il master secret dal premaster secret, combinandolo con i dati
casuali trasmessi nei client hello e server hello, ed applicando in sequenza sha-1 e md5.
7. Il master secret appena generato è quindi utilizzato per generare finalmente, ancora
tramite md5 e sha-1, la chiave segreta che verrà utilizzata nello scambio di dati, completa
di initialization vector e message authentication code.
8. Client e server comunicano che l'handshake è terminato e che i messaggi successivi
verranno cifrati con la chiave appena trovata.
9. Il trasferimento dati ha inizio.

Ssl utilizza numerosi protocolli crittografici per le sue operazioni, quali rsa per le operazioni
di autenticazione, Diffie-Hellman per la negoziazione di chiavi segrete, md5 e sha-1 per la
verifica di integrità dei messaggi, des e rc2/rc4 per le cifratura dei dati.
La sicurezza di Ssl sarà quindi innanzitutto subordinata alla sicurezza di tutti questi
algoritmi, che puntano sulla difficile risolvibilità in tempi accettabili di particolari problemi
matematici.
Al momento attuale, tutti gli algoritmi utilizzati da Ssl sono ritenuti sicuri: cioè non si
conosce un procedimento matematico che ci permetta di calcolare, a partire da una chiave
pubblica, la sua corrispondente privata.
Un hacker che vorrebbe cercare di introfularsi nel sistema, avrebbe tre possibilità:
• Attaccare il server
• Attaccare il client
• Attaccare la linea di comunicazione
Grazie agli algoritmi utilizzati da ssl, l’attacco alla linea di comunicazione è molto difficile,
quindi conviene escluderlo. Comunque rimangono sempre il client e il server…

ATTACCHI AL CLIENT
Un certificato digitale mira ad evitare che qualcuno possa spacciarsi per qualcun altro,
legando, attraverso la firma di una terza parte fidata, una coppia di chiavi ad una persona
o ad un'organizzazione, garantendo così l'autenticazione delle controparti.
Cominciamo a vedere per esempio come tale processo di autenticazione sia implementato
all'interno del nostro navigatore e, a questo scopo, ci poniamo all'inizio del passo 3, in cui
riceviamo il certificato da parte del server appena contattato. Tale certificato conterrà la
chiave pubblica del server stesso, un'indicazione della Certification Authority che ha
rilasciato il certificato stesso, una data di scadenza, un identificativo del domain name per
cui è stato rilasciato il certificato (in questo caso sarebbe quindi www.server.com). Il tutto
sarà poi firmato con la chiave privata dell'Autorità per la Certificazione stessa, allegando
cioè al certificato un hash di tutti i dati che lo compongono e cifrando tale hash con tale
chiave privata.
Il navigatore, alla ricezione del certificato, ricalcola l'hash dei dati e lo confronta con quello
ricevuto, decodificato con la chiave pubblica dell'Autorità (le chiavi pubbliche delle
principali autorità sono già presenti nel nostro browser). Se i due hash corrispondono,
saremo sicuri che il certificato è autentico e che non è stato modificato. Inoltre, il client
controlla che il certificato non sia scaduto e che il domain name riportato sul certificato
corrisponda a quello con cui si sta cercando di connettersi. Se tutto va a buon fine, si sarà
creata quindi una "trust chain" dalla Certification Authority all'entità per cui il certificato è
stato emesso. Infine, il navigatore, cifrando il premaster secret con la chiave pubblica
riportata sul certificato del server, può sincerarsi che il server sia effettivamente in
possesso della chiave privata corrispondente.
Una soluzione al problema consiste nel crearsi, utilizzando le librerie di OpenSSL, una
propria coppia di chiavi ed un proprio certificato da fornire al client al posto di quello del
server. Nemmeno qui però le cose risultano essere semplici, perché tale certificato non
sarebbe firmato da una Certification Authority fidata, impedendo quindi la creazione della
trust chain necessaria al client per riconoscere come autentica la chiave pubblica riportata
sul certificato stesso. Il risultato è che sullo schermo della vittima apparirebbe un warning,
indicante che l'identità del server contattato non è risultata verificabile. Ed ecco qui quello
a cui abbiamo accennato prima: la tecnologia si ferma e comincia il cervello umano,
perché sarà l'utente a dover scegliere se proseguire comunque oppure no e la sua
sicurezza dipenderà unicamente dalla bontà della decisione.

L'attaccante ha comunque altre frecce per il suo arco. Una possibilità potrebbe essere
comprare un certificato da Verisign e fornirlo assieme alla chiave pubblica al posto di
quella del server al momento dell'handshaking con il client. Ma il navigatore si
accorgerebbe del trucco, perché il domain name contattato non corrisponderebbe a quello
riportato sul certificato. Risultato: un altro warning all'utente.
Un metodo per evitare questi scomodi warning, è per l'attaccante fare leva sul fatto che,
nella stragrande maggioranza dei casi, un utente si collega al sito all'inizio in maniera non
cifrata, semplicemente digitando www.server.com senza anteporre "https://". Il browser
avvierà una normale connessione http alla porta 80 del server, che provvederà poi a
ridirigere la connessione verso la 443 su https. L'attaccante in questo caso può
intercettare la connessione non cifrata, mantenere tale connessione sul lato client e
proseguire con una connessione cifrata dal lato server. In questo modo, il client non
entrerebbe mai in modalità cifrata e non richiederebbe alcun certificato. Unico problema:
non apparirebbe il lucchetto nel navigatore della vittima, che avrebbe quindi la possibilità
di accorgersi che qualcosa non va (la location bar riporterebbe http invece di https ma a
questo si ovvia con un po' di Javascript, nascondendola e sostituendola con una fasulla).
Ammesso invece che l'attaccante abbia nel suo arsenale un certificato valido e una entry
corrispondente sul dns, l'azione diventa ancora più insidiosa, perché la ridirezione dalla 80
alla 443 può avvenire sul server Ssl dell'attaccante, che ridigerebbe la connessione da
www.server.com:80 a www.evil.com:443. Il domain name del certificato e della
connessione corrisponderebbero, il browser non lancerebbe warning di sorta, il lucchetto
sarebbe al suo posto e la location bar sarebbe sempre tenuta sotto controllo tramite
Javascript.
Ma non basta...
E questa è solo la punta dell'iceberg, perché se gli utenti che prestano poca attenzione a
quello che succede alle loro connessioni cifrate sono parecchi, altrettanto numerosi sono
quelli che per esempio lanciano allegramente ogni eseguibile che arrivi via mail, senza
controllarlo prima con un antivirus aggiornato. Anche perché, diciamolo chiaramente,
crearsi una coppia di chiavi, un certificato corrispondente, effettuare un poisoning delle
tabelle arp della vittima, installare e configurare un fake Ssl server con uno script in perl
che modifichi in real time il codice html prima di inoltrarlo al destinatario, arricchendolo nel
frattempo con opportuno codice Javascript, è decisamente molto complicato. Sarà molto
più semplice per l'hacker far lanciare alla vittima un eseguibile che installi un
semplicissimo key logger che registri le password che vengono digitate o un qualsiasi
troiano che ci spedisca le chiavi private eventualmente presenti su disco o in memoria,
oppure portare la vittima su una pagina web che esegua l'upload di cookies e di token di
autenticazione verso la macchina dell'attaccante.

ATTACCHI AL SERVER
E se dal lato client le insidie non mancano, sul lato server le cose non sono certo più
rassicuranti: i dati viaggiano cifrati, d'accordo. Ma una volta raggiunto il server? Anche qui
le cose che possono andare storte fioccano, perché potremmo avere a che fare con un
server Ssl perfettamente corazzato che utilizza cifrature a prova di attacco atomico ma con
dietro un amministratore di rete che lascia aperti tutti i vari Unicode bug che settimana
dopo settimana vengono riportati su svariati siti. Un web server, a meno di applicare tutte
le patch che man mano vengono rilasciate, sarà vulnerabile a ben più di un attacco e lo
stesso discorso vale per le applicazioni che costituiscono il front-end della piattaforma di e-
banking. Qualche mese fa, in un test effettuato su un campione di banche online, è
risultato che quasi un terzo dei server analizzati risultava vulnerabile ad almeno una
tipologia di remote exploit.