The New York Times - Prejšnji teden smo poročali, da so hekerji napadli strani ameriške banke Citigroup in odtujili osebne in osnovne finančne podatke (CVV-kod kartic niso dobili) številk približno 200.000 uporabnikov, kar predstavlja en odstotek vse komitentov banke. Uradnih podatkov o škodi tedaj ni bilo in jih ni niti danes, so pa na splet priplavali podatki o vrsti ranljivosti, ki so jo hekerji izkoristili. Izkazalo se je, da je bila za napako kriv površno spisana spletna stran, proti kateri je bila Sonyjeva zaščita kot Fort Knox, kot se je izrazil eden izmed bralcev Slashdota.
Hekerji so se na najprej kot običajen uporabnik prijavili na spletno stran, ki je bila namenjena njihovim komitentov, kar ni težko. Ko pa so bili enkrat na straneh, so med računi preskakovali tako, da so v naslovni vrstici zamenjali svojo številko računa z neko drugo in tako pristali v računu druge stranke. Morali so poslati zgolj 200.000 zahtevkov in strežnik je vsakokrat vrnil podatke o računu neke stranke.
To pomeni, da si hekerji tega imena pravzaprav niti ne zaslužijo. Citigroup je stran napisal tako malomarno, kot že dolgo nobeno resno podjetje. To ni bil niti najosnovnejši napad s SQL-vrivanjem, ampak še nekaj bolj preprostega. Strežnik sploh ni izvajal nobenega preverjanje pristnosti, tj. ustreznosti trenutne seje in zahtevanih podatkov, ampak jih je delil vsem, ki so poslali navaden HTTP-jevski zahtevek $_GET. Sistem je bil že po dizajnu odprt, saj številke računov niso tako tajne kot številke kreditnih kartic, tako da z njihovim poznavanjem ne bi smeli imeti možnosti pridobiti kakršnihkoli osebnih podatkov.
Po tovrstnem programiranju so znane tudi nekatereslovenske banke, ki zadnje čase ne odgovarjajo preveč rade na provokativna vprašanja v zvezi z njihovo varnostjo.
isti "napad" je bil mogoč na starem AIPS-u. Samo tam nisi rabo nič spremenit pa si včasih vido tuje podatke. Najpogosteje se je to pojavljalo med prijavljanjem v novi letnik.
Everyone started out as a newbie.
Sadly only a handful ever progress past that point.
To ni bil niti najosnovnejši napad s SQL-vrivanjem, ampak še nekaj bolj preprostega. Strežnik sploh ni izvajal nobenega preverjanje pristnosti, tj. ustreznosti trenutne seje in zahtevanih podatkov, ampak jih je delil vsem, ki so poslali navaden PHP-jevski zahtevek $_GET.
HTTP GET request nima veze s PHPjem. Poslje ga client, na server-sidu (npr. PHP ali kaj tretjega) pa potem preberejo ta request, v PHPju pac preko branja spremenljivke $_GET :)
V bistvu je to še najboljša zaščita. Nihče namreč ne pričakuje, da bi bili tako glupi, da bi dopustili takšno pomankljivost. Dokler se ne najde nekdo, ki je enako ali še bolj glup.
Tudi na Sparkasse so me debelo gledali, ko sem rekel, da bi želel videti zgodovino svojih gesel, da vidim, če sem si ga narobe zapisal ali pa mi ga je dejansko kdo vkradel in geslo zamenjal. Ženska na pulstu: ne rabite se bati, pri nas še ni bilo vdora.
Zakaj majo pol sploh login skripto, ce stran itaq ne zna delati z session/cookiesi? Krneki res...bolano debilno. Se 12 letni froc bi znal boljs naredit stran.
Sj ma 90+% bank vse svoje storitve in APIje "zavarovane" na isti nacin. Recimo...kup webservices, ki jih lahko uporabljas.Rabis username in geslo(da mislis da je neka varnost)...potem pa sledi salabajzarstvo.Username in geslo vpisujes v parametre funkcij webservica(ker majstri se niso slisali ne za SSL ne za client certifikate ali pa vsaj minimalno server side ssl+plaintext authorizacijo...kar je se zmer drek ampak vsaj 1 stopnicka boljse kot posiljanje plaintexta brez sslja). Ce jim to omenis te pa pomirijo s tem, da bojo zadevo zafirewallal na tvoj ip.Problem je pa v tem, da zahtevajo storitve v 1 tednu tko, da programerji neki spacajo skupi...potem se verjetno zavezejo, da bojo ze kasneje izboljsali ampak ta kasneje se nikoli ne zgodi, ker pridev v veljavo rek "if it ain't broke don't fix it"...dokler se ne najde 15 letn mulc, ki se ti obesi na tist router in pogleda tvoj unsecure http get/post. In take firme majo cez vecino placil z mastercardom,viso, diners club in podobnimi.Pomojem so njihova najvecja zascita ravno ponudniki, ki se obseijo na te apije in potem nudijo storitve naprej(EON al kaj mamo ze mi pri nas).
To ni nič takšnega, Windows Server 2003 in IIS6 se še vedno uporabljata.
Saj ni pomembno to, ali se še uporabljata, važno je, do kdaj zadevo podpira proizvajalec (lifecycle), ker po tem času nimaš več popravkov, krpanja varnostnih lukenj... Marsikje uporabljajo tudi še Win98.
Na isti način se je včasih dalo popravit oglas na bolhi. Lahko si si nastavil čas poteka izven običajnih 3 5 ali 7 (al kak je že bilo), seveda pa si lahko vse to delal tudi na druge accounte.
Fino bi bilo slišat uradno stališče te firme glede varnosti in kvalitete njihovih storitev!
Pa za takole napako bi podjetje IMO moralo odškodninsko odgovarjat.
Glede banke pa - zanimivo bi bilo stališče Banke Slovenije ali ta banka še obvladuje tveganja. Ker če jih ne, lahko sledi odvzem licence.
Večje firme ki se ukvarjajo z bančnem poslovanje v bilo kateri obliki imajo redne revizije. Problem je da vodstvo ne želi zapravit denar v nekaj kar ne prinaša dobička in IT vidijo kot strošek.
Po bančnih predpisih banke morajo obvladovati določena tveganja. Vseh seveda ne. Osnovna varnost spletnih bank je že med njimi.
Hmm, kateri predpis pa določa karkoli v vezi s spletno banko? Jaz nobenega ne najdem, Na žalost je vse to v domeni samih bank.
Ni ne, bančne firme imajo najbolj urejen IT glede spoštovanja določenih standardov. Drugje je bistveno slabše.
Ne biti toliko siguren v to kar trdiš. Namreč IT je že kolikortoliko urejen in tudi na papirjih je veliko zapisano. Koliko se pa to napisano potem spoštuje je pa drugo vprašanje. So stvari, ki ne gredo samo mimo pravil, ampak tudi mimo vsake pametne ideje - in to celo za čisto trivialne zadeve.
@nebivedu; lahko podaš prosim samo en tak primer trivialne zadeve? Delam namreč v IT-ju ene slovenskih bank (pa nei Sparkasse) in se ne bi ravno mogel strinjati s tvojim pisanjem.
Ko ne gre več, ko se ustavi, RESET Vas spet v ritem spravi.
Po bančnih predpisih banke morajo obvladovati določena tveganja. Vseh seveda ne. Osnovna varnost spletnih bank je že med njimi.
Hmm, kateri predpis pa določa karkoli v vezi s spletno banko? Jaz nobenega ne najdem, Na žalost je vse to v domeni samih bank.
Ni ne, bančne firme imajo najbolj urejen IT glede spoštovanja določenih standardov. Drugje je bistveno slabše.
Ne biti toliko siguren v to kar trdiš. Namreč IT je že kolikortoliko urejen in tudi na papirjih je veliko zapisano. Koliko se pa to napisano potem spoštuje je pa drugo vprašanje. So stvari, ki ne gredo samo mimo pravil, ampak tudi mimo vsake pametne ideje - in to celo za čisto trivialne zadeve.
Sem siguren, ker delam že preveč let v IT-ju. Iz sistemskega vidika je zadeva zelo solidna, ampak programiranje je še vedno zapuščeno samo sebi. Tu na žalost še vedno ni definiranih standardov.
Pred par leti je podobno ranljivost imela spletna stran Gorenjske Borznoposredniške Družbe. Pri posodabljanju osebnih podatkov se je obrazec poslal na [nekje].php?id=[id_uporabnika]. Zamenjava id-a in hop, podatki ciljnega uporabnika [brez preverjanja] so bili spremenjeni.
Luknje kljub opozorilu niso zakrpali vse do zamenjave spletne strani.
Praviš, da naj študenta torej pošljejo nazaj študirati.
Strinjal se bi, če bi vedel za kakšen predmet na kateri koli rač-inf smeri katere koli višje ali visoke šole v Sloveniji, ki se ukvarja s pristopi k pravilnem programiranju.
Praviš, da naj študenta torej pošljejo nazaj študirati.
Strinjal se bi, če bi vedel za kakšen predmet na kateri koli rač-inf smeri katere koli višje ali visoke šole v Sloveniji, ki se ukvarja s pristopi k pravilnem programiranju.
Pri nam so poleg parih vrstic kode tudi povedali in zahtevali, da je potreben pravilen pristop k programiranju. Sicer izgovor, da se šole ne ukvarjajo s tem je lari-fari... Če delaš na takem projektu, potem moraš bit sposoben sam iskat, brat in razumet literaturo, da se čimveč naučiš.
Na isti način se je včasih dalo popravit oglas na bolhi. Lahko si si nastavil čas poteka izven običajnih 3 5 ali 7 (al kak je že bilo), seveda pa si lahko vse to delal tudi na druge accounte.
in zveš pravo ime uporabnika, če imaš njegov nick. Še več je takih for, tudi v nekaterih spletnih trgovinah ki ponujajo dolpoteg, se da z malo igranja z URL-ji dobit marsikaj zastonj. :)
Praviš, da naj študenta torej pošljejo nazaj študirati.
Strinjal se bi, če bi vedel za kakšen predmet na kateri koli rač-inf smeri katere koli višje ali visoke šole v Sloveniji, ki se ukvarja s pristopi k pravilnem programiranju.
Programiranje (kodiranje) je samo del celotnega procesa. Zadeva je bila verjetno čisto pravilno sprogramirana (sicer ne bi delovala), a je bila zasnovana napačno. Nikakor tudi ni stvar programerja, da se odloči o takih zadevah.
Matthai: tako je povsod. OK, tole, kar opisujete v zvezi s tema bankama je šlamparija brez primere, ampak vem, kako stiskaški so naročniki. Radi bi imeli vse za minimalno plačilo. Potem je precej stvari potrebno narediti zelo na hitro. Tukaj se je to na žalost naredilo pri napačnih stvareh.
Real life example pri stranki: "Lahko vam ponudimo rešitev A, narejeno točno kot ste vi zahtevali, za X EUR. Ampak vam svetujemo bolj optimalno, varno in robustno rešitev B, ki bo vzela malo več dela, toda s tem boste rešili tudi vse prihodnje težave, podobne trenutni. Stala bi pa X+5% EUR." Stranka: "Hočemo rešitev A." "Ampak (ponovi vse argumente in podkrepi s konkretnimi primeri)." Stranka: "Ne, nimamo (5% EUR) denarja, hočemo cenejšo rešitev." "Ampak, čez čas se bo težava ponovila in boste takrat dali spet X EUR za rešitev!" Stranka: "Hočemo rešitev, ki je zdaj cenejša."
Pa ti kaj naredi...
Anyway, on topic: a kdo ve, če ima Sparkasse še vedno podobne varnostne luknje? Da ne bomo šli z dežja (NLB) pod kap, ko zamenjam banko...
. 
