Újabb, több böngészőt érintő sebezhetőségre hívják fel a figyelmet a szakemberek

Titkosítás, biztonság, privát szféra

Biztonsági szakemberek egy újabb, ijesztőnek tűnő böngésző exploitra/sebezhetőségre hívják fel a figyelmet. A probléma az összes nagyobb platformot - Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Opera és Adobe Flash - érinti. A "Clickjacking" névre hallgató sebezhetőségről eredetileg az OWASP NYC AppSec 2008 konferencián esett volna szó, de az Adobe és más érintett gyártók kérésére az előadást törölték, amíg megfelelő javítás nem érkezik a problémára.

A Clickjacking sebezhetőség felfedezése mögött álló Robert Hansen és Jeremiah Grossman információ morzsákat adtak közre a problémáról. Az egyik, konferencián résztvevő szerint a sebezhetőség valóban 0day.

Grossman megerősítette, hogy az Internet Explorer és a FF legújabb verziói egyaránt érintettek.

A népszerű FF bővítmény, a NoScript fejlesztője szerint is "valóban ijesztő" a probléma, de a korábban napvilágot látottakkal ellentétben nem igaz, hogy a NoScipt nem tud védelmet nyújtani. A fejlesztő szerint a NoScript alapértelmezett beállításokkal is képes a lehetséges támadások nagy részét ártalmatlanítani, azonban a teljes védelemhez szükséges a bővítmény "Plugins|Forbid <IFRAME>" opciójának bekapcsolása.

További részletek itt.

( 4fonya | 2008. 09. 28., v – 18:28 )

a teljes védelemhez szükséges a bővítmény "Plugins|Forbid

" opciójának bekapcsolása

Még jó hogy alapból így használom. :-) FF-3.0.3 van.
Valahogy olyan ez az egész mint a golyó és a páncél "versenyfutása". Nem lesz addig vége amíg akad olyan valaki aki másnak vagy másban kárt akar tenni. :-(

( 4fonya | 2008. 09. 28., v – 18:33 )

Már látom: Firefox 3.0.4, 3.0.5, 3.0.6, 3.0.7, 3.0.8, 3.0.9, 3.0.10 .......

Egyébként arra gondoltam hogy most kijavítják a hibát és lesz 3.0.4 belőle. Két nap múlva valaki talál egy újabb hibát -> javítás -> 3.0.5. Aztán megint hiba és megint javítás ........ Olyan ez mint a végtelen mese. Gondolom hogy azért valahol a 3.0.115627 környékén abbahagyják az egészet és inkább elmennek kapálni.

( tomsolo | 2008. 09. 28., v – 19:28 )

azt ugye vágja mindenki, hogy javascript nélkül ilyen vicces dolgok nem történnek meg.

ezek szerint lynx(és társai) a legbiztonságosabb böngészők? :)

"A very intelligent turtle, found programming UNIX a hurdle
The system, you see ran as slow as did he,And that’s not saying much for the turtle."

> telnet host 80 - na ez eddig 100% proven secure

Naiv lélek...

Úgy látszik, nem láttál még escape szekvenciát, ami átállítja a színeket, átkapcsol alternatív betűkészletre (olvashatatlan krix-kraxokra), átméretezi a terminál ablakot, átírja a terminál ablak címét, majd a sztori megkoronázásaként a terminál új címét egy szép kis escape szekvencia formájában beleküldi a billentyűpufferbe, pont mint ha te gépelted volna be.

(Emulátora válogatja, hogy a fentiek melyike működik és melyik nem.)

Sőt, van egy még izgalmasabb ötletem is... kizárólag elvi síkon.

Szóval "telnet host 80"-nal leszedsz egy honlapot. A rosszindulatú webszerver megpróbálja megtippelni a:

- usernevedet (finger, ident (tudom, elavultak, manapság nincsenek ilyenek), vagy ha pl. loginos site-ra lépsz be (itt a cookie rész telnettel az nem tiszta, de valahogy nyilván megoldod), akkor betippeli, hogy ugyanaz,
- gépnevedet (reverse dns),
- oprendszeredet (port scan),
és ezek alapján megpróbálja megtippelni, hogy a promptod hogyan néz ki. Lehet hogy nagyon szar az algoritmus, és 1000-ből egyszer jön csak be, de nézzük azt, amikor bejön.

Szóval a rosszindulatú szerver kiküldi látszólag a helyes adatot, a végén a promptodat, és vár. Te meg át vagy verve, azt hiszed, hogy az az igazi promptod. Megint kell egy mázlifaktor, de tegyük fel, hogy épp akkora peched van, hogy egy "ssh user@gépnév" parancsot gépelsz be következőnek, ami eljut a rosszindulatú webszerverhez, ő visszaküldi hogy "Password: ", te meg gépeled is be neki a jelszavadat (oké, local echo, megint egy apró buktató, de tegyük fel hogy gyorsan gépelsz és ütöd az entert reflexből és csak utána esik le hogy valami nem stimmelt). A jelszó meg máris ott van a rosszindulatú támadónál.

Szóval tessék elfelejteni, hogy a "telnet 80" biztonságos! :-)

Nem nyert (legalábbis OS X alatt, ahol most vagyok). Aszongya:
-E Stops any character from being recognized as an escape character.
csakhogy a telnet a válaszban nem foglalkozik az escape karakterek jelentésével, küldi ki őket simán a stdout-ra. Gondolom ez az opció az inputra vonatkozik. Vagy nem tudom mire. Mindenesetre a http válaszban lévő escape-eket változatlanul küldi ki a terminálra, próbáld ki.

Tipp1: Epp valakinek a szejjelhekkelt Mac-et javitgatja, es kozben forumozik.
Tipp2: Leitatta Gabu, o meg reszegen vett egy ilyen gepet.
Tipp3: A HUP "Bekuldes" gombja igazabol egy iframe-ben van, es egy rosszindulatu kod az elkuldes pillanataban JS-el replace-elte az UHU-t OS X-re.

Large Hadron Collider :)
honlapkészítés

Én arra gondoltam, hogy a kívánt információt sha256-al kódolva kapod vissza. Van rá 10 másodperced hogy fejbe visszafordítsd és a megfelelő választ megadd ellenkező esetben a telnet automatikusan zárja a kapcsolatot :-)

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

azt ugye vágja mindenki, hogy javascript nélkül ilyen vicces dolgok nem történnek meg.
Hát a cikkek szerint ez nem igaz, pont azt mondják, hogy a javascript ehhez egyáltalán nem szükséges.

DE valaki plíz magyarázza már el nekem, hogy ez pontosan hogy is működik, mert az összes cikkben mást sem szajkóznak, minthogy "it's not little bad, it's a lot bad", meg hogy "it's really spooky", de konkrét technikai részletet még sehonnan sem sikerült kiszednem.
---
Linux is bad juju.

Hát a cikkek szerint ez nem igaz, pont azt mondják, hogy a javascript ehhez egyáltalán nem szükséges.

"In the meantime, the only fix is to disable browser scripting and plugins. "
http://jeremiahgrossman.blogspot.com/2008/09/cancelled-clickjacking-owa…

leegyszerűsítve arról van szó - biztonsági szempontból - hogy az összes fennt említett böngészőben nincs mód arra hogy egy iframe elemet biztonságosan lehessen kezelni és ne lehessen vissza élni vele...
a felhasználó nem lehet benne biztos hogy amire klikkel/beír az tényleg az adott laphoz tartozik-e... vagy pedig egy oda feszített iframe be ír/klikkel...

mondjuk minnél többet gondolkodok arra jutok, hogy ez eléggé túlliheget történet...

"A very intelligent turtle, found programming UNIX a hurdle
The system, you see ran as slow as did he,And that’s not saying much for the turtle."

szerintem nem az. Fentebb linkelgettek egy példaoldalt, az azért eléggé meggyőző szerintem. Tény, hogy a módszer kábé az előszoba kitapétázása a kulcslyukon keresztül, viszont a rosszándékú emberek ügyesen tapétáznak. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

de ez a az egész a vizuális megtévesztésre épül... a fenti példa máris nem működik illetve lebukik ha:

- random változik a myspace profil formjának dizájnja/struktúrája
- user piszkálgatja betűméretet, megjelenést
- saját stylus lapot használ
- nem használ stílus lapot

"A very intelligent turtle, found programming UNIX a hurdle
The system, you see ran as slow as did he,And that’s not saying much for the turtle."

jah. majd védekezünk ellene vizuális megtévesztésen alapuló védelemmel: postitet rakunk a képernyő sarkára, de nem a jelszavunk lesz rajta;)

amint fentebb említették, az általad említett példák nem jellemzőek, és egy elég jól menő oldallal sokakat meg lehet téveszteni. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd