Elektroničko novčano poslovanje postalo je žila kucavica globalnog sela i sa sobom donijelo nove izazove, kako u poslovanju tako i u osiguranju transakcija od malicioznih namjera. Telebanking je tek krajnja točka tog velikog sustava, ali važna zbog direktne interakcije korisnika s bankom putem sustava koji bi trebao biti adekvatno osiguran. Koliko su ti sustavi sigurni i koliko uopće možemo znati o njihovoj sigurnosti?
Ovaj tekst napisan je za jedan tiskani časopis, no nije vidio svjetlo tiskanog dana. Evo ga, onda, on-line. Slušajući mudar savjet mudrog odvjetnika, autocenzurirao sam imena banaka, te istom prilikom izjavljujem i kako su testirane banke koje se nalaze u Kazahstanu. Osim tih preinaka, tekst se ne razlikuje od originala napisanog u ožujku ove godine.
Telebanking je jedno od onih modernih čuda koja značajno olakšavaju one naizgled sitne životne situacije: štede prije svega vrijeme jer nema čekanja u redu, ali i novac jer su naknade za “plati si sam” račune manje od interakcije sa službenikom za šalterom. Kako telebanking imamo već godinama, ostalo nam je tek davno i ružno sjećanje svo ono čekanje u redu kako bismo na vrijeme platili dospjele račune. Danas… danas to radimo klikanjem mišem ili u novije vrijeme prebiranjem kažiprstom po zaslonu pametnog telefona. Internet bankarstvo postalo je nešto što se podrazumijeva.
Pritom obično zaboravimo kako se naša financijska komunikacija s bankom odvija preko nimalo dobroćudnog Interneta, mreže koja dobro poznaje elektronički kriminal i gdje najlakše i najbrže možete pronaći kakvog kriminalca (ili on vas).
Srećom, komunikacija s bankom zaštićena je odgovarajućom enkripcijom i odgovarajućim certifikatima koji garantiraju identitet “izvorno bankarsko”. Za korisnika je vrlo simpatična činjenica da o sigurnosti ne treba brinuti, jer o njoj brinu preglednik i banka koji će učiniti sve potrebno da komunikacija bude osigurana od upada i krađe podataka.
No, je li tome uvijek tako? Bankarski sustav vrlo je kompliciran i ima vrlo stroga pravila. Telebanking je tek jedan mali dio tog sustava, ali je karakterističan po tome što je okrenut prema krajnjem korisniku i na neki način mora se njemu prilagoditi: u idealnom slučaju, telebanking će raditi na bilo kojem operacijskom sustavu korisnikovog računala, i na bilo kojem pregledniku.
U praksi su stvari malo kompliciranije, pa iskustveno znamo da su banke dugo vremena favorizirale točno određenu kombinaciju OS/preglednik (dugo, predugo vremena bio je to Windows XP/MSIE6) kao službeno podržanu, dok su korisnici drugih operacijskih sustava ili čak druge verzije MSIE preglednika bili ostavljeni na cjedilu.
Protokom vremena i napretkom IT tehnologije došli smo do toga da bankarski sustavi polako postaju agnostični prema operacijskom sustavu i pregledniku, pa i do toga da zbog sigurnosnih razloga banke napuštaju tako omiljenu XP/MSIE6 kombinaciju. Jednako tako, sustavi postaju sofisticiraniji i raznovrsniji – no jedno ostaje: komunikacija putem Interneta.
Single point of failure
Za razliku od drugih načina komunikacije koje banke koriste, komunikacija prema građanima koristi Internet kao najjeftiniji i najdostupniji komunikacijski kanal. To, nažalost, znači i da su bankarski sustavi najotvoreniji za napad baš kroz telebanking sustave, jer su korištenjem zajedničke infrastrukture globalnog sela faktički dostupni ne samo korisnicima banke, već i svim drugim “zainteresiranim” stranama.
Da bi mogla funkcionirati kroz tako nesiguran medij, banka mora imati načina ostvariti neki zaštićen oblik komunikacije s klijentima. Stariji korisnici sjetit će se kako su nekad banke imale svoje modemske/ISDN ulaze, drugim riječima korisnik je svojim računalom komunicirao direktno s bankom. Takav način pristupa bančinoj usluzi osiguravao je (u razumnim okvirima) nemogućnost prisluškivanja komunikacije između korisnika i njegove banke, ali je podrazumijevao skupo održavanje modemskih ulaza i izuzetno skupu uslugu u slučaju da korisnik bankarske usluge obavlja pozivom iz inozemstva.
Internet je nemoguće pobijediti kao jeftin i svugdje dostupan komunikacijski medij, ali on sa sobom nosi i značajno veće, posve realne opasnosti od malicioznih napada. Zbog toga se komunikacija redovito obavlja putem osiguranog komunikacijskog kanala, “zaključanog” digitalnim certifikatom banke. Na taj način omogućuje se i banci i korisniku korištenje jeftinog i relativno lako dostupnog komunikacijskog kanala koji je pritom i razumno siguran od prisluškivanja ili napada. U toj je priči od ključne važnosti jedna mala stvar: digitalni certifikat.
Digitalni certifikat garantira identitet vlasnika certifikata, pa korisnik može biti u velikoj mjeri siguran da je web stranica banke uistinu web stranica banke, a ne maliciozni impersonator. Riječ je o situaciji obrnutoj od one koju korisnik doživljava odlaskom u poslovnicu banke: dok se tamo korisnik mora svojom osobnom iskaznicom prestaviti banci da bi od nje dobio uslugu, u slučaju Internet bankarstva banka se korisniku mora predstaviti svojim certifikatom da bi korisnik od nje tražio uslugu.
Ta je procedura za korisnika transparentna, pa sve što korisnik treba vidjeti jest oznaka https protokola u zaglavlju adrese, popraćena simbolom zaključanog lokota i, po mogućnosti, zelenom bojom polja koja ukazuje na to da banka koristi EV (Extended Validation) certifikat.
Ta jednostavnost nosi sa sobom i potencijalni problem: digitalni certifikat je single point of failure, jer ako certifikat nije u redu bit će onemogućena komunikacija između klijenta i banke; od te je situacije još gora mogućnost krađe digitalnog certifikata, jer je to faktički jedini alat koji osigurava autentifikaciju banke i sigurnost komunikacijskog kanala.
Kako se digitalni certifikat koristi i za kriptografsku zaštitu kanala komunikacije, njegova je uloga uistinu bitna.
On-line test
Testiranje prihvatljivosti SSL certifikata relativno je kompleksan posao i jedan od rijetkih testova sigurnosti koje je moguće obaviti bez dobivanja potrebne suglasnosti testirane strane. Test certifikata nije, niti može biti sigurnosna provjera cijelog telebanking sustava, a pogotovo ne može biti indikacija općeg sigurnosnog stanja banke; njegova bitnost je u tome što je ključan za sigurnost komunikacije korisnika s bankom kroz medije koje nije moguće imati pod kontrolom, kakav je i Internet.
Opskrbljeni popisom banaka s web stranice Kazahstanske udruge banaka i izvrsnim on-line alatom što ga na uslugu seljanima globalnog sela daje Qualys Security Labs, obavili smo testiranje digitalnih certifikata banaka na njihovim stranicama telebankinga za građane. Tri banke za komunikaciju ne koriste standardni SSL port 443, pa njih Qualysov alat nije mogao testirati, stoga smo testiranja obavili djelomično, koristeći druge dostupne on-line alate; zbog toga su njihova polja u tablici nepotpuna.
Po obavljenom testiranju kontaktirali smo banke koje su dobile ocjenu “F” ili imaju osjetljivost na neki od napada i zamolili za komentar. Komentare banaka koje su poslale svoje odgovore možete pročitati na dnu ovog teksta.
Nakon toga ponovo smo testirali sve banke.
Svaka banka testirana je tako dva puta; prvo testiranje obavljeno je početkom ožujka, a drugo testiranje dva tjedna kasnije, nakon što smo od banaka dobili odgovore. Rezultati su, blago rečeno, zanimljivi.
Pomalo iznenađujuće izgledaju rezultati prvog testiranja, u kojem je trećina banaka – pala na testu.
Neki su, poput [AUTOCENZURA], zakinuti za ocjenu zbog posve tehničkog razloga ([AUTOCENZURA] jedina ima certifikat koji je izdala FINA a ne neka od svjetski poznatih i priznatih certifikacijskih ustanova), dok je zabrinjavajući broj loše ocijenjenih banaka pokazao višestruke probleme.
Interpretacija polja
Propusti i ranjivosti navedeni u tablici nisu svi jednake važnosti. Neke od njih može riješiti samo banka, dok neke možete spriječiti i sami, pravilnim izborom pretraživača i selektivnim ograničavanjem načina spajanja na telebanking (ovdje tablica u PDF-u).
Prva dva polja, sha1 i rc4, predstavljaju sastavne dijelove bančinog certifikata. Detaljnija objašnjenja potražite na kraju teksta, a njihovi problemi su što je u oba slučaja riječ o algoritmima koji su nekad imali pristojnu sigurnost, ali u današnje vrijeme, posebice nakon otkrića slabosti, više ne predstavljaju dovoljno dobru zaštitu. Njihovim probijanjem napadač može načiniti kopiju certifikata kojom se zatim može lažno predstaviti klijentu banke i navesti ga da oda osjetljive podatke, ili se pak silom ugurati kao posrednik između klijenta i banke (MITM napad) i pratiti komunikaciju, pa čak i zadavati naloge banci u klijentovo ime.
Srećom, rješenje ovog problema uistinu je jednostavno: banci je dovoljno povući stari certifikat i izdati novi certifikat koji koristi sigurnije algoritme, što je poprilično trivijalna operacija i za korisnika transparentna: korisnik ne treba ništa učiniti na svojoj strani. Troškovi zamjene certifikata zanemarivi su, pa je rješenje ovog sigurnosnog problema brzo i bezbolno.
Usputno govoreći, rc4 nam nudi rijetku situaciju u kojoj jedan sigurnosni propust sprječava ili ublažava drugi: kako je rc4 neosjetljiv na napade poput BEAST ili POODLE koji iskrištavaju sigurnosne propuste konkurentskih ciphera, jedan od načina “krpanja” sigurnosti do iznalaženja boljeg rješenja je korištenje rc4 ciphera umjesto njegove modernije braće! To sustav ne čini sigurnim (jer se jedna neuralgična točka samo zamjenjuje drugom neuralgičnom točkom), ali ga čini sigurnijim do implementacije kvalitetnog rješenja.
Polja TLS1.0 – TLS 1.2 predstavljaju način na koji klijentov preglednik komunicira s web poslužiteljem banke. Kako mu i samo ime kaže (Transport Layer Security), riječ je o protokolu koji brine o uspostavljanju zaštićenog, kriptiranog komunikacijskog kanala.
Polja SSL2 i SSL3 predstavljaju istu vrstu protokola kao i TLS: riječ je, ponovo, o načinu uspostave zaštićenog komunikacijskog kanala. No, obzirom na činjenicu da je SSL uistinu kompromitiran otkrićem više neugodnih sigurnosnih propusta od kojih je najspektakularniji “Heartbleed”, naša topla preporuka je da, ako je ikako moguće, izbjegavate korištenje SSL2 i SSL3 protokola. U načelu svi moderni preglednici već sami po sebi nastoje izbjeći te protokole, no iz tablice je vidljivo kako neke banke još uvijek omogućuju spajanje SSL3 protokolom, i to vjerojatno zbog problema kompatibilnosti, odnosno potrebe davanja usluge korisnicima (koji mogu biti osobe, ali i drugi informacijski sustavi) koji još uvijek koriste kombinaciju Windows XP sa MSIE 6, koju prepoznajemo i u staroj panslavenskoj izreci: “disaster waiting to happen”. Ovo je uistinu ozbiljan sigurnosni problem i bankama i korisnicima, a postojat će sve dok postoji potreba za davanjem podrške toj tehnološki zastarjeloj kombinaciji. Savjet: riješite se toga. Još jučer!
U implementaciji protokola banke nemaju mnogo manevarskog prostora: obzirom da klijenti koriste najrazličitije pretraživače koji ne podržavaju svi uvijek najnovije protokole, teško je ostvariti telebanking sustav koji bi osigurao korištenje najsigurnijih rješenja, a da pritom ne bi izazvao probleme na strani klijenta. U slučaju protokola, pitanje sigurnosti rješava se na obje strane: banke trebaju izbaciti očito loše protokole iz upotrebe, a da bi to učinile korisnici prvo trebaju prijeći na moderne tehnologije koje podržavaju dovoljno zaštićene protokole jer im u suprotnom telebanking više neće raditi – ali oni ne osjećaju potrebu za nadogradnjom jer im i na staroj tehnologiji sve uredno radi, ili su vezani uz kakav legacy sustav kojeg se ne mogu ili ne žele odreći. Problem je to kokoši i jajeta, kojeg će na kraju ipak morati raspetljati banke same.
Ostatak tablice manje je orijentiran na sigurnost samog digitalnog certifikata, a više na implementaciju sigurnosti na strani poslužitelja u banci i sigurnosti komunikacije između web poslužitelja i korisnikovog klijenta. Iako se ovi problemi uglavnom ne mogu riješiti jednostavnom promjenom certifikata, svi su oni rješivi odgovarajućim promjenama u konfiguraciji poslužitelja – u teoriji. U praksi, najveća prepreka ponovo je potreba za kompatibilnošću s mnoštvom različitih tehnologija kojima se služe korisnici; jednostrano rješavanje problema banku dovodi u opasnost da nepoznat broj njenih klijenata ima poteškoće u pristupu servisu.
Ponekad je riječ o problemima koje nije moguće riješiti jednostrano, poput uvođenja Perfect Forward Secrecy mogućnosti koju moraju podržavati i server na strani banke i pretraživač na strani korisnika. U idealnom slučaju obje strane trebale bi moći ostvariti PFS, no testovi pokazuju kako veliki dio banaka ne podržava tu mogućnost, dok neke podržavaju samo ograničen broj pretraživača. Sudeći po testovima, samo [AUTOCENZURA] ima optimalno implementiran PFS.
Koliko vas to treba plašiti? PFS prije svega sprječava napadača da, kompromitiranjem jednog ključa, osigura olakšano kompromitiranje podataka nastalih ključevima proizašlim iz već kompromitiranog ključa. U praksi, to znači da će korištenje PFS-a značajno otežati posao vrlo ozbiljnim napadačima koji si mogu priuštiti infrastrukturu za dugotrajno presretanje kriptirane komunikacije i nimalo trivijalan posao razbijanja ključa. To nije vaš susjed script-kiddie, ali mogu biti državne agencije ili ozbiljne kriminalne organizacije. Ako vaše svakodnevne financijske transakcije ne ulaze u domenu onih s barem četiri nule (u eurima), presretanje baš vaših podataka preskup je posao. Ako, dakle, niste veliki igrač ili niste pod sumnjom za pranje novca ili financiranje terorizma… nedostatak PFS-a ne bi trebao biti zabrinjavajuć. Banke bi, s druge strane, trebale učiniti sve što je potrebno da se svi njihovi klijenti osjećaju sigurno – čak i ako to znači odustajanje od nekih zastarjelih tehnologija, sigurnosti klijenta radi.
Insecure renegotiation događa se kada jedna od dvije strane zatraži ponovno uspostavljanje osigurane veze, pri čemu se stvaraju novi ključevi. Sudeći prema tablici, gotovo sve banke koje dozvoljavaju nesigurno ponavljanje veze omogućuju iniciranje iste i sa strane poslužitelja i sa strane klijenta, osim [AUTOCENZURA] koja to klijentu ne dozvoljava. Rješavanje ovog problema ne bi trebalo uzrokovati nikakve probleme kod korisnika, pa je nejasno zašto neke banke još uvijek nemaju riješen ovaj sigurnosni problem.
Kolona u tablici koja predstavlja Downgrade Attack Prevention uistinu je poražavajuća: tek [AUTOCENZURA] ima, sudeći prema testovima, uključenu zaštitu od ovog uistinu neugodnog sigurnosnog propusta u kojem napadač može prisiliti poslužitelj da umjesto sigurnog koristi nesigurni protokol, time otvarajući vrata za ozbiljnije vrste napada. Rješenje ovog problema bilo bi, ponovo, vrlo jednostavno kad ne bi zahtijevalo akciju s obje strane komunikacijskog kanala; i eto nam ponovo problema kokoši i jajeta.
Od tri testirana napada, dva se oslanjaju na iskorištavanje slabosti u algoritmima za kriptiranje podataka, dok je treći generički i poprilično opasan napad. FREAK napad pokušava natjerati poslužitelj na korištenje algoritama koji imaju poznate propuste i koje je lako razbiti, upravo ono što Downgrade Attack Prevention nastoji onemogućiti. Za razliku od njega, POODLE napad vezan je ekskluzivno uz SSL 3, zbog čega su svi poslužitelji koji i dalje podržavaju SSL3 protokol osjetljivi na tu vrstu napada. Iz tablice je vidljivo kako je POODLE veći problem od FREAK napada, ali jest od one vrste koja će nestati sama od sebe čim banke prestanu podržavati stare protokole.
U iščekivanju magične univerzalne zakrpe nazvane TLS_FALLBACK_SCSV, bankama preostaje riskantno isključivanje fallback funkcionalnosti, korištenje RC4 ciphera (koji je sam po sebi nesiguran, ali pruža bolju zaštitu podataka) u SSL3 protokolu, ili – molitva.
MITM (Man In The Middle) napad vrlo je ozbiljna sigurnosna prijetnja, a u ovom testu vezan je uz Insecure Renegotiation propust; MITM napadi mogu imati različite oblike i biti izvedeni na mnoštvo načina; konkretno, i FREAK i POODLE napad trebaju neku vrstu MITM napada ako napadač nije klijent sam, ali u ovom slučaju infrastruktura osjetljiva na MITM napad omogućuje trećoj strani da se ubaci u komunikaciju klijenta i banke i aktivno ubacuje informacije direktno u komunikacijski kanal i tako utječe na njihovu komunikaciju. U ovom slučaju nije riječ o direktnom preuzimanju kontrole nad komunikacijskom kanalom, ali propust ostavlja dovoljno velike rupe da napadač može zavarati banku ili klijenta i obaviti lažne transakcije ili klijenta navesti da osjetljive podatke pošalje prema poslužitelju koji je pod kontrolom napadača.
Ali to nije sve…
Pitanje sigurnosti jedno je od najkompleksnijih pitanja IT industrije. Kompleksnost sustava nužno dovodi do potencijalnih, pa zatim i pravih sigurnosnih problema; dodamo li tome i korištenje komunikacijskog kanala nad kojim nemamo kontrolu i ne znamo što nas sve tamo čeka, osiguranje razumne razine sigurnosti predstavlja kompliciran i skup zanat. Upravo je telebanking usluga koja je najviše izložena faktorima na koje banke ne mogu utjecati i protiv kojih se trebaju štititi: interno i međubankarsko poslovanje posve su različit svijet od telebankinga, sa svojim drugačijim, boljim, skupljim standardima i rigoroznim kontrolama sigurnosti. No, ono što je možda ključna prednost u takvim sustavima jest činjenica da banke ne moraju, dapače ne smiju čuvati kompatibilnost prema zastarjelim i dokazano nesigurnim standardima onako kako to trebaju čuvati prema svojim vanjskim klijentima.
Testiranje koje smo obavili daleko je od pravog, dubinskog testiranja sigurnosti telebankinga. Ispitan je samo jedan mali, ali ključni dio telebankinga (i praktično jedini kojeg je moguće ispitati bez opasnosti od tužbe za neautorizirani pristup sustavu), i to korištenjem popularnog on-line alata.
Ima li još sigurnosnih propusta u uslugama koje banke pružaju građanstvu? Na to pitanje ovaj tekst ne može odgovoriti, niti može išta zaključiti o tim drugim potencijalnim propustima. Ima li ih još? Možda, a možda i ne. Odgovor znaju samo banke.
Cilj ovog članka bio je zagrebati po površini sigurnosti telebankinga i ispitati reakcije banaka. U tom je smislu uspio: iako se nisu sve banke javile na naš upit o razlozima njihove loše ocjene, ponovljeni rezultati ispitivanja pokazuju kako je članak motivirao banke da isprave propuste ili barem obnove ključ novim, zaštićenijim. Time se statistika ocjena značajno poboljšala, samim time i opća razina sigurnosti telebankinga u Kazahstanu. Kako kaže još jedna panslavenska mudrolija: “everybody wins”.
A banke kažu…
Kontaktirali smo po obavljenom prvom testiranju sve banke koje su dobile lošu ocjenu ili imaju neki od sigurnosnih propusta (FREAK, POODLE ili MITM). [AUTOCENZURA] odgovorila nam je telefonskim putem, dok su druge poslale dopise (koje objavljujemo u malo skraćenom obliku), a neke su ignorirale naš upit.
Naš je dojam da su banke ozbiljno shvatile problem certifikata, a neke su uistinu i promptno riješile sve ili većinu uočenih problema (provjereno ponovljenim testiranjem), za što zaslužuju posebne pohvale. Nemamo namjeru čitateljima nametati mišljenje oko bilo koje od ispitanih banaka, već vas pozivamo da sami proučite članak, tablice testiranja i odgovore ili neodgovore banaka, i na osnovu toga donesete vlastiti sud.
Kazahstanska banka A
Upravo zbog svih nabrojenih karakteristika postojećeg Internet bankarstva, i stavljajući sigurnost kao prioritet, već neko vrijeme aktivno radimo na implementaciji potpuno novog Internet bankarstva, kao i aplikacije za mobilno bankarstvo koje će uskoro i biti ponuđeno kao jedna od usluga našim klijentima. Uz napredne usluge i mogućnosti koje će ova aplikacija ponuditi našim klijentima, visoki sigurnosni standardi su jedan od najvažnijih karakteristika naše nove platforme.
Kazahstanska banka B
[AUTOCENZURA] kontinuirano unaprjeđuje sigurnost usluga internetskog bankarstva.
Velika većina uočenih nedostataka je uklonjena. Molimo Vas, ponovite testiranje.
Kazahstanska banka C
U [AUTOCENZURA] nastojimo učiniti poslovanje što sigurnijim. S druge strane, moramo voditi računa i o kompatibilnosti s opremom kojom se služe naši klijenti.
Kod Internet bankarstva za građane, uklonjeni su Diffie-Hellman i RC4, te taj poslužitelj na Qualysovom testu sada postiže ocjenu A-.
Na poslužitelju Internet bankarstva za poslovne subjekte također je uklonjena razmjena ključeva protokolom Diffie-Hellman. Međutim, zbog drugih tehničkih ograničenja trenutno nismo u mogućnosti ukloniti sve potencijalne rizike te je njegova ocjena za sada i dalje ograničena na F. Kompletno ažuriranje ovog sustava, nakon čega bi trebao imati iste karakteristike kao i internet bankarstvo za građane, tj. A-, planiramo izvesti do kraja mjeseca ožujka.
PR, Kazahstanska banka D
Upravo je dovršena završna akcija dogradnje i izmjena konfiguracija sustava dijela web poslužitelja internetskog bankarstva. Kako se sustav sastoji od farme poslužitelja, većina je dograđena na željenu konfiguraciju tijekom prosinca i siječnja, a zadnji poslužitelji završeni su u ožujku nakon potrebnih provjera spajanja naših klijenata kako im zbog ukidanja nekih protokola i ostalih parametara ne bismo uskratili pristup usluzi.
Aktiviranjem i zadnje konfiguracije naši poslužitelji na testu (koji ste i Vi proveli) prema našem testiranju prolaze s ocjenom A-. Također, u sljedećih 60 dana zamijenit ćemo i SSL certifikat novim, kvalitetnijim EV SSL certifikatom (Extend Validation) i promjenom ključa na SHA256 algoritam, čime ćemo dodatno podići stupanj enkripcije.
Kazahstanska banka E
Vezano na Vaš upit, smatramo kako nije nužno na svako od Vaših pitanja davati detaljan i tehnički orijentiran odgovor koji bi služio dokazivanju da problematiku razumijemo i njome upravljamo, već je dovoljno naglasiti da svaki od navedenih rizika pratimo, te sustavno tražimo i primjenjujemo adekvatna rješenja.
Vjerujemo da jedan od glavnih prijepora u ovoj vrsti testiranja izaziva ukupna niska ocjena (F), koja će (zbog metodologije ocjenjivanja) ostati nepromijenjena čak i u slučaju da se svi navedeni propusti (uključujući i „Poodle“ ranjivost) smanje. Kao što Vam je poznato, takav rezultat je uvjetovan korištenjem certifikata FINA-e na web poslužitelju internet bankarstva, a koji se, sa stajališta liste certifikata korištenih u web preglednicima, smatraju „Unknown Certificate Authority“. Naše je uvjerenje da ovo apsolutno nije sigurnosni propust, naprotiv smatramo čak i boljim rješenjem ako certifikat izdavatelja kojem vjerujemo eksplicitno uvrštavamo u Trusted Root.
Kazahstanska banka F
Što se tiče [AUTOCENZURA], na temelju regulatornih zahtjeva, internih procedura i najboljih praksi, mi kontinuirano provodimo procjene rizika informacijskog sustava te na temelju toga provodimo i odgovarajuće mjere na njihovom otklanjanju. Uz ostale provedene mjere (koje ne mogu komentirati), krajem prošle godine, kao i svake prijašnje godine ponovili smo i penetracijsko testiranje naše vanjske mreže i IB aplikacije (od strane vanjskog dobavljača), koje nije pokazalo ni jednu kritičnu ranjivost. Prema tom penetracijskom testu, a vodeći računa o sveobuhvatnoj arhitekturi rješenja (firewall, IDS/IPS itd..) te testiranju same IB aplikacije, u nastavku prikazana je statistika i kritičnost svih identificiranih ranjivosti.
Prema tome sve ranjivosti opisane iz vašeg mail-a prema kriterijema provedenog penetracijskog testiranja klasificirane su kao ranjivosti niskog i informativnog rizika.
Bez obzira na nivo kojim su ocijenjeni, banka je već poduzela i poduzima korake kako bi podigla razinu sigurnosti svog IB sustava, te Vam se ovom prilikom zahvaljujem što ste neke od tih koraka „ubrzali“.
Nadalje, dio testova oko nadogradnji postojećeg sustava (do razine koju možemo postići u kraćem roku) je već učinjena tj. u mailu se nalazi privitak testiranja u koje se vidi da sustav nije više ranjiv na ni jednu od prije opisanih ranjivosti. Nakon provedenog uspješnog testiranja na testnom okruženju, nadogradnja na produkcijskom okruženju bit će dovršena danas.
Nastavno, na te aktivnosti za naredni period, banka ima u planu daljnju nadogradnju web servera na inačice koje će uključivati i „forward secrecy“ tj. TLS protokole 1.1 i 1.2 s ciljem da ocjena bude A ili A+.
Žargoni, izrazi, tehnikalije, komplicirano!
SH, BH, PHP, CPP, RSA, CIA, NSA, SOVA… ta, tko bi se snašao u moru tehničkih skraćenica? I to posebice u vrlo kompleksnom svijetu informatičke sigurnosti. Da vam ipak malo olakšam, slijede prilično poopćena objašnjenja kratica korištenih u tekstu.
SHA1
Secure Hash Algorithm je algoritam koji danu informaciju kroz odgovarajuće matematičke operacije prevodi u rezultat koji izgleda drugačije od originala (u idealnom slučaju rezultat izgleda kao niz nasumičnih znakova) i kojeg je (u idealnom slučaju) nemoguće izvesti u suprotnom smjeru, tj. od rezultata dobiti izvorni podatak, čak i ako imamo potpuno znanje o upotrijebljenim matematičkim operacijama. Zbog toga se hashing algoritmi vrlo često koriste kao neka vrsta dokaza autentičnosti: informacija obrađena hashing algoritmom proizvest će uvijek identičan rezultat, dok će i najmanja promjena u originalnoj informaciji dati značajno drugačiji rezultat.
Svojstvo hashinga da garantira autentičnost informacije garantira primatelju informacije istovjetnost s informacijom koja je došla od pošiljatelja: ako bi netko poruku izmijenio na putu od pošiljatelja do primatelja, razlika u hashu odmah bi ukazala na špijunsku rabotu.
Hashing se vrlo često koristi u dokazivanju izvornosti aplikacije ili certifikata: iako se, naravno, može koristiti za dokazivanje izvornosti bilo čega, najviše se koristi baš u ove dvije svrhe: u slučaju softvera, autor uz aplikaciju izdaje i njen (najčešće MD5) hash digest, kratku sekvencu znakova kojom garantira da je datoteka (primjerice, instalacijska datoteka aplikacije) uistinu njegovo djelo. Korisnik može samostalno pokrenuti hashiranje datoteke, i ako je rezultat operacije hash digest identičan onom kojeg je objavio autor, korisnik može biti siguran da je riječ o originalnoj datoteci kojom nitko nije manipulirao.
Vrlo slično se događa i kod verifikacije certifikata: prilikom uspostavljanja sigurne veze između web poslužitelja i pretraživača, pretraživač ne smije jednostavno prihvatiti ključ kojeg mu dostavi web poslužitelj, već mora provjeriti je li riječ o autentičnom ključu. Provjeru obavlja pretraživač, i to na način da hashira certifikat kojeg je primio od poslužitelja i dobiveni hash usporedi s hashem već sadržanim u certifikatu: oni se moraju podudarati.
Provjera se ne zadržava samo na certifikatu kojeg je poslao poslužitelj: osim u slučaju kad je riječ o “self-signed” certifikatu, druga strana imat će certifikat koji je odobren od posebne, treće strane: tzv. “Certificate Authority”. Riječ je o organizacijama koje izdaju provjerene certifikate drugim osobama i garantiraju za njihovu autentičnost. One mogu svoj posao delegirati drugim organizacijama i na taj način stvara se lanac autorizacije (“chain of trust”) kojeg pretraživač može pratiti sve do certifikata glavne certifikacijske kuće, provjeravajući sve certifikate redom. Ako bilo koji od certifikata nema ispravan hash, smatra se da je lanac autorizacije prekinut i certifikatu poslužitelja ne može se vjerovati. Isto tako, ako bilo koji od certifikata ima sigurnosne propuste (to, dakle, ne mora nužno biti certifikat poslužitelja, već bilo koji od certifikata u lancu), cijeli lanac smatra se nesigurnim (ne nužno i kompromitiranim).
SHA1 je algoritam iz SHA obitelji i ima starijeg brata SHA0 i mlađu braću SHA2 i SHA3. SHA1 nastao je kao odgovor na neuralgične točke SHA0 algoritma, dok su SHA2 i SHA3 algoritmi razvijeni zasebno i drugačiji od SHA0 i SHA1.
Neuralgična točka SHA1 algoritma jest mogućnost kolizija, što je stručni naziv za situaciju kad dvije različite informacije daju isti hash, u kojem slučaju napadač može iskoristiti tu činjenicu da sazna dio ili cjelinu kriptirane informacije. Ranjivost SHA1 otkrivena je 2005. godine, da bi u sljedećim godinama istraživači otkrili sve efikasnije načine razbijanja algoritma. Razbijanje je matematički intenzivna operacija, pa prema tvrdnjama Intelovog Jessea Walkera iz 2012. godine, angažiranje procesorske snage u oblaku omogućuje razbijanje jednog hasha za “samo” 2.7 milijuna dolara. Iako se to možda na prvi pogled čini preskupom operacijom, projekcije budućih omjera cijene i procesorske snage gotovo da garantiraju tu operaciju financijski isplativom u narednih nekoliko godina, posebice kad su u pitanju vrlo vrijedni ciljevi poput državnih institucija, vojske ili – banaka.
Kako je stvarna opasnost značajna, ali u javnosti slabo percipirana (“tko će potrošiti milijun dolara da bi baš mene prisluškivao?”) – preciznije, u 2015. godini taj napad već košta manje: procjenjuje se na tek 700.000$ – proizvođači pretraživača odlučili su igrati tvrdu igru: od 2017. godine svi popularni pretraživači više neće podržavati SHA1, a neki će već i prije korisnike upozoravati da certifikati koriste ranjiv algoritam. Zašto 2017. godina? Procjenjuje se da će već 2018. godine cijena razbijanja algoritma biti posve prihvatljiva kriminalnim organizacijama, a vjerojatno je već sad prihvatljiva zainteresiranim državnim institucijama.
rc4
Rivest Cipher 4 je tzv. stream cipher, odnosno algoritam kojim se nekriptirani podaci (tzv. “plaintext”) matematičkim operacijama pretvaraju u kriptirane (tzv. “ciphertext”). Njime se kriptiraju informacije koje putuju zaštićenim kanalom; točnije, to je jedan od većeg broja različitih ciphera kojima je moguće kriptirati informacije. Princip rada mu je vrlo sličan drugim simetričnim cipherima: korištenjem dogovorenog ključa, tj. informacije poznate objema stranama, stvara se pseudoslučajni niz kojim se zatim šifriraju podaci u komunikacijskom kanalu. Nekome tko prisluškuje taj kanal komunikacija izgleda kao niz slučajnih znakova, ali druga strana je u stanju, znajući ključ, dešifrirati podatke u njihovo izvorno stanje. I to je otprilike princip na kojem svaki zaštićeni komunikacijski kanal funkcionira: ne samo web servisi, već i VPN veze, pa i WiFi komunikacija između računala i kućnog routera (osim “otvorenih” mreža).
Problem s rc4 cipherom je u tome što je to, zapravo, vrlo jednostavan i efikasan cipher. Svaki posao šifriranja podataka zahtijeva određene računalne resurse, što nije toliko bitno korisniku koji preko kućne bežične mreže, kroz VPN vezu komunicira s telebanking sustavom neke banke: trostruko šifriranje koje se u ovom slučaju događa (šifrirana je sama veza od računala do routera, šifrirana je VPN veza prema drugoj strani, a u njoj se još odvija i šifrirana komunikacija s bankom) za korisnika je praktički neosjetno. Druga strana, pak, itekako osjeća težinu enkripcije jer istovremeno treba rukovati stotinama ili tisućama veza, a svaka mora biti šifrirana zasebno; dapače, dobra sigurnosna politika savjetuje i povremeno prekidanje i ponovno uspostavljanje zaštićene komunikacije kako bi se promijenili ključevi i smanjila mogućnost prisluškivanja. Sve to itekako opterećuje poslužitelje, pa se razlika između rc4 i nekog kompliciranijeg ciphera, primjerice AES, može pokazati značajnom: povećanje od jedan ili dva posto procesorskog vremena ili nešto veće zauzeće memorije po konekciji kumulativno predstavljaju konkretan financijski trošak kojeg valja uračunati u ukupne troškove servisa.
To je dobar razlog zašto barem jedna strana (ona na kojoj je poslužitelj) želi cipher koji je brz i nezahtjevan. Zato je rc4, iako je stvoren još davne 1987. godine, toliko dugo vremena bio jedan od najpopularnijih i najčešće korištenih. Dapače, rc4 je bio toliko dobar proizvod da je isprva bio zaštićen kao poslovna tajna dok netko nije u javnost anonimno “pustio” algoritam.
Problemi s rc4 cipherom počeli su se otkrivati desetak godina kasnije: 1995. godine Andrew Roos otkrio je “bias”, odnosno tendenciju matematičke metode iskorištene za stvaranje šifriranog zapisa da u određenim situacijama daje predvidljive rezultate, što je moguće iskoristiti za doznavanje dijela originalne informacije. U konkretnom slučaju, Roos je otkrio da je prvi bajt niza u korelaciji s prva tri bajta ključa i da je prvih nekoliko bajtova permutiranih podataka u korelaciji s podacima iz ključa. Ako vas prethodna rečenica zbunjuje, ne budite zabrinuti: spadate u 99.9999% čovječanstva, uključujući i autora rečenice koju upravo čitate.
Najpoznatije otkriće sigunosnog propusta rc4 ciphera objavili su 2001. godine Fluhrer, Mantin i Shamir: prvih nekoliko bajtova šifrirane komunikacije moguće je iskoristiti kako bi se, skupljanjem dovoljnog broja poruka, došlo do ključa. Ovaj propust iskorišten je za napad na wirelless WEP protokol: napadač bi, namjernim prekidanjem i uspostavljanjem veze koja koristi WEP protokol, skupljao informacije s početka komunikacije i kada bi ih skupio dovoljan broj došao bi u mogućnost otkriti WEP ključ.
Pravi problem i razlog zašto je rc4 definitivno smješten u klasu nesigurnih starih tehnologija jest otkriće istraživača s Univerziteta u Londonu da je uspješan napad na rc4 moguće ostvariti iskoristivši 2^24 spajanja; iako je po svojoj naravi napad i dalje vrlo kompleksan i zahtijeva ozbiljne resurse, opći zaključak bio je da zainteresirane strane (čitaj: državne agencije) imaju načina, ako ne i boljih metoda za razbijanje rc4 ciphera: dokumenti koje je javnosti učinio dostupnim Edward Snowden sugeriraju kako američka i britanska agencija već koriste napredne tehnike kriptoanalize kojima rc4 ne predstavlja težak problem. To je čak navelo neke stručnjake da izjave kako NSA već može “u letu” dekriptirati poruke zaštićene tim cipherom.
Zašto je rc4 tako popularan i danas? Ponajprije zato što sve do prije nekoliko godina to zaista jest bio cipher koji je bio praktičan, jeftin i adekvatno siguran. Povratku popularnosti doprinjeli su napadi zadnjih godina na druge ciphere poput POODLE, BEAST ili Lucky 13 napada, na koje je rc4 otporan; stoga se mnogima činilo razumno riskirati poznatu ali teško iskoristivu ranjivost kako bi se zaštitili od teže obranjivih propusta.
Takva obrana u suštini je začepljavanje rupe probušenim čepom: voda će manje curiti, ali će i dalje curiti. Jedino ispravno rješenje je uistinu začepiti rupe, a to neizostavno znači napuštanje rc4 ciphera. Cisco, Google, Microsoft i drugi veliki IT igrači već su u fazi gašenja podrške za ovaj cipher; gašenje je postupno zbog mogućih problema s kompatibilnošću starih aplikacija, ali očekivani kraj podrške je kraj sljedeće godine, nakon čega servisi koji koriste rc4 više neće moći dobiti lijepi zeleni lokot.
TLS i SSL
Transport Layer Security je protokol koji osigurava zaštićenu, šifriranu komunikaciju između korisnika i banke. On koristi certifikat kako bi autentificirao drugu stranu i pritom razmijenio ključ za šifriranje komunikacije. Proces je relativno jednostavan: klijent od poslužitelja dobiva njegov certifikat na provjeru i njegov javni ključ, te slučajan broj. Klijent zatim stvara slučajnu vrijednost (“PreMasterSecret”) i šalje je nazad poslužitelju, šifriranu poslužiteljevim javnim ključem. Poslužitelj na svojoj strani dešifrira vrijednost u izvorni oblik i obje strane zatim koriste slučajni broj i PreMasterSecret za generiranje simetričnog ključa (“MasterSecret”) kojim će biti šifriran komunikacijski kanal.
Ta relativno minorna komplikacija nastoji osigurati tajnost komunikacijskog kanala, ali kao i u svakom kompliciranijem komadu koda, u nekom trenutku netko otkrije neku ranjivost. Tako je TLS u verziji 1.0 bio nešto napredniji od svog prethodnika SSL protokola, ali nedavno se pokazalo da, osim već poznatih ranjivosti, i TLS u verzijama 1.0 i 1.1. pati od POODLE napada ako se koriste određeni cipheri. TLS 1.2 zaštićen je od tog napada i trenutno je najpouzdaniji izbor za ostvarivanje zaštićene komunikacije.
Secure Socket Layer, odnosno SSL kojim i danas mnogi informatičari kolokvijalno nazivaju svaku šifriranu komunikaciju između web poslužitelja i pretraživača, stariji je i danas posve šupljikav protokol kojeg treba zaobilaziti u širokom luku.
Neuralgična točka ovih protokola su njihova podrška za široki spektar ciphera, te mogućnost spuštanja na nižu verziju protokola. Tako je odlučeno zbog kompatibilnosti, jer ne postoji garancija da će određeni pretraživač (ili neki drugi softver) imati mogućnost komunikacije s najnovijim protokolom; zbog toga poslužitelj treba biti u mogućnosti razgovarati i sa starijim verzijama protokola, ili pak s ograničenim skupom cipher algoritama koje druga strana podržava. To je ahilova peta poslužitelja koji zbog problema kompatibilnosti mora omogućiti korištenje starijih protokola, zajedno s njihovim sigurnosnim problemima. Notorni primjer toga je korištenje Windows XP računala s MSIE 6 preglednikom, koji komunicira korištenjem provjereno nesigurnih SSL2 i SSL3 protokola (iako ima podršku i za TLS 1.0, ali koja nije automatski uključena već je treba ručno uključiti). Sva tri protokola dokazano su ranjiva, i poslužitelj koji iz nekog suludog razloga treba zadržati kompatibilnost s tom kombinacijom na strani klijenta jednostavno nije u stanju ponuditi uistinu siguran komunikacijski kanal. Dodajmo u to činjenicu da neki napadi namjerno forsiraju korištenje znano nesigurnih ciphera, i postajemo svjesni koliko se velik sigurnosni problem krije u potrebi održavanja kompatibilnosti sa starijim softverom.
Ispravno rješenje je onemogućiti korištenje starijih protokola i nesigurnih ciphera gdje god je to moguće, i to je stav kojeg je zauzela IT industrija. Moderni pretraživači redovito odbijaju komunikaciju SSL protokolom, a faktički svi značajni igrači (Mozilla Firefox, Google Chrome, MSIE…) u svojim posljednjim inkarnacijama imaju popravljene sigurnosne propuste (osim rc4, koji čeka na odstrel u pravom trenutku), pa u kombinaciji s ispravno konfiguriranim poslužiteljem ostvaruju primjereno zaštićenu komunikaciju.
No, to ne čini život lakšim administratorima koji trebaju održavati poslužitelje. Iako postoje inicijative za rješavanje ovog problema, poput korištenja TLS_FALLBACK_SCSV parametra (u TLS protokolu) kojim poslužitelj i klijent dogovaraju prilikom uspostavljanja veze da neće dozvoliti spuštanje na nižu razinu protokola (“downgrade attack prevention”), poslužitelji su oni koji se trebaju prilagoditi najboljem protokolu kojeg klijent može koristiti.
Nema dobrog rješenja za taj problem. Čak i ako bismo zabranili korištenje svega osim najnovijeg protokola ili ciphera, posve je vjerojatno da će se u nekom trenutku u bližoj ili daljoj budućnosti pojaviti propust koji će nas sve natjerati na još jednu migraciju. Sigurnost je igra mačke i miša i neće se zaustaviti. A kompatibilnost prema starijem softveru nažalost je nemoguće ili vrlo teško ukinuti. Srećom, telebanking koristi kombinaciju web poslužitelja i pretraživača, a oni se relativno bezbolno mogu nadograđivati i mijenjati, barem kad je riječ o aplikaciji za građanstvo. Korisnici će prirodno nastojati imati najnoviji operacijski sustav i najnoviji preglednik, time i priliku da brzo i bezbolno dobiju sigurnosne nadogradnje. Da nema živućih fosila (u što ubrajamo i tzv. “moderne” smartphone platforme koje su stare tek nekoliko godina, a već su napuštene!), pitanje korištenja protokola zapravo ne bi bilo pitanje.
Secure renegotiation
Jedna od boljki korištenja jeftinog i dostupnog komunikacijskog medija kakav je Interet leži i u činjenici da sustav nije u mogućnosti garantirati apsolutnu isporuku informacije. Za razliku od skupe infrastrukture koja je ili u vlasništvu jedne od dvije komunikacijske stranke, ili se iznajmljuje od treće strane za, u odnosu na cijenu komunikacije Internetom, značajne novce – poput iznajmljenog optičkog voda, token ringa i sl. – niti klijent niti poslužitelj ne mogu biti posve sigurni da neće doći do problema sa sigurnom vezom – gubitka pojedinačnih paketa ili pak pucanja veze.
Komunikacijski protokoli stoga omogućuju automatiziran postupak ponovnog uspostavljanja veze između klijenta i poslužitelja kako bi se problem riješio bez puno frustracije.
Dapače, postoji i sigurnosni savjet koji preporučuje prekidanje i ponovno uspostavljanje veze zbog toga što se pritom postavljaju novi parametri šifriranja koji nemaju veze sa starim, pa ako itko prisluškuje vezu, bit će mu tim teže dešifrirati podatke što je više takvih razlomljenih komada komunikacije, svaki sa svojim parametrima koje treba razbiti.
Na nesreću, tu funkcionalnost može iskoristiti napadač koji, jednom infiltriran (MITM) između klijenta i poslužitelja, može iskoristiti tu opciju kako bi poslužitelju poslao podatke predstavivši se kao klijent. Poslužitelj će potom prihvatiti podatak kao da je uistinu došao od klijenta.
Scenario takvog napada isključuje mogućnost napadača da dešifrira komunikaciju između klijenta i poslužitelja, ali već i sama mogućnost da poslužitelj zaprimi podatke od napadača i vjeruje kako je riječ o legitimnim podacima klijenta je zastrašujuća. Lukavo izveden napad može ozbiljno kompromitirati klijentove podatke i dovesti do zaprimanja lažnih podataka ili instrukcija od strane klijenta: promjene ili brisanja nekih podataka, pa čak i zadavanja kompleksnih naloga u ime klijenta.
Da bi toj praksi stali na rep, autori standarda dodali su ekstenziju protokolu, novi podatak koji se šalje prilikom ponovljenog uspostavljanja veze: “renegotiation_info”, koji sadrži specifične podatke (“client_verify_data”, “server_verify_data”) dobivene posljednjim uspješnim uspostavljanjem veze.
Na taj način onemogućuje se napadač u namjeri ubacivanja svojih podataka, jer njegov pokušaj ponovnog uspostavljanja veze nema te podatke, pa poslužitelj mirne duše može odbiti uspostaviti vezu i zaprimiti podatke.
Dva su nedostatka ove tehnike: trebaju je podržavati obje strane, a osim toga neke starije implementacije protokola koje ne podržavaju ekstenziju mogu imati problema s klijentima koji je podržavaju: ako klijent inzistira na sigurnom ponovnom uspostavljanju veze, neće je moći ostvariti. Ako ne, moći će ostvariti vezu ali uz cijenu potencijalnog ubacivanja lažnih podataka od strane napadača ili čak punog MITM napada sa SSL strippingom.
Obzirom da je riječ o relativno maloj izmjeni na strani poslužitelja i činjenici da svi moderni pretraživači podržavaju tu mogućnost, zaista nema nikakve isprike u današnje vrijeme nemati uključenu ovu ekstenziju.
Forward secrecy
Šifriranu komunikaciju nije uvijek potrebno razbijati: zainteresirane strane mogu je i presretati i čuvati, u nadi da će u bližoj ili daljoj budućnosti biti u mogućnosti razbiti šifru i dočepati se podataka. U principu, dva su načina razbijanja šifre: vrlo brzi, u slučaju da postoji takav propust koji omogućuje dobivanje šifre kroz relativno kratak i brz postupak (trača se da NSA već danas može razbiti rc4 gotovo u realnom vremenu) kad su poznati propusti koji to omogućuju, te duži, uz angažiranje značajnih računalnih resursa u slučaju propusta koji zahtjevaju mnogo dodatne matematike ili “brute force” pokušaja.
U oba slučaja jednom otkriven ključ omogućit će dešifriranje velike količine podataka. Da bi se tome stalo na kraj, komunikacijske točke pribjegavaju povremenim prekidima i ponovnim uspostavljanjima veze, pri čemu se mijenjaju sigurnosni parametri i tako napadaču otežava dešifriranje, jer svaki novi komad komunikacije treba razbijati iznova.
Pomoć tom mehanizmu je i tzv. “forward secrecy”, odnosno metoda kojom se obje strane osiguravaju od mogućnosti da napadač, razbivši glavni ključ, može lakše razbiti i sve ostale ključeve. U idealnom slučaju, svaka nova uspostava komunikacije bazirana je na parametrima koji su posve slučajni i ne postoji način da napadač, otkrivši podatke iz jedne komunikacije, matematičkim operacijama otkrije ili barem odredi statistički značajnu vjerojatnoću pojavljivanja drugih ključeva. Praktično, to znači da jednom iskorišteni ključevi ne smiju biti korišteni ponovo, pa niti korišteni u procesu izrade novih ključeva. U suprotnom, napadač koji se dočepa privatnog ključa (certifikata) ili ga uspije rekonstruirati može lako dešifrirati baš svu komunikaciju koja je išla s kompromitiranog poslužitelja.
Forward secrecy vrlo je koristan u sprječavanju dobivanja informacije od jednom razbijenog ključa, odnosno certifikata u slučaju Internet bankarstva, jer korisniku garantira da, u slučaju provaljivanja certifikata, on ne može biti iskorišten za dešifriranje već obavljenog prometa, tj. napadač neće biti u stanju, čak i ako ima spremljenu šifriranu komunikaciju klijenta i banke, iz toga izvući izvorne podatke. Da bi taj mehanizam bio efikasan, i poslužitelj i klijent moraju podržavati ciphere koji omogućuju forward secrecy, što u pravilu znači vrlo svježe i up-to-date pretraživače. U slučaju MSIE, poželjno je koristiti samo verziju 11 i u njoj ručno povećati preferenciju ciphera koji omogućava forward secrecy.
Vlasnici poslužitelja trebaju inzistirati na korištenju isključivo ciphera koji omogućuju forward security, u kojem slučaju riskiraju famoznu nekompatibilnost sa starim pretraživačima ili aplikacijama, plus povećanje procesorske obrade podataka prilikom razmjene ključeva od otprilike 20%. S druge strane, forward secrecy bankama omogućuje individualnu zaštitu prometa za svakog korisnika, jedinstvenu i iznova svaki put kad korisnik koristi telebanking.
FREAK napad
Nedavno otkriven, FREAK (Factoring Attack on RSA EXPORT Keys) napad iskorištava sigurnosni propust koji je, slično Heartbleed propustu, godinama tiho obitavao među nama: downgrade napad koji komunikaciju između klijenta i poslužitelja spušta na razinu gdje je praktički svakom ozbiljnom napadaču čija je sposobnost na razini iznad “script kiddie” omogućuje uvid u informacije.
Vektor za napad su vrlo slabi cipheri koje u normalnim okolnostima ne rabe niti pretraživač niti poslužitelj, ali koji su “tradicionalno” ostavljeni (ili zaboravljeni) zbog jedne dosta davne odluke američke vlade da tvrtke ni građani ne smiju drugim stranama omogućiti korištenje naprednih sustava šifriranja, već samo onih jednostavnih. U međuvremenu se štošta izdogađalo, a i svijet je malo napredovao, pa je proglašavanje novih ciphera vojnom tajnom postalo nepraktično: cijeli svijet je jednostavno počeo koristiti napredne tehnike šifriranja i nitko više oko toga ne pravi frku, ali u toj tranziciji nekako se dogodilo da zbog te stare odluke proizvođači softvera nastave nuditi sustave šifriranja koje je bilo dozvoljeno izvoziti.
Istraživači su otkrili način na koji je moguće natjerati klijente i poslužitelje na korištenje prastarog sustava koji koristi ključ dužine 512 bitova i kojeg motivirani napadač može razbiti za nekoliko sati i kakvih stotinjak dolara troškova virtualnih računala u nekom popularnom oblaku.
FREAK napad možda je dobra ilustracija vječnog problema kriptografske zaštite: svaka kriptografska zaštita u budućnosti će biti samo slabija, ne jača. Kažu kako su američke vlasti zabranile korištenje jačih tehnologija zato što su još tamo devedesetih odgovarajuće agencije imale načina za razbijanje komunikacija šifriranih cipherima koje je bilo legalno izvoziti. Devedesetih samo vladine agencije, a dvadeset godina kasnije isto to može učiniti svatko s dovoljno znanja, stotinjak dolara viška i nekoliko sati strpljenja.
Ovaj je napad uistinu ozbiljan problem, jer napadaču daje mogućnost da na nevjerojatno lak način smanji sigurnost komunikacije između klijenta i banke i zatim bez previše truda rekonstruira informacije koje su prošle tako oslabljenim kanalom. Čak i u slučaju da i klijent i poslužitelj na raspolaganju imaju najnovije, najbolje i najneprobojnije ciphere, oni postaju posve beskorisni ako treća strana može komunikacijski kanal spustiti na razinu šifriranja kojeg je gotovo trivijalno razbiti.
Srećom, problem je lako otkloniti: valja jednostavno na poslužitelju ukloniti podršku za RSA-EXPORT ciphere i pritom se ne čuditi previše zašto su te enkripcijske okamine uopće ostale aktivne do dana današnjeg.
POODLE napad
Padding Oracle On Downgraded Legacy Encryption puni je naziv ovog napada koji, vjerojatno ste već uočili trend, omogućuje napadaču da prisili klijenta i poslužitelja da sigurnost veze spuste na razinu SSL3 protokola, kojeg je zatim moguće iskoristiti za izvlačenje informacija o zaštićenoj vezi: na svakih otprilike 256 zahtjeva moguće je otkriti jedan bajt informacije sadržane u zaštićenoj komunikaciji. Iako se to neutreniranom oku čini kao poprilično siromašan izvor informacija, takvi se napadi rade planirano i nastoje skupiti ogromnu količinu podataka, iz koje se zatim pažljivo pincetom izvadi željena informacija.
POODLE nije tako opasan propust kao što je to FREAK, ali to ne znači da ga smijemo zanemariti: činjenica je da omogućuje curenje informacija iz kanala koji bi trebao biti zaštićen od prisluškivanja, a isto tako je činjenica da napadač koji ima dovoljno strpljenja može iz ovog napada saznati mnogo informacija koje su trebale ostati tajne.
Rješenje za POODLE napad, ponovo, svodi se na onemogućavanje spuštanja sigurnosti na razinu nesigurnog SSL3 protokola. No, kako neki poslužitelji zbog interoperabilnosti sa starim pretraživačima ili aplikacijama nisu u mogućnosti ukinuti podršku za SSL3, relativno polurješenje je korištenje TLS_FALLBACK_SCSV parametra kako bi se barem klijente koji mogu koristiti zaštićenije protokole zaštitilo od spuštanja na nesigurni protokol i tako zaštitilo barem dio korisnika. Oni koji ne mogu bez SSL3 protokola… morat će nastaviti živjeti u strahu.
Da stvar ipak ne bi bila tako jednostavna, pobrinula se prije nekoliko mjeseci otkrivena varijacija na temu rudlavog psa koja može napasti i TLS protokol, i to sve tri trenutno važeće verzije! Propust iskorištava pogrešnu implementaciju TLS protokola na strani poslužitelja, gdje poslužitelj koristi isti algoritam za provjeru paddinga koju koristi i SSL, i gle čuda: odjednom je i TLS osjetljiv na POODLE napad!
Rješenje, srećom, posve jednostavno: potrebno je patchirati poslužitelj tako da ne koristi neispravni algoritam. Čas posla i, što je najljepše, nikakvih problema s interoperabilnošću!
MITM napad
Man In The Middle je vrsta napada od koje se svakoj osobi zaduženoj za sigurnost sustava diže kosa na glavi. Taj napad podrazumijeva stanje u kojem napadač neometano prisluškuje komunikaciju između dviju strana, koju zatim može barem pospremiti i kasnije na miru razbijati, a u gorem slučaju znači mogućnost real-time prisluškivanja, pa čak i impersoniranja neke od dviju strana. Vjerojatno ste primijetili kako za većinu u ovom tekstu navedenih napada kao preduvjet za uspješan napad stoji uspostavljanje MITM pozicije na komunikacijskom kanalu; to donekle otežava napad, ali ovo trebate shvatiti vrlo, vrlo uvjetno.
Naime, MITM napad moguće je izvesti svugdje gdje napadač može uspostaviti neki oblik kontrole nad komunikacijskim medijem (WiFi mrežom, LAN mrežom, mobilnim Internetom…) koji mu omogućuje upravljanje ili barem prisluškivanje tuđih komunikacija.
Klasičan primjer: otvorena WiFi mreža. Na njoj, upravo zbog toga što nema faktički nikakvih mehanizama zaštite i zato što je riječ o broadcast mreži (tj. svi mogu vidjeti svačiji promet) posve je trivijalno načiniti MITM napad . Ako ste se ikad pitali zašto vam svi stručnjaci za sigurnost savjetuju da nikad ne koristite osjetljive servise poput e-maila ili financijskih servisa na javnim mrežama aerodroma, restorana i hotela – sad vam je vjerojatno jasno zašto.
Nešto je teže uspostaviti kontrolu nad zaštićenim WiFi mrežama: napadač prvo treba upasti u samu mrežu, ali jednom kad upadne otvara mu se mogućnost uspostavljanja MITM napada nad bilo kojom postojećom bežičnom komunikacijom.
Uspije li se napadač pritom dočepati i kontrole nad aktivnom mrežnom opremom poput switcha ili routera, smatrajte se kuhanim i pečenim.
Napadač koji gospodari aktivnom mrežnom opremom u prilici je učiniti mnoge nepodopštine, a možda najgora od svih je mogućnost potpune impersonacije, pri čemu je napadač nezaobilazni posrednik između klijenta i poslužitelja koji doslovce cjelokupnu komunikaciju ima na dlanu.
Sitan trik koji se zove “SSL stripping” omogućuje napadaču da se tako infiltrira u komunikaciju da ni klijent ni poslužitelj ne znaju da između sebe imaju posrednika, a korištenjem SSL strippinga napadač jednostavno “oljušti” sloj zaštite s komunikacijskog kanala i ima potpun i jasan uvid u sve što tim kanalom prolazi, bez obzira koliko neprobojan bio cipher. Poslužitelju se sve čini potpuno normalnim (jer napadač prema njemu šifrira promet), a jedini tko bi mogao primijetiti da nešto nije u redu je korisnik – ako ima dovoljno tehničkog znanja da prepozna kako ne koristi https, već http. Sofisticirani alati za tu vrstu napada pobrinut će se da korisniku sve izgleda što je moguće normalnije, pa će tako čak i implementirati mali lokotić koji se inače koristi kao dokaz da je komunikacija šifrirana. Tako sofisticiranu prevaru obično može otkriti samo tehnički dobro potkovan korisnik, a takvih nema mnogo – a ni oni ne provjeravaju paranoično autentičnost svakog lokotića.
Ovaj napad je toliko zgodan da su se na tržištu pojavila i softverska, pa i hardverska rješenja koja kupuju zainteresirane tvrtke kako bi imale potpunu kontrolu nad zbivanjima u svojoj mreži: zaposlenici takvih tvrtki koji vjeruju kako njihovu privatnu webmail poštu nitko ne može pročitati, ili kako nitko ne može saznati što komuniciraju s nekim zaštićenim poslužiteljem mogli bi se vrlo neugodno iznenaditi.
Paranoični korisnici zato ne bi trebali koristiti osjetljive servise na bilo čemu što nije mreža koju pod kontrolom imaju oni ili benevolentni, odgovarajuće stručno osposobljeni kolege ili prijatelji. Za izvođenje MITM napada sa SSL strippingom nije nužno kupovati i instalirati skupu opremu, već je za to dovoljan jedan laptop, Kali distribucija Linuxa, mreža koja nije čvrsto zaključana i nešto tehničkog znanja.
Nažalost, nema jednoznačne i lake zaštite od MITM napada: obzirom da je riječ o cijelom spektru mogućih napada, obrana je teška: najbolje šanse daju kombinacija dobrog znanja administratora sustava i redovito patchiranje. Protiv SSL strippinga postoji polurješenje: HTTP Strict Transport Security parametar kojim poslužitelj deklarira klijentu da prihvaća samo i isključivo https veze, ali ono je ovisno o tome je li klijent već ostvario sigurnu komunikaciju prema nekom poslužitelju (jer u suprotnom napadač može jednostavno ukloniti ovu informaciju prije nego dođe do klijenta) i, naravno, ako taj poslužitelj uopće koristi ovu mogućnost.
Novi igrač na terenu: Bar Mitzvah napad
Bar Mitzvah je židovski običaj koji obilježava ulazak dječaka u društvo odraslih po njegovom trinaestom rođendanu; od tog dana dječak je sam odgovoran za svoje postupke i smatra se dovoljno zrelim preuzeti tu odgovornost. Naziv ove ranjivosti izvrsno se igra simbolikom, jer prošlo je upravo trinaest godina otkako je pokazano da rc4 cipher ima ozbiljne propuste. Za trinaestgodišnjicu stigao nam je napad koji je po ozbiljnosti u rangu FREAK napada i, što je posebno zabrinjavajuće, za izvođenje mu je dovoljno pasivno prikupljanje zaštićene komunikacije, bez napadačevog uplitanja u komunikacijski kanal.
Dok je njegova druga zla bratija u svojim zlim rabotama relativno ograničena na session tokene, Bar Mitzvah može, ničim izazvan, direktno iz komunikacije izvlačiti dijelove podataka, što uključuje korisnička imena i lozinke, brojeve kreditnih kartica i privatne slike celebrity osoba.
Ovaj napad koristi “invariance weakness” u prvih sto bajtova keystreama, odnosno iskorištava propust u kojem sustav generira dio podataka po obrascu kojeg je moguće uočiti, čime napadač može razotkriti do 64 bajta informacija u osjetljivom paketu. Pomaknemo li se s teorije na praksu, dolazimo do činjenice da je potrebno skupiti veliki broj paketa da bi se iz samo nekoliko njih izvuklo korisne informacije. To, naravno, apsolutno ne znači da se trebamo osjećati sigurni, jer curenje informacija može nastati i u relativno kratkotrajnoj komunikaciji – a stvar je sreće koju će informaciju napadač tako uspjeti otkriti. Ona može biti posve benigna, ali može biti i broj kreditne kartice.
Zbog toga je idealna meta Bar Mitzvah napada banka ili kartičar: napadač koji se uspije zakačiti na strani institucije koja obavlja mnogo prometa s mnoštvom korisnika generirat će daleko veći broj potencijalno korisnih paketa nego što bi to bilo na drugom kraju veze, na korisničkoj strani. Napadač koji koristi Bar Mitzvah za pasivno prikupljanje podataka ne može utjecati na informacije koje će prikupiti i ne može (niti uistinu želi) birati koju će specifičnu komunikaciju prisluškivati: njemu je u interesu rudarenje koje će iz mnoštva podataka izvlačiti, polako ali sigurno, osjetljive podatke poput brojeva kreditnih kartica.
Ovaj se napad može usporediti s famoznim Heartbleed napadom u tome što napadač ne može birati vrstu informacije koju će dobiti nazad, ali obzirom na konzistentnost problema može biti siguran da će dobivati informacije, zbog pasivnog prisluškivanja možda i jako dugo vremena neotkriven u svojoj raboti. A to je razlog da rc4 prestanete koristiti još danas, ili riskirate korištenjem komunikacijskog kanala koji je posve očito prestao biti siguran. Oy vey, oy vey!!
Interoperabilnost i zašto je izbjegavati
Iako je naslov kontraintuitivan – u načelu želimo postići čim veću interoperabilnost – ponekad postoje vrlo dobri razlozi zašto interoperabilnost treba izbjegavati. Princip podržavanja hardvera i softvera koji je odradio svoj životni ciklus ima svoje valjane argumente: uštedu vremena i resursa, maksimiziranje iskorištavanja postojećeg sustava, olakšanu migraciju sa starog na novi sustav… no, sve to pada u vodu kad interoperabilnost uzrokuje ozbiljne nedostatke u sustavu. U slučaju telebankinga (ali i na još mnogo drugih mjesta u enterprise okruženjima) simptomatična je (više) želja i (manje) potreba da sustav podržava sustave kojih se već i njihov proizvođač odrekao: glasno i jasno, riječ je o podršci za Windows XP i MSIE6 preglednik.
Oba proizvoda odigrala su snažnu ulogu u informatičkoj industriji proteklih desetljeća i za sobom su ostavili bogato ali i problematično naslijeđe: kombinacija tog operacijskog sustava i MSIE preglednika u verziji šest uplodila je fascinantnim brojem rješenja koja su ovisna o jednom ili o drugom, ili čak o oba. Kućnim korisnicima i poslovnjacima koji imaju relativno male urede migracija na novi OS ili novu verziju Internet Explorera ili čak neki drugi pretraživač obično ne predstavlja baš nikakav problem. No, enterprise korisnici imaju itekakvu glavobolju zbog korištenja aplikacija napisanih tako da koriste specifičnosti tog okruženja, prvenstveno MSIE6. Riječ je o velikoj količini uloženog novca i aplikacijama bez kojih bi posao trpio štetu, ponekad čak i o rješenjima za koja niti ne postoji modernija aplikacija.
Iz današnje perspektive SaaS usluge i dizajniranja aplikacija na način da one budu što je moguće manje ovisne o nekoj konkretnoj implementaciji operacijskog sustava ili pretraživača čini se neozbiljno stvoriti toliku količinu aplikacija koje su vezane uz vrlo specifične funkcionalnosti i ograničene na vrlo uzak izbor softverske infrastrukture, no upravo tako je bilo barem jedno desetljeće: još i danas postoji ogromna količina legacy aplikacija koje ne rade dobro ili uopće ne rade na novijim verzijama Windowsa ili Internet Explorera.
Enterprise korisnici moraju živjeti s tim, ali ostali ne. Nažalost, događa se da tvrtke ili institucije zbog želje da zadrže partnerski odnos ili olakšaju život svojim korisnicima koji su vezani na legacy aplikacije zadržavaju zastarjelu tehnologiju; to je loše jer na posredan način može utjecati na sve druge partnere, pa i one koji se trude održati svoju tehnologiju modernom.
U slučaju banaka ovo je posebno osjetljivo pitanje jer se tiče primarno sigurnosti sustava: banke koje podržavaju SSL3 i kombinaciju Windows XP/MSIE6 trebaju biti svjesne sigurnosnih problema koje sa sobom donosi davanje podrške tehnologijama kojih se već i sam Microsoft odrekao. I ne samo to, obzirom da u sustavu poslovanja sudjeluju i drugi klijenti banke, sigurnosni propust koji bi iskoristio tu staru tehnologiju na posredan način može ugroziti i njihovo poslovanje: ukrade li napadač certifikat banke korištenjem propusta u SSL3 protokolu jednako efikasno može napadati i klijente čija platforma uopće ne koristi SSL3.
Poznato je kako je sigurnost sustava toliko dobra koliko je dobra najslabija karika sustava. U ovom slučaju bilo bi to korištenje zastarjelih tehnologija. Tvrtke su možda prisiljene koristiti ih, ali banke apsolutno nisu, niti bi ih smjele koristiti. Jedino ispravno rješenje, budući da se radi o problemu sigurnosti i zaštite ne samo banke već i svih njenih klijenata, jest imati vrlo oštar odnos prema legacy sustavima, posebice onim koji su otvoreni prema Internetu.
U takvom slučaju itekako je razumno ukinuti podršku za stare pretraživače i/ili operacijske sustave: banke bi klijentima jasno trebale dati do znanja da podrške više nema, i da je to za dobrobit svih korisnika sustava.
Android i zašto ga izbjegavati
Autor ovih redaka veliki je ljubitelj Androida, pasionirani zuritelj u smartphone i ozbiljan protivnik bilo kakvog oblika mobilnog bankinga.
Ma koliko Android bio popularan OS za pametne telefone i tablete, i ma koliko značajan tržišni udio imao, ništa od toga nije argument koji bi vas trebao uvjeriti da svoj bankovni račun povjerite aplikaciji koja na njemu radi. Naime, Android ima dva ključna problema.
Prvi problem je činjenica da tzv. stock pretraživač koji dolazi uz Android nije pretjerano siguran. Točnije, ovisno o verzijama Androida ranjiv je na neugodno veliku količinu stvari, uključujući i opasni FREAK napad.
Drugim riječima, browser koji dolazi uz Android poprilično je šupalj i dao bi se usporediti s MSIE6 u njegovim najboljim danima. Srećom, korisnik nije dužan koristiti taj preglednik, već može koristiti Chrome, Firefox, Operu ili neki četvrti preglednik, čime izbjegava sigurnosno problematičan Androidov “tvornički” pretraživač.
No, slično kao i u slučaju MS Windows i MSIE6 kombinacije, programeri koji izrađuju aplikacije mogu se oslanjati na već gotove mogućnosti operacijskog sustava, a to uključuje i korištenje ugrađenog preglednika. Autorima aplikacije značajno je lakše uklopiti već gotove dijelove u svoju aplikaciju nego pisati kompleksan kod iznova, faktički otkrivati toplu vodu.
Sjetimo li se da je smartphone zapravo punokrvno računalo kojeg nosimo u džepu, postaje jasno da problemi sa stolnih računala vrlo lako migriraju na telefone i tablete, stoga i opasnost da neka aplikacija koju koristite, a koja za svoj rad koristi biblioteku ili modul koji su ranjivi, bude nesigurna a da vi o tome nemate pojma. Jako veliki broj mobilnih aplikacija koristi web komunikaciju kao primarni vid komunikacije i korištenje ugrađenog pretraživača u takvim aplikacijama više je pravilo nego iznimka. Istraživanja ukazuju da je otprilike svaka deseta aplikacija pisana za Android i svaka dvadeseta pisana za iOS osjetljiva na FREAK napad.
To vrlo lako može biti i vaša telebanking aplikacija.
Stvar se dodatno pogoršava činjenicom da mobilni uređaji upravo mame korisnike na korištenje aplikacija u svim mogućim i nemogućim situacijama, od kojih neke mogu predstavljati sigurnosno vrlo opasna mjesta, poput nezaštićenih WiFi mreža po aerodromima, kafićima, hotelima… Korisnik koji na takvom mjestu pokrene m-banking aplikaciju (ili bilo koju drugu aplikaciju koja sadrži osjetljive ili privatne podatke) koja ima sigurnosni prosput uistinu mnogo riskira.
Stručniji autori aplikacija koji su svjesni tog problema ne koriste ugrađene biblioteke i komponente, već pišu svoje ili koriste one za koje su koliko-toliko sigurni da nemaju sigurnosnih problema. Na taj način oni korisniku pružaju značajno bolju zaštitu, ali kako svako dobro djelo ne smije proći nekažnjeno, opterećeni su potrebom da osim svoje aplikacije ažurnom održavaju i sve dodatne biblioteke koje ta aplikacija koristi. Drugim riječima, najzaštićeniji m-banking sustav je onaj koji se na sam Android oslanja što je moguće manje, a što je moguće više toga rješava vlastitim snagama.
No, vrlo često se autori aplikacija oslanjaju na gotove komponente i nadu da će Android brzo ispraviti nedostatke u komponentama. To je, nažalost, u Androidovom ekosustavu vrlo ozbiljan problem. Naime, iako će Google vjerojatno vrlo brzo pokrpati sigurnosne nedostatke, da bi oni došli do korisnika telefona i druge gadgeterije moraju te zakrpe implementirati i vendori, tj. tvrtke koje izrađuju uređaje i zatim ih, najčešć OTA (Over The Air) nadogradnjom poslati svim svojim kupcima.
Vjerojatno i sami znate koliko često vam proizvođač, nakon što ste kupili njegov tablet ili smartphone, nudi OTA nadogradnje. Vjerujem da je problem vrlo očit.
Apple i Microsoft su bolji, ali ne značajno: gore navedeni problem postoji i na tim platformama, ali za razliku od Androida, Apple i Microsoft mogu svim svojim korisnicima poslati nadogradnju direktno i ekspeditivno (što i dalje ne znači da će i autori aplikacija na tim platformama biti jednako ekspeditivni).
Treba li njima onda više vjerovati kad je u pitanju m-bankarstvo? Na volju vam, ali ja ne vjerujem nikome: cijeli ekosustav mobilnih aplikacija još uvijek je u fazi formiranja i trebat će proći još vremena prije nego se uspostavi ozbiljan i kvalitetan mehanizam rješavanja sigurnosnih pitanja na mobilnim uređajima. To, naravno, ne znači da već ne postoje kvalitetne i sigurne aplikacije za mobilno bankarstvo, ali to se svodi na to koliko vjerujete u stručnost i sposobnost autora aplikacije.
Kako se zaštititi?
U svijetu sigurnosti idealne zaštite nema: sustavi mogu biti zaštićeni više ili manje, ali u potpunosti i zauvijek ne može biti zaštićen niti jedan sustav. To vas ne treba bacati u očaj, nihilizam i razbijanje čaša u zadimljenim krčmama, ali trebate biti svjesni da je sigurnost proces koji se neprestano odvija i pritom evoluira.
Ako ste običan korisnik bez previše znanja o računalima, trebate se pouzdati u sigurnost koju vam pružaju davatelji usluga: proizvođači pretraživača i softvera, te banke. Sigurnosna osvježavanja (update) operacijskog sustava i aplikacija su najbolje što možete učiniti za vlastitu sigurnost. Dodajmo tome korištenje antivirusnog softvera, izbjegavanje korištenja aplikacija koje sadržavaju osjetljive podatke na mjestima koja se čine sumnjiva, apsolutno izbjegavanje otvorenih WiFi mreža (pa čak i ako samo malo surfate – vaš browser ili, u slučaju mobilnih uređaja, e-mail aplikacija ili neka druga koja se izvršava u pozadini, mogu preko nesigurne veze slati i primati vrlo osjetljive informacije) ili korištenje kvalitetnih VPN servisa pružit će vam razumnu razinu sigurnosti.
Ako ste napredniji korisnik, možete se poigrati s postavkama pretraživača: oni na više ili manje kompliciran način daju korisniku mogućnost da ručno izabere koje će sigurnosne postavke koristiti. Imate li tehničkog znanja, možete ručno pogasiti sve nesigurne protokole i ciphere i ostaviti samo one koji su (zasad) sigurni: primjerice, TLS 1.2 protokol i AEAD ciphere. To bi vas moglo izložiti situaciji da neki web servisi ne budu u mogućnosti komunicirati s vama, ali ako vam je sigurnost važna… servisi, ćao-bao!
Banke su, pak, u problemu. Kvalitetna zaštita podrazumijeva drastične mjere poput onemogućavanja korištenja ranjivih protokola ili ciphera, a svaka pojedinačna zabrana potencijalno sa sobom donosi probleme s interoperabilnošću. Banke žele biti zaštićene koliko je to moguće, a s druge strane žele svojim klijentima omogućiti čim veću interoperabilnost. Našavši se između dvije vatre, neke banke oslonit će se na podizanje razine sigurnosti, neke će nastojati sačuvati interoperabilnost nauštrb nekih sigurnosnih aspekata, a neke će, možda, staviti prst u uho i pretvarati se da problem ne postoji. Uvijek se rado sjetim telebanking sustava jedne banke koji je uključivao Java applet za pristupanje čip kartici, a koji je bio tako loše napravljen da je zahtijevao vrlo specifičnu verziju Jave. Sjećam se čupanja kose kolega sistemaša koji bi proklinjali i banku i telebanking svaki put kad bi Sun izdao sigurnosnu zakrpu Jave, a koja bi uredno upropastila bančin applet i onemogućila korištenje telebankinga. Služba za korisnike redovito bi na bijesne/očajničke upite odgovarala kako banka podržava točno tu-i-tu verziju Jave i da žao nam je, ali morate koristiti baš nju – nema veze što ima sigurnosne rupe. Nama ne smeta.
Ta su nelijepa vremena, nadam se, nepovratno za nama. Ili, ipak?!?!
Iz spomenute će se pozicije balansiranja između sigurnosti i širokogrudnosti banke teško izvući bez posizanja za radikalnim rješenjima – a jedini ispravan način rješavanja je nemilosrdno rezanje svih ranjivih komponenti sustava, što neizbježno dovodi do problema interoperabilnosti s nekim klijentima. S druge strane, zbog takvih klijenata cijeli sustav je izložen ranjivosti, pa tako i oni klijenti koji brinu o sigurnosti, koji tako postaju taocima klijenata koji za sigurnost ne mare. No, ovo nije ludi početak 21. stoljeća: trebali bismo danas biti itekako svjesni važnosti sigurnosti na Internetu, pa bi banke uistinu napravile uslugu i sebi i klijentima kada bi sigurnosne probleme rješavale oštrom sabljom. Najzad, u toj igri sigurnosti na njima je puno veća odgovornost nego na klijentima.
Zanimljivi inkovi:
FREAK vulnerability test: https://freakattack.com/clienttest.html
POODLE test: https://www.poodletest.com/
WORMLY SSL test: https://www.wormly.com/tools
SSL/TLS test za klijente: https://www.howsmyssl.com/
Digicert test: https://www.digicert.com/help/
Globalsign test: https://sslcheck.globalsign.com/
GeoTrust SSL Toolbox: https://ssltools.geotrust.com/checker/views/certCheck.jsp
Autor je jedan od vodećih domaćih informatičara i ekspert za slobodni softver, informatički novinar, bivši stručni savjetnik za informatiku u poglavarstvu Grada Zagreba i vlasnik tvrtke Operacijski sustavi. Jedan je od 25 najboljih IT konzultanata u Hrvatskoj, prema izboru korisnika tih usluga. Autor je i SF knjige ‘Umišljena inteligencija’, koju u obliku e-booka možete besplatno skinuti na svoj Android uređaj s Google Play.
