Részletek az openssl.org elleni támadással kapcsolatban

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

Ahogy arról pár nappal ezelőtt beszámoltunk, az OpenSSL projekt webszerverét támadás érte, amelynek során a weboldalt deface-elték. Az OpenSSL projekt a támadás észlelése után közvetlenül gyors vizsgálatot tartott és arra jutott, hogy a forráskód-tárolók nem érintettek. Részleteket későbbre ígéretek.

Az ígéretnek megfelelően megérkezett a tájékoztatás. A részletesebb vizsgálat a következő eredményt hozta: az OpenSSL projekt webszervere egy virtuális szerver, amely ugyanazon internetszolgáltató ügyfélkörével osztozik egy hypervisor-on. A szolgáltató nem biztonságos jelszavakat használt, ami azt eredményezte, hogy illetéktelenek hozzáférhettek a hypervisor menedzsment konzoljához és onnantól kezdve manipulálni tudták az OpenSSL projekt virtuális gépét.

Az OpenSSL projekt újból megerősítette, hogy a forráskód-tárolók érintetlenek, azaz illetéktelenek ahhoz nem fértek hozzá. A támadók azon kívül, hogy lecserélték a weboldal index.html oldalát, semmi más változtatást nem csináltak. Sem operációs rendszer oldali, sem OpenSSL sebezhetőség nem játszott szerepet a támadás során.

Részletek a bejelentésben.

( Fisher v | 2014. 01. 05., v – 12:15 )

Hát igen, a leggyengébb láncszemen múlik a lánc erőssége.

Mindegy, szerintem a VMware-nek muszaj volt megszolalnia, hogy a virtualizacio tovabbra is fasza... Mert lassuk be, majdnem mindegy, hogy milyen termekekrol van szo, ez az egesz story egy eleg nagy ellenerv a cloud megoldasokra. Nem azt mondom, hogy egy mindent elsopro erv, de azert egy erv.... fognak meg erre az esetre hivatkozni.

( zrubi v | 2014. 01. 06., h – 10:36 )

Azért a szolgáltató megbírna némi fikázást/meghurcolást egy ilyen miatt...

(persze gondolom az átlagügyfél pont leszarja, akiknek meg preztízs kérdés annak meg érdeke tagadni, hogy valaha is történt ilyesmi)

--
zrubi.hu

( manfreed (nem ellenőrzött) | 2014. 01. 06., h – 11:38 )

Azért az is szép, hogy a szolgáltató bele tud nyúlni a virtuális gépbe.

Aki a hypervisor-t üzemelteti, az technikailag bármit megtehet a rajta futó virtuális gépekkel, amit csak nem szégyell.

Amióta VMware-rel foglalkozom (persze ez bármelyik virtualizációs technológiára igaz), azt szajkózom, hogy minden bizalom kérdése, ami akkor domborodik ki igazán, ha a VM-ek és a hypervisor különböző üzemeltetőkhöz tartozik --> tehát hosting esetén.

Eddig is az volt, de virtuális környezetben ez nagyságrendileg változik. És akkor még arról nem is beszéltünk, hogy az ügyfelek egymással milyen viszonyba kerülnek ilyen esetben.

Persze marketinggel és occsósítással mindent el lehet feledtetni... ;)

--
zrubi.hu

"Aki a hypervisor-t üzemelteti, az technikailag bármit megtehet a rajta futó virtuális gépekkel, amit csak nem szégyell."

De miért? Hogyan? Itt ugye arról volt szó hogy management konzolhoz fértek hozzá. Miket tud egy ilyen konzol? Bocsi, nem láttam még ilyet. Itthon virtualboxozok, gondolom aligha nevezhető egy lapon a kettő.

+1 Ez a legkényelmesebb, a shell exec API-ra ki van vezetve.

De ha nincs fenn a tools, akkor lehet még syscall trappeléssel is játszani (~remote debug), valamint a guest memóriaképbe belepiszkálással is, de ezekhez azért érteni is kell.
---
Régóta vágyok én, az androidok mezonkincsére már!

Szerveren kicsit macerásnak tűnik az ötlet.
Vagy "bedrótozod" valahova a titkosításhoz használt jelszót és akkor ott vagy, ahol a part szakad vagy indításkor kell megadni, de akkor minden boot humán felügyeletet igényel. És ha történik egy áramkimaradás, ami még redundáns szünetmentes mellett is előfordulhat, mint az közismert ( :D ), akkor máris ugrasztani kell az ügyeletest, hogy irány a gépterem, mert jelszó kell a boothoz.

