🥇Audit bezpečnosti cloudovej platformy MCS

SkyShip Dusk od SeerLight

Budovanie akýchkoľvek služieb si nevyhnutne vyžaduje neustále úsilie o zabezpečenie. Zabezpečenie je nepretržitý proces, ktorý zahŕňa neustálu analýzu a zlepšovanie ochrany produktu, sledovanie noviniek o zraniteľnostiach a mnoho ďalšieho. Vrátane auditov. Audity sa vykonávajú vlastnými silami aj silami externých expertov, ktorí môžu radikálne pomôcť so zabezpečením, pretože nie sú ponorení do projektu a majú nezaujatý pohľad.

Tento článok sa zaoberá práve týmto nezaujatým pohľadom externých expertov, ktorí pomohli tímu Mail.ru Cloud Solutions (MCS) otestovať cloudovú službu a tým, čo našli. Ako "externé sily" MCS vybralo spoločnosť Digital Security, známych svojou vysokou odbornou znalosťou v oblasti informačnej bezpečnosti. V tomto článku preskúmame niektoré zaujímavé zraniteľnosti, ktoré boli nájdené počas externého auditu — aby vás obchádzali podobné problémy, keď budete vytvárať svoju vlastnú cloudovú službu.

Popis produktu

Mail.ru Cloud Solutions (MCS) je platforma na budovanie virtuálnej infraštruktúry v cloude. Zahrňuje IaaS, PaaS a trh pripravených obrazov aplikácií pre vývojárov. Vzhľadom na architektúru MCS bolo potrebné skontrolovať bezpečnosť produktu v nasledujúcich oblastiach:

ochrana infraštruktúry virtualizačného prostredia: hypervízory, smerovanie, firewally;
ochrana virtuálnej infraštruktúry zákazníkov: izolácia navzájom, vrátane siete, súkromné siete v SDN;
OpenStack a jeho otvorené komponenty;
S3 vlastného vývoja;
IAM: multitenantné projekty s rolovým modelom;
Vision (strojové videnie): API a zraniteľnosti pri práci s obrázkami;
webové rozhranie a klasické webové útoky;
zraniteľnosti PaaS komponentov;
API všetkých komponentov.

Snáď z dôležitého pre ďalší príbeh — všetko.

Aké práce sa vykonávali a prečo sú potrebné?

Audit bezpečnosti je zameraný na odhaľovanie zraniteľností a chýb v konfigurácii, ktoré môžu viesť k úniku osobných údajov, úprave citlivých informácií alebo k porušeniu dostupnosti služieb.

Počas prác, ktoré trvajú v priemere 1-2 mesiace, audítori opakujú kroky potenciálnych útočníkov a hľadajú zraniteľnosti v klientskej a serverovej časti vyberaného servisu. V kontexte auditu cloudovej platformy MCS boli stanovené nasledujúce ciele:

Analýza autentifikácie v servise. Zraniteľnosti v tejto súčasti by mohli okamžite dovoliť prístup k cudzím účtom.
Preskúmanie modelu rolí a rozdeľovania prístupu medzi rôznymi účtami. Pre útočníka je možnosť získať prístup k cudzej virtuálnej mašine žiadaným cieľom.
Zraniteľnosti klientskej časti. XSS/CSRF/CRLF/atď. Existuje možnosť útoku na iných používateľov cez škodlivé odkazy?
Zraniteľnosti serverovej časti: RCE a rôzne injekcie (SQL/XXE/SSRF a tak ďalej). Serverové zraniteľnosti sú zvyčajne ťažšie nájsť, ale vedú k kompromitácii okamžite viacerých používateľov.
Analýza izolácie používateľských segmentov na úrovni siete. Pre útočníka nedostatok izolácie významne zvyšuje plochu útoku na iných používateľov.
Analýza obchodnej logiky. Je možné oklamať systém a vytvárať virtuálne mašiny zadarmo?

V tomto projekte sa práce vykonávali podľa modelu „Gray-box": audítori interagovali so servisom s privilégiami bežných používateľov, ale čiastočne mali prístup k zdrojovým kódom API a mohli si vyjasniť podrobnosti s vývojármi. Zvyčajne ide o najpohodlnejší a zároveň dosť realistický model práce: vnútorné informácie môžu byť aj tak zhromaždené útočníkom, ide len o otázku času.

Nájdené zraniteľnosti

