Bezpečnost elektronického bankovnictví

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Bezpečnost elektronického bankovnictví Bakalářská práce

Autor:

Michal Pernikl Informační technologie, Správa a řízení IS

Vedoucí práce:

Praha

Ing, Antonín Vogeltanz

Duben, 2011

Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne 19. 4. 2011

………………………. Michal Pernikl

Poděkování: Na tomto místě bych rád poděkoval vedoucímu práce Ing. Antonínu Vogeltanzovi za cenné připomínky a odborné rady, kterými přispěl k vypracování této bakalářské práce. Dále bych chtěl poděkovat celé své rodině za velkou podporu v průběhu celého studia.

Anotace: Tato bakalářská práce se zabývá produkty elektronického bankovnictví, které nabízejí svým klientům banky v České republice. Jednotlivé produkty jsou popisovány hlavně z pohledu bezpečnosti a bezpečnostních mechanismů, kterými disponují. Převáţná část práce je zaměřena na internetové bankovnictví, které patří k nejpouţívanějším produktům elektronického bankovnictví. U toho produktu jsou bezpečnostní prvky a mechanismy popsány mnohem podrobněji neţ u ostatních. Dále jsou zde uvedeny aktuální techniky útoku na tento produkt a obrana proti nim. Nejdůleţitější částí práce je analýza bezpečnosti internetového bankovnictví, jejíţ výsledky reflektují stav bezpečnosti těchto produktů u vybraných bank v ČR. V závěru práce jsou uvedeny návrhy na zvýšení bezpečnosti jak na straně klienta, tak na straně banky.

Annotation: This bachelor thesis deals with electronic banking products offered by banks to their clients in the Czech Republic. Individual products are described primarily in terms of safety and security mechanisms. Most of the work is focused on Internet banking, which is one of the most used electronic banking products. The security elements and mechanisms of this product are described more closely than others. There is also list of the current techniques of attacks against this product and defense against them. The most important part of this work is to analyze the security of Internet banking, the results reflect the state of safety of these products in selected banks in the country. The conclusion includes suggestions for enhancing safety of the client and also the bank.

Klíčová slova: Elektronické bankovnictví, internetové bankovnictví, GSM bankovnictví, PDA bankovnictví, Java bankovnictví, telefonní bankovnicvtí, TV bankovnictví, bezpečnost, autentizace, autorizace, SSL, phishing, pharming, XSS, CSFR, MITM, SQL injekce.

Key words: Electronic banking, internetbanking, GSM banking, PDA banking, Java banking, Phonebanking, TV banking, security, authentication, authorization, SSL, phishing, pharming, XSS, CSFR, MITM, SQL injection.

Obsah Úvod ........................................................................................................................................... 8 1. Současná podoba elektronického bankovnictví ................................................................ 10 1.1. Internetbanking .......................................................................................................... 10 1.1.1

Technologie ................................................................................................................... 10

1.1.2

Požadavky na technické vybavení na straně klienta ..................................................... 12

1.1.3

Služby ............................................................................................................................ 13

1.1.4

Výhody a nevýhody ....................................................................................................... 13

1.2.

Homebanking ............................................................................................................. 13

1.2.1

Technologie ................................................................................................................... 13

1.2.2

Služby ............................................................................................................................ 14

1.2.3

Výhody a nevýhody ....................................................................................................... 14

1.3.

GSM banking ............................................................................................................. 14

1.3.1

Technologie a funkce .................................................................................................... 14

1.3.2

Služby ............................................................................................................................ 15

1.3.3

Výhody a nevýhody ....................................................................................................... 16

1.4.

WAP banking ............................................................................................................. 16

1.4.1

1.5.

Java banking .............................................................................................................. 17

1.5.1

Technologie ................................................................................................................... 17

1.5.2

Požadavky na technické vybavení klienta ..................................................................... 19

1.5.3

Služby ............................................................................................................................ 19

1.5.4

Výhody a nevýhody ....................................................................................................... 20

1.6.

PDA banking.............................................................................................................. 20

1.6.1

Technologie ................................................................................................................... 20

1.6.2

Služby ............................................................................................................................ 21

1.6.3

Výhody a nevýhody: ...................................................................................................... 21

1.7.

Phonebanking............................................................................................................. 22

1.7.1

Technologie ................................................................................................................... 22

1.7.1

Výhody a nevýhody: ...................................................................................................... 24

1.8.

2.

Technologie ................................................................................................................... 16

TV banking ................................................................................................................ 24

1.8.1

Technologie ................................................................................................................... 24

1.8.2

Služby ............................................................................................................................ 26

1.8.3

Výhody a nevýhody: ...................................................................................................... 26

Bezpečnostní prvky jednotlivých forem elektronického bankovnictví ............................. 27 2.1. Základní poţadavky na bezpečnost ........................................................................... 27 2.1.1

Identifikace klienta ........................................................................................................ 27

2.1.2

Identifikace banky ......................................................................................................... 29

2.1.3

Zabezpečení komunikačního kanálu ............................................................................. 29

2.1.4

Zabezpečení klientského zařízení .................................................................................. 30

2.1.5

2.2.

Bezpečnostní prvky Internetbankingu ....................................................................... 30

2.2.1

Identifikace klienta v internetbankingu ........................................................................ 30

2.2.2

Identifikace banky v prostředí internetbankingu .......................................................... 37

2.2.3

Zabezpečení komunikačního kanálu v prostředí internetbankingu .............................. 38

2.2.4

Zabezpečení klientského zařízení v prostředí internetbankingu .................................. 39

2.3.

Bezpečnostní prvky GSM banking ............................................................................ 40

2.3.1

Identifikace klienta v GSM bankingu ............................................................................. 40

2.3.2

Identifikace banky v prostředí GSM bankingu .............................................................. 40

2.3.3

Zabezpečení komunikačního kanálu v prostředí GSM banking .................................... 40

2.4.

Bezpečnostní prvky v Java bankingu......................................................................... 41

2.4.1

Identifikace klienta v prostředí Java bankingu .............................................................. 41

2.4.2

Identifikace banky v prostředí Java bankingu ............................................................... 41

2.4.3

Zabezpečení komunikačního kanálu v prostředí Java bankingu ................................... 42

2.5.

Bezpečnostní prvky v PDA bankingu ........................................................................ 42

2.5.1

Identifikace klienta v prostředí PDA bankingu .............................................................. 42

2.5.2

Identifikace banky v prostředí PDA bankingu ............................................................... 42

2.5.3

Zabezpečení komunikačního kanálu v prostředí PDA bankingu ................................... 42

2.6.

Bezpečnostní prvky v Phonebankingu ....................................................................... 42

2.6.1

Identifikace klienta v Phonebankingu ........................................................................... 42

2.6.2

Zabezpečení komunikačního kanálu v prostředí Phonebankingu ................................. 43

2.7.

3.

Zabezpečení bankovního systému ................................................................................ 30

Bezpečnostní prvky v TV bankingu .......................................................................... 43

2.7.1

Identifikace klienta v prostředí TV bankingu ................................................................. 43

2.7.2

Identifikace banky v prostředí TV bankingu .................................................................. 43

2.7.3

Zabezpečení komunikačního kanálu v prostředí TV bankingu ...................................... 43

Hrozby a nové trendy útoků na nejpouţívanější produkty e-bankingu............................. 44 3.1. Phishing ..................................................................................................................... 44 3.1.1

3.2.

Obrana proti phishingu ................................................................................................. 45

Pharming .................................................................................................................... 46

3.2.1

Globální Pharming ......................................................................................................... 47

3.2.2

Lokální Pharming ........................................................................................................... 47

3.2.3

Obrana proti pharmingu ............................................................................................... 48

3.3.

Cross-site scripting XSS ............................................................................................ 50

3.3.1

3.4.

Cross-site Request Forgery CSRF ............................................................................. 50

3.4.1

3.5.

Obrana proti CSRF ......................................................................................................... 53

SQL injection ............................................................................................................. 53

3.5.1

3.6.

Obrana proti XSS ........................................................................................................... 50

Obrana proti SQL injection: ........................................................................................... 54

Man in the midle ........................................................................................................ 54

3.6.1

DHCP spoofing ............................................................................................................... 54

3.6.2

ICMP Redirecting ........................................................................................................... 55

3.6.3

3.7.

4.

Mallware .................................................................................................................... 57

3.7.1

Trojské koně .................................................................................................................. 57

3.7.2

Obrana ........................................................................................................................... 57

Analýza bezpečnosti internetového bankovnictví v ČR ................................................... 58 4.1. Bezpečnost procesu autentizace klienta ..................................................................... 58 4.1.1

Hodnocení autentizačních mechanismů nižší úrovně ................................................... 58

4.1.2

Hodnocení autentizačních mechanismů vyšší úrovně .................................................. 59

4.1.3

Vyhodnocení bezpečnosti procesu autentizace ............................................................ 60

4.2.

Bezpečnost procesu autorizace transakcí ................................................................... 61

4.2.1

Hodnocení autorizačních mechanismů ......................................................................... 61

4.2.2

Vyhodnocení bezpečnosti procesu autorizace .............................................................. 63

4.3.

Test bezpečnosti webových stránek vůči XSS útokům ............................................. 64

4.3.1

Testovací nástroj Acutenetix Web Vulnerability Scanner ............................................. 64

4.3.2

Test zabezpečení webových stránek České spořitelny proti XSS útokům..................... 66

4.3.3

Test zabezpečení webových stránek ČSOB proti XSS útokům ...................................... 66

4.3.4

Test zabezpečení webových stránek GE Money Bank proti XSS útokům ..................... 66

4.3.5

Test zabezpečení webových stránek Komerční banky proti XSS útokům ..................... 66

4.3.6

Vyhodnocení testu zabezpečení webových stránek proti XSS útokům ........................ 66

4.4.

5.

Transparentní proxy ...................................................................................................... 56

Analýza kvality SSL .................................................................................................. 67

4.4.1

Testovací nástroj SSL Labs ............................................................................................. 67

4.4.2

Test kvality SSL u České spořitelny ................................................................................ 70

4.4.3

Test kvality SSL u ČSOB .................................................................................................. 70

4.4.4

Test kvality SSL u GE Money Bank ................................................................................. 71

4.4.5

Test kvality SSL u Komerční banky ................................................................................ 71

4.4.6

Vyhodnocení testu kvality SSL ....................................................................................... 71

4.5. Vyhodnocení analýzy bezpečnosti vybraných bank .................................................. 72 Návrhy na sníţení rizika úspěšného útoku ........................................................................ 74 5.1. Návrhy jak zvýšit bezpečnost na straně banky .......................................................... 74 5.1.1

Informovat klienty o možných rizicích .......................................................................... 74

5.1.2

Kontrola klientovo OS a prohlížeče ............................................................................... 75

5.1.3

DNS secure .................................................................................................................... 75

5.2.

Návrhy jak zvýšit bezpečnost na straně klienta ......................................................... 76

5.2.1

Webový prohlížeč a bezpečnostní doplňky ................................................................... 77

Závěr ......................................................................................................................................... 80 Seznam literatury ...................................................................................................................... 84 Seznam obrázků........................................................................................................................ 88 Seznam tabulek ......................................................................................................................... 89 Seznam příloh ........................................................................................................................... 89

Úvod Informační a komunikační technologie (dále pouze ICT) se stali nedílnou součástí našich ţivotů. Někteří z nás tyto technologie přivítali s otevřenou náručí a ţivot bez nich si uţ ani nedokáţou představit. Někteří, zejména starší generace, k nim přistupují poněkud skeptičtěji. Obrovský rozmach těchto technologií s sebou ovšem přináší nejen pozitiva, v podobě rychlosti, komfortnosti a dostupnosti různých produktů a sluţeb, ale samozřejmě také negativa. Za hlavní negativa jsou povaţovány zejména bezpečnostní hrozby, na které můţeme ve světě ICT narazit. Většina lidí vyuţívající tyto technologie o bezpečnostních hrozbách ani netuší nebo je rozsah jejich vědomostí o této problematice nedostatečný. V takových případech to většinou končí tak, ţe skutečné bezpečnostní hrozby a jejich důsledky poznají aţ na vlastní kůţi. Velmi diskutovaným tématem v oblasti ICT bezpečnosti jsou produkty a sluţby elektronického bankovnictví. Skutečnost, která napomáhá tomu, ţe media i odborné publikace skloňují bezpečnost elektronického bankovnictví ve všech pádech, je zakotvena hlavně v rozšířenosti těchto sluţeb a v důsledcích, které by případné narušení bezpečnosti u elektronického bankovnictví mohlo přinést. Nebavíme se zde o průměrném viru, který Vám přijde do emailové schránky a Váš antivir ho během 2 vteřin detekuje a zlikviduje, ale o velmi sofistikovaných metodách a technikách, které mohou klidně i Vaše šesticiferné konto vyţdímat do posledního haléře a to během několika vteřin aniţ byste si toho všimli. Je nebezpečí útoku elektronického bankovnictví opravdu tak veliké nebo nám media přestavují pouze paranoidní katastrofické scénáře? Jaké metody a techniky pouţívají hackeři1, aby se dostali k mým těţce vydělaným penězům? Jaké opatření bych já sám mohl podniknout pro obranu proti těmto útokům? Pokud si i Vy kladete takové otázky, patříte do skupiny osob, které by si měly přečíst tuto bakalářskou práci, kde odpovědi na tyto otázky dozajista najdete. V první kapitole této práce se seznámíme hlavně s nezbytným základem, ve kterém si představíme jednotlivé produkty elektronického bankovnictví a bankovní operace, které lze prostřednictvím nich provádět. Nepostradatelnou součástí tohoto úvodu je také vysvětlení principu technologie, na základě které jednotlivé produkty pracují a pro lepší pochopení dané problematiky je popis kaţdého produktu doplněn znázorněním jeho architektury. V závěru kaţdého produktu nechybí ani výčet výhod či nevýhod toho či onoho produktu. 1

Hacker – Je počítačový specialista, který disponuje detailními znalostmi informačních systému. Dnes jsou za hackery označovány hlavně osoby, které mají tyto znalosti a zneuţívají je k průniku do cizích systémů za účelem poškození napadeného subjektu, či za účelem vlastního obohacení.

8

V druhé kapitole si představíme tyto produkty ještě jednou, ale nyní uţ z pohledu bezpečnosti. Řekneme si, jaké bezpečnostní zásady by teoreticky měly obsahovat všechny formy elektronického bankovnictví bez ohledu na to, o jaký konkrétní produkt se jedná. Také si vysvětlíme funkci základních pouţívaných bezpečnostních mechanismů. V další fázi zjistíme, jak na tom jednotlivé produkty oproti teoretickým předpokladům ve skutečnosti jsou. Třetí kapitola potěší hlavně začínající hackery, kteří zde získají základní přehled o technikách a metodách útoků směřovaných na klienty internetového bankovnictví. Nejsou zde popsány úplně všechny typy útoků, protoţe jejich rozpětí by neodpovídalo rozsahu této práce, ale uvedl jsem hlavně útoky, které jsou stále aktuální. Útoky jsou popisovány obecně, avšak u některých je pro lepší pochopení uvedena názorná ukázka. Pro uklidnění čtenáře je u kaţdého útoku uveden také způsob obrany ať uţ na straně banky nebo na straně klienta. Čtvrtá kapitola představuje jádro celé práce. V této části je provedena analýza bezpečnosti internetového bankovnictví čtyř vybraných bank. Analýza je sloţena z hodnocení bezpečnosti procesu autentizace klienta a autorizace transakcí, dále analýza obsahuje test bezpečnosti proti útokům typu cross-site scripting a test kvality SSL2. Z výsledného hodnocení si čtenář můţe udělat obrázek jak je na tom s bezpečností právě jeho banka, pokud pouţívá internetové bankovnictví u některé z testovaných bank. Popřípadě si můţe podobnou analýzu své banky provést sám, protoţe metodika i pouţité nástroje jsou v této kapitole také uvedeny. V páté kapitole, se dozvíme, jakým způsobem i Vy můţete přispět ke zvýšení bezpečnosti Vašeho účtu a Vašich financí v prostředí internetového bankovnictví. Je zde uvedeno několik návrhů jak pro bankovní instituce, tak pro obyčejného uţivatele tohoto produktu.

2

SSL – Z anglického názvu Security Socket Layer. Protokol vyuţívaný pro bezpečnou komunikaci v prostředí internetu.

9

1.

Současná podoba elektronického bankovnictví 1.1. Internetbanking Internet je celosvětová síť propojující miliony počítačů na celém světě, coţ je jeden

z důvodů, proč si ho i banky vybraly jako jeden z moţných kanálů přímého bankovnictví. Internetbanking je aplikace, která umoţňuje klientům bank spravovat svoje finance, platby a komunikovat se svou bankou přes internet.

1.1.1 Technologie Komunikačním kanálem mezi klientem a bankou je síť internet. Jednou z nejoblíbenějších sluţeb, kterou síť internet nabízí je World Wide Web (v dále pouze web). Web si můţeme přestavit jako soustavu HTML3 souborů, které jsou známé pod pojmem webové stránky. Tyto stránky jsou vzájemně propojeny prostřednictvím HTTP4 protokolu. Web vyuţívá architektury client-server, coţ znamená, ţe veškeré HTML dokumenty jsou uloţeny na webovém serveru a uţivatel k nim získá přístup prostřednictvím webového klienta, který je reprezentován ve formě webového prohlíţeče. Aby bylo moţné dohledat konkrétní HTML dokument, bylo nutné všem HTML dokumentům přiřadit jednoznačnou identifikaci v podobě URL5 adresy, kterou uţivatel při procházení webu vţdy zadá do adresové řádky webového prohlíţeče. Sluţby webu vyuţili i banky pro svoji aplikaci internetbanking. Ukázka prostředí této aplikace je umístěna v příloze P1. Vzhledem k tomu, ţe internetbanking je webovou aplikací, nevystačí si pouze s architekturou webový client- webový server, ale vyuţívá vícevrstvou architekturu, která je znázorněna na obrázku č. 1. Architektura ve většině případů obsahuje následující vrstvy: -

Client tier: o

Tato vrstva v n-vrstvé architektuře představuje hardwarové a softwarové vybavení na straně klienta. V případě internetbankingu jde o počítač, notebook případně netbook, který disponuje webovým prohlíţeče.

3

HTML – Z anglického názvu Hyper Text Markup Language. Je to značkovací jazyk určený pro tvorbu webových stránek. 4 HTTP – Z anglického názvu Hypert Text Transport Protocol. Pomocí tohoto protokolu se dotazujeme webového serveru na jednotlivé webové stránky. 5 URL – Z anglického názvu Uniform Resource Locator. Slouţí k identifikaci objektů ve webovém světě.

10

-

Presentation tier: o

Prezentační vrstva představuje webový server, který na ţádost z klientské vrstvy poskytuje statické HTML stránky a samozřejmě v případě ţádosti na dynamicky generovaný obsah např. na aplikaci internetbanking komunikuje s business vrstvou. Na webovém serveru je většinou umístěn serverový certifikát, kterým server prokazuje svou identitu klientovi. Dále webový server navazuje s webovým klientem šifrované SSL/TLS spojení, o kterém se blíţe zmiňuji v následující kapitole. V praxi se nejčastěji pouţívá např. webový server Apache nebo IIS (Internet Infomation Server).

-

Business tier: o Business vrstvu reprezentuje aplikační server, kde je umístěna aplikace internetbanking a vykonávána veškerá aplikační logika. V této vrstvě dochází k autentizaci a autorizaci klienta, které budou podrobněji popsány v následující kapitole. V praxi jsou často vyuţívány aplikační servery WebSphere Server od společnosti IBM, Weblogic Application Server od společnosti Oracle, Glassfish od společnosti Sun Microsystems nebo opensource Tomcat.

-

Enterprise tier: o

Enterpreise vrstva umoţňuje přístup do databáze banky. Je reprezentována databázovým serverem, kterým můţe být např. databázový server Oracle, Microsoft SQL server, MySQL nebo Firebird. V některých případech můţe být mezi business vrstvou a enterprise vrstvou umístěna ještě integrační vrstva, která zajišťuje lepší komunikaci mezi aplikací a databází a odbourává závislost konkrétní aplikace na konkrétní databázi. Jednotlivé vrstvy jsou z důvodu bezpečnosti odděleny firewallem.

11

Obrázek 1: Architektura internetbankingu Zdroj: Vlastní

1.1.2 Požadavky na technické vybavení na straně klienta Hardwarové požadavky -

Procesor:

-

Operační paměť:

-

HDD:

minimum 233MHz minimum 128MB 300MB

Softwarové požadavky -

Kompatibilní operační systémy: o Microsoft XP SP3, Microsoft Vista(32bit i 64bit), Microsoft 7(32bit i 64bit), Microsoft Windows Server 2008 o Linux Ubuntu 9.10 o MacOS X 10.6 Snow Leopard

-

Podporované webové prohlíţeče: o MS Internet Explorer 6.0, 7.0, 8.0 o Mozila Firefox 3.6.x o Google Chrome 4 o Opera 10.5 o Safari 4.x

