od SeerLight
Budovanie akejkoľvek služby nevyhnutne zahŕňa neustálu prácu na bezpečnosti. Bezpečnosť je nepretržitý proces, ktorý zahŕňa neustálu analýzu a zlepšovanie bezpečnosti produktov, sledovanie správ o zraniteľnostiach a oveľa viac. Vrátane auditov. Audity sú vykonávané interne aj externými odborníkmi, ktorí môžu radikálne pomôcť s bezpečnosťou, pretože nie sú ponorení do projektu a majú otvorenú myseľ.
Článok je o tomto najpriamejšom pohľade externých odborníkov, ktorí pomohli tímu Mail.ru Cloud Solutions (MCS) testovať cloudovú službu, a o tom, čo našli. Ako „vonkajšiu silu“ si MCS vybrala spoločnosť Digital Security, ktorá je známa svojou vysokou odbornosťou v kruhoch informačnej bezpečnosti. A v tomto článku analyzujeme niekoľko zaujímavých zraniteľností nájdených v rámci externého auditu – aby ste sa vyhli rovnakému raku pri vytváraní vlastnej cloudovej služby.
Popis produktu
je platforma na budovanie virtuálnej infraštruktúry v cloude. Zahŕňa IaaS, PaaS a trh hotových obrázkov 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: vzájomná izolácia, vrátane siete, privátnych sietí v SDN;
- OpenStack a jeho otvorené komponenty;
- S3 nášho vlastného dizajnu;
- IAM: projekty viacerých nájomcov so vzorom;
- Vision (počítačové videnie): API a zraniteľné miesta pri práci s obrázkami;
- webové rozhranie a klasické webové útoky;
- zraniteľnosti komponentov PaaS;
- API všetkých komponentov.
Možno je to všetko podstatné pre ďalšiu históriu.
Aký druh práce sa vykonal a prečo to bolo potrebné?
Bezpečnostný audit je zameraný na identifikáciu slabých miest a chýb v konfigurácii, ktoré by mohli viesť k úniku osobných údajov, úprave citlivých informácií alebo narušeniu dostupnosti služby.
Počas práce, ktorá trvá v priemere 1-2 mesiace, audítori opakujú akcie potenciálnych útočníkov a hľadajú zraniteľnosti v klientskej a serverovej časti vybranej služby. V rámci auditu cloudovej platformy MCS boli identifikované tieto ciele:
- Analýza autentifikácie v službe. Zraniteľnosť tohto komponentu by pomohla okamžite sa dostať do účtov iných ľudí.
- Štúdium vzoru a riadenia prístupu medzi rôznymi účtami. Schopnosť získať prístup k virtuálnemu stroju niekoho iného je pre útočníka žiaducim cieľom.
- Zraniteľnosť na strane klienta. XSS/CSRF/CRLF/atď. Je možné zaútočiť na iných používateľov prostredníctvom škodlivých odkazov?
- Zraniteľnosť na strane servera: RCE a všetky druhy injekcií (SQL/XXE/SSRF atď.). Zraniteľnosť servera sa vo všeobecnosti hľadá ťažšie, ale vedie ku kompromisu mnohých používateľov naraz.
- Analýza izolácie segmentov používateľov na úrovni siete. Pre útočníka nedostatočná izolácia výrazne zvyšuje útočnú plochu proti iným používateľom.
- Analýza obchodnej logiky. Je možné oklamať podniky a vytvárať virtuálne stroje zadarmo?
V tomto projekte sa pracovalo podľa modelu „Gray-box“: audítori interagovali so službou s privilégiami bežných používateľov, ale čiastočne vlastnili zdrojový kód API a mali možnosť objasniť podrobnosti s vývojármi. Toto je zvyčajne najpohodlnejší a zároveň celkom realistický model práce: interné informácie môže útočník stále zbierať, je to len otázka času.
Našli sa slabé miesta
Predtým, ako audítor začne posielať rôzne užitočné zaťaženia (úžitok použitý na vykonanie útoku) na náhodné miesta, je potrebné pochopiť, ako veci fungujú a aká funkcia je poskytovaná. Môže sa zdať, že ide o zbytočné cvičenie, pretože na väčšine skúmaných miest nebudú žiadne zraniteľnosti. Ale iba pochopenie štruktúry aplikácie a logiky jej fungovania umožní nájsť najkomplexnejšie vektory útokov.
Je dôležité nájsť miesta, ktoré sa zdajú byť podozrivé alebo sa nejakým spôsobom veľmi líšia od ostatných. A takto sa našla prvá nebezpečná zraniteľnosť.
IDOR
Zraniteľnosť IDOR (Insecure Direct Object Reference) je jednou z najbežnejších zraniteľností v obchodnej logike, ktorá umožňuje jednému alebo druhému získať prístup k objektom, ku ktorým v skutočnosti prístup nie je povolený. Zraniteľnosť IDOR vytvára možnosť získať informácie o používateľovi rôzneho stupňa kritickosti.
Jednou z možností IDOR je vykonávať akcie so systémovými objektmi (používatelia, bankové účty, položky v nákupnom košíku) manipuláciou s prístupovými identifikátormi k týmto objektom. To vedie k najnepredvídateľnejším následkom. Napríklad možnosť nahradenia účtu odosielateľa finančných prostriedkov, prostredníctvom ktorého ich môžete ukradnúť iným používateľom.
V prípade MCS audítori práve objavili zraniteľnosť IDOR spojenú s nezabezpečenými identifikátormi. V osobnom účte používateľa boli identifikátory UUID použité na prístup k akýmkoľvek objektom, ktoré sa zdajú byť, ako hovoria bezpečnostní experti, pôsobivo nezabezpečené (to znamená chránené pred útokmi hrubou silou). Pri určitých subjektoch sa však zistilo, že na získanie informácií o používateľoch aplikácie sa používajú bežné predvídateľné čísla. Myslím, že tušíte, že bolo možné zmeniť ID užívateľa o jedno, odoslať požiadavku znova a získať tak informácie obídením ACL (zoznam riadenia prístupu, pravidlá prístupu k údajom pre procesy a používateľov).
Falšovanie požiadavky na strane servera (SSRF)
Na produktoch OpenSource je dobré, že majú obrovské množstvo fór s podrobným technickým popisom vzniknutých problémov a ak budete mať šťastie, aj s popisom riešenia. Táto minca má však aj druhú stranu: podrobne sú opísané aj známe zraniteľnosti. Napríklad na fóre OpenStack sú nádherné popisy zraniteľností и , s opravou ktorého sa z nejakého dôvodu nikto neponáhľa.
Bežnou funkcionalitou aplikácií je možnosť užívateľa poslať na server odkaz, na ktorý server klikne (napríklad stiahnuť obrázok z určeného zdroja). Ak bezpečnostné nástroje nefiltrujú samotné odkazy alebo odpovede vrátené zo servera používateľom, útočníci môžu takúto funkciu ľahko použiť.
Zraniteľnosť SSRF môže výrazne posunúť vývoj útoku. Útočník môže získať:
- obmedzený prístup k napadnutej lokálnej sieti, napríklad iba cez určité segmenty siete a pomocou určitého protokolu;
- úplný prístup k lokálnej sieti, ak je možný downgrade z aplikačnej úrovne na transportnú úroveň a v dôsledku toho úplné riadenie záťaže na aplikačnej úrovni;
- prístup k čítaniu lokálnych súborov na serveri (ak je podporovaná schéma file:///);
- И многое другое.
Zraniteľnosť SSRF je už dlho známa v OpenStack, ktorý je svojou povahou „slepý“: keď kontaktujete server, nedostanete od neho odpoveď, ale dostanete rôzne typy chýb/oneskorení v závislosti od výsledku požiadavky. . Na základe toho môžete vykonať skenovanie portov na hostiteľoch vo vnútornej sieti so všetkými z toho vyplývajúcimi dôsledkami, ktoré netreba podceňovať. Napríklad produkt môže mať back-office API, ktoré je prístupné len z podnikovej siete. Pomocou dokumentácie (nezabudnite na zasvätených) môže útočník použiť SSRF na prístup k interným metódam. Napríklad, ak sa vám nejakým spôsobom podarilo získať približný zoznam užitočných adries URL, pomocou SSRF ich môžete prejsť a vykonať požiadavku – relatívne povedané, previesť peniaze z účtu na účet alebo zmeniť limity.
Toto nie je prvýkrát, čo bola v OpenStack objavená zraniteľnosť SSRF. V minulosti bolo možné stiahnuť VM ISO obrazy z priameho odkazu, čo tiež viedlo k podobným dôsledkom. Táto funkcia bola teraz odstránená z OpenStack. Komunita to zjavne považovala za najjednoduchšie a najspoľahlivejšie riešenie problému.
A v verejne dostupnú správu zo služby HackerOne (h1), využitie už nie slepého SSRF s možnosťou čítania metaúdajov inštancií vedie ku root prístupu k celej infraštruktúre Shopify.
V MCS boli odhalené zraniteľnosti SSRF na dvoch miestach s podobnou funkcionalitou, ktoré však bolo takmer nemožné zneužiť kvôli firewallom a iným ochranným prvkom. Tak či onak, tím MCS tento problém aj tak vyriešil, bez čakania na komunitu.
XSS namiesto načítania škrupín
Napriek stovkám napísaných štúdií je útok XSS (cross-site scripting) z roka na rok stále najviac zraniteľnosť webu (resp ?).
Nahrávanie súborov je obľúbeným miestom každého bezpečnostného výskumníka. Často sa ukazuje, že môžete načítať ľubovoľný skript (asp/jsp/php) a vykonávať príkazy OS, v terminológii pentesterov - „načítať shell“. Popularita takýchto zraniteľností však funguje oboma smermi: pamätajú sa na ne a vyvíjajú sa proti nim nápravné opatrenia, takže v poslednej dobe má pravdepodobnosť „nabitia škrupiny“ tendenciu k nule.
Útočiaci tím (v zastúpení Digital Security) mal šťastie. OK, v MCS na strane servera sa skontroloval obsah stiahnutých súborov, povolené boli iba obrázky. Ale SVG je tiež obrázok. Ako môžu byť obrázky SVG nebezpečné? Pretože do nich môžete vložiť úryvky JavaScriptu!
Ukázalo sa, že stiahnuté súbory sú dostupné pre všetkých používateľov služby MCS, čo znamená, že je možné napadnúť iných používateľov cloudu, teda správcov.
Príklad XSS útoku na phishingový prihlasovací formulár
Príklady zneužitia XSS útokov:
- Prečo sa snažiť ukradnúť reláciu (obzvlášť preto, že teraz sú všade cookies iba HTTP, chránené pred krádežou pomocou skriptov js), ak načítaný skript môže okamžite pristupovať k zdrojovému API? V tomto prípade môže užitočné zaťaženie použiť požiadavky XHR na zmenu konfigurácie servera, napríklad pridať útočníkov verejný kľúč SSH a získať prístup SSH na server.
- Ak politika CSP (politika ochrany obsahu) zakazuje vkladanie JavaScriptu, útočník sa bez neho zaobíde. Pomocou čistého HTML vytvorte falošný prihlasovací formulár pre stránku a ukradnite heslo správcu prostredníctvom tohto pokročilého phishingu: phishingová stránka pre používateľa skončí na rovnakej adrese URL a pre používateľa je ťažšie ju odhaliť.
- Nakoniec sa útočník môže zariadiť — nastavte súbory cookie väčšie ako 4 kB. Používateľovi stačí odkaz otvoriť iba raz a celá stránka sa stane nedostupnou, kým používateľa nenapadne špecificky vyčistiť prehliadač: webový server vo veľkej väčšine prípadov odmietne takého klienta prijať.
Pozrime sa na príklad ďalšieho zisteného XSS, tentoraz s šikovnejším exploitom. Služba MCS umožňuje kombinovať nastavenia brány firewall do skupín. Názov skupiny bol tam, kde bolo zistené XSS. Jeho zvláštnosťou bolo, že vektor sa nespustil okamžite, nie pri prezeraní zoznamu pravidiel, ale pri odstraňovaní skupiny:
To znamená, že scenár sa ukázal byť nasledujúci: útočník vytvorí pravidlo brány firewall s názvom „load“, správca si to po chvíli všimne a spustí proces odstránenia. A tu funguje škodlivý JS.
Pre vývojárov MCS na ochranu pred XSS v nahraných obrázkoch SVG (ak ich nemožno vynechať), tím Digital Security odporučil:
- Umiestnite súbory nahrané používateľmi na samostatnú doménu, ktorá nemá nič spoločné so súbormi cookie. Skript sa spustí v kontexte inej domény a nebude predstavovať hrozbu pre MCS.
- V HTTP odpovedi servera odošlite hlavičku „Content-disposition: attachment“. Potom sa súbory stiahnu prehliadačom a nespustia sa.
Okrem toho je teraz vývojárom k dispozícii mnoho spôsobov, ako zmierniť riziká zneužívania XSS:
- pomocou príznaku „Iba HTTP“ môžete zneprístupniť hlavičky „Cookies“ relácie škodlivému JavaScriptu;
- značne sťaží útočníkovi zneužitie XSS;
- moderné nástroje šablón, ako napríklad Angular alebo React, automaticky dezinfikujú používateľské údaje pred ich odoslaním do prehliadača používateľa.
Zraniteľnosť dvojfaktorovej autentifikácie
Na zlepšenie zabezpečenia účtu sa používateľom vždy odporúča povoliť 2FA (dvojfaktorové overenie). Je to skutočne účinný spôsob, ako zabrániť útočníkovi získať prístup k službe, ak boli ohrozené poverenia používateľa.
Zaručuje však použitie druhého overovacieho faktora vždy bezpečnosť účtu? Pri implementácii 2FA existujú nasledujúce bezpečnostné problémy:
- Vyhľadanie OTP kódu hrubou silou (jednorazové kódy). Napriek jednoduchosti ovládania sa s chybami, ako je nedostatočná ochrana pred hrubou silou OTP, stretávajú aj veľké spoločnosti: , .
- Slabý generačný algoritmus, napríklad schopnosť predpovedať ďalší kód.
- Logické chyby, ako napríklad možnosť vyžiadať si v telefóne jednorazové heslo niekoho iného, ako je táto zo služby Shopify.
V prípade MCS je 2FA implementovaná na základe Google Authenticator a . Samotný protokol je už overený časom, no implementácia overenia kódu na strane aplikácie stojí za kontrolu.
MCS 2FA sa používa na niekoľkých miestach:
- Pri autentifikácii užívateľa. Existuje ochrana pred hrubou silou: používateľ má len niekoľko pokusov na zadanie jednorazového hesla, potom sa vstup na chvíľu zablokuje. Toto blokuje možnosť výberu OTP hrubou silou.
- Pri generovaní offline záložných kódov na vykonanie 2FA, ako aj jej zakázanie. Tu nebola implementovaná žiadna ochrana hrubou silou, ktorá umožnila, ak ste mali heslo k účtu a aktívnu reláciu, vygenerovať záložné kódy alebo úplne vypnúť 2FA.
Vzhľadom na to, že záložné kódy sa nachádzali v rovnakom rozsahu hodnôt reťazcov ako tie, ktoré generovala aplikácia OTP, šanca nájsť kód v krátkom čase bola oveľa vyššia.
Proces výberu OTP na deaktiváciu 2FA pomocou nástroja „Burp: Intruder“.
Výsledok
Celkovo sa MCS javí ako bezpečný produkt. Počas auditu sa tímu pentestingu nepodarilo získať prístup ku klientskym virtuálnym počítačom a ich údajom a tím MCS rýchlo opravil nájdené chyby.
Tu je však dôležité poznamenať, že bezpečnosť je nepretržitá práca. Služby nie sú statické, neustále sa vyvíjajú. A je nemožné vyvinúť produkt úplne bez zraniteľností. Môžete ich však nájsť včas a minimalizovať tak možnosť ich opätovného výskytu.
Teraz sú už všetky spomínané zraniteľnosti v MCS opravené. A aby sa počet nových znížil na minimum a skrátila sa ich životnosť, tím platformy pokračuje v tomto:
- pravidelne vykonávať audity externými spoločnosťami;
- podporovať a rozvíjať účasť;
- zapojiť sa do bezpečnosti. 🙂
Zdroj: hab.com