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

 ( trey | 2014. január 4., szombat - 15:07 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

VMware-nel nem nagyon komaljak ezt a feltetelezest: "We have no reason to believe that the OpenSSL website defacement is a result of a security vulnerability in any VMware products and that the defacement is a result of an operational security error."

http://blogs.vmware.com/security/2014/01/recent-openssl-website-defacement.html

Persze nyilvan itt is valakit hibaztatni kell.

- "defacement is a result of an operational security error."
vö:
- "Our investigation found that the attack was made through insecure passwords at the hosting provider"

Most akkor én nem tudok olvasni vagy ők (vmware)?

Az még a linkelt txt korábbi verziójára hivatkozott: http://web.archive.org/web/20140102171315/https://www.openssl.org/news/secadv_hack.txt

BlackY

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.

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

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

Mi gátolná meg ebben?
--
zsebHUP-ot használok!

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

Viruális gépek ezek.
--
zsebHUP-ot használok!

"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ő.

Elég, ha újra tudta indítani a gépet és nem volt boot védelem / lemeztitkosítás / anyámkínja. Onnan root-ot szerezni nem nagy kunszt.

--
trey @ gépház

+ legtöbb esetben ott a beépített rootkit: a vmware tools. :)

--
zrubi.hu

+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!

Igen, erre gondoltam. Én vagyok naív, hogy "komolyabb" körökben alapnak tartom a lemeztitkosítást? :)

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.

irány a gépterem? hát akkor minek van vnc konzol és hasonló?

Virtuálisan értettem... :)
(nekem jó tíz éven át még a gépterembe kellett rohangálni, ha valami ilyen gond volt)
Lényeg, hogy kell valaki, aki be tudja bootolni a gépet.

Két szervernél ez még poén, 1000-nél már nem annyira:)


// Happy debugging, suckers
#define true (rand() > 10)

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!

Minden adatot cloudba!:)


// Happy debugging, suckers
#define true (rand() > 10)

"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 memóriát nem kell nagyon piszkálni, csak kiolvasni.
+ a (vmware) toolok
+ miután fut a szerver (jelen esetben) egyátalán nincs jelentősége hogy titkosított az FS vagy sem.

Ez asszem bőven elég :)

--
zrubi.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

Ha csak a disken lévő adatot látod, és azon belül titkosított fs van, akkor normáls esetben (egyéb sérülékenység hiányában) nem látsz bele a tartalmába.

De egy ilyen korlátozott hozzáférés (és a feltételeid) nem túl életszerű.

--
zrubi.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

open-vm-tools = a vmwaretools előre fordított változata az adott disztibúciókhoz/kernelhez.

De exploit ellen egyik sem véd. Ő maga teszi lehetővé a VM-ek kényelmes kezelését.

--
zrubi.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

Én nem mondtam azt, hogy a host teljhalamú ura nem tud ilyet csinálni, dehogy nem tud... de ha a másolás-beillesztés nem csal, akkor "illetéktelenek hozzáférhettek a hypervisor menedzsment konzoljához". Gondolom ez a konzol csak nem tud ilyet

Ahogy ezt már a többiek is írták: "azellen nem véd" ;)

--
zrubi.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

A VirtualBox GUI-ja megfelel a menedzsment konzolnak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Encrypted FS a megoldás.
--
PtY - www.onlinedemo.hu

Sajnos nem megoldas. Lasd a szalat feljebb.

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.

Esély mindenre van. :)
--
PtY - www.onlinedemo.hu

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

A MEDVE NEM JÁTÉK!
3 ÉVES KOR ALATT NEM AJÁNLOTT, MERT LENYELHETI AZ APRÓ RÉSZEKET.
MADE IN CHINA

:)

Nem kell felni, nem bant a maci, csak kicsit megkostol... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.