Další požadovaný software -

JRE (Java Runtime Environment) 1.6.0.18

12

1.1.3 Služby V prostředí internetbankingu má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o aktuální zůstatek o historie transakcí o elektronické vyúčtování o příkazy čekající na zpracování o aktuální kurzovní lístek

-

Bankovní operace: o zadávat jednorázové a trvalé příkazy k úhradě a inkasu (i do zahraničí) o platit za sluţby mobilních operátorů M-platby o svolení k inkasu (SIPO, Telefonica O2)

-

Další bankovní služby: o ţádost o úvěr spotřebitelský / hypoteční

1.1.4 Výhody a nevýhody Mezi přednosti internetového bankovnictví patří zcela jistě příjemné uţivatelské prostředí a rozsah dostupným bankovních operací, které lze prostřednictví této aplikace uskutečnit, coţ činí z internetbankingu lídra mezi ostatními produkty elektronického bankovnictví. Za nevýhodu lze povaţovat skutečnost, ţe internetové bankovnictví se stává terčem útoků hackerů mnohem častěji neţ ostatní formy elektronického bankovnictví.

1.2. Homebanking Homebanking je aplikace, která se velmi podobá internetbankingu. Také se zde jedná o komunikaci mezi klientem a bankou prostřednictvím sítě internet. Zásadní rozdíl je v tom, ţe se klient můţe připojit ke svému účtu jak přes webový prohlíţeč, tak i přes speciální bankovní software. Homebanking je velmi oblíben ve firemní sféře, nicméně v soukromé sféře se mnohem více prosadil právě intenetbanking.

1.2.1 Technologie Komunikační kanál mezi klientem a bankou je opět zprostředkován sítí internet. Klient musí být opět vybaven počítačem s připojením k internetu a v případě, ţe chce pouţívat

13

desktopovou bankovní aplikaci v reţimu off-line, musí disponovat také webovým prohlíţečem. Klient nejprve nainstaluje speciální bankovní aplikaci na svůj počítač, dále pak nainstaluje přiloţenou databázi (pokud se jedná o firmu, kde má mít k aplikaci přístup více uţivatelů, databáze se nainstaluje na server a aplikace je pak instalována na jednotlivé pracovní stanice). Poté se musí přes webový prohlíţeč připojit k webovému serveru banky, kde zadá autentizační údaje a z webové aplikace homebankingu si stáhne synchronizační data, coţ jsou číselníky databáze. Pak uţ záleţí na klientovi samotném, zda desktopovou bankovní aplikaci bude pouţívat v on-line reţimu tzn., ţe bude veškeré transakce provádět v rámci desktopové aplikace. Nebo má moţnost tuto aplikaci pouţívat v reţimu off-line, to znamená, ţe vytvoří např. sadu příkazů k úhradě a pak se připojí k webové aplikaci, kde tyto příkazy pouze exportuje z databáze desktopové aplikace do webové aplikace homebanking, kde je pak pouze potvrdí a odešle.

1.2.2 Služby Homebanking nabízí klientům provádět téměř stejné bankovní operace jako internetbanking.

1.2.3 Výhody a nevýhody Velkou výhodu u homebankingu je moţnost jeho propojení s účetním softwarem, čehoţ si firemní klienta velmi cení. Mezi nevýhody bych zařadil nutnost instalace speciálního bankovního softwaru a tím pádem omezení fungování aplikace pouze na počítače, kde je aplikace instalována. Nicméně tahle skutečnost můţe být z pohledu bezpečnosti brána jako výhoda.

1.3. GSM banking Dalším produktem, kterým se banky pokusili přiblíţit své klienty k jejich účtům, nese název GSM banking. GSM je globální systém pro mobilní komunikaci, z čehoţ vyplývá, ţe je tato sluţba přístupná pouze prostřednictvím mobilního telefonu.

1.3.1 Technologie a funkce Komunikačním kanálem mezi bankou a klientem je síť GSM. Specifickou vlastností GSM sítě je Subscribe Identity Modul. Tento modul je známý pod pojmem SIM karta, která

14

obsahuje potřebné informace pro přihlášení uţivatele do sítě. SIM karta je přenositelná a je moţné ji pouţít v kaţdém mobilním telefonu, který není opatřen SIM lockem6. Aby klient banky mohl GSM banking vyuţívat, musí mít dispozici mobilní telefon a samozřejmě také SIM kartu, která podporuje funkce SIM toolkit7. Klient pak navštíví pobočku své banky, kde mu na SIM kartu nainstalují bankovní aplikaci (u některých operátorů je tato aplikace jiţ nainstalována). Prostřednictví této aplikace pak můţe provádět dostupné bankovní operace. Po dokončení kaţdé operace např. příkazu k úhradě se automaticky zadané hodnoty příkazu transformují do formátu SMS8, která je pak odeslána do banky. Banka po ověření autentizace odešle klientovi odpověď na poţadovanou operaci formou SMS. Další technologie, která byla vyuţívána pro komunikaci mezi klientem a bankou v rámci sítě GSM bylo tzv. SMS bankovnictví. Klient komunikoval s bankou prostřednictví SMS, ve kterých musel ručně vypsat veškeré parametry transakce, kterou chtěl uskutečnit a to ve formátu definovaném bankou. Výhoda této technologie byla v tom, ţe nevyţadovala po SIM kartě funkci SIM toolkit, naproti tomu bych za velkou nevýhodu povaţoval klientem ručně psané poţadované transakce, coţ mohlo být velice náchylné na chybné příkazy a nepříliš uţivatelsky příjemné. V současnosti tuto technologii nemá ve své nabídce ţádná banka v ČR.

1.3.2 Služby V prostředí GSM bankingu má klient přístup k následujícím bankovním operacím: -

Přístup k informacím: o aktuální zůstatek (O2, T-Mobile, Vodafone) o historie transakcí – zasláním SMS/e-mail (O2, T-Mobile, Vodafone) o kurzovní lístek (O2, T-Mobile, Vodafone)

-

Bankovní operace: o jednorázový a trvalý příkaz k úhradě (v rámci ČR) (O2, T-Mobile, Vodafone) o svolení k inkasu (Vodafone)

-

Další služby: o dobíjení SIM karty (O2, T-Mobile, Vodafone)

6

SIM lock – Mobilní telefon disponující tímto prvkem umoţňuje pouţití SIM karty od pouze jednoho mobilního operátora. 7 SIM toolkit – Podpora přídavných funkcí SIM karty. 8 SMS – Z anglického názvu Short Message Servis (sluţba krátkých textových zpráv)

15

Obrázek 2: Ukázka GSM banking Zdroj: http://www.penize.cz/nakupy/15759-gsm-banking

1.3.3 Výhody a nevýhody Hlavní výhodu GSM bankovnictví shledávám v tom, ţe umoţňuje spravovat účet klienta prostřednictvím mobilního telefonu, kterým lze provádět bankovní operace kdekoliv, kde je dostupný signál operátora, coţ je mnohem širší okruh pouţití neţ u internetového bankovnictví. Nevýhodou pro uţivatele tohoto typu elektronického bankovnictví určitě bude méně bohatá nabídka dostupných sluţeb a horší přehlednost aplikací ve srovnání s internetovým bankovnictvím.

1.4. WAP banking Další z produktů elektronického bankovnictví, který klientovi umoţňoval komunikovat s bankou prostřednictvím mobilního telefonu, nese název WAP9 banking. WAP technologie je v současnosti převálcována modernějšími technologiemi, jako jsou PDA banking a Java banking, jejichţ rozborem se zabývám v následujících podkapitolách. Produkt WAP bankingu všechny banky stáhli ze svých nabídek.

1.4.1 Technologie WAP je standard pro bezdrátový přenos dat pouţívaný u mobilních telefonů. Důvodem, proč se u mobilních telefonů nepouţíval protokol TCP/IP a na místo toho se pouţíval protokol WAP, je velké mnoţství dat, které se nedalo přes síť GSM přenést. Můţeme tedy říct, ţe WAP je ekvivalentem TCP/IP s tím, ţe je pouţíván pro menší mnoţství přenášených dat a tedy vhodný ekvivalent pro přístup k internetu v síti GSM.

9

WAP – Z anglického názvu Wireless Application Protocol. Internetový protokol pouţívaný pro GSM sítě.

16

Obrázek 3: Architektura WAP bankingu Zdroj: Vlastní

1.5. Java banking Vzhledem k neúspěchu WAP bankingu hlavně z důvodů velkých datových přenosů a nepříjemného uţivatelského prostředí, vznikla výzva realizovat řešení umoţňující on-line spojení klienta s bankou prostřednictvím mobilního telefonu a to v takové podobě, která by zachovala výhody internetbankingu a zároveň vymítila neduhy WAP bankingu. Reakcí na tyto poţadavky byl vznik produktu nesoucí název Java banking. V současné době má ve svých produktových nabídkách Java bankovnictví pouze Komerční banka a Unicredit bank.

1.5.1 Technologie Jak z názvu vyplývá, aplikace je vyvinuta v programovacím jazyku Java a to konkrétně v platformě J2ME, coţ je platforma pro vývoj aplikací určených pro mobilní telefony. Jako první na trhu se s technologií Java banking mohla v ČR pochlubit Komerční banka, a proto jsem zvolil pro popis technologie právě její produkt Mobilní banka. Komunikace mezi klientem a bankou je řešena on-line, o coţ se v sítí GSM starají technologie GPRS10, EDGE11 nebo 3G12. Aby bylo moţné splnit poţadavky na niţší zátěţ přenášených dat a tedy udělat z klientského zařízení tzv. tenkého klienta, bylo nutné celý projekt Mobilní banky zaloţit na třívrstvé architektuře, která je znázorněna na obrázku č. 4. 10

GPRS – Z anglického názvu General Packet Radio Service. Sluţba učená pro přenos dat v rámci sítě GSM. EDGE – Z anglického názvu Enhanced GPRS. Vylepšení systému GPRS. 12 3G – Nová generace sluţeb určených pro přenos dat v rámci sítě GSM. 11

17

Ta se od dvouvrstvé architektury, která obsahuje vrstvu klienta a datovou vrstvu, liší tím, ţe se mezi klienta a datový zdroj vkládá aplikační server. Tím se dosáhne toho efektu, ţe téměř všechnu aplikační logiku, kterou byl zatěţován klient, převezme aplikační server a tím pádem klientovi výrazně uleví. O implementaci Java bankingu v komerční bance se starala společnost Cleverlance Enterprise Solution s.r.o., která zde pouţila vlastní produkt Frond-End server. Tento produkt se stará o řešení klienta a aplikačních serverů v třívrstvé architektuře. Front-End klient představuje klienta, který je nainstalován na klientském zařízení (v tomto případě na mobilním telefonu) a můţeme si ho představit jako aplikační prohlíţeč. Ve FrontEnd klientovi není napevno naprogramována ţádná aplikace a slouţí pouze k její interpretaci, jako například webový prohlíţeč slouţí k interpretaci HTML kódu. K interpretaci aplikace dojde ve chvíli, kdy Front-End server pošle do aplikačního prohlíţeče danou aplikaci a ten si uloţí potřebná data pro běh aplikace do paměti. Tím dojde k výrazné redukci datového toku mezi Front-End klientem a Front-End serverem. Front-End server slouţí tedy jako úloţiště aplikací a také jako prostředník mezi klientem a datovým zdrojem, kterým je bankovní server. Jako aplikační server je v případě produktu Mobilní banka pouţit Websphere apllication server V6.0.

Obrázek 4: Architektura Java banking Zdroj: Vlastní

18

1.5.2 Požadavky na technické vybavení klienta Hardwarové požadavky: -

Paměť telefonu:

minimum 84kb

-

Operační paměť:

minimum 200kb

-

Aktivní datové sluţby: GPRS, EDGE nebo 3G

-

Displej:

barevný 256 barev, rozlišení minimálně 128x128

Softwarové požadavky: -

kompatibilita s J2ME MIDP 1.0

1.5.3 Služby V prostředí JAVA banking má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o historie transakcí o aktuální zůstatek o zbývající limit o kurzovní lístek (Unicredit bank) o úrokové sazby u termínovaných vkladů (Unicredit bank)

-

Bankovní operace: o jednorázový příkaz k úhradě (v rámci ČR) o trvalý příkaz k úhradě (v rámci ČR) (Unicredit bank)

-

Další služby: o M-platby ( O2,Vodafone, T-Mobile) o vyuţití šablon pro opakující se platby

Obrázek 5: Ukázka prostředí Java banking Zdroj: [44] 19

1.5.4 Výhody a nevýhody Hlavní výhodu JAVA bankingu shledávám v uţivatelském prostředí viz. obrázek č. 5, které je velmi pěkně zpracované podobně jako u internetbankingu a jeho ovládání je velmi intuitivní a to vše při zachování výhod pro bankovnictví prostřednictvím mobilního telefonu. Další plus bych dal za zvolení třívrstvé architektury, která výrazně odlehčila datové toky. Za nevýhodu lze povaţovat poţadavek, aby byl mobilní telefon kompatibilní s J2ME MIDP 1.0, coţ můţe být problém u starších mobilních telefonů.

1.6. PDA banking Internetbanking se stal na poli produktů elektronického bankovnictví absolutním lídrem, a proto se banky pokoušely svým klientům nabízet produkty, které se tomuto uţivatelskému prostředí podobají, a proto některé banky vsadily na PDA banking.

1.6.1 Technologie PDA13 můţeme povaţovat za osobní počítač do kapsy. Na trhu se můţeme setkat se dvěma verzemi PDA. První verzí je PDA bez GSM modulu, tedy bez SIM karty a moţnosti připojení k síti GSM. Druhá verze PDA modulem GSM disponuje a je tedy moţné s tímto zařízením pracovat navíc jako s mobilním telefon. PDA zařízení je specifické větším dotykovým displejem a moţností připojení k wifi14 síti. PDA banking vyuţívá ke komunikaci mezi klientem a bankou stejný komunikační kanál jako internetbanking, kterým je internet. Klient vlastnící PDA zařízení s GSM modulem, má moţnost se k síti internet připojit dvěma způsoby a to buď prostřednictví wifi sítě nebo prostřednictvím sítě GSM, kde se o datový přenos starají jiţ zmíněné GPRS, EDGE nebo 3G. PDA zařízení dále musí ve svém programovém vybavení disponovat webovým prohlíţečem, který splňuje HTML standarty. Klient se pak prostřednictvím webového prohlíţeče připojí k webovému serveru banky, kde se přihlásí ke svému účtu, stejně jako je to u internetbankingu. Stejná je v tomto případě i n-vrstvá architektura, která opět obsahuje webový server, aplikační server a databáze poskytující data pro bankovní aplikaci. Tato architektura je zobrazena na obrázku č. 6.

13 14

PDA – Z anglického názvu Personal digital asistent. Wifi . Bezdrátová síť určená pro počítačovou komunikaci.

20

Jediným rozdílem vůči internetbankingu a také zároveň důvodem nazývat tento produkt PDA banking, je vzhled bankovní webové aplikace, která je zjednodušená a přizpůsobena menší velikosti displeje u PDA zařízení.

Obrázek 6: Architektura PDA banking Zdroj: Vlastní

1.6.2 Služby V prostředí PDA bankingu má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o historie transakcí o aktuální zůstatek o přehled blokací plateb platebními kartami o přehled termínovaných vkladů

-

Bankovní operace: o jednorázový a trvalý příkaz k úhradě

-

Další služby: o zaloţení termínovaného vkladu

1.6.3 Výhody a nevýhody: Hlavní výhodu PDA banking přináší hlavně klientům, kteří vlastní PDA zařízení. Tyto klienti mohou spravovat svůj účet kdekoliv v dosahu sítě wifi nebo sítě GSM a to v prostředí, které se pyšní klady internetbankingu, coţ je intuitivní ovládání a velká přehlednost oproti GSM bankingu. 21

Za nevýhodu lze povaţovat uţší nabídku bankovních operací, které by mohli být v tomto prostřední klidně na úrovni operací u internetového bankovnictví.

1.7. Phonebanking Dalším produktem, kterým se banky pokusily přiblíţit své klienty k jejich účtům, byl pojmenován Phonebanking. Jak uţ název napovídá, klient si pro spojení se svým účet vystačí pouze s telefonem, který můţe mít podobu klasické pevné linky nebo mobilního telefonu. Produkt Phonebanking můţeme rozdělit na další dva produkty a to IVR15 nebo Callcentrum.

1.7.1 Technologie V obou případech phonebankingu je komunikačním kanálem buď telefonní síť při pouţití pevného telefonu nebo síť GSM při poţití mobilního telefonu. IVR Systém Technologie IVR umoţňuje rozhovor klienta s automatickým hlasovým systémem. Základem IVR technologie je schopnost rozpoznat hlas nebo tónovou volbu telefonu, coţ znamená, ţe klient musí disponovat telefonem s tónovou volbou. Automatický hlasový systém klientovi nabídne veškeré operace, které jsou vţdy reprezentovány konkrétním znakem na klávesnici telefonu. Klient vţdy stiskne na klávesnici znak, který zvolenou operaci reprezentuje. Tímto způsobem klient ovládá všechny dostupné funkce tohoto typu bankovnictví. Hierarchie jednotlivých operací, které má klient prostřednictví IVR k dispozici je zobrazena na obrázku č. 7. Služby IVR: V prostředí IVR má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o historie transakcí o aktuální zůstatek o přehled blokací plateb platebními kartami o kurzovní lístek o úrokové sazby o bankovní poplatky

15

IVR – Z anglického názvu Interactive Voice Response (interaktivní hlasová odezva).

22

Obrázek 7: Ukázka struktury IVR Zdroj: [7] Callcentrum V případě Callcentra komunikuje klient přímo s pracovníkem banky, nikoliv pouze s hlasovým automatem a tudíţ není nutné, aby klientův telefon disponoval tónovou volbou. Služby Callcentra: V prostředí Callcentra má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o historie transakcí o aktuální zůstatek o přehled blokací plateb platebními kartami o kurzovní lístek o úrokové sazby o bankovní poplatky

-

Bankovní operace o jednorázový a trvalý příkaz k úhradě (i do zahraničí) o svolení k inkasu (O2, SIPO)

-

Další služby: o dobíjení SIM karty o změna limitu platební karty

23

1.7.1 Výhody a nevýhody: Za hlavní výhodu Phonebankingu v podobě callcentra shledávám moţnost provádět transakce a být přitom v kontaktu s pracovníkem banky, coţ můţe být při řešení nestandardních operací uţitečné. Naopak nevýhodou callcentra je cena za provedené transakce, která je ve srovnání s ostatními produkty elektronického bankovnictví mnohem vyšší. Za výhodu IVR systému povaţuju levnější způsob získání informací oproti Callcentru. Bohuţel nevýhodou IVR systému je neschopnost provádět aktivní bankovní operace.

1.8. TV banking S nástupem digitalizace televizního vysílání se značně rozšířili moţnosti vyuţití televize. Této příleţitosti se chopily banky a rozhodly se vyuţít televizi jako dalším moţnost komunikace klienta s bankou resp. se svým účtem. Výsledkem tohoto počinu je TV banking. První a v současné době jedinou bankou, která v České republice nabízí TV banking, je Poštovní spořitelna a její produkt nese název TV banka.

1.8.1 Technologie Na produktu TV banka spolupracovala Poštovní spořitelna s mobilním operátorem Eurotel (v současnosti Telefonica O2 Czech Republic a.s.). Komunikace mezi klientem a bankou probíhá prostřednictví IPTV16, coţ je tzv. televize přes internetový protokol. Aby mohl klient pouţívat IPTV a tedy i TV banku potřebuje vysokorychlostní přípojku k internetu (ADSL17, ADSL2+), modem, set-top box18 a televizní přijímač. Vzhledem k tomu, ţe se způsob vysílání IPTV liší od zemského, satelitního, či kabelového digitálního vysílání, je nutné, aby klient měl k dispozici speciální set-top box, určený právě pro IPTV. Spojení mezi klientem a bankou je realizováno prostřednictví sítě internet. V konkrétním případě Poštovní spořitelny a její TV banky, set-top box prostřednictvím sítě internet komunikuje s prostřední vrstvou, která je zde realizována Empire Middlewarem 24x7, který poskytuje klientovi aplikaci TV banka a je propojený s informačním systémem banky. Empire Middleware je postaven na Websphere apllication serveru V6.0 a databázi Oracle a pouţívá 16

IPTV – Zkratka anglického názvu Internet Protocol Television. ADSL – Zkratka anglického názvu Asymmetric Digital Subscriber Line. Asymetrické internetové připojení, kde je rychlost stahovaných dat větší, neţ rychlost dat odesílaných. 18 Set-top box – Zařízení slouţící k převodu digitálního televizního signálu na analogový. 17

24

tenkého Java klienta pro aplikaci TV banka stejně jako je tomu například u jiţ zmíněného Java bankovnictví. Architektura TV bankingu je zobrazena na obrázku č. 8. Aby klient mohl vyuţívat TV banku Poštovní spořitelny, musí mít aktivované internetové bankovnictví MAX internet a dále musí disponovat sluţbou O2 TV od společnosti Telefonika O2 Czech republic a.s. Po připojení k TV bance klient provádí veškeré dostupné aplikace prostřednictví dálkového ovladače a během toho je provázen televizním bankéřem. Do budoucnosti je plánováno rozšíření aplikace o hlasový vstup na straně klienta, aby mohl přímo komunikovat s bankéřem. Další vizí na rozšíření TV bankingu je instalace malé kamery do set-top boxu a umoţnění tak plnohodnotné videokonference. Další moţnost, kterou můţe klient pouţít pro připojení k aplikaci TV banka, je prostřednictvím počítače a aplikace Windows Media Center. Samozřejmostí je nutnost připojení počítače k síti internet. Poţadavkem na programové vybavení počítače je operační systém Windows Vista nebo novější, které obsahují aplikaci Windows Media Center. V prostředí této aplikace nalezneme TV bankovnictví pod sluţbu TV banka.

Obrázek 8: Architektura TV banking Zdroj: Vlastní

25

1.8.2 Služby V prostředí TV banking má klient přístup k následujícím bankovním sluţbám: -

Přístup k informacím: o aktuální zůstatek o transakční historie o kurzovní lístek o příkazy čekající na zpracování

-

Bankovní operace: o jednorázový a trvalý příkaz k úhradě (i do zahraničí) o svolení k inkasu (SIPO, Telefonica O2)

-

Další služby: o dobíjení SIM karty

1.8.3 Výhody a nevýhody: Za výhodu TV bankingu lze povaţovat poměrně velkou nabídku jak pasivních, tak aktivních bankovních operací, která je srovnatelná s nabídkou internetového bankovnictví a také příjemné uţivatelské rozhraní, jehoţ ukázka je v příloze P2. Nicméně hlavní nevýhodu tohoto produktu vidím v rozsáhlosti technického vybavení, kterým musí klient disponovat. V konkrétním případě TV banky si musí klient pořídit sluţbu O2 TV, bez které není moţno TV banku provozovat, coţ v důsledku pro klienta znamená značné prodraţení této formy elektronického bankovnictví oproti ostatním způsobům, které umoţňují vzdáleně spravovat své finance. Druhá moţnost připojení se k TV bance přes Windows Media Center, je sice méně náročná na technické vybavení, nicméně v případě pouţití počítače bych radši zvolil internetové bankovnictví, jehoţ nabídka jak aktivních, tak pasivních operaci je stále širší neţ u TV bankingu.

26

2.

Bezpečnostní prvky jednotlivých forem elektronického bankovnictví Jak jiţ vyplývá z předchozí kapitoly, banky se v rámci produktů elektronického

bankovnictví snaţí obsáhnout veškeré dostupné informační a komunikační technologie a vyuţít je pro zprostředkování bankovních sluţeb svým klientům. Základem kvalitního produktu elektronického bankovnictví však není jen rozsah bankovních operací, které můţe klient vyuţít nebo příjemnost uţivatelského prostředí, skrze které svůj účet ovládá, ale zejména jeho bezpečnost.

2.1. Základní požadavky na bezpečnost Vzhledem k tomu, ţe u všech produktů elektronického bankovnictví probíhá komunikace mezi klientem a bankou vzdáleně a tedy prostřednictvím některého z tzv. komunikačních kanálů je nutné z pohledu bezpečnosti zajistit splnění následujících bezpečnostních kritérií: 1. Identifikace klienta 2. Identifikace banky 3. Zabezpečení komunikačního kanálu 4. Zabezpečení klientského zařízení (popsáno pouze v souvislosti s internetbankingem) 5. Zabezpečení bankovního systému Splněním těchto kriterií získáme nutný bezpečnostní základ, ale nikoliv nelze tvrdit, ţe produkt splňující tyto kriteria bude absolutně bezpečný. O skutečné bezpečnostní robustnosti daného typu elektronického bankovnictví budou rozhodovat hlavně pouţité bezpečnostní technologie, mechanizmy a prvky, které budou v jiţ zmíněných základních pěti bodech implementovány.

2.1.1 Identifikace klienta Jeden z nejdůleţitějších bezpečnostních poţadavků směřuje na identifikaci klienta. Aby banka dosáhla skutečnosti, ţe umoţňuje přístup k bankovnímu účtu a k dostupným bankovním operacím pouze osobě, která je skutečným majitelem účtu, musí implementovat bezpečností prvky, kterým říkáme autentizace a autorizace. 27

Autentizace klienta Autentizace je proces, při kterém dochází k ověření identity klienta. Cílem tohoto procesu je zjistit, zda o přístup k účtu ţádá skutečně jeho majitel a nikoliv někdo, kdo se za majitele pouze vydává. Autentizace bývá zaloţená na některé z následujících metod: 1.) Uţivatel něco ví: -

Tento typ autentizační metody spočívá v tom, ţe klient disponuje jedinečnou informací, kterou nezná ţádná jiná osoba. Většinou se jedná o uţivatelské jméno, heslo nebo identifikační číslo.

2.) Uţivatel něco má: -

Tento typ autentizační metody spočívá v tom, ţe klient disponuje nějakým zařízením, pomocí kterého proběhne proces autentizace. Můţe jít například o USB token, kalkulátor, čipovou kartu či mobilní telefon

3.) Uţivatel něco je: -

Tento typ autentizační metody spočívá v tom, ţe klient dokazuje svou identitu prostřednictvím jeho biometrických vlastností, kterými mohou být například otisk prstu nebo skenování duhovky.

Zmíněné metody autentizace lze samozřejmě kombinovat, coţ jistě přispěje k bezpečnostní robustnosti autentizace. Při pouţití zmíněných kombinací pak mluvíme o více faktorové autentizaci. Autorizace transakcí Autorizace je proces, který slouţí k ochraně pravosti přenášených dat mezi klientem a bankou. V první řadě se jedná o ochranu dat proti jejich pozměnění neoprávněnou osobou a také o ochranu příjemce dat (v našem případě banku) před popřením pravosti odeslaných dat ze strany odesílatele (v našem případě klienta banky). Jiţ autentizovanému klientovy jsou po úspěšné autorizaci přidělena určitá oprávnění, např. moţnost provádět aktivní bankovní operace.

28

2.1.2 Identifikace banky Dalším bezpečnostním poţadavkem je identifikace banky. Aby klient měl jistotu, ţe svěřuje své údaje opravdu bance a nikoliv někomu, kdo se za banku pouze vydává, je důleţité, aby měl moţnost si její identitu ověřit. Bohuţel ne u kaţdého typu elektronického bankovnictví se mu taková moţnost naskytne. Tento bezpečnostní prvek splňuje pouze internetové bankovnictví, kde se klient připojuje k webovému serveru banky a vzhledem k tomu zde hrozí největší riziko, ţe se připojí k jinému webovému serveru, který se za bankovní pouze vydává. Identita banky je u internetového bankovnictví ověřována prostřednictví SSL certifikátu, který si klient můţe ověřit v prostředí svého webového prohlíţeče. Blíţe se o SSL certifikátu zmíním v odstavci “Zabezpečení komunikačního kanálu v prostředí internetbanigu“.

2.1.3 Zabezpečení komunikačního kanálu Dalším velmi důleţitým poţadavkem na bezpečnostní robustnost produktů elektronického bankovnictví je zabezpečení komunikačního kanálu. Vzhledem k tomu, ţe tímto kanálem proudí velmi důvěrná a citlivá data, mohlo by jejich získání neoprávněnou osobou mít fatální následky. Z tohoto důvodů se téměř ve všech komunikačních kanálech pouţívá šifrování, které znemoţňuje získání výše zmíněných citlivých dat neoprávněnou osobou. Rozlišujeme dva typy šifrování: Symetrické šifrování Tento typ šifrování pouţívá symetrický šifrovací, respektive dešifrovací klíč. Slovo „symetrický“ napovídá, ţe je pouţit stejný klíč pro šifrování i dešifrování. Z tohoto důvodu je nutné, aby si oba účastníci komunikace tento klíč před jejím zahájením vyměnili. Mezi základní symetrické šifry patří DES19, 3DES20, RC2, RC421, AES22, IDEA23. Asymetrické šifrování Tento typ šifrování pouţívá k šifrování a dešifrování dva klíče. Prvním klíčem je klíč soukromý, který si jeho majitel většinou uchovává v tajnosti a druhý klíč je klíčem veřejným, kterým jeho majitel distribuuje protistraně, se kterou chce komunikovat. K šifrování a

19

DES – Zkratka anglického názvu Data Encryption Standard 3DES – Zkratka anglického názvu Triple Data Encryption Standard 21 RC2,RC4 – Zkratka anglického názvu Rivest Cipher (proudová šifra) 22 AES – Zkratka anglického názvu Advanced Encryption Standard 23 IDEA – Zkratka anglického názvu International Data Encryption Algorithm 20

29

dešifrování lze pouţít oba klíče. Lze tedy zašifrovat např. zprávu soukromým klíčem a dešifrovat ji klíčem veřejný a stejně tak lze šifrovat zprávu klíčem veřejným a dešifrovat ji klíčem soukromým. Mezi základní asymetrické šifry patří RSA24, Diffie-Hellmanův algoritmus

2.1.4 Zabezpečení klientského zařízení Klientským zařízením se myslí zařízení, prostřednictvím kterého se klient připojuje k některému z produktů elektronického bankovnictví. U tohoto zařízení by měly být implementovány takové bezpečností prvky a mechanismy, které jsou schopné zamezit zneuţití tohoto zařízení nebo dat v něm uloţených k neoprávněnému přístupu k některému z produktů elektronického bankovnictví. Klientské zařízení je obecně povaţováno z pohledu bezpečnosti za nejslabší článek řetězce, protoţe bezpečnostní robustnost toho zařízení je pouze v rukou klienta, který se v mnoha případech k této povinnosti staví velmi benevolentně.

2.1.5 Zabezpečení bankovního systému Naopak bankovní systém lze povaţovat za bezpečnostně nejvíce robustní článek řetězce. Bezpečnost je zde zajištěna řadou hardwarových a softwarových bezpečnostních prvků, o jejichţ konfiguraci a provoz se starají IT specialisti.

2.2. Bezpečnostní prvky Internetbankingu Internetbanking je nejpouţívanějším produktem elektronického bankovnictví a i z tohoto důvodů představuje pro útočníky nejperspektivnější terč. Je nevyhnutelné, aby internetbanking splňoval všechny bezpečnostní poţadavky a to v co nejvyšší moţné míře a zajistil tak bezpečnou komunikaci mezi klientem a bankou v rámci tohoto komunikačního kanálu.

2.2.1 Identifikace klienta v internetbankingu Jak jiţ bylo zmíněno, k identifikaci klienta se pouţívají autentizační mechanismy, které jsou pak následovány autorizačními mechanismy, které uţivateli umoţňují provádění určitých operací, a které mají zajistit ochranu pravosti předávaných dat mezi klientem a bankou. V prostředí internetového bankovnictví se setkáváme s více faktorovou autentizací, která umoţňuje klientovi přístup k účtu a ve většině případů k pasivním bankovním operacím. 24

RSA – Zkratka vytvořená z iniciálů autorů této šifry, kterými jsou Rivest, Shamir, Adleman.

30

V případě, ţe chce klient vykonávat také aktivní bankovní operace, musí podstoupit navíc autorizační proces. Autentizace a autorizace se v rámci architektury internetbankingu uskutečňuje prostřednictvím aplikačním serveru. 1.) Autentizace typu „uživatel něco ví“ v prostředí internetbankingu V prostředí internetového bankovnictví jsou u tohoto typu pouţívány hlavně identifikační čísla, uţivatelská jména nebo hesla, která jsou tvořeny alfanumerickými znaky. Hesla bývají zadávány vícenásobně, a proto je nutné, aby nezůstávali na serveru v čistě textové podobě. Většinou bývají algoritmem obsahujícím jednocestnou funkci znehodnoceny a v takové podobě uloţeny do systému, aby nebylo moţné jejich zneuţití. Při opětovné autentizaci uţivatele se údaje opět pomocí stejné funkce znehodnotí a pak se porovnají s jiţ uloţenými údaji. Z bezpečnostního hlediska se nejedná o dostačující bezpečnostní prvek, který by mohl samostatně slouţit k autentizaci uţivatele a z toho důvodu je u všech bank poskytujících internetové bankovnictví pouţíván v kombinaci s autentizačními prvky typu „uţivatel něco má“. 2.) Autentizace typu „uživatel něco má“ v prostředí internetbankingu -

Autentizační kalkulačka

Autentizační kalkulátory jsou elektronická zařízení slouţící pro autentizaci klienta. Aplikační logika těchto zařízení většinou disponuje hashovacími funkcemi25 jako jsou např. MD526 nebo SHA27. Funkce autentizační kalkulačky je zaloţena na sdíleném tajemství, coţ můţe být například řetězec znaků, který je uloţen jak v kalkulačce, tak v bankovní databázi, kde musí být u kaţdého klienta uvedeno jeho konkrétní sdílené tajemství. Po té se ke sdílenému tajemství přidává některá další instance, z těchto dvou instancí se pomocí jiţ zmíněných algoritmů MD5 nebo SHA-1 vytvoří kontrolní součet, který pak slouţí jako jednorázové heslo. Vzhledem k tomu, ţe aplikace internetbanking zná z bankovní databáze sdílené tajemství daného klienta a také zná další instanci a algoritmus, kterým je tvořen kontrolní součet, je

25

Hashovací funkce – Jedná se o funkci, která vytváří ze vstupních dat otisk, který má fixní délku. Dále lze tento otisk nazývat také jako hash nebo kontrolní součet. 26 MD5 – Zkratka anglického názvu Message-Digest algorithm 5 27 SHA – Zkratka anglického názvu Secure Hash Algorithm

31

schopna si tento kontrolní součet také vytvořit a porovnat pak klientův kontrolní součet se svým kontrolním součtem a pokud jsou shodné, klient je autentizován. Autentizační kalkulátory mohou být buď v provedení s klávesnicí, kde je sdílené tajemství zašifrováno PIN kódem nebo bez klávesnice, kde sdílené tajemství PIN kódem chráněné není. Zmíněnou další instancí můţe být: a) Čas V takovém případě je autentizační kalkulačka vybavena hodinami a jednorázové heslo je vytvořeno kontrolním součtem z aktuálního času a sdíleného tajemství. Aplikace internetového bankovnictví pouţije ke kontrole aktuální čas bankovního serveru a sdílené tajemství konkrétního klienta z databáze a vytvoří si stejným algoritmem z těchto instancí kontrolní součet, a pokud dojde ke shodě s kontrolním součtem klienta, tak ho autorizuje a umoţní mu přístup do aplikace. b) Chalenge – Response V takovém případě při přihlašování klienta k aplikaci internetového bankovnictví, server vygeneruje náhodný řetězec (challenge), který klient zadá do svého kalkulátoru, kde se tento řetězec spojí se sdíleným tajemstvím a opět pomocí algoritmu se vytvoří kontrolní součet, který klient pouţije jako jednorázové heslo a napíše ho do přihlašovacího formuláře aplikace internetového bankovnictví (response). Server opět zná sdílené tajemství i klientovi odeslaný řetězec a také si z těchto instancí vytvoří kontrolní součet, který porovnává s kontrolním součtem klienta. V případě, ţe se shodují, je klient autentizován a je mu umoţněn přístup do aplikace. V tomto případě je nutné vyuţívat autentizační kalkulátor s klávesnicí. -

Autentizace prostřednictvím GSM – SMS kód

K autentizaci prostřednictví sítě GSM se vyuţívá mobilní telefon klienta. Klient zadá v přihlašovacím formuláři aplikace nějaký typ uţivatelského jména a hesla na bázi autentizace „klient něco ví“ a aplikace si najde v databázi telefonní číslo uţivatele a zašle mu prostřednictví SMS zprávy jednorázové heslo, které pak klient zadá do autentizačního formuláře aplikace a ta porovná zadané heslo s heslem odeslaným a v případě shody klienta autentizuje a umoţní mu přístup do aplikace internetového bankovnictví. Bezpečnost tohoto typu autentizace je poměrně vysoká, protoţe útočník by musel odposlouchávat dva nezávislé komunikační kanály, coţ je velmi náročná záleţitost.

32

-

Autentizace digitálním certifikátem

Další moţností autentizace v prostředí internetbankingu je vyuţití digitálního certifikátu. Digitální certifikát lze povaţovat za bezpečnostní rozšíření technologie, kterou nazýváme elektronický podpis. Základ elektronického podpisu představuje asymetrická kryptografie. Elektronický podpis představuje důkaz pravosti dat a vytváří se ve dvou krocích. 1. Odesílatel nejdříve spočte hash dokumentu, který chce odeslat. 2.

Spočtený hash zašifruje svým soukromým klíčem a odešle ho příjemci. Tento soukromým klíčem zašifrovaný hash se nazývá elektronický podpis.

Způsob jakým příjemce ověří pravost tohoto dokumentu je následující: 1. Příjemce si spočte hash přijatého dokumentu. 2. Veřejným klíčem odesílatele dešifruje hash, který zašifroval odesílatel svým soukromým klíčem. 3. Dešifrovaný hash porovná s hashem, který spočítal z přijatého dokumentu a pokud se oba shodují, dostává důkaz, ţe dokument mohl být vytvořen pouze majitelem soukromého klíče a nebyl během cesty modifikován.

Obrázek 9: Princip elektronického podpisu Zdroj: [4] Digitální certifikát je ve své podstatě veřejným klíčem uţivatele, který je podepsán elektronickým podpisem certifikační autority28 a lze ho povaţovat za potvrzení o reálném spojení daného uţivatele a jeho veřejného klíče.

28

Certifikační autorita – Subjekt, který vydává digitální certifikáty

33

Pokud chce kdokoliv získat digitální certifikát, musí si vygenerovat soukromí a veřejný klíč. Veřejný klíč si pak nechá podepsat soukromým klíčem certifikační autority, která si podle své certifikační politiky ověří, zda je ţadatel opravdu tím, za koho se vydává a na základě tohoto ověření mu certifikát buď vydá, nebo nevydá. Druhou moţností je, ţe si certifikát uţivatel podepíše sám a bude disponovat tzv. self-signed certifikátem, který však nebude vzbuzovat takovou důvěru, jako certifikáty podepsané certifikační autoritou. Nejdůleţitější informace, které certifikát obsahuje, jsou veřejný klíč, informace o majiteli veřejného klíče, informace o certifikační autoritě, která certifikát vydala a doba platnosti certifikátu. Soustava technických a organizačních opatření spojených s vydáváním, správou, pouţívání a odvoláváním kryptografických klíčů se sdruţuje pod názvem PKI. PKI je definována řadou norem, z nichţ RFC a X509 se zabývají pouţitím kryptografických klíčů a certifikátů v prostředí internetu. O proces autentizace prostřednictvím digitálního certifikátu se v prostředí internetového bankovnictví stará internetový prohlíţeč, respektive některý z jeho zásuvných modulů (plugin). Zásuvné moduly jsou softwarové komponenty, které lze do prohlíţeče nainstalovat pro rozšíření jeho funkcionality. Vzhledem k tomu, ţe dosud neexistuje ţádný standard pro digitální podpis v prostředí internetového prohlíţeče, nelze očekávat, ţe všechny banky se budou drţet jednotné technologie. Lze říci, ţe mezi technologie, které jsou schopné digitální podpis v internetovém prohlíţeči aplikovat patří Java, ActiveX, .NET, silverlight a platforma flash. Digitálního certifikát klient můţe získat v podobě souboru nebo můţe být implementován přímo do čipu. V praxi jsou nejvyuţívanější následující dvě varianty: a) Certifikát v souboru V případě certifikátu v souboru je moţné digitální certifikát uloţit na jakýkoliv typ přenosného média nebo uloţit na harddisk počítače, coţ z bezpečnostních důvodů není doporučováno, protoţe pro případného útočníka, není sloţité tento soubor získat. b) Čipová karta V tomto případě je digitální certifikát implementován do čipu čipové karty, která chrání přístup k certifikátu PINem. V tomto případě musí být klient vybaven čtečkou karet, aby bylo moţné zajistit přístup k certifikátu v internetovém prohlíţeči. Z hlediska bezpečnosti je tato varianta robustnější neţ certifikát v souboru na nezabezpečeném přenosném mediu, nicméně 34

nutnost pouţití čtečky sniţuje flexibilitu pouţití, protoţe ji s sebou klient většinou nenosí a tím pádem se omezuje na pouze domácí vyuţití internetbankingu. Způsob autentizace v internetovém bankovnictví si klient můţe u své banky vybrat. Zvolit můţe buď niţší úroveň autentizace, kterou představují jméno a heslo, digitální certifikát v souboru a SMS kód, nebo si klient můţe zvolit vyšší úroveň autentizace, která je zprostředkována prostřednictvím digitálního certifikátu na čipové kartě nebo prostřednictvím kalkulátoru. Autentizační mechanismy vyšší úrovně jsou samozřejmě bezpečnostně robustnější a většinou jsou bankami na rozdíl od mechanismů niţší úrovně zpoplatněny. Přehled autentizačních mechanismů jak niţší, tak vyšší úrovně je zachycen v tabulkách č. 1 a č. 2.