Predtým, než audítor začne posielať rôzne payloady (užitočnú záťaž, ktorou sa vykonáva útok) na náhodné miesta, je potrebné pochopiť, ako funguje to, čo je dostupné. Môže sa zdať, že je to zbytočná činnosť, pretože v väčšine preskúmaných miest nenájdete žiadne zraniteľnosti. Ale len pochopenie štruktúry aplikácie a logiky jej fungovania umožní nájsť tie najzložitejšie vektory útokov.

Je dôležité nájsť miesta, ktoré sa zdajú podozrivé alebo sa veľmi líšia od ostatných. A prvá nebezpečná zraniteľnosť bola nájdená práve týmto spôsobom.

IDOR

IDOR zraniteľnosti (Insecure Direct Object Reference, nebezpečné priame odkazy na objekty) sú jedným z najčastejších variantov zraniteľností v obchodnej logike, ktorý umožňuje určitým spôsobom získať prístup k objektom, ku ktorým nie je skutočne povolený prístup. IDOR zraniteľnosti vytvárajú možnosť získať informácie o používateľovi rôznej miery kritickosti.

Jedným z variantov IDOR je vykonávanie akcií s objektmi systému (používateľmi, bankovými účtami, tovarom v košíku) prostredníctvom manipulácií s identifikátormi prístupu k týmto objektom. To vedie k najnepredvídateľnejším následkom. Napríklad sa môže stať, že sa môže zmeniť účet odosielateľa finančných prostriedkov a tým sa môžu kradnúť prostriedky od iných používateľov.

V prípade MCS audítori objavili IDOR zraniteľnosť súvisiacu s nezabezpečenými identifikátormi. V osobnom účte používateľa sa na prístup k akýmkoľvek objektom používali identifikátory UUID, ktoré sa zdali, podľa bezpečnostných expertov, navonok neprehľadné (teda chránené pred útokom hrubou silou). Ale pre určité entity bolo zistené, že na získanie informácií o používateľoch aplikácie sa používajú bežne predvídateľné čísla. Myslím, že tušíte, že bolo možné zmeniť ID používateľa o jednotku, znovu poslať požiadavku a tým získať informácie obchádzajúce ACL (access control list, pravidlá prístupu k údajom pre procesy a používateľov).

Server Side Request Forgery (SSRF)

OpenSource produkty sú dobré v tom, že o nich existuje obrovské množstvo fór s podrobným technickým popisom vznikajúcich problémov a, ak máte šťastie, aj s popisom riešení. Ale táto minca má aj svoju druhú stranu: rovnako podrobne sú opísané aj známe zraniteľnosti. Napríklad na fóre OpenStack sú úžasné opisy zraniteľností [XSS] a [SSRF], ktoré akosi nikto nepospíchal opraviť.

Častá funkčnosť aplikácií je možnosť pre používateľa poslať serveru odkaz, na ktorý server prechádza (napríklad na načítanie obrázku z uvedeného zdroja). Pri nedostatočnej filtrácii prostriedkami bezpečnosti samotných odkazov alebo odpovedí vracaných od servera používateľom môže byť táto funkčnosť ľahko zneužitá útočníkmi.

Zraniteľnosti SSRF môžu významne posunúť útok vpred. Útočník môže získať:

obmedzený prístup k napadneteľnej lokálnej sieti, napríklad len k určitým segmentom siete a cez konkrétny protokol;
plný prístup do lokálnej siete, ak je možný downgrade z aplikačnej úrovne na transportnú úroveň a, ako výsledok, úplné ovládanie záťaže na aplikačnej úrovni;
prístup k čítaniu lokálnych súborov na serveri (ak je podporovaná schéma file:///);
a mnohého iného.

V OpenStacku je už dlho známa zraniteľnosť SSRF, ktorá má „slepý“ charakter: pri oslovení servera nedostávate odpoveď, ale dostávate rôzne typy chýb/zdržaní, v závislosti od výsledku požiadavky. Na základe toho je možné vykonať skenovanie portov na hostiteľoch v internej sieti, so všetkými vyplývajúcimi následkami, ktoré netreba podceňovať. Napríklad, produkt môže mať API pre back-office, ktoré je prístupné iba z firemnej siete. So záznamami (nezabúdajme na insiderov) môže útočník pomocou SSRF osloviť interné metódy. Napríklad, ak sa mu nejako podarilo získať približný zoznam užitočných URL, potom pomocou SSRF môže prejsť na ne a vykonať požiadavku — povedzme, previesť peniaze z účtu na účet alebo zmeniť limity.

Nie je to prvý prípad zistenia zraniteľnosti SSRF v OpenStacku. V minulosti bola možnosť nahrávať ISO obrazy VM priamym odkazom, čo tiež viedlo k podobným následkom. V súčasnosti je táto funkcia odstránená z OpenStacku. Zrejme sa komunita rozhodla, že to je najjednoduchšie a najspoľahlivejšie riešenie problému.

A v tom V verejne dostupnej správe zo služby HackerOne (h1) zneužitie už nie slepého SSRF s možnosťou čítania metadát inštancie vedie k získaniu Root prístupu k celej infraštruktúre Shopify.

V MCS sa na dvoch miestach s podobnou funkčnosťou objavili zraniteľnosti SSRF, avšak prakticky ich nebolo možné zneužiť kvôli firewallom a iným ochranám. Tak či onak, tím MCS túto problematiku aj tak opravil, bez čakania na komunitu.

XSS namiesto načítania „shellov“

Napriek stovkám napísaných výskumov, rok čo rok je XSS (útok medziwebového skriptovania) stále najčastejšie sa vyskytujúca webová zraniteľnosť (alebo útok?).

Nahrávanie súborov je obľúbené miesto pre každého bezpečnostného výskumníka. Často sa ukáže, že je možné nahrať ľubovoľný skript (asp/jsp/php) a vykonať príkazy operačného systému, v terminológii pen-testovateľov – „nahrať shell“. Ale populárnosť takýchto zraniteľností funguje v oboch smeroch: pamätajú sa na ne a vyvíjajú sa prostriedky proti nim, takže v poslednej dobe pravdepodobnosť „nahrať shell“ sa blíži k nule.

Útočnej skupine (v podobe Digital Security) sa šťastie usmialo. OK, na strane servera MCS sa kontroloval obsah nahrávaných súborov, povoľované boli len obrázky. Ale SVG je tiež obrázok. Čím môžu byť SVG obrázky nebezpečné? Tým, že do nich je možné vkladať fragmenty JavaScriptu!

Ukázalo sa, že nahrávané súbory sú dostupné všetkým používateľom služby MCS – to znamená, že je možné zaútočiť na iných používateľov cloudu, konkrétne na správcov.

Príklad vkladu pomocou XSS-útoku phishingovej prihlasovacej formy

Príklady vykorisťovania XSS-útoku:

Prečo sa snažiť ukradnúť reláciu (najmä, keď sa teraz všade používajú HTTP-Only cookies, chránené pred krádežou pomocou js-skriptov), ak môže nahraný skript okamžite pristupovať k API zdroja? V takom prípade môže užitočná záťaž prostredníctvom XHR-žiadostí zmeniť konfiguráciu servera, napríklad pridať otvorený SSH kľúč útočníka a získať SSH prístup k serveru.
Ak politika CSP (politika ochrany obsahu) zakazuje vkladanie JavaScriptu, útočník sa môže zaobísť bez neho. Na čisto HTML vytvoriť falošný prihlasovací formulár na stránku a ukradnúť heslo správcu prostredníctvom takého pokročilého phishingu: phishingová stránka pre používateľa sa nachádza na tom istom URL a používateľ ju má ťažšie odhaliť.
Nakoniec útočník môže spôsobiť klientský DoS – vystaviť Cookies väčšie ako 4 Kbyte. Používateľovi stačí raz otvoriť odkaz – a celá stránka sa stane nedostupnou, kým si nenapadne špeciálne vyčistiť prehliadač: v drvivej väčšine prípadov webový server odmietne prijať takého klienta.

Pozrime sa na príklad ďalšej odhalenej XSS, tentoraz s rafinovanejším vykorisťovaním. Služba MCS umožňuje kombinovať nastavenia firewallu do skupín. V názve skupiny bola odhalená XSS. Jej zvláštnosť spočívala v tom, že vektor nebol aktivovaný okamžite, nie pri prezeraní zoznamu pravidiel, ale pri odstraňovaní skupiny:

Teda, scenár vyzeral nasledovne: útočník vytvorí pravidlo firewallu s "náměšťou" v názve, administrátor si to po čase všimne a inicia proces odstránenia. A práve tu sa zlý JavaScript prejaví.

Vývojárom MCS sa pre ochranu pred XSS v nahrávaných SVG obrázkoch (ak sa od nich nemožno vzdať) odporučil tím Digital Security:

Umiestniť súbory nahrávané používateľmi na samostatnú doménu, ktorá nemá nič spoločné s "cookies". Skript bude vykonávaný v kontexte inej domény a nebude predstavovať hrozbu pre MCS.
V HTTP odpovedi servera odovzdať hlavičku „Content-disposition: attachment“. Potom sa budú súbory sťahovať prehliadačom, a nie vykonávať.

Okrem toho, v súčasnosti je pre vývojárov k dispozícii mnoho spôsobov, ako zmierniť riziká zneužitia XSS:

pomocou nastaviteľného parametra „HTTP Only“ je možné sprístupniť hlavičky relácií „Cookies“ nedostupné pre zlý JavaScript;
správne implementovaná politika CSP výrazne sťažuje zneužitie XSS pre útočníka;
moderné templatingové systémy, ako Angular alebo React, automaticky čistí používateľské údaje pred ich zobrazením v prehliadači používateľa.

Zraniteľnosti dvojfaktorovej autentifikácie

Pre zvýšenie bezpečnosti účtov sa používateľom vždy odporúča zapnúť 2FA (dvojfaktorovú autentifikáciu). Skutočne, je to účinný spôsob, ako zabrániť útočníkovi získať prístup k službe, ak boli uložené údaje užívateľa kompromitované.

Ale vždy poskytuje použitie druhého autentifikačného faktora garanciu bezpečnosti účtu? V realizácii 2FA existujú také bezpečnostné problémy:

Hrubé prelamovanie OTP kódu (jednorazových kódov). Napriek jednoduchosti zneužitia, také chyby, ako nedostatok ochrany pred brutálnym útokom OTP, sa vyskytujú aj u veľkých spoločností: prípad Slack, prípad Facebook.
Slabý algoritmus generovania, napríklad možnosť predpovedať nasledujúci kód.
Logické chyby, napríklad možnosť požiadať o cudzí OTP na svoj telefón, ako je to bolo u Shopify.

V prípade MCS je 2FA realizovaná na základe Google Authenticator a Duo. Samotný protokol už prežil testom času, avšak implementáciu kontroly kódu na strane aplikácie by malo byť potrebné preveriť.

V MCS sa 2FA používa na viacerých miestach:

Pri autentifikácii používateľa. Tu je ochrana pred hrubou silou: používateľ má len niekoľko pokusov na zadanie jednorazového hesla, potom je zadanie na nejaký čas zablokované. To bráni možnosti vykonať pokus o uhádnutie OTP.
Pri generovaní offline záložných kódov na vykonanie 2FA, ako aj pri jeho vypnutí. Ochrana proti hrubej sile tu nebola implementovaná, čo umožnilo, že pri existencii hesla k účtu a aktívnej relácii bolo možné regenerovať záložné kódy alebo úplne vypnúť 2FA.

Zohľadňujúc, že záložné kódy sa nachádzali v tom istom rozsahu hodnôt ako generované aplikáciou OTP, šanca uhádnuť kód v krátkom čase bola výrazne vyššia.

Proces uhádnutia OTP na vypnutie 2FA pomocou nástroja „Burp: Intruder“

Výsledok

Celkovo sa MCS ako produkt ukázal ako bezpečný. Počas auditu tímu pentesterov sa im nepodarilo získať prístup k klientským VM a ich dátam, a nájdené zraniteľnosti boli rýchlo opravené tímom MCS.

Ale je dôležité poznamenať, že bezpečnosť je kontinuálny proces. Služby nie sú statické, neustále sa vyvíjajú. A vyvinúť produkt úplne bez zraniteľností nie je možné. Ale je možné ich včas nájsť a minimalizovať šancu na ich opakovanie.

Všetky spomenuté zraniteľnosti v MCS sú už opravené. A aby sa nové zraniteľnosti minimalizovali a skracoval sa čas ich existencie, tím platformy pokračuje v nasledovnom:

pravidelne vykonávať audity externými spoločnosťami;
podporovať a rozvíjať účasť v programu Bug Bounty Mail.ru Group;
zaoberať sa bezpečnosťou. 🙂

Zdroj: habr.com