od SeerLight
Budování jakékoli služby nutně zahrnuje neustálou práci na zabezpečení. Zabezpečení je nepřetržitý proces, který zahrnuje neustálou analýzu a zlepšování zabezpečení produktů, sledování zpráv o zranitelnostech a mnoho dalšího. Včetně auditů. Audity provádějí jak interní, tak externí odborníci, kteří mohou radikálně pomoci s bezpečností, protože nejsou ponořeni do projektu a mají otevřenou mysl.
Článek je o tomto nejpřímějším pohledu externích odborníků, kteří pomohli týmu Mail.ru Cloud Solutions (MCS) testovat cloudovou službu, a o tom, co našli. Jako „externí sílu“ si MCS vybrala společnost Digital Security, která je známá svou vysokou odborností v kruzích informační bezpečnosti. A v tomto článku analyzujeme některé zajímavé zranitelnosti nalezené v rámci externího auditu – abyste se při vytváření vlastní cloudové služby vyhnuli stejnému raku.
Popis produktu
je platforma pro budování virtuální infrastruktury v cloudu. Zahrnuje IaaS, PaaS a tržiště hotových obrazů aplikací pro vývojáře. S ohledem na architekturu MCS bylo nutné prověřit bezpečnost produktu v následujících oblastech:
- ochrana infrastruktury virtualizačního prostředí: hypervizory, směrování, firewally;
- ochrana virtuální infrastruktury zákazníků: izolace od sebe navzájem, včetně sítě, privátních sítí v SDN;
- OpenStack a jeho otevřené komponenty;
- S3 naší vlastní konstrukce;
- IAM: projekty pro více nájemců se vzorem;
- Vision (počítačové vidění): API a zranitelnosti při práci s obrázky;
- webové rozhraní a klasické webové útoky;
- zranitelnost komponent PaaS;
- API všech komponent.
Možná je to vše podstatné pro další historii.
Jaký druh práce byl proveden a proč byl potřebný?
Bezpečnostní audit je zaměřen na identifikaci zranitelností a konfiguračních chyb, které by mohly vést k úniku osobních údajů, úpravě citlivých informací nebo narušení dostupnosti služeb.
Během práce, která trvá v průměru 1-2 měsíce, auditoři opakují akce potenciálních útočníků a hledají zranitelnosti v klientské a serverové části vybrané služby. V rámci auditu cloudové platformy MCS byly identifikovány následující cíle:
- Analýza autentizace ve službě. Chyby v této komponentě by pomohly okamžitě se dostat do účtů jiných lidí.
- Studium vzoru a řízení přístupu mezi různými účty. Pro útočníka je možnost získat přístup k virtuálnímu počítači někoho jiného žádoucím cílem.
- Chyby na straně klienta. XSS/CSRF/CRLF/atd. Je možné napadnout ostatní uživatele prostřednictvím škodlivých odkazů?
- Chyby zabezpečení na straně serveru: RCE a všechny druhy injekcí (SQL/XXE/SSRF a tak dále). Zranitelnosti serveru se obecně obtížněji hledají, ale vedou ke kompromitaci mnoha uživatelů najednou.
- Analýza izolace uživatelských segmentů na úrovni sítě. Pro útočníka nedostatek izolace výrazně zvyšuje útočnou plochu proti ostatním uživatelům.
- Analýza obchodní logiky. Je možné oklamat podniky a vytvořit virtuální stroje zdarma?
V tomto projektu se pracovalo podle modelu „Gray-box“: auditoři komunikovali se službou s privilegii běžných uživatelů, ale částečně vlastnili zdrojový kód API a měli příležitost vyjasnit si podrobnosti s vývojáři. To je obvykle nejpohodlnější a zároveň docela realistický model práce: interní informace může útočník stále sbírat, je to jen otázka času.
Byly nalezeny chyby zabezpečení
Než auditor začne posílat různé užitečné zatížení (užitné zatížení použité k provedení útoku) na náhodná místa, je nutné pochopit, jak věci fungují a jaká funkce je poskytována. Může se zdát, že jde o zbytečné cvičení, protože na většině studovaných míst nebudou žádná zranitelnost. Ale pouze pochopení struktury aplikace a logiky jejího fungování umožní najít ty nejsložitější útočné vektory.
Je důležité najít místa, která se zdají podezřelá nebo se nějakým způsobem velmi liší od ostatních. A tímto způsobem byla nalezena první nebezpečná zranitelnost.
IDOR
Zranitelnosti IDOR (Insecure Direct Object Reference) jsou jednou z nejčastějších zranitelností v obchodní logice, která jednomu nebo druhému umožňuje získat přístup k objektům, ke kterým přístup ve skutečnosti není povolen. Zranitelnosti IDOR vytvářejí možnost získat informace o uživateli různého stupně kritičnosti.
Jednou z možností IDOR je provádět akce se systémovými objekty (uživatelé, bankovní účty, položky v nákupním košíku) manipulací s přístupovými identifikátory k těmto objektům. To vede k nejvíce nepředvídatelným následkům. Například možnost nahrazení účtu odesílatele finančních prostředků, prostřednictvím kterého je můžete krást jiným uživatelům.
V případě MCS auditoři právě objevili zranitelnost IDOR spojenou s nezabezpečenými identifikátory. V osobním účtu uživatele byly identifikátory UUID použity pro přístup k jakýmkoli objektům, které se zdály, jak říkají bezpečnostní experti, působivě nejisté (to znamená chráněné před útoky hrubou silou). U určitých subjektů však bylo zjištěno, že k získávání informací o uživatelích aplikace se používají běžná předvídatelná čísla. Myslím, že tušíte, že bylo možné změnit ID uživatele o jedničku, odeslat požadavek znovu a získat tak informace obcházející ACL (seznam řízení přístupu, pravidla přístupu k datům pro procesy a uživatele).
Padělání požadavku na straně serveru (SSRF)
Na produktech OpenSource je dobré, že mají obrovské množství fór s podrobnými technickými popisy problémů, které se vyskytnou, a pokud budete mít štěstí, i s popisem řešení. Tato mince má ale i druhou stranu: jsou zde také podrobně popsány známé zranitelnosti. Na fóru OpenStack jsou například nádherné popisy zranitelností и , na jehož opravu z nějakého důvodu nikdo nespěchá.
Běžnou funkcionalitou aplikací je možnost uživatele odeslat na server odkaz, na který server klikne (například ke stažení obrázku z určeného zdroje). Pokud bezpečnostní nástroje nefiltrují samotné odkazy nebo odpovědi vrácené ze serveru uživatelům, mohou útočníci tuto funkci snadno využít.
Zranitelnosti SSRF mohou výrazně posunout vývoj útoku. Útočník může získat:
- omezený přístup k napadené lokální síti, například pouze přes určité segmenty sítě a pomocí určitého protokolu;
- plný přístup k místní síti, pokud je možný downgrade z aplikační úrovně na transportní úroveň a v důsledku toho plná správa zátěže na aplikační úrovni;
- přístup ke čtení lokálních souborů na serveru (pokud je podporováno schéma file:///);
- a mnohem více.
V OpenStacku je již dlouho známá zranitelnost SSRF, která je svou povahou „slepá“: když kontaktujete server, neobdržíte od něj odpověď, ale obdržíte různé typy chyb/zpoždění v závislosti na výsledku požadavku. . Na základě toho můžete provádět skenování portů na hostitelích ve vnitřní síti se všemi z toho vyplývajícími důsledky, které není radno podceňovat. Produkt může mít například back-office API, které je přístupné pouze z podnikové sítě. S dokumentací (nezapomeňte na zasvěcené osoby) může útočník použít SSRF k přístupu k interním metodám. Pokud se vám například podařilo nějakým způsobem získat přibližný seznam užitečných adres URL, můžete je pomocí SSRF projít a provést požadavek – relativně vzato, převést peníze z účtu na účet nebo změnit limity.
Není to poprvé, co byla v OpenStack objevena zranitelnost SSRF. V minulosti bylo možné stáhnout VM ISO obrazy z přímého odkazu, což také vedlo k podobným důsledkům. Tato funkce byla nyní z OpenStack odstraněna. Komunita to zjevně považovala za nejjednodušší a nejspolehlivější řešení problému.
A v veřejně dostupný report ze služby HackerOne (h1), využití již ne slepého SSRF s možností číst metadata instance vede ke kořenovému přístupu k celé infrastruktuře Shopify.
V MCS byly zranitelnosti SSRF objeveny na dvou místech s podobnou funkčností, které však bylo téměř nemožné zneužít kvůli firewallům a dalším ochranám. Tak či onak tým MCS tento problém stejně vyřešil, aniž by čekal na komunitu.
XSS místo načítání shellů
Navzdory stovkám napsaných studií je útok XSS (cross-site scripting) rok co rok stále nejvíce zranitelnost webu (resp ?).
Nahrávání souborů je oblíbeným místem každého bezpečnostního výzkumníka. Často se ukazuje, že můžete načíst libovolný skript (asp/jsp/php) a spouštět příkazy OS, v terminologii pentesterů - „načíst shell“. Ale popularita takových zranitelností funguje oběma směry: pamatují se a vyvíjejí se proti nim nápravná opatření, takže v poslední době se pravděpodobnost „načtení shellu“ blíží nule.
Útočící tým (v zastoupení Digital Security) měl štěstí. OK, v MCS na straně serveru byl zkontrolován obsah stažených souborů, povoleny byly pouze obrázky. Ale SVG je také obrázek. Jak mohou být obrázky SVG nebezpečné? Protože do nich můžete vkládat úryvky JavaScriptu!
Ukázalo se, že stažené soubory jsou dostupné všem uživatelům služby MCS, což znamená, že je možné napadnout další uživatele cloudu, tedy administrátory.
Příklad XSS útoku na phishingový přihlašovací formulář
Příklady zneužití XSS útoků:
- Proč se pokoušet ukrást relaci (zvláště proto, že nyní jsou všude cookies pouze HTTP, chráněné před krádeží pomocí skriptů js), pokud načtený skript může okamžitě přistupovat k zdrojovému API? V tomto případě může datová část pomocí požadavků XHR změnit konfiguraci serveru, například přidat útočníkův veřejný klíč SSH a získat přístup SSH k serveru.
- Pokud zásady CSP (zásady ochrany obsahu) zakazují vkládání JavaScriptu, útočník se bez něj obejde. Pomocí čistého HTML vytvořte falešný přihlašovací formulář pro web a ukradněte heslo správce prostřednictvím tohoto pokročilého phishingu: phishingová stránka pro uživatele skončí na stejné adrese URL a pro uživatele je obtížnější ji odhalit.
- Nakonec se může útočník zařídit — nastavit soubory cookie větší než 4 KB. Uživateli stačí odkaz otevřít pouze jednou a celý web se stane nepřístupným, dokud uživatele nenapadne konkrétně vyčistit prohlížeč: webový server v naprosté většině případů takového klienta odmítne přijmout.
Podívejme se na příklad dalšího detekovaného XSS, tentokrát s chytřejším exploitem. Služba MCS umožňuje kombinovat nastavení firewallu do skupin. Název skupiny byl místo, kde bylo zjištěno XSS. Jeho zvláštností bylo, že vektor nebyl spuštěn okamžitě, ne při prohlížení seznamu pravidel, ale při mazání skupiny:
To znamená, že scénář se ukázal být následující: útočník vytvoří pravidlo firewallu s „load“ v názvu, správce si toho po chvíli všimne a zahájí proces mazání. A tady funguje škodlivý JS.
Vývojářům MCS k ochraně před XSS v nahraných obrázcích SVG (pokud je nelze vynechat) tým Digital Security doporučil:
- Umístěte soubory nahrané uživateli na samostatnou doménu, která nemá nic společného s „cookies“. Skript bude spuštěn v kontextu jiné domény a nebude představovat hrozbu pro MCS.
- V odpovědi HTTP serveru odešlete hlavičku "Content-disposition: attachment". Poté budou soubory staženy prohlížečem a nebudou spuštěny.
Kromě toho je nyní vývojářům k dispozici mnoho způsobů, jak zmírnit rizika zneužití XSS:
- pomocí příznaku „Pouze HTTP“ můžete znepřístupnit záhlaví „Cookies“ relací škodlivému JavaScriptu;
- značně ztíží útočníkovi zneužití XSS;
- moderní šablonovací nástroje jako Angular nebo React automaticky dezinfikují uživatelská data před jejich odesláním do prohlížeče uživatele.
Chyby zabezpečení dvoufaktorové autentizace
Pro zlepšení zabezpečení účtu se uživatelům vždy doporučuje povolit 2FA (dvoufaktorové ověřování). Ve skutečnosti se jedná o účinný způsob, jak zabránit útočníkovi v získání přístupu ke službě, pokud byly prozrazeny přihlašovací údaje uživatele.
Zaručuje však použití druhého ověřovacího faktoru vždy bezpečnost účtu? Při implementaci 2FA existují následující bezpečnostní problémy:
- Hledání OTP kódu hrubou silou (jednorázové kódy). Navzdory jednoduchosti ovládání se s chybami, jako je nedostatek ochrany proti hrubé síle OTP, setkávají i velké společnosti: , .
- Slabý generovací algoritmus, například schopnost předvídat další kód.
- Logické chyby, jako je možnost požádat o jednorázové heslo někoho jiného na vašem telefonu, jako je tato ze služby Shopify.
V případě MCS je 2FA implementována na základě Google Authenticator a . Samotný protokol je již prověřen časem, ale implementace ověřování kódu na straně aplikace stojí za kontrolu.
MCS 2FA se používá na několika místech:
- Při ověřování uživatele. Existuje ochrana proti hrubé síle: uživatel má pouze několik pokusů o zadání jednorázového hesla, poté se vstup na chvíli zablokuje. To blokuje možnost výběru OTP hrubou silou.
- Při generování offline záložních kódů pro provedení 2FA a také při jeho deaktivaci. Zde nebyla implementována žádná ochrana hrubou silou, která umožňovala, pokud jste měli heslo k účtu a aktivní relaci, vygenerovat záložní kódy nebo úplně deaktivovat 2FA.
Vzhledem k tomu, že záložní kódy byly umístěny ve stejném rozsahu řetězcových hodnot jako ty generované aplikací OTP, byla šance na nalezení kódu v krátké době mnohem vyšší.
Proces výběru OTP pro deaktivaci 2FA pomocí nástroje „Burp: Intruder“.
Výsledek
Celkově se MCS jeví jako bezpečný produkt. Během auditu se týmu pentestingu nepodařilo získat přístup ke klientským virtuálním počítačům a jejich datům a nalezená zranitelnost byla rychle opravena týmem MCS.
Zde je ale důležité poznamenat, že bezpečnost je nepřetržitá práce. Služby nejsou statické, neustále se vyvíjejí. A je nemožné vyvinout produkt zcela bez zranitelností. Můžete je ale najít včas a minimalizovat šanci na jejich opakování.
Nyní jsou již všechny zmíněné zranitelnosti v MCS opraveny. A aby se počet nových snížil na minimum a zkrátila se jejich životnost, tým platformy pokračuje v tomto:
- pravidelně provádět audity externími společnostmi;
- podporovat a rozvíjet účast;
- zapojit se do bezpečnosti. 🙂
Zdroj: www.habr.com