JMÉNO A HESLO CERTIFIKÁT V SOUBORU SMS KÓD Citibank Česká spořitelna ČSOB eBanka Evropsko-ruská banka GeMoney Bank Komerční banka LBBW Bank Poštovní spořitelna Raiffeisenbank UniCredit Bank Volksbank

ANO ANO ANO ANO ANO ANO ANO ANO ANO ANO ANO ANO

ANO ANO ANO ANO

ANO

ANO ANO ANO ANO

ANO ANO

ANO

Tabulka 1: Autentizační mechanismy nižší úrovně nabízené u vybraných bank Zdroj:[5],[7],[37],[38],[39],[40],[41],[42],[43], Vlastní zpracování

35

ČIPOVÁ KARTA

KALKULÁTOR

ANO

Citibank Česká spořitelna ČSOB

ANO ANO ANO

eBanka Evropsko-ruská banka GeMoney Bank Komerční banka LBBW Bank Poštovní spořitelna

ANO ANO ANO

Raiffeisenbank

ANO ANO

UniCredit Bank Volksbank

Tabulka 2: Autentizační mechanismy vyšší úrovně nabízené u vybraných bank Zdroj:[5],[7],[37],[38],[39],[40],[41],[42],[43],[50],[51], Vlastní zpracování 3.) Autorizace transakcí v prostředí internetového bankovnictví Jak jiţ bylo zmíněno, autorizace je proces, který slouţí k ochraně pravosti přenášených dat mezi klientem a bankou. Pro plnohodnotnou autorizaci je nutné splnit dva body: 1. Ochrana dat proti jejich pozměnění neoprávněnou osobou. 2. Ochranu příjemce dat (v našem případě banku) před popřením pravosti odeslaných dat ze strany odesílatele (v našem případě klienta banky). Tyto aspekty plnohodnotně splňuje pouze digitální certifikát, který zaručuje jak integritu odesílaných dat, tak i nepopiratelnost účasti klienta na transakci. Dále je pro účel autorizace v prostředí internetbankingu vyuţíván také kalkulátor nebo je autorizace prováděna prostřednictví SMS kódu odeslaného na mobilní telefon klienta. Přehled autorizačních mechanismů je zachycen v tabulce č. 3.

36

SMS KÓD CERTIFIKÁT V SOUBORU ČIPOVÁ KARTA KALKULÁTOR

ANO

Citibank Česká spořitelna ČSOB eBanka Evropsko-ruská banka GeMoney Bank Komerční banka

ANO ANO ANO ANO ANO ANO

ANO ANO ANO ANO ANO ANO

LBBW Bank Poštovní spořitelna Raiffeisenbank UniCredit Bank

ANO ANO ANO

Volksbank

ANO

ANO ANO ANO

ANO ANO

ANO ANO

Tabulka 3: Autorizační mechanismy používané u vybraných bank Zdroj:[5],[7],[37],[38],[39],[40],[41],[42],[43],[50],[51], Vlastní zpracování

2.2.2 Identifikace banky v prostředí internetbankingu V internetovém bankovnictví komunikuje klient se svou bankou prostřednictví webového prohlíţeče. Ve svém webovém prohlíţeči zadá webovou adresu své banky a připojí se k webovému serveru banky. Vzhledem k tomu, ţe klient sděluje prostřednictvím webovému serveru aplikačnímu serveru své autentizační údaje, je nutné, aby měl moţnost si ověřit, zda je sděluje opravdu prostřednictvím webové stránky banky a ne podvodné stránky, která se pouze jako bankovní tváří. K tomuto účelu jsou vyuţívány digitální certifikáty. V tomto případě se nejedná o osobní certifikát pouţívaný pro autentizaci či autorizaci klienta, ale o tzv. serverový certifikát označovaný také jako SSL certifikát. SSL certifikát se nazývá z důvodu, ţe pro jeho vystavení na webovém serveru je nutné, aby webový server disponoval SSL protokolem, o kterém se zmíním v následující podkapitole. Získání certifikátu je téměř totoţné jako získání osobního certifikátu s tím rozdílem, ţe se nevystavuje na jméno uţivatele, ale na webovou doménu ţadatele. Ţadatel o serverový certifikát si opět musí vygenerovat dvojici klíčů - soukromý a veřejný. Veřejný pak s dalšími údaji odešle certifikační autoritě, která je podle certifikační politiky zkontroluje a u které si pak certifikát vyzvedne a nakonec ho nainstaluje na webový server. 37

Klient banky má pak moţnost ve své webovém prohlíţeči při přístupu do internetového bankovnictví tento certifikát zobrazit a zkontrolovat, zda se opravdu jedná o webový server banky. Důleţité údaje, které by měl klient kontrolovat, jsou webová adresa serveru, název certifikační autority, která certifikát vydala, a datum platnosti certifikátu. Ukázka SSL certifikátu je umístěna v příloze P3.

2.2.3 Zabezpečení komunikačního kanálu v prostředí internetbankingu Komunikační kanál mezi webovým prohlíţečem klienta a webovým server banky je zabezpečen protokolem SSL (Security Socket Layer). Vzhledem k tomu, ţe rodina protokolů TCP/IP neřešila zabezpečený přenos dat, bylo nutné implementovat vrstvu SSL, která je v klasické modelu TCP/IP vloţena mezi aplikační a transportní protokol viz.obrázek č. 10. Aplikační protokol, vyuţívaný ke komunikaci mezi webovým prohlíţečem a webovým serverem, se nazývá HTTP. V případě implementace jiţ zmíněné vrstvy SSL, která komunikaci šifruje, se tento protokol stává zabezpečeným a mění se na HTTPS. SSL protokol vyuţívá asymetrické šifrování pro navázání komunikace mezi klientem a serverem a symetrické šifrování při jiţ navázané komunikaci.

Obrázek 10: Umístění vrstvy SSL v protokolech TCP/IP Zdroj: [4] Aby bylo moţné vyuţívat SSL protokol, musí webový server disponovat serverovým certifikátem. Současná verze protokolu je SSL 3.0 vyuţívá algoritmus asymetrické šifrování RSA/DSS, algoritmus symetrické šifrování DES, 3DES, IDEA, RC2, RC4 a hashovací funkci SHA-1.

38

2.2.4 Zabezpečení klientského zařízení v prostředí internetbankingu Pod pojmem klientské zařízení se v prostředí internetbankingu rozumí hlavně PC. V podstatě existuje několik zásad, které banky svým klientům doporučují a kterých by se klienti měli drţet. Mezi nejdůležitější patří: 1.) zabezpečený přístup do systému 2.) pravidelně aktualizovaný systém (hlavně bezpečnostní záplaty) 3.) nainstalovaný antivirový systém, který je pravidelně aktualizovaný 4.) správně nastavený firewall 5.) aktualizovaný webový prohlíţeč

39

2.3. Bezpečnostní prvky GSM banking 2.3.1 Identifikace klienta v GSM bankingu K autentizaci a autorizaci klienta v prostředí GSM banking slouţí tzv. bankovní PIN označovaný také jako BPIN. BPIN je 4-8 místné číslo zvolené klientem, prostřednictvím kterého se přihlašuje do aplikace GSM banking a současně mu umoţňuje v tomto prostředí provádět pasivní i aktivní bankovní operace. Aby si klient mohl zvolit BPIN potřebuje znát tzv. bankovní PUK označovaný jako BPUK, který získá buď přímo od svého operátora v případě, ţe SIM karta jiţ obsahuje bankovní aplikaci nebo od své banky v případě ţe je nutné aplikaci na SIM kartu nahrát. Při prvním přihlášení pak klient zadá svůj BPUK, pomocí kterého si zvolí svůj BPIN, kterým se pak v prostředí aplikace autentizuje a autorizuje provedené transakce.

2.3.2 Identifikace banky v prostředí GSM bankingu V prostředí GSM bankingu bohuţel nelze ověřit, zda uţivatel opravdu komunikuje se svou bankou, jako tomu je například u internetbankingu, kde si klient ověřil pravost stránky prostřednictvím serverového certifikátu banky. Tímto bezpečnostním prvkem GSM banking nedisponuje hlavně z toho důvodu, ţe ověřování totoţnosti banky můţeme v tomto prostředí povaţovat za zbytečné a máme pro to hned dva důvody. Jedním z nich je, ţe klient nepřistupuje ke svému účtu prostřednictvím webové stránky banky, ale prostřednictvím aplikace, kde je velmi nízká pravděpodobnost, ţe by útočník vytvořil kopii této aplikace. Druhým důvodem proč si GSM banking můţe dovolit postrádat identifikaci banky je skutečnost, ţe je aplikace uloţená přímo na SIM kartě telefonu, coţ je z pohledu útočníka další těţko překonatelný problém.

2.3.3 Zabezpečení komunikačního kanálu v prostředí GSM banking Komunikace mezi bankou a mobilním telefonem klienta probíhá v rámci sítě GSM prostřednictvím šifrovaných SMS zpráv. Je zde pouţito symetrické šifrování, coţ znamená, ţe obě strany (tedy klient i banka) pouţívají stejný klíč k šifrování a dešifrování SMS. Konkrétní šifrovací algoritmus pouţívaný většinou bank v ČR k šifrování komunikace v GSM bankingu je 3DES, coţ je ve své podstatě třikrát implementovaný algoritmus DES. Algoritmus DES má délku klíče 56bit, z čehoţ vyplývá, ţe délka klíče 3DES je 168bitů.

40

2.4. Bezpečnostní prvky v Java bankingu 2.4.1 Identifikace klienta v prostředí Java bankingu Autentizace klienta je u produktu Mobilní banka od Komerční banky prováděna pouze prostřednictvím identifikačního čísla, PINu a hesla. Klientovi je pak umoţněno provádět jak pasivní, tak i aktivní bankovní operace. Klient nejdříve vypíše identifikační číslo a poté je vyzván, aby zadal vybraná čísla z PINu a vybraná čísla z hesla viz.obrázek č. 11.

Obrázek 11: Autentizace v prostředí Java banking Zdroj: [50] Autentizace klienta u produktu Smart banking od Unicredit Bank probíhá zadáním identifikačního čísla a hesla, čímţ se klient dostane k moţnosti provádět pouze pasivní bankovní operace. Autorizace transakcí je zde uskutečňována, některým z typů jednorázových hesel. Můţe se jednat o kalkulátor nebo sadu kódů. V tomto případě se autorizace prostřednictví SMS kódů nevyuţívá. Z bezpečnostního hlediska lze tvrdit, ţe UniCredit Bank se svým produktem Smart banking je z pohledu autentizace klienta a autorizace transakcí bezpečnostně robustnější, neboť Komerční banka u produktu Mobilní banka ţádný proces autorizace transakcí nenabízí.

2.4.2 Identifikace banky v prostředí Java bankingu Stejně jako u GSM bankingu tak ani u Java bankingu nelze ověřit, zda klient opravdu komunikuje s bankou. Důvodem je opět skutečnost, ţe by potenciální útočník musel vytvořit duplikát aplikace a nějakým způsobem ho dokázal spojit s aplikačním klientem, který je nainstalovaný v mobilním telefonu klienta, coţ opět můţeme povaţovat za těţko překonatelný problém.

41

2.4.3 Zabezpečení komunikačního kanálu v prostředí Java bankingu Komunikační kanál Java bankingu je zabezpečen symetrickým šifrováním AES. Šifra AES je povaţována za nástupce šifry DES, o které jsem se zmínil v kontextu s šifrou 3DES pouţívanou u GSM bankingu. Délka klíče u šifry AES můţe být 128, 192 nebo 256 bitů. AES je také nazýván jako blokový šifrovací algoritmus, protoţe je vţdy aplikován na data s pevně danou délkou 128 bitů.

2.5. Bezpečnostní prvky v PDA bankingu 2.5.1 Identifikace klienta v prostředí PDA bankingu K autentizaci klienta v prostředí PDA bankingu od Raiffeisenbank slouţí identifikační číslo v kombinaci s jednorázovým autentizačním kódem vygenerovaným na kalkulátoru. Autorizace transakcí je zprostředkována také kalkulátorem, ale uţivatel musí do kalkulátoru vypsat důleţité údaje z prováděné transakce, ze kterých je mu pak vygenerován jednorázový autorizační kód.

2.5.2 Identifikace banky v prostředí PDA bankingu Prostředí PDA bankingu umoţňuje klientovi ověřit identitu webových stránek banky stejně jako je tomu u internetbankingu prostřednictví serverového certifikátu banky.

2.5.3 Zabezpečení komunikačního kanálu v prostředí PDA bankingu O bezpečnou komunikaci se v prostředí PDA bankingu stará SSL vrstva, o jejímţ způsobu šifrování jsem se zmiňoval jiţ u internetbankingu.

2.6. Bezpečnostní prvky v Phonebankingu 2.6.1 Identifikace klienta v Phonebankingu U produktu Phonebanking většina bank vyuţívá k autentizaci svých klientů identifikační číslo, popřípadě heslo. V případě autorizace transakcí bývají vyuţívány jednorázová hesla. Můţe jít například o hesla generovaná kalkulátorem, nebo sadu jednorázových kódů. Jednorázové kódy prostřednictvím SMS se u tohoto produktu nepouţívají z toho důvodu, ţe klient telefon vyuţívá ke komunikaci s bankou a bylo by obtíţené, aby klient během hovoru obsluhoval ještě příchozí SMS zprávy.

42

Pro zvýšení bezpečnosti nabízejí banky zasílání informací o provedených transakcích na e-mail klienta nebo prostřednictvím SMS na klientův mobilní telefon.

2.6.2 Zabezpečení komunikačního kanálu v prostředí Phonebankingu Komunikačním kanálem mezi klientem a bankou je buď telefonní sít nebo síť GSM a komunikace mezi klientem a bankou není ţádným způsobem šifrována.

2.7. Bezpečnostní prvky v TV bankingu 2.7.1 Identifikace klienta v prostředí TV bankingu K autentizaci klienta u produktu TV banka od Poštovní spořitelny jsou vyţadovány stejné autentizační prvky jako u internetbankingu této banky, kterými jsou identifikační číslo a PIN klienta. K autorizaci transakcí se pak vyuţívá jednorázových kódů zaslaných prostřednictvím SMS na mobilní telefon klienta.

2.7.2 Identifikace banky v prostředí TV bankingu Moţnost ověření totoţnosti banky zde chybí a důvody, proč TV banka postrádá tento bezpečnostní prvek jsou podobné jako u Java bankingu. Potenciální útočník by musel opět duplikovat aplikačního klienta v klientském zařízení, které v tomto případě představuje buď set-top box nebo PC, kde je TV banka implementována v aplikaci Windows media center.

2.7.3 Zabezpečení komunikačního kanálu v prostředí TV bankingu O bezpečnou komunikaci se v prostředí TV bankingu stará SSL vrstva, o jejímţ způsobu šifrování jsem se zmiňoval jiţ u internetbankingu.

43

3.

Hrozby a nové trendy útoků na nejpoužívanější produkty e-bankingu V současně době je nejvyuţívanějším produktem elektronického bankovnictví

internetbanking. Útoky hackerů na tento produkt jsou vzhledem ke klientské popularitě této formy elektronického bankovnictví pochopitelné. V České republice jsme jiţ byli svědky několika útoků na klientské účty tuzemských bank, a proto tuto kapitolu povaţuji za velmi důleţitou část své práce. V této kapitole se budu zabývat moderními typy útoků na internetové bankovnictví a pokusím se co nejlépe vysvětlit princip jednotlivých útoků, aby čtenář mohl lépe pochopit jakým způsobem a proti čemu se bránit.

3.1. Phishing Phishing můţeme povaţovat za určitý druh spamu29, jehoţ účelem je získání finančních prostředků od oklamaných příjemců. Lance James ve své knize Phishing bez záhad definuje phishing jako „odesílání falešného e-mailu příjemci, který klamavým způsobem napodobuje legální instituci s úmyslem vyzvědět od příjemce důvěrné informace jako číslo platební karty nebo heslo k bankovnímu účtu. Takovýto e-mail většinou navádí uţivatele, aby navštívil nějaké podvodné stránky a zadal zde tyto důvěrné informace. Stránky této instituci samozřejmě nepatří a výsledkem je pak ukradení Vašich důvěrných údajů za účelem finančního zisku.“30 Slovo phishing vzniklo z anglického slova fishing (rybaření), protoţe podstata útoku je téměř totoţná. Útočník (rybář) rozešle e-maily odkazujících na podvodnou webovou stránku (nahodí háčky s návnadou) a čeká, aţ nějaký uţivatel (ryba) na tyto e-maily (návnadu) zareaguje. I kdyţ phishing je známý jiţ několik let, stále ho lze povaţovat za aktuální hrozbu nejen pro klienty banky vyuţívající internetové bankovnictví. Důkazem jeho aktuálnosti je poslední zaznamenaný pokus o phishingový útok na klienty Raiffeisenbank z ledna 2011.

29 30

Spam – Nevyţádaná pošta LANCE, James. Phishing bez záhad. [s.l.] : GRADA Publishing, a.s. , 2007. 282 s. ISBN 80-247-1766-2.

44

Pro uskutečnění phishingového útoku musí útočník podstoupit následující kroky: 1.) Výběr instituce, na kterou bude útok směřován Pokud bude útok směřován na klienty internetového bankovnictví, bude vybranou institucí banka, poskytující tuto formu elektronického bankovnictví 2.) Sběr platných e-mailových adres Vzhledem k tomu, ţe úspěšnost phishingu je podle Lance Jamese 0,01 aţ 0,1% je pro útočníka nutností, získat co největší mnoţství platných e-mailových adres. Ke sběru jsou vyuţívány tvz. bots nebo crawlers, coţ jsou nástroje určené přímo pro sběr e-mailových adres z webových stránek, vyhledávačů, diskusních fór, zákaznických databází atd. 3.) Vytvoření podvodné stránky K vytvoření podvodné stránky vyuţívají útočníci nástroje pro zrcadlení stránky. Tento nástroj stáhne dostupné hypertextové odkazy a útočník tak můţe získat odzrcadlenou stránku. Příkladem takového nástroje je Wget. 4.) Rozeslání podvodných e-mailů s odkazem na podvodné stránky Pro rozesílání e-mailů pouţívají útočníci nástroje pro hromadnou poštu. Vzhledem k tomu, ţe útočníci vědí, ţe se na jejich podvod dříve nebo později přijde, musejí nějakým způsobem zajistit, aby se v záhlaví rozeslaných e-mailů nezobrazovala jejich IP adresa.

3.1.1 Obrana proti phishingu Obrana proti těmto podvodným e-mailům spočívá v první řadě v obezřetnosti příjemce, který by měl být schopný phishingový e-mail rozpoznat. Obecně platí několik zásad, podle kterých lze phishing odhalit a odvrátit tak tento pokus o zneuţití důvěrných údajů. 1.) Pokud obdrţíte e-mail od Vaší banky, ve kterém Vás vybízí k zadání přihlašovacích údajů, zcela jistě se jedná o podvrh. Většinou jsou přihlašovací údaje vyţadovány pod pohrůţkou zablokování účtu nebo se nesou ve stínu bezpečnostních zpráv typu: „ Byl zaznamenán pokus o vykradení účtu, prosíme Vás o přihlášení a kontrolu Vašeho účtu“.

45

2.) Příjemce by měl hledat znaky podvodného e-mailu, například pravopis. Většina phishingových útoků se uskutečňuje ze zahraničí a čeština v takovém e-mailu je krkolomná, nicméně najdou se i výjimky, které mají pravopis v pořádku. Dalším znakem můţe být e-mailová adresa odesílatele. Banka s Vámi nebude komunikovat přes jiný e-mailový účet neţ ten, který obsahuje doménu banky. Ukázka phishingového e-mailu směřovaného na klienty internetového bankovnictví Raiffeisenbank z ledna 2011 je umístěna v příloze P4. 3.) Nikdy nepřistupujte na stránky banky prostřednictví odkazu obsaţeného v e-mailu a vţdy vepište webovou adresu banky přímo do adresového řádku prohlíţeče. V případě, ţe by příjemce podvodného e-mailu přesto vstoupil na podvrţené webové stránky prostřednictvím odkazu obsaţeného v e-mailu, zjistí, ţe webová adresa neodpovídá webové adrese banky a dále by ho měl prohlíţeč upozornit, ţe stránky jsou nedůvěryhodné, protoţe s největší pravděpodobností nebudou obsahovat serverový certifikát ze seznamu schválených certifikátů. Ukázka podvrţené webové stránky, jejíţ odkaz obsahoval phishingový e-mail na klienty internetového bankovnictví Raiffeisenbank z ledna 2011 je umístěna v příloze P5. 4.) V případě jakéhokoliv podezření kontaktujte svoji banku o přijatém e-mailu.

3.2. Pharming V případě pharmingu se jedná opět o útok, jehoţ cílem je získat důvěrné údaje uţivatele za účelem zisku. Oproti phishingu je pharming sofistikovanější a mnohem nebezpečnějším útokem. Cílem pharmingu je přesměrování skutečné webové stránky na podvodnou stránku, která je vzhledově těţko rozeznatelná od originálu. Abychom pochopili, jakým způsobem k takovému přesměrování dochází, je důleţité vědět, jak prohlíţení webových stránek funguje. Kaţdá webová stránka má svoji IP adresu, vzhledem k tomu, ţe by bylo velmi nepraktické, aby uţivatelé při navazování spojení s webovou stránkou museli zadávat její těţko zapamatovatelnou IP adresu, vznikl systém DNS. Systém DNS je celosvětová databáze doménových jmen. O překlad webové adresy na IP adresu se starají servery DNS známé také jako Name servery. Příklad funkce DNS serveru je na obrázku č. 12. 46

Obrázek 12: Ukázka funkce DNS serveru Zdroj: [4] Podle způsobu provedení útoku, lze pharming rozdělit na globální a lokální.

3.2.1 Globální Pharming Pharming na globální úrovni spočívá v tom, ţe útočník napadne vybraný DNS server a změní v něm IP adresu některé webové stránky za IP adresu své podvodné stránky. Globální se označuje proto, ţe všichni uţivatelé vyuţívající tento DNS server při zadání webové adresy například internetového bankovnictví určité banky, jsou přesměrováni na podvodné stránky, aniţ by o tom věděli.

3.2.2 Lokální Pharming Pharming na lokální úrovni nemění IP adresy v DNS serveru, ale přímo na konkrétním počítači. V počítačích s operačním systémem Windows se jedná o změnu v souboru hosts, který nalezneme v C:\Windows\System32\drivers\etc. V tomto souboru lze s právy správce přiřadit libovolné webové adrese libovolnou IP adresu. Na obrázku č. 13 je názorně vidět, jakým způsobem se zápis provádí. V tomto konkrétním případě jsem webové adrese www.mojebanka.cz přiřadil IP adresu 77.75.76.3, která náleţí webové stránce www.seznam.cz, z čehoţ vyplývá, ţe pokud zadám www.mojebanka.cz jsem přesměrován na www.seznam.cz.

47

Obrázek 13: Ukázka lokálního pharmingu Zdroj: Vlastní

3.2.3 Obrana proti pharmingu Jak jsem jiţ zmiňoval, pharming je sofistikovanější a nebezpečnější neţ phishing. Ani zkušený uţivatel webových sluţeb nemusí rozpoznat, ţe se jedná o pharming. Obrana proti oběma typům pharmingu 1.) Uţivatel by měl zkontrolovat serverový certifikát, zda se opravdu jedná o webové stránky jeho internetového bankovnictví. Problémem zde je skutečnost, ţe v systému jsou defaultně předinstalovány certifikáty několika certifikačních autorit a pokud útočníkovi projde registrace u některé z těchto autorit, můţe se i certifikát jevit jako skutečný certifikát banky. Uţitečné by bylo, kdyby si uţivatel pamatoval certifikační autoritu své banky a popřípadě ještě datum platnosti certifikátu, coţ by mu stačilo, aby se nestal obětí pharmingu. Bohuţel asi nikdo z nás tyto údaje certifikátu při vstupu do internetového bankovnictví nekontroluje. 2.) Uţivatel by měl zkontrolovat adresový řádek prohlíţeče při navázání spojení s webovým serverem banky. V případě, ţe se jedná o podvodnou stránku, nebude 48

se webová adresa v adresovém řádku shodovat s pravou adresou banky, ale bude nějakým způsobem pozměněna například https://ib24.csob.cz můţe mít tvar https://ib24.info.net coţ nemusí být na první pohled patrné a o to útočníkům jde. 3.) Pouţívání doplňkových nástrojů ve webovém prohlíţeči, které dokáţou získat doplňující informace o prohlíţené webové stránce. Příkladem takového nástroje můţe být produkt Netcraft Toolbar nebo Certificate Patrol. Obrana proti globálnímu pharmingu Obecně je napadení DNS serveru velmi sloţitou záleţitostí, vzhledem k bezpečnostním prvkům zabezpečujícím tento server. Zabezpečení DNS systému proti globálnímu pharmingu umoţňuje tzv. DNSSEC, který zavádí do systému DNS asymetrickou kryptografii. Podrobnější informace o technologii DNSSEC uvádím v poslední kapitole této práce. Obrana proti lokálnímu pharmingu Proti pharmingu na lokální úrovni se kromě bodů zmíněných výše lze bránit ještě následovně. 1.) Uţivatel by měl pouţívat pro připojování k intrenetovému bankovnictví pouze svůj vlastní počítač nebo počítač, který dobře zná. 2.) Počítač uţivatele by měl být opatřen sloţitými hesly pro přístup do systému a pravidelně aktualizovaným antivirovým systémem, protoţe útočník můţe provést změnu v souboru hosts buď tak, ţe se k počítači fyzicky dostane, v tomto případě by mu mělo cestu zkříţit přístupové heslo, nebo vzdáleně tak, ţe útočník do počítače nějakým způsobem dostane škodlivý software a ten buď vykoná práci za něj, nebo mu umoţní vzdáleně ovládat systém. V tomto případě by mu měl cestu zkříţit antivirový systém.

49

3.3. Cross-site scripting XSS XSS útok lze řadit mezi útoky typu „Code Injection“, které jsou specifické tím, ţe útočník vkládá na vstup aplikace svůj kód, který je touto aplikací na jejím výstupu interpretován. Konkrétně je XSS útok zaměřen na webové stránky a aplikace, z čehoţ vyplývá, ţe jako vstup jsou vyuţívány HTTP parametry, kterými jsou např. URL, formuláře a hodnoty cookies31. Útočník vyuţívá pro vloţení svého kódu bezpečnostních mezer a neošetřených vstupů. Skript vloţený na některý ze zmíněných vstupů je pak interpretován webovým prohlíţečem uţivatele. Skript útočníka můţe být klasický HTML kód nebo častěji pouţívaný Javascript, který můţe způsobit např. přesměrování na jinou stránku, získání citlivých údajů atd.

3.3.1 Obrana proti XSS Obrana na straně banky: Veškeré webové aplikace by měly mít ošetřeny vstupy. Tím je myšleno, ţe je nutné na vstupech definovat povolené znaky, respektive zakázat nebo nějakým způsobem neutralizovat zejména znaky uvozující HTML kód a Javascript. Jedná se především o znaky < > & “ ’ a další znaky pouţívané v těchto scriptovacích jazycích. K tomuto účelu lze vyuţít například htmlspecialchars( ). Obrana na straně klienta: 1.) Vypnout v prohlíţeči Javascript. 2.) Pouţití plug-inů, které upozorňují uţivatele na skutečnost, ţe na daných webových stránkách hrozí XSS útok. Jsou to například XSSme, Ad-Block, No Skript a další.

3.4. Cross-site Request Forgery CSRF CSRF je útokem, jehoţ cílem je donucení uţivatele k tomu, aby učinil akce poţadované útočníkem ve webové aplikaci, ke které je jiţ uţivatel přihlášen. Kombinací CSRF a sociálního inţenýrství32 můţe útočník donutit uţivatele webové aplikace k vykonání takových akcí, které útočníkovi umoţní přístup k citlivým údajům a podobně. Veškeré operace v

31

Cookie – Je malé mnoţství dat, které server odesílá klientovi, aby s ním udrţel navázanou relaci. Sociální inţenýrství – Způsob získávání citlivých informací od uţivatelů a manipulace s uţivateli, aniţ by si tito uţivatelé uvědomovali, ţe tyto informace poskytují, popřípadě, ţe vykonávají předem naplánované akce. 32

50

takto napadené aplikaci jsou navíc prováděny jménem uţivatele, který se stal obětí tohoto útoku. Prvním aspektem, kterého vyuţívají CSRF útoky je tzv. relace mezi webovým prohlíţečem a webovým serverem, která vzniká při navázání spojení a je ukončena při ukončení tohoto spojení. K vytvoření takovéto relace slouţí tzv. cookie, které obsahuje ID relace a další informace o relaci, které přijímáme od webového serveru, se kterým jsme spojeni. Prohlíţeč tyto údaje ukládá do souboru a v případě dalšího poţadavku na stejný server je zasílá zpět. Druhým aspektem CSFR útoku je způsob zasílání poţadavků (requestů) webovému serveru. Mezi nejpouţívanější metody se řadí metoda GET a metoda POST. U metody GET je dotaz formulován jako součást URL, z čehoţ mohou vyplývat určité problémy, které umoţňují velmi jednoduše provést CSRF útok. Pro lepší pochopení metody dotazování GET přikládám ukázku.33 GET/ HTTP/1.1 Host: www.programujte.com User-Agent: Mozila/5.0 (Windows;0;Windows NT 5.1;en-US;ru:1.7.6) Gecko/20050225 FireFox/1.0.1 Conection:Keep-Alive V první řádku dotazu je jasně vidět, ţe se jedná o metodu GET, dále první řádek obsahuje ještě typ protokolu v našem případě HTTP a jeho verzi. Druhý řádek pak udává jméno serveru, kam má být poţadavek zaslán. Ostatní řádky pro nás v tomto případě nejsou důleţité. Výsledná URL bude vypadat takto: http://programujte.com/ Pokud se dotáţeme na nějakou stránku pod doménou www.programujte.com, můţe dotaz vypadat následovně. GET/index.php?rubrika=26-programovani HTTP/1.1 Host: www.programujte.com User-Agent: Mozila/5.0 (Windows;0;Windows NT 5.1;en-US;ru:1.7.6)

33

LÁSLO, Petr. Programujte.com [online]. 2008 [cit. 2011-04-03]. Ajax – 5. lekce. Dostupné

z WWW: . 51

Gecko/20050225 FireFox/1.0.1 Conection:Keep-Alive Výsledná URL pak bude vypadat následovně: http://programujte.com/index.php?rubrika=26-programovani Jak je vidět, problémem metody GET je skutečnost, ţe konkrétní akce nebo lepé řečeno stavy, se přenáší přímo v těle URL za otazníkem, čehoţ CSRF útoky vyuţívají. Pokud budeme předpokládat, ţe uţivatel je přihlášen k webové aplikaci internetového bankovnictví a tedy existuje mezi jeho webovým prohlíţečem a webovým serverem výše zmíněná relace a zároveň tato webová aplikace vyuţívá metodu GET, stačí útočníkovi pouze znalost zápisu potřebných akcí v URL v této aplikaci a postrčení této URL tomuto přihlášenému uţivateli. V případě, ţe uţivatel klikne na takto formulované URL, akce předdefinované útočníkem se spustí, protoţe webový server spolu s poţadavkem obdrţí uţivatelovo cookie a pozná, ţe uţivatel je jiţ autentizovaný a tedy provedení těchto akcí nic nebrání. V případě metody POST se akce předávají přímo v těle dotazu, takţe v URL nejsou vidět, coţ sice útok CSRF neznemoţňuje, ale alespoň trochu komplikuje. Takţe pokud útočník chce, aby dotaz obsahoval jím předurčené akce např. pro převod určité částky na určitý účet, musí získat podobu tohoto formuláře a také proměnné, které formulář pouţívá. Poté útočník musí tento formulář naplnit svými vstupními hodnotami. Ve finále opět podstrčí odkaz uţivateli, který je přihlášen k webové aplikaci na kterou chce útočit. Odkaz na webových stránkách útočníka by mohl vypadat následovně. 34

34

Hacker007.7x.cz [online]. [cit. 2011-04-03]. Útok CSRF při pouţití metody POST. Dostupné z WWW:
52

3.4.1 Obrana proti CSRF Obrana na straně banky: 1.) Aplikace internetového bankovnictví, by měla akceptovat pouze metodu dotazování POST. I kdyţ lze útok provést i prostřednictvím této metody, útočník to bude mít alespoň komplikovanější. 2.) Kontrola hlavičky HTTP Referer, která umoţňuje zjistit, z jakého URL přišel právě kladený dotaz (request). 3.) Skutečně efektivní ochranou je implementace procesu autorizace transakcí v aplikaci internetového bankovnictví, která zamezí provedení transakce i při úspěšném CSRF útoku. 4.) Omezená doba relace mezi klientovo webovým prohlíţečem a webovým serverem sníţí riziko CSRF útoku. Obrana na straně klienta: Klient se proti tomuto typu útoku můţe bránit pouze tím, ţe v době, kdy je autentizován ve svém internetovém bankovnictví, nenavštěvuje jiné webové servery.

3.5. SQL injection SQL injection stejně jako XSS patří do kategorie „Code Injection“ útoků. Útočníci zde opět vyuţívají neošetřených vstupů aplikace, kam vkládají svůj kód, který je aplikací interpretován na jejím výstupu. Jak jiţ název napovídá SQL injection je útok zaměřený na manipulaci s daty v databázi prostřednictví vstupu aplikace, která tuto databázi vyuţívá. Útočník na vstupu aplikace zadá SQL dotaz, který mu umoţní přístup k datům, ke kterým nemá legitimní přístup. Takto získaná data mohou být například uţivatelská jména, hesla, e-maily a jiné citlivé údaje uţivatelů, kteří jsou v napadené aplikaci registrováni. Ukázka SQL inject: [17] SELECT * FROM users WHERE login='admin' OR 1=1--

53

Ukázkový SQL dotaz umoţní v případě neošetřeného vstupu přihlášení s právy administrátora.

3.5.1 Obrana proti SQL injection: Uţivatel se proti SQL injection bránit nemůţe, proto se o ochranu uţivatelských dat musí postarat v případě internetbankingu banka, která by měla ošetřit vstupy aplikace proti SQL dotazům.

3.6. Man in the midle Další v řadě útoků, které lze směrovat na aplikace internetového bankovnictví jsou útoky Man in the middle (dále jen MITM). Tento typ útoku spočívá v tom, ţe se útočník nějakým z níţe zmíněných způsobů snaţí vstoupit mezi dva účastníky komunikace jako prostředník a získat tak moţnost tuto komunikaci odposlouchávat nebo dokonce modifikovat. K tomuto účelu lze vyuţít několik metod, ale vzhledem k jejich mnoţství zde uvedu pouze některé.

3.6.1 DHCP spoofing Protokol DHCP se stará o dynamické přidělování IP adres a dalších síťových parametrů koncovým zařízením jako jsou maska podsítě35, gateway36 a DNS server. Útok nazývaný DHCP spoofing vyuţívá toho, ţe v jedné síti můţe současně existovat několik DHCP serverů, coţ znamená, ţe útočník můţe do sítě podstrčit vlastní DHCP server a podstrčit tak své oběti falešný DNS server nebo falešnou gateway. Při podstrčení falešného DNS serveru nastane identická situace jako při aplikaci pharmingu, o kterém jsem jiţ hovořil v úvodu této kapitoly. Při podstrčení falešné gateway je útok MITM nekompletní, protoţe nastane taková situace, ţe data, která bude oběť přes falešnou gateway (počítač útočníka) posílat do internetu, útočník odposlechne a můţe je modifikovat, ale data, která se vrací z internetu k oběti jiţ půjdou přes regulerní gateway přímo k oběti a tudíţ útočník jiţ nemá moţnost je odposlechnout nebo modifikovat viz. obrázek č. 14.

35

Maska podsítě – Pomáhá rozlišit rozdělení sítě a podsítě. Má stejný zápis jako IP adresa Gateway – Lze říci, ţe se jedná o „směrovač“, prostřednictvím kterého přístupujeme z lokální sítě do sítě internet. 36

54

Obrázek 14: DHCP spoofing – falešná gateway Zdroj: [31]

3.6.2 ICMP Redirecting Protokol ICMP pracuje na transportní vrstvě. Primárně je vyuţíván k signalizaci mimořádných událostí, o kterých pak informuje některým typem zprávy. Samotný název útoku napovídá, ţe typ zprávy, který v tomto případě útočníka zajímá, je zpráva o změně směrování. Zprávu o změně směrování v klasické situaci zasílá gateway, kdyţ zjistí, ţe by bylo rychlejší nebo výhodnější posílat data přes jinou gateway jako je tomu na obrázku č. 16, kde uţivatel Host H chce posílat data na vzdálenou pobočku a jako gateway má nastavený router R1. Kdyţ uţivatel odešle pakety na router R1, tento router zjistí, ţe efektivnější by bylo, aby uţivatel vyuţíval jako gateway router R2, nicméně pakety nezahodí a odešle je na router R2, který je pak odešle na vzdálenou pobočku. Zároveň router R1 odešle uţivateli Host H ICMP redirecting zprávu, kde mu řekne, ţe pro odeslání dat na vzdálenou pobočku je vhodné nastavit jako gateway router R2. Stejným způsobem to bude zkoušet útočník. Bude tedy zasílat oběti falešné pakety ICMP redirecting, ve kterých bude chtít, aby si změnil gateway na falešnou gateway.

55

Obrázek 15: ICMP redirecting Zdroj: [29] Obrana proti ICMP redirectingu Dostatečnou obranou můţe poskytovat správně nastavený firewall, který bude zprávy na přesměrování zahazovat.

3.6.3 Transparentní proxy Tato metoda útoku je aplikovatelná i na odposlech a modifikaci komunikace chráněnou SSL vrstvou. Způsob útoku spočívá v tom, ţe útočník se vydává za výchozí bránu, ovšem v tomto případě se jedná o dokonalejší formu útoku, neţ u DHCP spoofingu, protoţe v tomto případě můţe útočník odposlouchávat a modifikovat jak data, která odesílá uţivatel serveru, tak i data, která odesílá server uţivateli. Aby uţivatel, který se připojuje ke svému internetovému bankovnictví, nepoznal, ţe komunikace mezi ním a serverem není šifrována, musí útočník zfalšovat serverový certifikát dané banky a vytvořit tak SSL tunel mezi ním a uţivatelem. V případě, ţe uţivatel tento certifikát přijme, vytvoří se spojení mezi ním a útočníkem a vzápětí se vytvoří SSL spojení mezi útočníkem a serverem banky, kterou uţivatel poţaduje. Útočník pak získává moţnost odposlouchávat a modifikovat data tekoucí od uţivatele k bance i od banky k uţivateli, k čemuţ můţe vyuţívat například programy, jako jsou SSL Strip nebo Ettercap. Obrana proti Transparentní proxy 1.) Obrana proti tomuto útoku je velice sloţitá, protoţe pokud se útočníkovi podaří vytvořit zfalšovaný certifikát u některé z certifikačních autorit, které jsou v uţivatelově prohlíţeči povaţovány za důvěryhodné, nelze rozpoznat, ţe nějaký útok vůbec probíhá. 56

2.) Zjistit probíhající útok by se mohlo uţivateli internetového bankovnictví podařit u procesu autorizace transakce.

3.7. Mallware Mallware vznikl spojením dvou anglických slov Malicious Software, tedy škodlivý software. Jeho posláním je infiltrace do počítačového systému a provedení předem definovaných instrukcí. Šíření mallwaru je podle jeho typu také rozdílné. Nejčastěji se setkáváme s šíření prostřednictvím e-mailu, sociálních sítí, přenosných medií a dalších. Mallware je někdy chybně označován za virus, coţ je pouze jedna podskupina mallwaru. Rozdělení mallwaru je moţné hned z několika hledisek jako např. podle cíle napadení, podle umístění v počítačové paměti, podle projevu chování a další. Vzhledem k rozsahu této práce jsem se rozhodl nepopisovat zde jednotlivé typy virů a jejich chování, protoţe dle mého názoru by to pro tuto práci nebylo přínosem. Proto se zde zmíním pouze o jednom typu mallwaru, kterým jsou trojské koně, které jsou z hlediska útoku na internetové bankovnictví opravdu podstatné. Podrobnější informace o mallwaru nabízí kniha Moderní počítačové viry, která je umístěna v seznamu literatury s označením [35].

3.7.1 Trojské koně Trojské koně jsou velmi významnou podskupinou mallwaru, která se na rozdíl od virů samovolně nemnoţí a nevyuţívá ţádného hostitele, ale samostatně vystupuje pod některým spustitelným souborem. Některé typy trojských koní se dokonce mohou vydávat za uţitečný program (např. jako antivirus) a přitom jsou škodlivé. Trojské koně se dále rozdělují do několika kategorií, které jiţ nebudu popisovat. Vyzdvihl bych pouze tzv. Pasword-stealing skupinu, která se, jak název napovídá, specializuje na odcizení identifikačních údajů. Principem odcizení hesel je sledování stisknutých kláves na klávesnici. Tento typ trojského koně je také znám pod pojmem Keylogger.

3.7.2 Obrana Obranou proti mallwaru jsou jednoznačně antivirové systémy s aktuální virovou databází.

57

4.

Analýza bezpečnosti internetového bankovnictví v ČR Z předchozí kapitoly je zřejmé, ţe existuje celá řada útoků směřujících na webové