Nem, inkább azért vagy naív, mert azt gondolod, hogy ha egy guestben diszket titkosítanak, attól még a host teljhatalmú ura nem fér hozzá az adathoz. :)
Kb. mintha minden reggel az első szembejövőnek odaadnád a lakáskulcsod, hogy estig őrizze, akkor majd be szeretnél menni vele.
--
zsebHUP-ot használok!

"azt gondolod, hogy ha egy guestben diszket titkosítanak, attól még a host teljhatalmú ura nem fér hozzá az adathoz"
Erről mesélhetnél nagy általánosságban is. Ha csak a virtuális gép memóriájának piszkálására és az esetleges host-guest toolok sebezhetőségének a dolgaira gondoltál, akkor értem, és jogos, de ha ezen túl is van érved, az érdekelne.
--
PtY - www.onlinedemo.hu

A toolok és a memória egy dolog - ettől tekintsünk el.
Ha fut a gép, attól még a disken az adat titkosítva van. Hogyan is lehet azokhoz hozzáférni ha nem piszkáljuk a memóriáját, és/vagy nem használunk ki host-guest tool sérülényenységeket?
Engem csak ez érdekel - lehet, hogy nem volt egyértelmű az előző posztom...
--
PtY - www.onlinedemo.hu

Tudom, csak arra voltam kíváncsi, hogy ha a host megfelelően védett, akkor van-e egyéb trükk, amivel számolni kell.
Amúgy pont az ilyen host-guest toolok miatt szeretem a KVM-et.

btw. vmware-tools. Az open-vm-tools használata mennyivel ad esetleg jobb védelmet az exploitok ellen (az eredeti vmware toolshoz képest)?
--
PtY - www.onlinedemo.hu

Nem értetted a kérdésem.
Egyrészt nem azonos az open-vm-tools a vmware-tools-szal.
Utóbbiban sokkal több feature van, előbbiben csak azok a funkciók, amik OSS alapon elérhetőek voltak.
Innentől kezdve nagyon nem mindegy, hogy melyik változatban mennyi sérülékenységet lehet kihasználni, amivel a futó VM esetleg mérgezhető/átvehető.
Tehát a kérdés az, hogy melyik használata esetén nagyobb az esélye annak, hogy valahol belenyúlnak, ha a hostra bajutnak.

Értsd:
több feauture == több lehetőség
vagy
vmware termék == megbízhatóbb
vagy
oss == megbízhatóbb
--
PtY - www.onlinedemo.hu

Hasonló az otthoni gépedhez: Ott Te is hozzáférsz bármelyik virtuális gépedhez, nem??

Management konzol: az a cucc, amivel magát a hypervisort (sőt, cluster esetén többet egyszerre), és ezen keresztül a rajta futó összes gépet birizgálhatod...

--
zrubi.hu

Miért is?
Mikor nagyobb az esélye annak, hogy belenyúlnak az adataimba?
Ha harmadik félnél tartom a vm-em, és nem használok encfs-t, vagy ha ugyanez, csak van encfs?

Ilyen alapon, ha bármi feltörhető, akk hülyeség password123-on kívül más jelszót adni a root-nak?
Elég érdekes hozzáállás.
--
PtY - www.onlinedemo.hu

Igen, az eselyt valoban csokkented (ezert szerintem is jo otlet titkositott lemezt hasznalni), de a megoldas nem teljes.

A titkositas feloldasahoz hasznalt kulcsot ugyanis valamikor be kell vinned, es ezt is elkaphatjak. Persze erre mondhatod, hogy azt mar ssh-n (vagy barmi mas encriptalt csatornan) csinalod, titkositva, na de mikor az eslo ssh session-t inditod ok mar vonalban lehetnek.

( PtY | 2014. 01. 07., k – 08:53 )

Közös lónak túrós a gazdája.
Ezért kell saját infrastruktura, hogy a rajtad kívül álló tényezőket a minimálisra csökkentsd. Szolgáltató idióta biorobotja miatt rohadt nagy károk is lehettek volna.

A MEDVE NEM JÁTÉK!
--
PtY - www.onlinedemo.hu