Novice » Varnost » Napad na Citigroup izkoristil trivialno luknjo
Reycis ::
techfreak,
1: je drazje, ker moras nekam med pogoje delovanja vtakniti klavzulo o sejnih piskotih kar zadevo podrazi. mogoce ravno za 5%
2: sodec po opisu problem to ni tak problem, kje naj bi se ID vodil, ampak nekaj drugega (ker naj bi se tak ali podoben problem cez caz ponovil). Mogoce so jim hotli prodat en boljsi kos hardware-a za v server kot minimum?
1: je drazje, ker moras nekam med pogoje delovanja vtakniti klavzulo o sejnih piskotih kar zadevo podrazi. mogoce ravno za 5%
2: sodec po opisu problem to ni tak problem, kje naj bi se ID vodil, ampak nekaj drugega (ker naj bi se tak ali podoben problem cez caz ponovil). Mogoce so jim hotli prodat en boljsi kos hardware-a za v server kot minimum?
WarpedGone ::
Ja še vedno je marsikaj možnega, recimo: http://www.bolha.com/zvu.php?user_id=te... 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. :)
Iz moje sobe se je ravnokar zaslišal glasen FAAAAK...
Edit: Še vedno mejle pošiljajo na zdavnaj mrtvi email.si. Šalabajzerji jedni ...
Zbogom in hvala za vse ribe
Zgodovina sprememb…
- spremenilo: WarpedGone ()
Reycis ::
Matthai dej ne bebcka delat iz sebe. Dejstvo je, da ce ID vodis v seji in sejo vodis preko sejnega piskota (tako kot v preko 99% premirih se), lahko zaradi uporabe piskotov nastopijo pravne posledice. Zdaj lahko izbiras med:
-dopises med pogoje uporabe da stran za svoje delovanje uporablja piskote
-najames svetovalno druzbo, ki ti zagotovi da ne potrebujes dovoljenja uporabnika za uporabo sejnih piskotov
-se odlocis, da ignoriras problematiko in riskiras placilni nalog od inspekcije
Zame nobena od teh treh opcij ni zastonj. Seveda je najlazje v pogoje uporabe vtakniti se dolocilo o piskotih. Se vedno pa kot izdelovalec spletnih stvari moras pomisliti tudi na to malenkost in jo urediti. Dejstvo je, da tega posebej ne izkazes na racunu ampak je vracunana v paket. Zaradi tega pa to se ne pomeni, da je zastonj. In ce na hitrico pregledas pogoje velikih slovenskih strani bos nasel tudi dolocilo o piskotih. Se slo-tech ga ima.
Se opravicujem za "bebcka". Ker iz preostalih tem mislim, da si dovolj pameten, da ves o cemu sem govoril, sklepam da si le zelel, da se preostalim bralcem foruma razjasnim kako lahko zaradi vodenja spremenljivke v seji namesto v URLju se dejansko povecajo stroski izdelave strani.
-dopises med pogoje uporabe da stran za svoje delovanje uporablja piskote
-najames svetovalno druzbo, ki ti zagotovi da ne potrebujes dovoljenja uporabnika za uporabo sejnih piskotov
-se odlocis, da ignoriras problematiko in riskiras placilni nalog od inspekcije
Zame nobena od teh treh opcij ni zastonj. Seveda je najlazje v pogoje uporabe vtakniti se dolocilo o piskotih. Se vedno pa kot izdelovalec spletnih stvari moras pomisliti tudi na to malenkost in jo urediti. Dejstvo je, da tega posebej ne izkazes na racunu ampak je vracunana v paket. Zaradi tega pa to se ne pomeni, da je zastonj. In ce na hitrico pregledas pogoje velikih slovenskih strani bos nasel tudi dolocilo o piskotih. Se slo-tech ga ima.
Se opravicujem za "bebcka". Ker iz preostalih tem mislim, da si dovolj pameten, da ves o cemu sem govoril, sklepam da si le zelel, da se preostalim bralcem foruma razjasnim kako lahko zaradi vodenja spremenljivke v seji namesto v URLju se dejansko povecajo stroski izdelave strani.
Zgodovina sprememb…
- spremenil: Reycis ()
krneki0001 ::
@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.
Koliko let delaš v IT-ju ene izmed slovenskih bank, da tako dobro poznaš IT banke?
Zgodovina sprememb…
- spremenilo: krneki0001 ()
poweroff ::
Matthai dej ne bebcka delat iz sebe. Dejstvo je, da ce ID vodis v seji in sejo vodis preko sejnega piskota (tako kot v preko 99% premirih se), lahko zaradi uporabe piskotov nastopijo pravne posledice.
Kakšne pa? Slučajno zelo dobro poznam tovrstno zakonodajo, zato kar na dan z besedo. Govorimo seveda o session in persistent cookijih.
Zame nobena od teh treh opcij ni zastonj. Seveda je najlazje v pogoje uporabe vtakniti se dolocilo o piskotih.
Da, to stane vsaj kakšnih 100 jurjev. EUR seveda...
(mislim, kakšne bučke)...
In ce na hitrico pregledas pogoje velikih slovenskih strani bos nasel tudi dolocilo o piskotih. Se slo-tech ga ima.
Ne boš verjel - ta del sem jaz pisal.
Se opravicujem za "bebcka". Ker iz preostalih tem mislim, da si dovolj pameten, da ves o cemu sem govoril, sklepam da si le zelel, da se preostalim bralcem foruma razjasnim kako lahko zaradi vodenja spremenljivke v seji namesto v URLju se dejansko povecajo stroski izdelave strani.
Ampak če vodiš "spremenljivko v URL-ju", to potem ni avtentikacija. Saj to veš, ne? Razen če bi na vsaki strani zahteval ponoven vpis gesla.
sudo poweroff
Reycis ::
Hiter odgovor za Matthani:
Glede pravnih posledic uporabe poskotov:
Nisem pravnik in jih ne poznam. Imam pa toliko inteligence da sem zaznal, da skoraj vse strani uporabljajo klavzulo o piskotih. Zato sklepam, da je potrebna. Lahko bi najel tudi svetovalno sluzbo, ki bi zame ugotovila kaj tocno, ce sploh je potrebno vendar je enostavneje ce se zgledujem po drugih straneh in to upostevam. Priznam nimam pojma kaksna pravne posledice sledijo. Predvidevam pa da ce ne uporabljas nobenih piskotov te klavzule ne potrebujes.
Glede cene klavzule si se obesil na to, da sem napisal:
"1: je drazje, ker moras nekam med pogoje delovanja vtakniti klavzulo o sejnih piskotih kar zadevo podrazi. mogoce ravno za 5%"
Mislim, da se strinjava da cena je vecja od 0. Priznam pa, da je 5% najbrz ornk pretiravanje. Vendar pa je lahko tudi realna v primerih ko je naknadno dodana samo klavzula.
Glede vodenja spremenkljivke v URL:
Ni nujno, da se v URL vodi doticno spremenljivko neposredno. Velika vecina spletnih aplikacij za vodenje seje uporablja piskote. Vsi dobri programerji pa vedo, da to ni edini nacin. Namesto v piskotu lahko vodis ID seje (ali pa na koncu koncev tudi nek self made token) v URLju. Na ta nacin lahko brez uporabe kakrsnihkoli piskotov vodis spremenljivke na strezniku brez da bi jih imel uporabnik neposredno spreminjat preko URL. Enako kot ce bi posiljal piskote. Odpade pa potreba in z njo povezani stroski klavzule. Zadeva pa prinasa nekatera druga varnostna tveganja zato vsi raje uporabljajo piskote in pisejo klavzule.
tl;dr -> Jaz pravim, da strosek uporabe piskotov obstaja (napram neuporabi) zaradi potrebe po klavzuli. Ti pa pravis da tega stroska ni oz. da je zanemarljiv. Kul, se ne strinjava ane; jaz bom prezivel
.
Glede pravnih posledic uporabe poskotov:
Nisem pravnik in jih ne poznam. Imam pa toliko inteligence da sem zaznal, da skoraj vse strani uporabljajo klavzulo o piskotih. Zato sklepam, da je potrebna. Lahko bi najel tudi svetovalno sluzbo, ki bi zame ugotovila kaj tocno, ce sploh je potrebno vendar je enostavneje ce se zgledujem po drugih straneh in to upostevam. Priznam nimam pojma kaksna pravne posledice sledijo. Predvidevam pa da ce ne uporabljas nobenih piskotov te klavzule ne potrebujes.
Glede cene klavzule si se obesil na to, da sem napisal:
"1: je drazje, ker moras nekam med pogoje delovanja vtakniti klavzulo o sejnih piskotih kar zadevo podrazi. mogoce ravno za 5%"
Mislim, da se strinjava da cena je vecja od 0. Priznam pa, da je 5% najbrz ornk pretiravanje. Vendar pa je lahko tudi realna v primerih ko je naknadno dodana samo klavzula.
Glede vodenja spremenkljivke v URL:
Ni nujno, da se v URL vodi doticno spremenljivko neposredno. Velika vecina spletnih aplikacij za vodenje seje uporablja piskote. Vsi dobri programerji pa vedo, da to ni edini nacin. Namesto v piskotu lahko vodis ID seje (ali pa na koncu koncev tudi nek self made token) v URLju. Na ta nacin lahko brez uporabe kakrsnihkoli piskotov vodis spremenljivke na strezniku brez da bi jih imel uporabnik neposredno spreminjat preko URL. Enako kot ce bi posiljal piskote. Odpade pa potreba in z njo povezani stroski klavzule. Zadeva pa prinasa nekatera druga varnostna tveganja zato vsi raje uporabljajo piskote in pisejo klavzule.
tl;dr -> Jaz pravim, da strosek uporabe piskotov obstaja (napram neuporabi) zaradi potrebe po klavzuli. Ti pa pravis da tega stroska ni oz. da je zanemarljiv. Kul, se ne strinjava ane; jaz bom prezivel
. Zgodovina sprememb…
- spremenil: Reycis ()
poweroff ::
No, jaz sem zelo dobro preučil zakonodajo v zvezi s tem in so mi stvari jasne. Dejstvo je, da strošek klavzule je zanemarljiv. Sploh če ga skopiraš iz drugih spletnih strani. Če pa si seveda nategunsko IT podjetje, je verjetno smiselno, da naročniku zaračunaš ta strošek kot ogromen znesek, po možnosti podprt z obširno (in seveda nepotrebno) raziskavo.
Smiselno je seveda zate, ne za neukega naročnika.
Vodenje seje preko URLja seveda je opcija. Samo je treba imeti nekaj pameti in narediti tisto, kar pri session cookijih browser naredi avtomatsko. Ne recimo tako kot tisto znano dvorno slovensko IT podjetje, ki je za en precej velik državni organ v Sloveniji to izvedlo tako, da sem pred par meseci odkril kako s spremembo URLja ugrabit sejo in dostopat do kritično občutljivih podatkov tega državnega organa.
Ko sem jim zadevo predstavil (organu) so najprej eno uro lovili sapo, na koncu pa prišli do tega, da se zadevo da popraviti, jih bo pa pošastno drago stala. Popravek bo seveda delal dvorni IT ponudnik, ki je celo stvar že v osnovi zajeb**.
Na splošno ugotavljam, da v teh krajih ljudem ni jasno kaj je to avtentikacija in kako narediti varno spletno avtentikacijo.
Evo, ker sem dobre volje še en primer. Za enega naročnika sem delal varnostni pregled aplikacije. Podatki iz njihove baze se se znašli na spletu in ker so bili to podatki, ki jih je treba varovati po zakonu je bila seveda pizdarija.
JAsno - takoj so posumili na teorijo zarote. Prideva z direktorjem tja in rečem naročniku če pokaže spletno aplikacijo. Top gre na login page, vpiše u/p in se začne sprehajat po bazi.
Nakar tipa prosim, da se odjavi.
Sedem za računalnik in vpišem URL, ki je bil vpisan prej (ko je bil prijavljen). In padem seveda v bazo, ki sem jo lahko tudi spreminjal.
Rečem tipu da je problem v tem, da oni predvidevajo, da bo v bazo vsakdo skušal vstopiti zgolj skozi login page, če pa nekdo vpiše direkten URL pa oni predvidevajo, da je user ustrezno logiran (a tega ne preverjajo).
Pravi da ne, da je to zato, ker se je on prej logiral iz tega računalnika "in je nekaj ostalo v cacheju". Pa ga vprašam ali se je odjavil ali ne. Reče da ja, ampak si je browser ziher nekako zapomnil da je bil on prej logiran.
Potem ležerno potegnem ven svoj laptop in ga vprašam, če se vsi strinjamo, da iz mojega laptopa nikoli ni bil nihče logiran v njihovo bazo.
Reče ja, nakar vklopim mašino in notri vpišem direktni URL... bingo, bil sem v bazi.
Tip se je dobesedno sesedel na stol, tako da sva z direktorjem že mislila klicati rešilca. Zadevo jim je programirala neka znanan firma, revizijo so dali delat drugi znani IT firmi, pa so oboji kompletno zajebali.
No, mi smo ugotovili kje je problem v pol re, potem smo rabili še ene pol ure, da smo spisali le report in 15 minut za račun. Moj najbolj easy-money...
Smiselno je seveda zate, ne za neukega naročnika.
Vodenje seje preko URLja seveda je opcija. Samo je treba imeti nekaj pameti in narediti tisto, kar pri session cookijih browser naredi avtomatsko. Ne recimo tako kot tisto znano dvorno slovensko IT podjetje, ki je za en precej velik državni organ v Sloveniji to izvedlo tako, da sem pred par meseci odkril kako s spremembo URLja ugrabit sejo in dostopat do kritično občutljivih podatkov tega državnega organa.
Ko sem jim zadevo predstavil (organu) so najprej eno uro lovili sapo, na koncu pa prišli do tega, da se zadevo da popraviti, jih bo pa pošastno drago stala. Popravek bo seveda delal dvorni IT ponudnik, ki je celo stvar že v osnovi zajeb**.
Na splošno ugotavljam, da v teh krajih ljudem ni jasno kaj je to avtentikacija in kako narediti varno spletno avtentikacijo.
Evo, ker sem dobre volje še en primer. Za enega naročnika sem delal varnostni pregled aplikacije. Podatki iz njihove baze se se znašli na spletu in ker so bili to podatki, ki jih je treba varovati po zakonu je bila seveda pizdarija.
JAsno - takoj so posumili na teorijo zarote. Prideva z direktorjem tja in rečem naročniku če pokaže spletno aplikacijo. Top gre na login page, vpiše u/p in se začne sprehajat po bazi.
Nakar tipa prosim, da se odjavi.
Sedem za računalnik in vpišem URL, ki je bil vpisan prej (ko je bil prijavljen). In padem seveda v bazo, ki sem jo lahko tudi spreminjal.
Rečem tipu da je problem v tem, da oni predvidevajo, da bo v bazo vsakdo skušal vstopiti zgolj skozi login page, če pa nekdo vpiše direkten URL pa oni predvidevajo, da je user ustrezno logiran (a tega ne preverjajo).
Pravi da ne, da je to zato, ker se je on prej logiral iz tega računalnika "in je nekaj ostalo v cacheju". Pa ga vprašam ali se je odjavil ali ne. Reče da ja, ampak si je browser ziher nekako zapomnil da je bil on prej logiran.
Potem ležerno potegnem ven svoj laptop in ga vprašam, če se vsi strinjamo, da iz mojega laptopa nikoli ni bil nihče logiran v njihovo bazo.
Reče ja, nakar vklopim mašino in notri vpišem direktni URL... bingo, bil sem v bazi.
Tip se je dobesedno sesedel na stol, tako da sva z direktorjem že mislila klicati rešilca. Zadevo jim je programirala neka znanan firma, revizijo so dali delat drugi znani IT firmi, pa so oboji kompletno zajebali.
No, mi smo ugotovili kje je problem v pol re, potem smo rabili še ene pol ure, da smo spisali le report in 15 minut za račun. Moj najbolj easy-money...
sudo poweroff
ABX ::
Citigroup suffered about US$2.7 million in losses ...
http://yro.slashdot.org/story/11/06/26/...
http://yro.slashdot.org/story/11/06/26/...
Vaša inštalacija je uspešno spodletela!
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Hekerji Citigroupu ukradli 2,7 milijona dolarjev, celotna škoda okrog sto milijonov dOddelek: Novice / Varnost | 7468 (6022) | poweroff |
| » | Marčevski napad na RSA kompromitiral žetone SecurIDOddelek: Novice / Varnost | 12729 (10680) | MyotisSI |
| » | Hekerji napadli CitigroupOddelek: Novice / Varnost | 6411 (5744) | amigo_no1 |
| » | Novi varnostni mehanizmi slovenskih bank (strani: 1 2 )Oddelek: Novice / Varnost | 11628 (8119) | CaqKa |
| » | Cool pc nagrada (strani: 1 2 )Oddelek: Pomoč in nasveti | 6214 (4730) | Raw |