aplikace a tudíţ i na aplikace internetového bankovnictví. Banky ve svých publikacích pro veřejnost varují před některými typy těchto útoků a doporučují svým klientů drţet se tzv. zásad internetové bezpečnosti, ale zároveň své klienty ujišťují, ţe na implementaci jejich webových aplikací se podílejí nejlepší specialisté v oboru a tudíţ povaţují tyto aplikace za bezpečnostně robustní. Jak je to s bezpečností internetového bankovnictví v ČR ve skutečnosti se pokusím zjistit právě v této kapitole. Bezpečnostní analýza internetového bankovnictví bude obsahovat: 1.) Subjektivní posouzení procesu autentizace klienta 2.) Subjektivní posouzení procesu autorizace transakcí. 3.) Testování schopnosti obrany proti XSS. 4.) Testování kvality SSL.

4.1. Bezpečnost procesu autentizace klienta V této podkapitole bude hodnocena bezpečnost procesu autentizace klientů v prostředí internetového bankovnictví vybraných bank. Bezpečnost tohoto procesu bude hodnocena z pohledu dvou útoků, kterými jsou phishing a pharming, o kterých jsem jiţ hovořil v kapitole nesoucí název „Hrozby a nové trendy útoků na nejpouţívanější produkty e-bankingu“. Cílem obou těchto útoků, je přimět klienta, aby navštívil falešné webové stránky útočníka, které mohou být téměř nerozeznatelné od skutečných bankovních, a získat tak od svých obětí autentizační údaje. Hodnocení bezpečnosti pouţitých autentizačních mechanismů se bude odvíjet od moţnosti jejich zneuţití prostřednictvím výše zmíněných útoků.

4.1.1 Hodnocení autentizačních mechanismů nižší úrovně Jméno a heslo: -

Nejslabší mechanismus autentizace

-

Samostatně proti zmíněným útokům není odolný

-

Hodnocení = 0 bodů 58

Certifikát v souboru: -

Středně silný mechanismu autentizace

-

Proti zmíněným útokům je středně odolný

-

Hodnocení = 50 bodů

SMS kód: -

Velmi silný mechanismus autentizace.

-

Proti zmíněným útokům je naprosto odolný.

-

Hodnocení = 100 bodů

BODOVÉ HODNOCENÍ AUTENTIZACE 0 50 100 JMÉNO A HESLO

CERTIFIKÁT V SOUBORU

ANO ANO ANO ANO

Česká spořitelna ČSOB GeMoney Bank Komerční banka

ANO ANO

SMS KÓD

ANO ANO

Tabulka 4: Autentizační mechanismy nižší úrovně používané u vybraných bank Zdroj:[5],[7],[50],[51], Vlastní zpracování

4.1.2 Hodnocení autentizačních mechanismů vyšší úrovně Certifikát na čipové kartě: -

Velmi silný mechanismus autentizace.

-

Proti zmíněným útokům je naprosto odolný.

-

Hodnocení = 100bodů

Kalkulátor: -

Velmi silný mechanismus autentizace.

-

Proti zmíněným útokům je naprosto odolný.

-

Hodnocení = 100 bodů

59

BODOVÉ HODNOCENÍ AUTENTIZACE 100 100 ČIPOVÁ KARTA Česká spořitelna ČSOB

KALKULÁTOR

ANO ANO

GeMoney Bank Komerční banka

ANO

Tabulka 5: Autentizační mechanismy vyšší úrovně používané u vybraných bank Zdroj: [5],[7],[50],[51], Vlastní zpracování

4.1.3 Vyhodnocení bezpečnosti procesu autentizace Bodové hodnocení vybraných bank je zobrazené v tabulce č. 6. Nejniţšího bodového hodnocení dosáhla Česká spořitelna, coţ je důsledkem toho, ţe v niţší úrovni autentizačních mechanismů pouţívá pouze jméno a heslo, coţ je z pohledu útočníka pouţívajícího útok phishing či pharming ideální cíl. Někdo by mohl oponovat tím, ţe na autentizaci aţ tak nezáleţí, kdyţ proces autorizace má vysokou bezpečnostní úroveň a tudíţ není moţné provést jakoukoliv aktivní operaci. Toto tvrzení je pravdivé pouze z části, protoţe útočníkovi, který získá přístup k účtu, je umoţněno provádět pasivní operace. Příkladem takové pasivní operace můţe být například úprava šablon, které máte vytvořené pro opakované platby. Útočník můţe změnit číslo účtů, na které se finanční částka odesílá a třeba i výši odeslané částky, čehoţ si klient banky nemusí ani všimnout a takto upravenou šablonu pouţívá dál a ani netuší, ţe kaţdý měsíc například místo platby za elektřinu posílá své peníze na útočníkův účet. Media deklarují, ţe útok na klienty České spořitelny je důsledkem toho, ţe tato banka má v ČR nejvíce klientů. Já bych naopak spekuloval o tom, ţe určitý vliv na zacílení těchto útoků právě na klienty České spořitelny, má právě zmíněná nízká úroveň bezpečnosti procesu autentizace klienta. Naopak nejvyššího bodového hodnocení dosáhla ČSOB, která pouţívá bezpečnostně velmi kvalitní autentizační mechanismy, které by těmto typům útoků odolaly.

60

Česká spořitelna ČSOB GeMoney Bank Komerční banka

BODOVÉ HODNOCENÍ AUTENTIZACE 100 200 150 150

Tabulka 6: Bodové ohodnocení použitých autentizačních mechanizmů u vybraných bank Zdroj: Vlastní

4.2. Bezpečnost procesu autorizace transakcí V druhé části této analýzy bude hodnocena bezpečnost procesu autorizace transakcí v prostředí internetového bankovnictví. Bezpečnost tohoto procesu bude hodnocena z pohledu útoků typu MITM, o kterých jsem hovořil v třetí kapitole této práce. Cílem těchto útoků je, stát se prostředníkem mezi dvěma komunikujícími stranami a získat tak moţnost tuto komunikaci odposlouchávat a modifikovat. Hodnocení bezpečnosti autorizačních mechanismů se bude odvíjet od moţnosti pouţití útoku typu MITM na tyto mechanismy.

4.2.1 Hodnocení autorizačních mechanismů SMS kód: -

V tomto případě autorizace klient odešle vyplněný formulář poţadované transakce na aplikační server banky v „nešifrované podobě“, coţ znamená, ţe v případě útoku MITM, můţe útočník formulář pozměnit (např. změnit číslo účtu a převáděnou částku). Aplikační server pak odešle klientovi SMS kód, který klient zadá v aplikaci a tím pádem transakci autorizuje. SMS zpráva, která je klientovi poslána obsahuje také základní údaje o transakci jako je číslo účtu, částka a další informace, podle kterých pak klient můţe zkontrolovat, zda poloţky transakce souhlasí s poloţkami, které chtěl opravdu uskutečnit.

-

Útok typu MITM zde můţe být úspěšný pouze v případě, ţe si klient nezkontroluje, zda se údaje o transakci obsaţené v SMS zprávě shodují s údaji, které vyplnil v prostředí internetového bankovnictví.

-

Hodnocení = 70bodů

61

Certifikát na čipové kartě: -

V případě čipové karty je autorizace výrazně bezpečnější, protoţe klient podepisuje prováděné transakce svým soukromým klíčem, takţe v případě útoku MITM je útočník bezmocný. I kdyby útočník získal veřejný klíč na rozšifrování, pořád mu bude chybět klíč soukromý, kterým by musel pozměněné poloţky transakce opět zašifrovat, aby je mohl odeslat na bankovní server.

-

Útok MITM nemůţe být úspěšný.

-

Hodnocení = 100bodů

Certifikát v souboru: -

Princip je zde stejný jako v případě certifikátu na čipové kartě. Většinou je tento způsob autorizace kombinován ještě s autorizací prostřednictvím SMS kódu, protoţe vzhledem k tomu, ţe je certifikát umístěn na libovolném přenosném mediu nebo v horším případě na pevném disku počítače, je zde moţnost jeho odcizení mnohem vyšší neţ v případě čipové karty.

-

Útok MITM nemůţe být úspěšný.

-

Hodnocení = 100bodů

Kalkulátor: -

V případě autorizace prostřednictví kalkulátoru musí klient do kalkulátoru opsat jednotlivé poloţky transakce, které spojí např. s aktuálním časem a prostřednictvím algoritmu, který kalkulátor obsahuje, si vygeneruje autorizační kód, který pak zadá v aplikaci internetbankingu a odešle na server, který vytvoří stejný algoritmus a kódy porovná. V případě útoku MITM útočník nemá moţnost nepozorovaně změnit údaje transakce.

-

Útok MITM nemůţe být úspěšný.

-

Hodnocení = 100bodů

62

70

BODOVÉ HODNOCENÍ 100 100

100

SMS KÓD CERTIFIKÁT V SOUBORU ČIPOVÁ KARTA KALKULÁTOR Česká spořitelna ČSOB GeMoney Bank Komerční banka

ANO ANO ANO ANO

ANO ANO ANO ANO

ANO

Tabulka 7: Autorizační mechanismy používané u vybraných bank Zdroj:[5],[7],[50],[51], Vlastní zpracování

4.2.2 Vyhodnocení bezpečnosti procesu autorizace Z tabulky č. 7 je vidět, ţe stejně jako u autentizace je i u autorizace trendem vyuţívání jiného komunikačního kanálu v podobě SMS kódu, čímţ se výrazně zvýší bezpečnostní úroveň tohoto procesu. V nabídkách zůstává také moţnost autorizace prostřednictvím certifikátů, coţ je hlavně ve variantě čipové karty velmi bezpečný mechanismus. Naopak kalkulátory, jejichţ bezpečnost je také velmi vysoká, banky ze svých nabídek nejspíše z finančních důvodů stahují. Bodové hodnocení vybraných bank je zobrazeno v tabulce č. 8. Všechny banky disponují podobnými mechanismy zabezpečení, a proto i bodové hodnocení je velmi podobné. Výjimkou je Komerční banka, která jako autorizační mechanismy nabízí buď kombinaci certifikát v souboru a SMS kód, čímţ předchází moţnosti odcizení hůře zabezpečeného certifikátu nebo autorizaci prostřednictví čipové karty, a proto získala nejvyšší počet bodů. Vzhledem k útokům typu MITM lze konstatovat, ţe bezpečnost autorizačního procesu je u vybraných bank na velmi vysoké úrovni a provedení útoku je moţné pouze v případě, ţe autorizačním mechanismem je pouze SMS kód a navíc v kombinaci s klientem, který si nezkontroluje údaje transakce obsaţené spolu s SMS kódem v přijaté SMS zprávě.

63

Česká spořitelna ČSOB GeMoney Bank Komerční banka

BODOVÉ HODNOCENÍ AUTORIZACE 170 170 170 270

Tabulka 8: Bodové ohodnocení použitých autorizačních mechanizmů u vybraných bank Zdroj: Vlastní

4.3. Test bezpečnosti webových stránek vůči XSS útokům Další test, kterému bude podrobeno internetové bankovnictví vybraných bank, bude test zabezpečení webových stránek proti XSS, coţ je útok spočívající v injekci skriptů do neošetřených vstupů webové aplikace jako jsou formuláře, URL a další. Blíţe je technika útoku XSS popsána ve třetí kapitole.

4.3.1 Testovací nástroj Acutenetix Web Vulnerability Scanner Test bude vykonán pomocí nástroje Acunetix Web Vulnerability Scanner od společnosti Acunetix. Tento nástroj se řadí do skupiny bezpečnostních webových skenerů. Webové skenery analyzují nastavení webového serveru a hledají bezpečnostní mezery, které by mohli umoţnit uskutečnění útoků, jako jsou XSS, SQL inject, CSRF a další. Původně byl v úmyslu test, který by prověřil schopnost obrany proti veškerým známým útokům, nicméně se mi nepodařilo nalézt software, jehoţ neplacená verze, by byla schopná tyto testy uskutečnit na jiné webové stránce, neţ je testovací web společnosti, která tento software vyvinula. Z toho důvodu padlo rozhodnutí na software od společnosti Acunetix, který umoţňuje plnou funkčnost pouze na svém testovacím webu, ale zároveň umoţňuje testovat bezpečnostní mezery umoţňující XSS na libovolném webovém serveru. Výsledky webového skeneru Acunetix Web Vulnerability Scanner jsou prezentovány prostřednictvím grafu, kde je zobrazena četnost výskytu bezpečnostních mezer, které jsou pak dále rozděleny dle závaţnosti viz.obrázek č. 16. Dále tento software umoţňuje zobrazit přesnou lokalizaci těchto bezpečnostních mezer viz.obrázek č. 17, coţ umoţní lepší orientaci při případných opravách těchto chyb, které webová aplikace obsahuje.

64

Obrázek 16: Struktura výsledků Acunetix Web Vulnerability Scanner Zdroj: Vlastní

Obrázek 17: Ukázka lokalizace bezpečnostních mezer webové aplikace Zdroj: Vlastní

65

Vzhledem ke skutečnosti, ţe většina uţivatelů internetbankingu přistupuje ke svému účtu tím způsobem, ţe si do adresové řádky prohlíţeče zadá nejprve URL adresu domovské stránky banky a teprve z této stránky přistoupí přes odkaz na stránku, kde je vyţadovaná autentizace pro vstup do aplikace samotné, je nutné otestovat jak domovskou stránku, tak i stránku určenou pro autentizaci, protoţe moţnost výskyt XSS se vztahuje samozřejmě na obě tyto stránky.

4.3.2 Test zabezpečení webových stránek České spořitelny proti XSS útokům Výsledky testu ukazují, ţe stránky České spořitelny neobsahují ţádné bezpečnostní mezery, které by umoţňovaly pouţití XSS. Výsledky jsou uvedeny v příloze P6.

4.3.3 Test zabezpečení webových stránek ČSOB proti XSS útokům Výsledky testu ukazují, ţe stránky ČSOB neobsahují ţádné bezpečnostní mezery, které by umoţňovaly pouţití XSS. Výsledky testu jsou uvedeny v příloze P7.

4.3.4 Test zabezpečení webových stránek GE Money Bank proti XSS útokům Výsledky testu ukazují, ţe stránky GE Money Bank neobsahují ţádné bezpečnostní mezery, které by umoţňovaly pouţití XSS. Výsledky testu jsou uvedeny v příloze P8.

4.3.5 Test zabezpečení webových stránek Komerční banky proti XSS útokům Výsledky testu ukazují, ţe stránky Komerční banky neobsahují ţádné bezpečnostní mezery, které by umoţňovaly pouţití XSS. Výsledky jsou uvedeny v příloze P9.

4.3.6 Vyhodnocení testu zabezpečení webových stránek proti XSS útokům Z výsledků provedených testů vyplývá, ţe banky mají své webové stránky velmi dobře zabezpečeny proti XSS útokům. Na ţádné z testovaných webových stránek nebyla nalezena ţádná bezpečnostní mezera umoţňující výše zmíněný útok, a proto získaly všechny banky za obranu proti XSS 100 bodů.

66

Česká spořitelna ČSOB GeMoney Bank Komerční banka

BODOVÉ HODNOCENÍ ZABEZPEČENÍ WEBOVÝCH STRÁNEK 100 100 100 100

Tabulka 9: Bodové hodnocení zabezpečení webových stránek vybraných bank proti XSS Zdroj: Vlastní

4.4. Analýza kvality SSL V druhé kapitole této práce jsem zmiňoval, ţe bezpečnost komunikačního kanálu mezi klientem a bankou je u internetbankingu zajištěna prostřednictvím SSL technologie, která vytváří tzv. bezpečný tunel pro data posílaná oběma stranami. Takto šifrovaná data by teoreticky neměla být odposlechnutelná či modifikovatelná některou třetí stranou. Nicméně tato technologie není jen o existenci či neexistenci SSL vrstvy, ale zejména o jejím nastavení, pouţitých certifikátech, protokolech na výměnu klíčů, pouţitých šifrovacích algoritmech, délkách klíčů a dalších parametrech SSL technologie. Nastavení SSL je záleţitostí webového serveru. K nejpouţívanějším webovým serverům se dnes řadí Apache, coţ je opensource od společnosti Apache Software Foudation a druhým nejpouţívanějším je IIS (Internet Information Services) od společnosti Microsoft Corporation.

4.4.1 Testovací nástroj SSL Labs V této části své práce jsem se rozhodl podrobit testování kvality SSL u výše zmíněných bank. K analýze kvality SSL jsem vyuţil online testovací nástroj SSL Labs od společnosti Qualys, Inc., která se zabývá počítačovou bezpečností od roku 1999. Tento nástroj je volně dostupný na webové adrese www.ssllabs.com. Parametry hodnocené SSL Labs Program SSL Labs provádí analýzu veškerých parametrů SSL, které jsou pak rozděleny do čtyř základních skupin, kterými jsou certifikát, podporované protokoly, výměna klíčů a robustnost pouţitého šifrování. Základní skupiny jsou pak bodově ohodnoceny od 0-100 bodů, podle výsledků, kterých dosáhly. Výsledek kvality SSL je dán celkovým bodovým

67

hodnocením a také je známkován od A do F, kde A=1 a F=5. Hodnocení je stejné jako ve škole, coţ znamená, ţe A je nejlepší a F je nejhorší. Struktura výsledků je zobrazena na obrázku č. 18.

Obrázek 18: Struktura výsledků SSL Labs Zdroj: [52] Hodnocení SSL Labs Průběh analýzy a následného hodnocení kvality SSL nástrojem SSL Labs obsahuje následující kroky: 1.) Nejdříve probíhá kontrola certifikátu, zda je platný a zda je důvěryhodný (vydaný důvěryhodnou CA). Pokud je tato kontrola vyhodnocena bodovým počet 0 bodů, je výsledné hodnocení rovněţ 0 bodů. 2.) V druhém kroku dochází ke kontrole nastavení serveru ve třech kategoriích: a. Podporované protokoly b. Výměna klíčů c. Robustnost pouţitého šifrování 3.) V třetím kroku se ze získaných informací vytvoří výsledky a podle dosaţených bodů se odvodí známka viz.obrázek č. 19, která reprezentuje kvalitu implementovaného SSL.

68

Obrázek 19: Legenda známkování podle dosažených bodů Zdroj: [52] Hodnocení podporovaných protokolů Webový server většinou podporuju více protokolů (např. SSL 2.0, SSL 3.0, TLS 1.0) a jejich hodnocení zachycuje obrázek č. 20.

Obrázek 20: Legenda hodnocení podporovaných protokolů Zdroj: [52] Hodnocení výměny klíčů Výměna klíčů slouţí k tomu, aby alespoň jedna strana měla moţnost ověřit totoţnost té druhé, a dále slouţí ke generování tajného klíče pro zbylou dobu relace. Hodnocení této skupiny zachycuje obrázek č. 21.

Obrázek 21: Legenda hodnocení výměny klíčů Zdroj: [52]

69

Hodnocení robustnosti použitého symetrického šifrování Robustnost šifrování představuje sílu symetrické šifry, která je pouţívaná převáţnou část relace. Hodnocení tohoto parametru zachycuje obrázek č. 22.

Obrázek 22: Legenda hodnocení robustnosti použitého šifrování Zdroj: [52]

4.4.2 Test kvality SSL u České spořitelny Výsledek testu kvality u České spořitelny je umístěn v příloze P10. Základní údaje Hodnocení:

A/85bodů

Certifikační autorita:

Verisign

Server:

Apache

Podporované protokoly:

SSL 2.0 Upgrade, SSL 3.0, TLS

Délka klíče:

SHA1-RSA/2048 bitů

Nejsilnější symetrická šifra:

AES/256 bitů

4.4.3 Test kvality SSL u ČSOB Výsledek testu kvality u ČSOB je umístěn v příloze P11. Základní údaje Hodnocení:

A/85bodů

Certifikační autorita:

Globalsign

Server:

Microsoft-IIS/6.0

Podporované protokoly:

SSL 2.0+Upgrade Support, SSL 3.0, TLS

Délka klíče:

SHA1-RSA/2048 bitů

Nejsilnější symetrická šifra:

AES/256 bitů

70

4.4.4 Test kvality SSL u GE Money Bank Výsledek testu kvality u GE Money Bank je umístěn v příloze P12. Základní údaje Hodnocení:

A/88bodů

Certifikační autorita:

Verisign

Server:

IBM HTTP Server

Podporované protokoly:

SSL 2.0+Upgrade Support, SSL 3.0, TLS

Délka klíče:

SHA1-RSA/2048 bitů

Nejsilnější symetrická šifra:

AES/256 bitů

4.4.5 Test kvality SSL u Komerční banky Výsledek testu kvality u Komerční banky je umístěn v příloze P13. Základní údaje Hodnocení:

A/84bodů

Certifikační autorita:

Verisign

Server:

IBM HTTP Server

Podporované protokoly:

SSL 2.0+Upgrade Support, SSL 3.0, TLS

Délka klíče:

SHA1-RSA/2048 bitů

Nejsilnější symetrická šifra:

RC4/128 bitů

