od SeerLight
Každá služba musí zahrnovat neustálou práci na zabezpečení. Zabezpečení je trvalý proces, který zahrnuje neustálou analýzu a zlepšování ochrany produktu, sledování novinek o zranitelnostech a mnoho dalšího. Zahrnuje i audity. Audity provádějí jak interní specialisté, tak externí odborníci, kteří mohou zásadně přispět k zabezpečení, protože nejsou ponořeni do projektu a mají nezaujatý pohled.
Článek pojednává o zmíněném nezaujatém pohledu externích odborníků, kteří pomohli týmu Mail.ru Cloud Solutions (MCS) otestovat cloudovou službu, a o tom, co objevili. Jako 'externí síly' MCS zvolila společnost Digital Security, známou svou vysokou odborností v oblasti kybernetické bezpečnosti. V tomto článku se zaměříme na některé zajímavé zranitelnosti nalezené v rámci externího auditu — abyste se vyhnuli podobným problémům, když budete vytvářet svou vlastní cloudovou službu.
Popis produktu
ochrana infrastruktury virtuálního prostředí: hypervizory, směrování, firewally;
- ochrana virtuální infrastruktury zákazníků: vzájemná izolace včetně sítě, soukromé sítě v SDN;
- OpenStack a jeho otevřené komponenty;
- S3 vlastní výroby;
- IAM: multitenantní projekty s rolovým modelem;
- Vision (strojové vidění): API a zranitelnosti při práci s obrázky;
- webové rozhraní a klasické webové útoky;
- zranitelnosti komponentů PaaS;
- API všech komponent.
- Snad z podstatného pro další příběh — vše.
Jaké práce byly provedeny a proč jsou potřebné?
Audit zabezpečení má za cíl odhalit zranitelnosti a chyby v konfiguraci, které mohou vést k úniku osobních údajů, modifikaci citlivých informací nebo k narušení dostupnosti služeb.
Bezpečnostní audit se zaměřuje na odhalování zranitelností a chyb v konfiguraci, které mohou vést k úniku osobních údajů, modifikaci citlivých informací nebo k porušení dostupnosti služeb.
Během postupů, které obvykle trvají 1-2 měsíce, auditoři simulují akce potenciálních útočníků a hledají zranitelnosti v klientské a serverové části vybraného služeb. V kontextu auditu cloudové platformy MCS byly stanoveny následující cíle:
- Analýza autentizace v službě. Zranitelnosti v této komponentě by okamžitě umožnily přístup k cizím účtům.
- Zkoumání rolové modely a rozdělení přístupu mezi různými účty. Pro útočníka by možnost získat přístup k cizím virtuálním strojům byla žádoucí cílem.
- Zranitelnosti klientské části. XSS/CSRF/CRLF/atd. Existuje možnost napadnout jiné uživatele prostřednictvím škodlivých odkazů?
- Zranitelnosti serverové části: RCE a různé injekce (SQL/XXE/SSRF a tak dále). Serverové zranitelnosti jsou obvykle těžší k nalezení, ale mohou vést ke kompromitaci mnoha uživatelů najednou.
- Analýza izolace uživatelských segmentů na úrovni sítě. Pro útočníka absence izolace výrazně zvyšuje povrch útoku na ostatní uživatele.
- Analýza obchodní logiky. Je možné podvést obchod a vytvářet virtuální stroje zdarma?
V tomto projektu byly práce prováděny podle modelu 'Gray-box': auditoři spolupracovali se službou s oprávněními běžných uživatelů, ale částečně měli k dispozici zdrojový kód API a mohli si vyjasnit detaily s vývojáři. Obvykle je to nejoblíbenější a zároveň dost realistický model práce: interní informace mohou být stejně tak shromážděny útočníkem, jde jen o otázku času.
Nalezené zranitelnosti
Než auditor začne posílat různé payloady (užitečné zatížení, pomocí kterého se provádí útok) na náhodná místa, je nutné pochopit, jak co funguje, jaké funkce jsou k dispozici. Může se zdát, že to je zbytečná činnost, protože ve většině prozkoumaných míst žádné zranitelnosti nebudou. Ale pouze pochopení struktury aplikace a logiky jejího fungování umožní nalézt ty nejkomplexnější vektory útoků.
Je důležité najít místa, která vypadají podezřele nebo se výrazně liší od ostatních. A první nebezpečná zranitelnost byla nalezena právě tímto způsobem.
IDOR
IDOR zranitelnost (Insecure Direct Object Reference, nezabezpečené přímé odkazy na objekty) je jedním z nejběžnějších typů zranitelností v obchodní logice, který umožňuje různými způsoby získat přístup k objektům, k nimž ve skutečnosti přístup není povolen. IDOR zranitelnosti vytvářejí možnost získání informací o uživatelských datech různé kritičnosti.
Jednou z variant IDOR je provádění akcí s objekty systému (uživateli, bankovními účty, zbožím v košíku) prostřednictvím manipulace s identifikátory přístupu k těmto objektům. To vede k velmi nepředvídatelným důsledkům. Například to může umožnit náhradu účtu odesílatele peněz, což umožňuje krást peníze od ostatních uživatelů.
V případě MCS auditoři skutečně objevili IDOR zranitelnost spojenou s nezabezpečenými identifikátory. V uživatelském rozhraní pro přístup k jakýmkoli objektům byly použity identifikátory UUID, které se zdály být, jak říkají bezpečnostní experti, ohromně neprolomitelné (tj. chráněné před útokem hrubou silou). Ale u některých entit bylo zjištěno, že pro získání informací o uživatelích aplikace se používají běžná předvídatelná čísla. Myslím, že tušíte, že by bylo možné změnit ID uživatele o jednu jednotku, znovu odeslat žádost a tímto způsobem získat informace obejitím ACL (access control list, pravidel přístupu k datům pro procesy a uživatele).
Server Side Request Forgery (SSRF)
OpenSource produkty jsou dobré tím, že o nich existuje obrovské množství fór s podrobným technickým popisem vznikajících problémů a, pokud máte štěstí, s popisem řešení. Ale tato mince má i svou odvrácenou stranu: také známé zranitelnosti jsou podrobně popsány. Například na fóru OpenStack existují vynikající popisy zranitelností. a , které nikdo nejeví spěch na opravu.
Častá funkčnost aplikací — možnost pro uživatele odeslat na server odkaz, na který server přechází (například aby načetl obrázek z uvedeného zdroje). Při nedostatečném filtrování prostřednictvím bezpečnostních prostředků samotných odkazů nebo odpovědí vracených serverem uživatelům, mohou tohoto funkce snadno zneužít útočníci.
Zranitelnosti SSRF mohou výrazně urychlit postup útoku. Útočník může získat:
- omezený přístup k napadené místní síti, například pouze k určitým segmentům sítě a pomocí určitého protokolu;
- úplný přístup k místní síti, pokud je možné downgrading z úrovně aplikací na úroveň transportu a tím pádem úplnou kontrolu nad zátěží na úrovni aplikací;
- přístup k načítání místních souborů na serveru (pokud je podporována schéma file://);
- a mnoho dalšího.
V OpenStacku je již dlouho známá zranitelnost SSRF, která má "slepotu": při volání serveru neobdržíte odpověď, ale dostanete různé typy chyb/zpoždění na základě výsledku požadavku. Na základě toho je možné provádět skenování portů na hostitelích ve vnitřní síti, se všemi následky, které je třeba podceňovat. Například produkt může mít API pro back-office, dostupné pouze z korporátní sítě. Pokud máte dokumentaci (nezapomínejte na insiderství), může útočník pomocí SSRF volat interní metody. Například, pokud se nějakým způsobem podařilo získat přibližný seznam užitečných URL, je možné cestou SSRF na ně projít a provést žádost — a to podmínečně znamená převést peníze z účtu na účet nebo upravit limity.
To není první případ nalezení zranitelnosti SSRF v OpenStack. V minulosti byla možnost nahrávat ISO obrazy VM prostřednictvím přímého odkazu, což také vedlo k podobným důsledkům. V současné době byla tato funkce z OpenStack odstraněna. Je zřejmé, že komunita to považovala za nejjednodušší a nejspolehlivější řešení problému.
A v V veřejné zprávě ze služby HackerOne (h1) využití již ne-slepého SSRF s možností čtení metadat instance vede k získání Root přístupu k celé infrastruktuře Shopify.
V MCS byly na dvou místech se podobnou funkcionalitou nalezeny zranitelnosti SSRF, ale prakticky je nebylo možné využít kvůli firewallům a jiným ochranným opatřením. Tak či onak, tým MCS tuto problematiku stejně opravil, aniž by čekal na komunitu.
XSS místo nahrávání "shellů"
Navzdory stovkám napsaných studií zůstává ročně XSS (útok mezisítového skriptování) stále webovou zranitelností (nebo ?).
Nahrávání souborů je oblíbené místo pro každého bezpečnostního výzkumníka. Často je možné nahrát libovolný skript (asp/jsp/php) a vykonávat příkazy operačního systému, což penta-testéři nazývají „nahrát shell“. Ale popularita těchto zranitelností funguje oběma směry: celou dobu se na ně pamatuje a vyvíjí se proti nim nástroje, takže v poslední době se pravděpodobnost „nahrát shell“ blíží nule.
Útočící tým (v podání Digital Security) měl štěstí. Dobře, na straně serveru v MCS se kontroloval obsah nahrávaných souborů, povoleny byly jen obrázky. Ale SVG je také obrázek. Jak mohou být SVG obrázky nebezpečné? Tím, že lze do nich vkládat fragmenty JavaScriptu!
Ukázalo se, že nahrávané soubory jsou dostupné všem uživatelům služby MCS — to znamená, že lze útočit na ostatní uživatele cloudu, konkrétně na administrátory.
Příklad vkládání pomocí XSS útoku phishingového formuláře pro přihlašování
Příklady využití XSS útoku:
- Proč se pokoušet ukrást relaci (o to víc, že nyní jsou všude HTTP-Only cookies, chráněné proti krádeži pomocí js skriptů), když může nahraný skript ihned kontaktovat API zdroje? V tomto případě může užitečné zatížení přes XHR požadavky změnit konfiguraci serveru, například přidat otevřený SSH klíč útočníka a získat SSH přístup na server.
- Pokud CSP politika (politika ochrany obsahu) zakazuje vkládání JavaScriptu, útočník se může obejít bez něj. Na čistém HTML vytvořit falešný přihlašovací formulář na stránky a ukrást heslo administrátora prostřednictvím takového pokročilého phishingu: phishingová stránka pro uživatele se ocitá na stejné URL a uživatel ji hůře odhalí.
- Nakonec může útočník způsobit — nastavit cookies větší než 4 kB. Uživatelovi stačí jednou otevřít odkaz — a celá stránka se stává nedostupnou, dokud se nezjistí, že je třeba speciálně vyčistit prohlížeč: ve většině případů se webový server odmítne přijmout takového klienta.
Zvážíme příklad dalšího odhaleného XSS, tentokrát s rafinovanějším využitím. Služba MCS umožňuje seskupovat nastavení firewallu. V názvu skupiny byla nalezena XSS. Její zvláštností bylo, že vektor nefungoval ihned, ne při prohlížení seznamu pravidel, ale při mazání skupiny:
To znamená, že scénář byl následující: útočník vytvoří pravidlo firewallu s "nákladem" v názvu, správce si ho po nějaké době všimne a zahájí proces odstranění. A právě v tu chvíli škodlivý JavaScript začne fungovat.
Pro vývojáře MCS, aby se chránili před XSS v nahrávaných SVG obrázcích (pokud se jich nelze vzdát), tým Digital Security doporučil:
- Umístit soubory nahrávané uživateli na samostatnou doménu, která nemá nic společného s "cookies". Skript bude vykonáván v kontextu jiné domény a nebude představovat hrozbu pro MCS.
- Ve HTTP odpovědi serveru vrátit hlavičku "Content-disposition: attachment". Pak budou soubory stahovány prohlížečem, a ne vykonávány.
Kromě toho je nyní k dispozici mnoho způsobů, jak zmírnit rizika exploatace XSS pro vývojáře:
- pomocí příznaku "HTTP Only" lze učinit relace "Cookies" nedostupnými pro škodlivý JavaScript;
- výrazně ztíží exploataci XSS pro útočníka;
- moderní šablonovací nástroje, jako jsou Angular nebo React, automaticky čistí uživatelská data před vykreslením v prohlížeči uživatele.
Zranitelnosti dvoufaktorové autentizace
Pro zvýšení bezpečnosti účtů se doporučuje uživatelům vždy zapnout 2FA (dvoufaktorovou autentizaci). Opravdu je to efektivní způsob, jak zabránit útočníkovi získat přístup ke službě, pokud byly uživatelské údaje kompromitovány.
Ale dává použití druhého faktoru autentizace vždy záruku ochrany účtu? V implementaci 2FA mohou nastat takové bezpečnostní problémy:
- Hrubé uhádnutí OTP kódu (jednorázových kódů). Navzdory jednoduchosti exploatace se takové chyby, jako je absence ochrany proti brutálním útokům na OTP, vyskytují i u velkých společností: , .
- Slabý algoritmus generování, například možnost předvídat další kód.
- Logické chyby, například schopnost požádat o cizí OTP na svůj telefon, jako je to ve Shopify.
V případě MCS je 2FA implementována na základě Google Authenticator a . Samotný protokol již prošel testem času, ale implementaci kontroly kódu na straně aplikace je nutné ověřit.
V MCS se 2FA používá na několika místech:
- Při autentizaci uživatele. Není zde ochrana proti hrubé síle: uživatel má k dispozici pouze několik pokusů pro zadání jednorázového hesla, poté je zadání na určitou dobu zablokováno. To blokuje možnost provedení hrubé síly pro OTP.
- Při generování offline záložních kódů pro provádění 2FA, a také při jejím vypnutí. Ochrana proti hrubé síle zde nebyla implementována, což umožňovalo, pokud měl uživatel heslo k účtu a platnou relaci, regenerovat záložní kódy nebo zcela vypnout 2FA.
Vzhledem k tomu, že záložní kódy byly umístěny ve stejném rozmezí hodnot řetězců jako generované aplikací OTP, šance na nalezení kódu v krátkém čase byla výrazně vyšší.
Proces pokusu o nalezení OTP pro vypnutí 2FA pomocí nástroje "Burp: Intruder".
Výsledek
Celkově se MCS jako produkt ukázal jako bezpečný. Během auditu se týmu penetračních testerů nepodařilo získat přístup k klientským VM a jejich datům, a nalezené zranitelnosti byly rychle opraveny týmem MCS.
Je však důležité poznamenat, že bezpečnost je neustálá práce. Služby nejsou statické, neustále se vyvíjejí. Vytvořit produkt zcela bez zranitelností není možné. Lze však včas najít a minimalizovat šanci na jejich opakování.
Nyní jsou všechny zmíněné zranitelnosti v MCS již opraveny. Aby se minimalizoval počet nových zranitelností a zkrátila doba jejich existence, tým platformy nadále provádí následující:
- pravidelně provádět audity externími firmami;
- udržovat a rozvíjet účast;
- věnovat se bezpečnosti. 🙂
Zdroj: habr.com
