Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Csúnya sebezhetőségeket javítottak az Amazon webszolgáltatásaiban

2011.10.30. 08:00 | buherator | 3 komment

Német kutatók súlyos hibákat fedeztek fel az Amazon Web Services-ben és az Ubuntu cloudjában is használt Eucalyptus platformban. A legkritikusabb - azóta már javított - sebezhetőségek ún. XML Signature Wrapping támadásokra adtak lehetőséget. Ezek a szolgáltatások SOAP interfészeit érintették, melyeken keresztül a felhasználók aláírt XML üzenetket használva adhattak parancsokat.

xml_sigwrap_orig.jpg

Ilyen esetben a SOAP fejléc tartalmazza az aláírást, egy időbélyeget és egy hivatkozást a hitelesített üzenettörzsre. A kutatók az utóbbi két komponens többszörözésével illetve az XML fán belüli átmozgatásával kezdtek el játszani, sikerrel. Mint kiderült, dupla üzenettörzs esetén az Amazon szolgáltatása az egyik példányt használta az aláírás ellenőrzéséhez, míg a másikat értelmezte és hajtotta végre. Így egy aláírt üzenet birtokában, az aláíró felhasználó nevében tetszőleges parancs végrehajtható volt. Azaz majdnem, ugyanis az időbélyeg (ami szintén hitelesítésre kerül) öt percet hagy a cselekvésre, ami nem mindig elegendő: az aláírt üzenetek beszerzésének egyik legegyszerűbb módja a fejlesztői fórumok túrása, ahol túlnyomó részt csak rég lejárt üzeneteket találunk. 

xml_sigwrap_t1.jpg

De semmi gond, az időbélyeg mezővel is el lehet játszani ugyanezt: ha két ilyen adat szerepel a fejlécben, az aláírás ellenőrzése az egyik figyelembevételével történik meg, míg a lejárat ellenőrzése a másikkal. Mikor a kutatók először jelezték a problémát az Amazonnak, az élelmes programozók úgy módosították a webszolgáltatást, hogy dobjon vissza minden üzenetet, amiben dupla időbélyeg fejléc szerepel. A gond az volt, hogy a második időbélyeg mezőt a duplikált üzenettörzsbe helyezve, vagy magát a fejlécet duplikálva újra meg lehetett kerülni az ellenőrzést.

xml_sigwrap_t2.jpg

De ezzel nincs vége a problémáknak: amennyiben ugyanis a SOAP üzenet nem került aláírásra, a felhasználó azonosítása és autentikációja pusztán az üzenetbe ágyazott (nyilvános!!!) X.509 tanúsítvány alapján történt meg. Erre már nincsenek szavak.

Az Eucalyptus esetében kicsit bonyolultabb volt a helyzet: itt az eredeti időbélyeget és üzenettörzset a SOAP séma betartása érdekében egy <wsse:Security> elem alá kellett helyezni, a valódi törzset ez után tetszőlegesen lehetett módosítani.

xml_sigwrap_euc.jpg

Az elemzésben még szó esik néhány XSS problémáról is, ezeket is javították, bár érdekes kérdés az Eucalyptus esetében, hogy vajon az ezen a platformon működő privát felhőket mikor fogják frissíteni?

Kis adalék a fentiekhez, hogy az AWS egys terheléselosztó hibája miatt nem rég 2 millió, Netflixnek szánt kérést egy másik felhasználóhoz irányított - kíváncsi vagyok mennyi bizalmas infót tartalmazott az adatofolyam!

Címkék: amazon cloud webservice aws soap eucalyptus web service iaas

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Aron bacsi 2011.10.30. 21:21:42

Átolvastam a cikket, de ez több sebből is vérzik, abban sem vagyok biztos, hogy itt a fejlesztők voltak a hibásak. Eleve az milyen XML parser lehet, amely a szabvánnyal ellentétben enged több "soap:Body" elemet? Arról nem is beszélve, hogy az "Id" típusú attribútumnak abban a névtérben egyedinek kellene lennie? Az XMLSpy nem tudott nekem ilyen üzeneteket létrehozni, mert a séma-validáción nem mentek át! Szóval, még az is lehet, hogy jó volt a programozók által fejlesztett kód az XML-DSIG feldolgozásra is, csak nem tudták, hogy az alatta levő rétegben az XML parser library, amivel dolgoznak elég barom módon működik...

buherator · http://buhera.blog.hu 2011.10.31. 11:14:17

@Aron bacsi:

Ezeket még én sem olvastam, de úgy nézem leírják a tipikus implementációs hibákat, amik ide vezetnek:

www.nds.rub.de/media/nds/downloads/mjensen/ICWS09.pdf

domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/

Ha jól emlékszem, egy csomó parser alapból nem foglalkozik a sémával. Viszont a fejlesztőnek ismernie kéne annyira az API-t, hogy be tudja kapcsolni a validációt (és az sem árt, ha tudja mire való). Szerintem.

Aron bacsi 2011.10.31. 13:09:39

@buherator: Mondjuk mi csak DOM-os parser-eket használtunk, de ott mind a Java, mind a .NET cuccai jók voltak, sémákat lehet (kell is) használni létrehozásnál és validálásnál egyaránt. Esetleg a SAX-osoknál lehet olyan, hogy a sémát nem nézik, ezt nem tudom...