4.4.6 Vyhodnocení testu kvality SSL Z uvedených výsledků nástroje SSL Labs vyplývá, ţe kvalita SSL u testovaných bank je zhruba na stejné úrovni. Všechny banky dosáhly výborného hodnocení a tedy známku A a rozsah bodů se pohyboval od 84 do 88 body viz.tabulka č. 10. Důvodem proč banky nezískaly plný počet bodů, je hlavně to, ţe nastavení SSL umoţňuje pouţití i slabších šifrovacích algoritmů, protoţe některé starší webové prohlíţeče neumějí ty nejnovější šifrovací algoritmy pouţít a banky samozřejmě nechtějí klienty, kteří pouţívají tyto prohlíţeče diskriminovat. Téměř shodný rating u testovaných bank je dán tím, ţe banky pouţívají velmi podobné parametry nastavení SSL. Serverové certifikáty, kterými banky disponují, jsou podepsány světově známými CA a mají podpisové schéma SHA1/RSA. Nejsilnější pouţité symetrické šifrování je AES, které má 256 bitů. Výjimkou je Komerční banka, kde je pouţito šifrování RC4, které má jen 128bitů, coţ je jeden z důvodů, proč tato banka dosáhla nejniţšího počtu bodů.

71

Česká spořitelna ČSOB GeMoney Bank Komerční banka

BODOVÉ HODNOCENÍ KVALITY SSL 85 85 88 84

Tabulka 10: Vyhodnocení testu kvality SSL u vybraných bank Zdroj: Vlastní

4.5. Vyhodnocení analýzy bezpečnosti vybraných bank Na výsledky analýzy bezpečnosti vybraných bank je nutné nahlíţet z pohledu prováděných testů. Například hodnocení procesu autentizace bylo hodnoceno z hlediska moţnosti provedení phishingového a pharmingového útoku, proces autorizace byl hodnocen z hlediska moţnosti provedení MITM útoku a test bezpečnosti webových stránek byl hodnocen z hlediska moţnosti provedení XSS útoku. Výjimkou je test kvality SSL, který bere v úvahu veškeré parametry, které mohou ovlivnit bezpečnost. Z dílčích výsledků bezpečnostní analýzy můţeme vidět, ţe některé testované oblasti jako kvalita SSL a zabezpečení webových stránek proti XSS útoku jsou u testovaných bank na téměř totoţné úrovni, která je velmi vysoká. K většímu rozchodu získaných bodů dochází zejména v hodnocení bezpečnosti procesu autentizace klienta a procesu autorizace transakcí, kde jsou pouţívány rozdílené bezpečnostní mechanismy. Celkové vyhodnocení je zobrazené v tabulce č. 11 a v grafu č. 1. Nejlepšího hodnocení dosáhla Komerční banka, která získala významný počet bodů v hodnocení bezpečnosti procesu autentizace klientů a zejména procesu autorizace transakcí. Naopak nejhoršího hodnocení dosáhla Česká spořitelna, kde je proces autentizace klienta v případě autentizace niţší úrovně bezpečnostně nejméně robustní, coţ je celkem zaráţející u banky, která se v minulosti jiţ několikrát stala obětí phishingu.

72

BODOVÉ HODNOCENÍ AUTENTIZACE AUTORIZACE ZABEZPEČENÍ PROTI XSS KVALITA SSL CELKEM Česká spořitelna ČSOB GeMoney Bank Komerční banka

100 200 150 150

170 170 170 270

100 100 100 100

Tabulka 11: Vyhodnocení analýzy bezpečnosti vybraných bank Zdroj: Vlastní

VÝSLEDNÉ BODOVÉ HODNOCENÍ ANALÝZY BEZPEČNOSTI

Získané body

800 600

555

508

455

604

400 200 0

Česká spořitelna

ČSOB

GeMoney Komerční Bank banka

Graf 1: Vyhodnocení analýzy bezpečnosti vybraných bank Zdroj: Vlastní

73

85 85 88 84

455 555 508 604

5.

Návrhy na snížení rizika úspěšného útoku V poslední kapitole této práce uvedu několik doporučení, které by mohli sníţit riziko

úspěšného útoku na internetové bankovnictví. Tato doporučení se budou odvíjet zejména od dvou předchozích kapitol, kde byly popsány moderní útoky na internetové bankovnictví a také byla provedena analýza bezpečnosti tohoto produktu u vybraných bank. Návrhy a doporučení budou směřovány na oba účastníky komunikace v internetovém bankovnictví, kterými jsou banka a klient.

5.1. Návrhy jak zvýšit bezpečnost na straně banky V druhé kapitole této práce jsem zmiňoval, ţe v řetězci klientské zařízení - komunikační kanál – bankovní systém, je právě IS banky bezpečnostně nejrobustnější článek řetězce, coţ je zřejmé i z výsledku jednotlivých testů, které byly součástí analýzy bezpečnosti internetového bankovnictví u vybraných bank. Banky řadí bezpečnost tohoto produktu mezi své priority a pokoušení se drţet krok s technologiemi, které jsou schopné tuto bezpečnost narušit. I přes tuto skutečnost bych si dovolit představit několik návrhu na zvýšení bezpečnosti.

5.1.1 Informovat klienty o možných rizicích Podle většiny bezpečnostních expertů, je největším bezpečnostním rizikem neinformovaný, neznalý a nezkušený uţivatel v oblasti informačních technologií a informační bezpečnosti. V souvislosti s touto skutečností banky zahrnuly do obsahu svých webových stránek tzv. „bezpečnostní doporučení“, které však uţivateli sdělí pouze bezpečnostní minimum jako např. mít aktualizovaný OS, aktualizovaný antivirový systém a aktivovaný firewall. Z mého pohledu povaţují tento typ bezpečnostního doporučení za nedostatečný, protoţe uţivatele sice informuje, jakým programovým vybavením by měl disponovat, ale uţ jej neupozorní na různé formy nejběţnějších útoků a uţ vůbec ne, jak se proti těmto útokům bránit. Banky se ve většině případů snaţí své klienty o bezpečnosti informovat velmi neagresivním způsobem. Tím je myšleno, ţe veškerá doporučení jsou buď ve velmi zkrácené formě umístěny přímo na přihlašovací stránce, nebo v rozsáhlejším vydání na domovské stránce banky. Tato neagresivní forma sice přispěje k tomu, ţe banka „neotravuje“ svého klienta při přístupu na svůj účet, nicméně se tomu tak děje na úkor bezpečnosti. 74

Mým doporučením pro banky je vytvoření e-learningového videa, kde budou uvedeny ukázky nejběţnějších útoků na internetové bankovnictví a obrana proti nim. Toto video bych umístil na přihlašovací stránky internetbankingu a uţivatelům, kteří se k internetovému bankovnictví připojují poprvé, bych nastavil povinné zhlédnutí.

5.1.2 Kontrola klientovo OS a prohlížeče V předchozí podkapitole jsem hovořil o tom, ţe banky ve svých bezpečnostních doporučeních uvádějí, ţe by klient měl disponovat aktualizovaným OS, aktualizovaným antivirovým systém a firewallem a také aktualizovaným internetovým prohlíţečem. Pro mnoho uţivatelů, kteří nepatří mezi zkušené uţivatele informačních technologií, tyto doporučení nemají valný význam, a proto si myslím, ţe i zde je ze strany banky zvolena neagresivní politika, jak prosazovat tyto bezpečnostní doporučení. Moţnosti prosazování těchto doporučení jsou mnohem rozsáhlejší. Protoţe pokud v prohlíţeči zadáte webovou adresu některého serveru, tento server pak přijme dotaz, který vypadá následovně. GET/index.php?rubrika=26-programovani HTTP/1.1 Host: www.programujte.com User-Agent: Mozila/5.0 (Windows;0;Windows NT 5.1;en-US;ru:1.7.6) Gecko/20050225 FireFox/1.0.1 Conection:Keep-Alive Z těchto údajů můţe webový server získat informace o výrobci a verzi Vašeho operačního systém a o výrobci a verzi Vašeho internetového prohlíţeče. Mým doporučením pro banky je kontrolovat verze OS a verze internetového prohlíţeče při vstupu do aplikace internetového bankovnictví a v případě neshody s bezpečnostními poţadavky nabídnout uţivateli odkaz na aktualizace nebo relevantní software.

5.1.3 DNS secure Dalším doporučením, jak zvýšit bezpečnost internetového bankovnictví je vyuţití technologie DNSSEC, kterou lze povaţovat za efektivní zabezpečení proti globálnímu pharmingu, o kterém jsem psal v třetí kapitole této práce. DNSSEC zavádí do systému DNS asymetrickou kryptografii. Drţitelé domén mají moţnost si vygenerovat dvojici klíčů. Soukromým klíčem pak podepíšou informace (např. IP 75

adresu, název domény), které o své doméně do systému DNS vkládají a veřejným klíčem se pak ověřuje pravost tohoto podpisu, a aby byl veřejný klíč dostupný všem, je distribuován nadřazené doméně. Nadřazenou doménou všech domén.cz je registr domén.cz. DNSSEC prakticky zamezí tomu, aby někdo zaměnil v systému DNS jakékoliv informace.37 V současné době nevyuţívá DNSSEC ţádná banka v ČR, coţ dokazuje test provedený na stránkách bezpecnedomeny.cz, jehoţ ukázka je zobrazena na obrázku č. 23.

Obrázek 23: Výsledek testu zabezpečení domén technologií DNSSEC Zdroj: [45]

5.2. Návrhy jak zvýšit bezpečnost na straně klienta Bezpečností na straně klienta se myslí hlavně bezpečnost zařízení, prostřednictvím kterého se klient připojuje ke svému internetovému bankovnictví. Bezpečnost tohoto zařízení se odvíjí nejen od programového vybavení, kterým toto zařízení disponuje, ale také znalostmi uţivatele, který s tímto zařízením pracuje. Programované vybavení klienta by mělo obsahovat operační systém, který disponuje všemi bezpečnostními záplatami, které byly na danou verzi tohoto systému vydány, dále by měl obsahovat firewall a aktualizovaný antivirový systém a samozřejmostí je aktuální verze internetového prohlíţeče. Znalosti, kterými by měl uţivatel takového systému disponovat, je těţké specifikovat, ale určitě by mezi nimi neměli chybět základy internetové komunikace, základy informační bezpečnosti a přehled o základních formách počítačové kriminality. 37

Nic.cz [online]. 2011 [cit. 2011-04-04]. Jak funguje DNSSEC. Dostupné z WWW: .

76

Z těchto dvou aspektů vyplývá tzv. „bezpečnostní minimum“, jehoţ splnění je dle mého názoru nutností k tomu, aby klient internetového bankovnictví mohl relativně bezpečně obsluhovat svůj účet prostřednictvím sítě internet. Dalším velmi důleţitým bezpečnostním aspektem je zabezpečení lokální sítě, ale to je bohuţel téma, jehoţ obsáhlost přesahuje rozsah této práce. Proto jsem se rozhodl své návrhy na zvýšení bezpečnosti zaměřit spíše na webové prohlíţeče, jakoţto hlavní nástroj přístupu klienta k internetovému bankovnictví a zejména na jeho doplňky.

5.2.1 Webový prohlížeč a bezpečnostní doplňky Jak jsem jiţ psal v první kapitole, v prostředí internetového bankovnictví probíhá komunikace mezi klientem a serverem. Klienta v tomto případě představuje náš počítač, který však k prohlíţení webového obsahu potřebuje určité programové vybavení, kterým je webový prohlíţeč. Základní funkcí webového prohlíţeče je komunikace s webovým serverem prostřednictví HTTP protokolu. Samotný prohlíţeč disponuje několika bezpečnostními prvky, jako jsou např. blokování vyskakovacích oken, blokování podvodných stránek a ověřování serverových certifikátů. Zejména poslední dvě nás v souvislosti s bezpečností internetového bankovnictví zajímají více. Blokování podvodních webů je zaloţené hlavně na databázi nahlášených podvodných webů. Pokud navštívíte stránky podvodného webu, Váš prohlíţeč vám oznámí, ţe je stránka podvodná a její obsah Vám nepovolí prohlíţet. Tímto způsobem lze relativně dobře zabránit phishingu i pharmingu. Problém nastane aţ v situaci, kdy podvodný web, ve chvíli kdy ho navštívíte, nebude v této databázi. V takovém případě je vhodné pouţívat doplňky, které Vám sdělí podrobnější informace o stránce, podle kterých můţe i méně zkušený uţivatel poznat, zda se jedná o podvodnou stránku či nikoliv. Ověřování serverových certifikátů prohlíţečem, je další velmi důleţitá věc z pohledu bezpečnosti. Například pokud přistupujete ke svému internetovému bankovnictví, Váš prohlíţeč při navazování spojení zabezpečeným SSL kanálem zjišťuje podrobnosti o serverovém certifikátu Vaší banky, zejména to jestli je tento certifikát podepsán důvěryhodnou certifikační autoritou. Jak prohlíţeč, tak i operační systém mají uloţeno několik certifikačních autorit, které jsou pro něj a tudíţ pak i pro Vás důvěryhodné. Problém můţe vzniknout ve chvíli, kdy si útočník zajistí podvodný certifikát od certifikační autority, kterou Váš prohlíţeč povaţuje za důvěryhodnou. Útočník pak můţe provést útok MITM a Váš prohlíţeč Vás ani neupozorní, ţe by se dělo něco nekalého. Jedna z moţností jak tento 77

problém řešit je ponechat si pouze certifikační autority, které podepsaly certifikáty serverům jako je Vaše banka a další Vámi pouţívané webové servery a ostatní přeinstalované certifikační autority smazat. Další moţností je pouţití plug-inu, který bude hlídat parametry certifikátů u vybraných serverů a pokud dojde k jejich změně, ohlásí ji. Doplňky zvyšují bezpečnost Netcraft anti-phishing tollbar Netcraft anti-phishing tollbar je dopňkem prohlíţeče, který slouţí k obraně proti phishingu a pharminku. Tento doplněk zobrazuje informace o právě navštívené webové stránce. Uţivatel tak získá informace o důvěryhodnosti stránky, datum kdy daná stránka byla zaloţena, název státu a organizace, která poskytuje dané stránce hosting38 a doplňkové informace o stránce jako např. IP adresa, sídlo společnosti, která web provozuje a další. Z mého pohledu se jedná o velmi uţitečný nástroj, který můţe přispět ke sníţení rizika úspěšného útoku formou phishingu či pharmingu. Netcraft anti-phishing tollbar je kompatibilní pouze v prohlíţečích Mozila Firefox verze 1.0 a vyšší a Internet Explorer verze 5.0 a vyšší.

Obrázek 24: Ukázka Netcraft anti-phishing tollbar Zdroj: [46] Certificate Patrol Tento plug-in si přiřadí k jednotlivým webovým serverům, které uţivatel navštěvuje jejich SSL certifikát a pokud dojde k změně jakéhokoliv z jeho parametrů, ohlásí uţivateli, k jaké změně došlo a upozorní ho na moţné nebezpečí. Z mého pohledu se jedná o velmi efektivní ochranu před podvodnými certifikáty, které mohou slouţit zejména k útokům MITM. Certificate Patrol je dostupný jen v prohlíţeči Mozila Firefox verze 2.0 a vyšší. 38

Hosting – Sluţba umoţňující pronájem prostoru pro webové stránky na webovém serveru pronajímatele.

78

NoScript Dalším rozšířením webového prohlíţeče, které sniţuje riziko úspěšného útoku zaloţeného na XXS nebo CSFR je NoSript. NoScript umoţňuje blokovat veškeré plug-iny jako jsou Javascript, Java, Flash a další. Uţivatel si můţe zvolit důvěryhodné stránky, kterým bude udělena výjimka a zařadí je na tzv. „white list“. Všechny ostatní budou mít tyto plug-iny blokovány. Tímto způsobem zabraňuje zneuţití bezpečnostních chyb, které by mohli být vyuţity k provedení XSS. NoScript je dostupný pouze pro prohlíţeč Mozila Firefox verze 1.0 a vyšší. Pro prohlíţeč Google Chrome byl vyvinut ekvivalent NotScript, jehoţ funkce jsou zcela totoţné.

79

Závěr Pokud se v současnosti podíváme do produktových nabídek elektronického bankovnictví bank v ČR, zjistíme, ţe se naše banky inspirovaly od svých zahraničních kolegů a snaţí se zprostředkovat své sluţby svým klientů prostřednictvím všech dostupných kanálů. Proto se můţeme setkat s produkty umoţňující spravování účtu přes počítač, mobilní telefon, pevnou linku a dokonce uţ i prostřednictvím televize. Informace, které v těchto produktových nabídkách zcela jistě v dostatečné míře nenalezneme, je bezpečnost těchto nabízených produktů. Proto byla bezpečnost těchto sluţeb a zejména bezpečnostní analýza internetového bankovnictví jedním s cílů této práce, aby byl vytvořen její ucelený obraz a jasně řečeno, zda lze povaţovat v současné době internetové bankovnictví za bezpečné. Na začátku této práce byly stanoveny základní kritéria bezpečnosti, kterými jsou identifikace klienta, identifikace banky, bezpečnost komunikačního kanálu, bezpečnost IS banky a bezpečnost klientského zařízení. Z těchto kritérií se vytvořily testy a hodnocení, na kterých byla celá analýza bezpečnosti postavená. Hodnotila se bezpečnost procesu autentizace klienta a autorizace transakcí, coţ spadá do kritéria identifikace klienta. Dále byla testována nástrojem SSL Labs kvalita SSL, coţ zahrnuje kritéria identifikace banky a bezpečnost komunikačního kanálu a jako poslední následoval test bezpečnost proti XSS, coţ odráţí kvalitu tvorby webových stránek a implementaci bezpečnostních mechanismů, coţ lze řadit mezi kritéria bezpečnost bankovního IS. Co se nepodařilo a ani ţádným mně známým způsobem nelze otestovat, je bezpečnost klientského zařízení, které samozřejmě není jednotné a liší se u kaţdého uţivatele. Z hodnocení procesů autentizace a autorizace je v porovnání s minulostí vidět velký pokrok. Řada bezpečnostních mechanismů pouţívaných v minulosti nemá pro současnost naprosto ţádní bezpečnostní význam a bylo nutné je inovovat, či přímo vyměnit za jiné, které jsou pro současnost dostatečné. Lze předpokládat, ţe bezpečnostní prvky a bezpečnostní mechanismy pouţívané v současnosti budou muset za několik let podstoupit naprosto stejný proces inovace, či výměny jako jejich předchůdci. Tím se chci dostat k velmi důleţitému faktu a to k tomu, ţe bezpečnost není jednorázová záleţitost, ale kontinuální zacyklený proces a je velkým přínosem, ţe si tento fakt banky v ČR uvědomují. Proto se dnes můţeme setkat s velmi zajímavými nabídkami, které řeší problém bezpečnosti procesů autentizace a autorizace. Trendem současné doby je více faktorová autentizace, která je většinou sloţená ze jména, hesla a SMS kódu, coţ já osobně povaţuji za obrovský přínos. Vzhledem k tomu, ţe jsou vyuţity dva nezávislé komunikační kanály, dovolím si tvrdit, ţe tato technologie účinně 80

odrazí celou řadu útoků a zejména ty, které se pokouší získat přístupové údaje k účtu klienta. Trendem procesu autorizace transakcí je také vyuţití nezávislého komunikačního kanálu opět v podobě SMS kódu, čímţ je úroveň bezpečnosti také výrazně posílena. Nelze ovšem tvrdit, ţe těmito trendy jsou ovlivněny všechny banky v ČR. Příkladem můţe být Poštovní spořitelna a Česká spořitelna, které dodnes zakládají celý proces autentizace klienta pouze na jménu a heslu, coţ je dle mého názoru fatální chyba. Sice proces autorizace transakcí je u obou institucí na velmi kvalitní úrovni, ale pro komplexní zabezpečení klientova účtu to rozhodně nestačí. Velmi zaráţející je to hlavně u České spořitelny, která byla v poslední době nejčastějším cílem phishingových útoků. Dalším testovaným kritériem byla bezpečnost komunikačního kanálu. Internetové prostředí lze charakterizovat skutečně jako prostředí komunikační, nikoliv však bezpečné. Sice toto prostředí disponuje řadou protokolů, norem a standardů, ale ty jsou většinou komunikačního charakteru nikoliv bezpečnostního. Důvod proč internet nedisponuje také řadou bezpečnostních protokolů je hlavně to, ţe se v době jeho vzniku s takovými bezpečnostními problémy nepočítalo a hlavně se nepočítalo s takovou masovou rozšířeností a dostupností tohoto komunikačního kanálu, se kterou se můţeme setkat dnes. Trochu naděje pro potápějící se loď nazývanou internetová bezpečnost, přinesla kryptografie v podobě symetrického a asymetrického šifrování a PKI se svým certifikáty, pomocí nichţ bylo moţné implementovat SSL protokol, který je pouţíván také v internetovém bankovnictví. SSL můţe být někým povaţována za technologii řešící všechny současné bezpečnostní problémy, někým zejména z řad specialistů na IT bezpečnost, za technologii, která je uţ dnes napadnutelná. Problémy této technologie však nejsou na straně šifrovacích mechanismů, ale na straně PKI a certifikačních autorit. Bylo zjištěno, ţe vytvořit falešný certifikát není aţ takový problém, jak by se mohlo zdát a tudíţ veškerá bezpečnost zaloţená na důvěryhodnosti certifikačních autorit upadá a spolu s ní i SSL. Proto je podle mého názoru nutné tuto technologii inovovat nebo vybudovat technologii novou. Pokud se odprostíme od skutečnosti, ţe tato technologie se dostává do váţných problémů a zaměříme se pouze na výsledky testů kvality SSL u jednotlivých bank v ČR, budeme velmi mile překvapeni, ţe kvalita bezpečnosti SSL je u testovaných bank na velmi vysoké úrovni. Jediným důvodem, proč banky z dostupných 100 bodů získali „pouze“ zhruba 85 bodů je jiţ zmíněný důvod, kterým je umoţnění pouţití slabšího šifrování, protoţe některé starší webové prohlíţeče neumějí ty nejnovější šifrovací algoritmy pouţít a banky samozřejmě nechtějí klienty, kteří pouţívají tyto prohlíţeče diskriminovat.

81

Posledním testovaným kritériem bylo testování bezpečnosti IS banky a to konkrétně bezpečnosti webových stránek. Původně byl zamýšlen test prostřednictvím webového skeneru, který by prověřil bezpečnost webových stránek proti všem známým útokům, bohuţel takový produkt by byl finančně náročný a tak jsem přistoupil na kompromis, kterým byla volba webového skeneru, který je distribuován zdarma a dokáţe testovat pouze proti XSS. V této se fázi musím přiznat, ţe rozsah testu bezpečnosti IS banky je nedostatečný, nicméně i přesto má svůj přínos. Z výsledků je vidět, ţe banky mají své stránky výborně ošetřeny proti XSS útokům a u ţádné testované banky nebyla odhalena ţádná bezpečnostní mezera. Z těchto výsledků lze usoudit, ţe takto mají banky ošetřené webové stránky i proti útokům SQL inject a CSRF. Vyhodnocení celé analýzy ukazuje, ţe testované banky, kromě nedostatků České spořitelny v procesu autentizace klienta, dopadli velice dobře a bezpečnostní prvky, které implementují ke svým produktům, mají vysokou bezpečnostní úroveň. Nyní je otázkou, zda lze internetové bankovnictví v ČR povaţovat za opravdu bezpečné. Odpověď bude mít lehce politický nádech, ale dovolím si tvrdit, ţe pravděpodobnost úspěšného útoku na internetové bankovnictví je velice nízká ovšem pouze v případě, ţe uţivatelem je IT profesionál nebo člověk s hlubšími znalostmi informačních technologií a zejména internetové bezpečnosti a tudíţ lze v tomto případě označit internetové bankovnictví za bezpečné. Není ţádným tajemstvím, ţe útočníci, kteří se nemůţou dostat přes kvalitní bezpečnostní mechanismus, vyuţívají k proniknutí do systému neznalosti uţivatele, a proto lze tvrdit, ţe pravděpodobnost úspěšného útoku se s niţšími znalostmi uţivatele výrazně zvyšuje. Proto by dle mého názoru člověk, který těmito znalostmi nedisponuje, měl tyto znalosti buď doplnit, nebo tuto formu elektronického bankovnictví pro své vlastní dobro nevyuţívat. Tímto tvrzením se dostáváme k druhému cíli práce, kterým bylo vytvoření návrhu na sníţení rizik souvisejících s útokem na internetové bankovnictví. Mezi základní návrhy, které směřuji na banky, je zvýšení právě zmíněných znalostí souvisejících s internetovou bezpečností a nejčastějšími typy útoků, se kterými by měl být klient vyuţívající tento typ bankovnictví seznámen, aby jejím hrozbám dokázal efektivněji čelit. Na stranu klienta byly směrovány hlavně návrhy v podobě bezpečnostních rozšíření webového prohlíţeče, které dokáţou indikovat nebezpečí hrozícího útoku i méně zkušenému uţivateli. Predikovat, jak to bude s bezpečností internetového bankovnictví do budoucna, je velice sloţité, nicméně lze očekávat útoky zejména na smartphony39, které se staly současným 39

Smartphone – Mobilní telefony s pokročilým operačním systémem. Ve většině případech v provedení s dotykovým displayem.

82

trendem a prostřednictvím kterých lze přistupovat, díky téměř plnohodnotnému prohlíţeči, který tato zařízení obsahují, i k internetovému bankovnictví. Budoucnost bezpečnostních mechanismů vidím hlavně ve více faktorovém ověřování, nic-méně nepředpokládám, ţe budou biometrického charakteru, jak predikovali někteří kolegové ve svých pracích jiţ před několika lety a to hlavně z finančních důvodů, které jsou pro banky podle mého názoru neakceptovatelné. Pokud se banky v ČR k biometrice přece jen uchýlí, určitě nebude působit jako plošný bezpečnostní mechanismus, ale bude pouţíván výhradně VIP klientelou. Z mého pohledu tato práce prezentuje ucelený pohled na téma bezpečnost elektronického bankovnictví. Poukazuje na současné produkty elektronického bankovnictví a jejich bezpečnostní prvky. Dále reflektuje problémy v současné bezpečnosti internetového bankovnictví v kombinaci s moderními útoky a zároveň odkazuje na současné moţnosti obrany proti těmto útokům. Čtenář tak získá přehled v dané problematice, který mu nabídne účinnou obranu, proti aktuálním hrozbám, které ho ve světě elektronického bankovnictví mohou potkat.

83

Seznam literatury Monografie: [1] DOSTÁLEK, Libor; KABELOVÁ, Alena. Velký průvodce protokoly TCP/IP a systémem DNS. 5.aktualitované vydání. Brno : Computer Press, a.s, 2008. 483 s. ISBN 978-80-2512236-5. [2] LANCE, James. Phishing bez záhad. [s.l.] : GRADA Publishing, a.s. , 2007. 282 s. ISBN 80-247-1766-2. [3] SCHLOSSBERGER, Otakar. Elektronické platební prostředky. 1. vydání. Praha : Bankovní institut vysoká škola, 2005. ISBN 80-7265-073-4.

Internetové zdroje: [4] DOSTÁLEK, Libor. Tutorial PKI. In TCP/IP bezpečnost [online]. Jendřichovice : 2002 [cit. 2011-04-03]. Dostupné z WWW: . [5] Csob.cz [online]. 2010 [cit. 2011-04-03]. Dostupné z WWW: . [6] Personal Digital Assistant. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 23. 6. 2007, last modified on 27.3.2011 [cit. 2011-04-03]. Dostupné z WWW: . [7] Csas.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [8] KRČMÁŘ, Petr. Root.cz [online]. 2005 [cit. 2011-04-03]. Televizní bankovnictví na dostah ruky. Dostupné z WWW: . [9] O2-tv.cz [online]. 2010 [cit. 2011-04-03]. Jak O2 TV funguje. Dostupné z WWW: . [10] Digizone.cz [online]. 2008 [cit. 2011-04-03]. Jak přijímat IPTV. Dostupné z WWW: . [11] Kryptografie.wz.cz [online]. [cit. 2011-04-03]. Kryptografie. Dostupné z WWW: . [12] Airdump.cz [online]. 2010 [cit. 2011-04-03]. XSS Cross-site-scripting . Dostupné z WWW: . [13] Cross-site scripting#Obrana. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, , last modified on 2011 [cit. 2011-04-03]. Dostupné z WWW: . 84

[14] MAČOK, Martin; STRÁDAL, Vít. NESMRTELNÝ CROSS-SITE SCRIPTING. Data Security Management [online]. 2005, 3, [cit. 2011-04-03]. Dostupný z WWW: . [15] Hoax.cz [online]. [cit. 2011-04-03]. Phishing. Dostupné z WWW: . [16] Hoax.cz [online]. 2011 [cit. 2011-04-03]. Internetove bankovnictvi RB (20110104). Dostupné z WWW: . [17] Secit.sk [online]. 2009 [cit. 2011-04-03]. SQL injection. Dostupné z WWW: . [18] VRÁNA, Jakub. Php.vrana.cz [online]. 2005 [cit. 2011-04-03]. Obrana proti SQL injection. Dostupné z WWW: . [19] PEJŠA, Jan. Zdrojak.root.cz [online]. 2008 [cit. 2011-04-03]. Co je Cross-Site Request Forgery a jak se mu bránit. Dostupné z WWW: . [20] Owasp.org [online].[cit. 2011-04-03]. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. Dostupné z WWW: . [21] Cross-site request forgery. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, , last modified on 2006 [cit. 2011-04-03]. Dostupné z WWW: . [22] FERSCHMANN, Petr. Zdrojak.root.cz [online]. 2008 [cit. 2011-04-03]. Bezpečnost na webu - přehled útoků na webové aplikace. Dostupné z WWW: . [23] KOSEK, Jiří. Kosek.cz [online]. 2010 [cit. 2011-04-03]. Bezpečnost webových aplikací. Dostupné z WWW: . [24] Hacker007.7x.cz [online]. [cit. 2011-04-03]. Útok CSRF při pouţití metody POST. Dostupné z WWW: . [26] Soom.cz [online]. 2007 [cit. 2011-04-03]. Cross-Site Request Forgery . Dostupné z WWW: . [27] DOBIÁŠ, J.; ŘÍHA, Z. Ics.muni.cz [online]. 2009 [cit. 2011-04-03]. Session Riding. Dostupné z WWW: .

85

[28] MARLINSPIKE, Moxie. Blackhat.com [online]. 2009 [cit. 2011-04-03]. New Tricks For Defeating SSL In Practice. Dostupné z WWW: . [29] Cisco.com [online]. 2008 [cit. 2011-04-03]. When Are ICMP Redirects Sent?. Dostupné z WWW: . [30] HALLER, Martin. Lupa.cz [online]. 2006 [cit. 2011-04-03]. Odposloucháváme data na přepínaném Ethernetu (6). Dostupné z WWW: . [31] HALLER, Martin. Lupa.cz [online]. 2006 [cit. 2011-04-03]. Odposloucháváme data na přepínaném Ethernetu (4). Dostupné z WWW: . [32] VONDRUŠKA, Mgr. Pavel. Informační sešit GCUCMP. Crypto-World [online]. 2009, 12, [cit. 2011-04-03]. Dostupný z WWW: . [33] POSPÍCHAL, Petr. Petr.pospichal.biz [online]. 2008 [cit. 2011-04-03]. Útoky v počítačových sítích. Dostupné z WWW: . [34] KOLÁČEK, Michal. Svethardware.cz [online]. 2009 [cit. 2011-04-03]. Počítačová havěť - vývoj a rozdělení malware. Dostupné z WWW: . [35] HÁK, Bc. Igor. Viry.cz [online]. 2005 [cit. 2011-04-03]. Moderní počítačové viry. Dostupné z WWW: . [36] Nic.cz [online]. 2011 [cit. 2011-04-04]. Jak funguje DNSSEC. Dostupné z WWW: . [37] Citibank.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [38] Erbank.eu [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [39] Lbbw.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [40] Postovnisporitelna.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [41] Rb.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: .

86

[42] Unicreditbank.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [43] Volksbank.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [44] Cleverlance.cz [online]. 2010 [cit. 2011-04-04]. Dostupné z WWW: . [45] Bezpecnedomeny.cz [online]. 2010 [cit. 2011-04-05]. Dostupné z WWW: . [46] Toolbar.netcraft.com [online]. 2004 [cit. 2011-04-06]. Dostupné z WWW: . [47] Noscript.net [online]. 2000 [cit. 2011-04-06]. Dostupné z WWW: . [48] I.iinfo.cz [online]. 2010 [cit. 2011-04-07]. Trendy v internetové bezpečnosti. Dostupné z WWW: . [49] Addons.mozilla.org [online]. 2004 [cit. 2011-04-07]. Certificate Patrol. Dostupné z WWW: . [50] Gemoney.cz [online]. 2004 [cit. 2011-04-11]. Dostupné z WWW: . [51] Mojebanka.cz [online]. 2006 [cit. 2011-04-11]. Dostupné z WWW: . [52] Ssllabs.com [online]. 2009 [cit. 2011-04-13]. Dostupné z WWW: .

87

Seznam obrázků OBRÁZEK 1: ARCHITEKTURA INTERNETBANKINGU ................................................................................. 12 OBRÁZEK 2: UKÁZKA GSM BANKING ................................................................................................. 16 OBRÁZEK 3: ARCHITEKTURA WAP BANKINGU ..................................................................................... 17 OBRÁZEK 4: ARCHITEKTURA JAVA BANKING ........................................................................................ 18 OBRÁZEK 5: UKÁZKA PROSTŘEDÍ JAVA BANKING ................................................................................... 19 OBRÁZEK 6: ARCHITEKTURA PDA BANKING ........................................................................................ 21 OBRÁZEK 7: UKÁZKA STRUKTURY IVR ................................................................................................ 23 OBRÁZEK 8: ARCHITEKTURA TV BANKING ........................................................................................... 25 OBRÁZEK 9: PRINCIP ELEKTRONICKÉHO PODPISU .................................................................................. 33 OBRÁZEK 10: UMÍSTĚNÍ VRSTVY SSL V PROTOKOLECH TCP/IP ............................................................... 38 OBRÁZEK 11: AUTENTIZACE V PROSTŘEDÍ JAVA BANKING ....................................................................... 41 OBRÁZEK 12: UKÁZKA FUNKCE DNS SERVERU ..................................................................................... 47 OBRÁZEK 13: UKÁZKA LOKÁLNÍHO PHARMINGU ................................................................................... 48 OBRÁZEK 14: DHCP SPOOFING – FALEŠNÁ GATEWAY ........................................................................... 55 OBRÁZEK 15: ICMP REDIRECTING .................................................................................................... 56 OBRÁZEK 16: STRUKTURA VÝSLEDKŮ ACUNETIX WEB VULNERABILITY SCANNER ......................................... 65 OBRÁZEK 17: UKÁZKA LOKALIZACE BEZPEČNOSTNÍCH MEZER WEBOVÉ APLIKACE ......................................... 65 OBRÁZEK 18: STRUKTURA VÝSLEDKŮ SSL LABS .................................................................................... 68 OBRÁZEK 19: LEGENDA ZNÁMKOVÁNÍ PODLE DOSAŽENÝCH BODŮ............................................................ 69 OBRÁZEK 20: LEGENDA HODNOCENÍ PODPOROVANÝCH PROTOKOLŮ ........................................................ 69 OBRÁZEK 21: LEGENDA HODNOCENÍ VÝMĚNY KLÍČŮ.............................................................................. 69 OBRÁZEK 22: LEGENDA HODNOCENÍ ROBUSTNOSTI POUŽITÉHO ŠIFROVÁNÍ ................................................ 70 OBRÁZEK 23: VÝSLEDEK TESTU ZABEZPEČENÍ DOMÉN TECHNOLOGIÍ DNSSEC ............................................ 76 OBRÁZEK 24: UKÁZKA NETCRAFT ANTI-PHISHING TOLLBAR .................................................................... 78

88

Seznam tabulek TABULKA 1: AUTENTIZAČNÍ MECHANISMY NIŽŠÍ ÚROVNĚ NABÍZENÉ U VYBRANÝCH BANK............................... 35 TABULKA 2: AUTENTIZAČNÍ MECHANISMY VYŠŠÍ ÚROVNĚ NABÍZENÉ U VYBRANÝCH BANK .............................. 36 TABULKA 3: AUTORIZAČNÍ MECHANISMY POUŽÍVANÉ U VYBRANÝCH BANK ................................................. 37 TABULKA 4: AUTENTIZAČNÍ MECHANISMY NIŽŠÍ ÚROVNĚ POUŽÍVANÉ U VYBRANÝCH BANK ............................ 59 TABULKA 5: AUTENTIZAČNÍ MECHANISMY VYŠŠÍ ÚROVNĚ POUŽÍVANÉ U VYBRANÝCH BANK ............................ 60 TABULKA 6: BODOVÉ OHODNOCENÍ POUŽITÝCH AUTENTIZAČNÍCH MECHANIZMŮ U VYBRANÝCH BANK ............. 61 TABULKA 7: AUTORIZAČNÍ MECHANISMY POUŽÍVANÉ U VYBRANÝCH BANK ................................................. 63 TABULKA 8: BODOVÉ OHODNOCENÍ POUŽITÝCH AUTORIZAČNÍCH MECHANIZMŮ U VYBRANÝCH BANK .............. 64 TABULKA 9: BODOVÉ HODNOCENÍ ZABEZPEČENÍ WEBOVÝCH STRÁNEK VYBRANÝCH BANK PROTI XSS ............... 67 TABULKA 10: VYHODNOCENÍ TESTU KVALITY SSL U VYBRANÝCH BANK ...................................................... 72 TABULKA 11: VYHODNOCENÍ ANALÝZY BEZPEČNOSTI VYBRANÝCH BANK.................................................... 73

Seznam příloh PŘÍLOHA P1-UKÁZKA PROSTŘEDÍ INTERNETBANKINGU ..................................................................... 90 PŘÍLOHA P2-UKÁZKA PROSTŘEDÍ TV BANKY .................................................................................. 91 PŘÍLOHA P3-UKÁZKA SERVEROVÉHO CERTIFIKÁTU ČSOB ................................................................. 92 PŘÍLOHA P4-UKÁZKA PHISHINGOVÉHO EMAILU URČENÉHO KLIENTŮM RAIFFEISENBANKY ....................... 93 PŘÍLOHA P5-UKÁZKA PODVODNÉ PŘIHLAŠOVACÍ STRÁNKY RAIFFEISENBANKY ...................................... 94 PŘÍLOHA P6-VÝSLEDKY TESTU ZABEZPEČENÍ PROTI XSS U ČESKÉ SPOŘITELNY ....................................... 95 PŘÍLOHA P7-VÝSLEDKY TESTU ZABEZPEČENÍ PROTI XSS U ČSOB ....................................................... 96 PŘÍLOHA P8-VÝSLEDKY TESTU ZABEZPEČENÍ PROTI XSS U GE MONEY BANK ........................................ 97 PŘÍLOHA P9-VÝSLEDKY TESTU ZABEZPEČENÍ PROTI XSS U KOMERČNÍ BANKY ........................................ 98 PŘÍLOHA P10-VÝSLEDEK TESTU KVALITY SSL U ČESKÉ SPOŘITELNY ..................................................... 99 PŘÍLOHA P11-VÝSLEDEK TESTU KVALITY SSL U ČSOB ................................................................... 100 PŘÍLOHA P12-VÝSLEDEK TESTU KVALITY SSL U GE MONEY BANK ................................................... 101 PŘÍLOHA P13-VÝSLEDEK TESTU KVALITY SSL U KOMERČNÍ BANKY ................................................... 102

89

PŘÍLOHA P1 Ukázka prostředí Internetbanking

Zdroj: Vlastní

90

PŘÍLOHA P2 Ukázka prostředí TV banky

Zdroj: [40]

91

PŘÍLOHA P3 Ukázka serverového certifikátu ČSOB

Zdroj: Vlastní

92

PŘÍLOHA P4 Ukázka phishingového e-mailu určeného klientům Raiffeisenbanky

Zdroj: [16]

93

PŘÍLOHA P5 Ukázka podvodné přihlašovací stránky Raiffeisenbanky

Zdroj: [16]

94

PŘÍLOHA P6 Výsledek testu zabezpečení proti XSS na domovské stránce České spořitelny

Zdroj: Vlastní Výsledek testu zabezpečení proti XSS na přihlašovací stránce České spořitelny

Zdroj: Vlastní

95

PŘÍLOHA P7 Výsledek testu zabezpečení proti XSS na domovské stránce ČSOB

Zdroj: Vlastní Výsledek testu zabezpečení proti XSS na přihlašovací stránce ČSOB

Zdroj: Vlastní

96

PŘÍLOHA Výsledek testu zabezpečení proti XSS na domovské stránce GE Money Bank

Zdroj: Vlastní Výsledek testu zabezpečení proti XSS na přihlašovací stránce GE Money Bank

Zdroj: Vlastní

97

P8

PŘÍLOHA P9 Výsledek testu zabezpečení proti XSS na domovské stránce Komerční banky

Zdroj: Vlastní Výsledek testu zabezpečení proti XSS na přihlašovací stránce Komerční banky

Zdroj: Vlastní

98

PŘÍLOHA P10 Výsledek testu kvality SSL u České spořitelny

Zdroj: Vlastní

99

PŘÍLOHA P11 Výsledek testu kvality SSL u ČSOB

Zdroj: Vlastní

100

PŘÍLOHA P12 Výsledek testu kvality SSL u GE Money Bank

Zdroj: Vlastní

101

PŘÍLOHA P13 Výsledek testu kvality SSL u Komerční banky

Zdroj: Vlastní

102