av SeerLight
Byggandet av vilken tjÀnst som helst krÀver stÀndigt arbete med sÀkerhet. SÀkerhet Àr en kontinuerlig process som innefattar stÀndig analys och förbÀttring av produktens skydd, övervakning av nyheter om sÄrbarheter och mycket mer. Bland annat - revisioner. Revisioner utförs bÄde internt och av externa experter, som kan ge avgörande hjÀlp med sÀkerheten, eftersom de inte Àr insyltade i projektet och har en oberörd syn.
Artikeln handlar om just denna obeflÀckade syn av externa experter som hjÀlpte teamet pÄ Mail.ru Cloud Solutions (MCS) att testa molntjÀnsten, och vad de upptÀckte. Som 'externa krafter' valde MCS företaget Digital Security, kÀnt för sin höga expertis inom cybersÀkerhet. I denna artikel kommer vi att gÄ igenom vissa intressanta sÄrbarheter som identifierades under den externa revisionen - för att ni ska undvika samma fÀllor nÀr ni skapar er egen molntjÀnst.
Produktbeskrivning
Àr en plattform för att bygga virtuell infrastruktur i molnet. Den inkluderar IaaS, PaaS, och en marknadsplats för fÀrdiga applikationsbilder för utvecklare. Med hÀnsyn till MCS:s arkitektur behövde produktsÀkerheten kontrolleras pÄ följande omrÄden:
- skydd av virtualiseringsmiljön: hypervisorer, routing, brandvÀggar;
- skydd av kundernas virtuella infrastruktur: isolering frÄn varandra, inklusive nÀtverksisolering, privata nÀtverk i SDN;
- OpenStack och dess öppna komponenter;
- Eget utvecklat S3;
- IAM: multitenanta projekt med en rollmodell;
- Vision (maskinsyn): API och sÄrbarheter vid bildhantering;
- webbgrÀnssnitt och klassiska webbattacker;
- sÄrbarheter i PaaS-komponenter;
- API för alla komponenter.
Kanske Àr det av betydelse för den fortsatta historien - det Àr allt.
Vilka arbeten utfördes och varför Àr de nödvÀndiga?
SÀkerhetsrevisionen syftar till att identifiera sÄrbarheter och konfigurationsfel som kan leda till lÀckage av personuppgifter, modificering av kÀnslig information eller till och med avbrott i tjÀnster.
Under arbetet, som i genomsnitt varar i 1-2 mÄnader, upprepar revisorerna handlingar som potentiella angripare skulle utföra och söker efter sÄrbarheter i den valda tjÀnstens klient- och serverdel. I samband med revisionen av den molnbaserade plattformen MCS identifierades följande mÄl:
- Analys av autentisering i tjÀnsten. SÄrbarheter i denna komponent skulle omedelbart kunna leda till obehörig Ätkomst till andras konton.
- Granskning av roller och ÄtkomstbegrÀnsningar mellan olika konton. För en angripare Àr möjligheten att fÄ ÄtgÄng till en annan virtuell maskin ett eftertraktat mÄl.
- SÄrbarheter i klientdelen. XSS/CSRF/CRLF/etc. Finns det en möjlighet att attackera andra anvÀndare via skadliga lÀnkar?
- SÄrbarheter i serverdelen: RCE och olika typer av injektioner (SQL/XXE/SSRF osv.). Serverrelaterade sÄrbarheter Àr vanligtvis svÄrare att hitta men kan leda till att mÄnga anvÀndare komprometteras samtidigt.
- Analys av isolering av anvÀndarsegment pÄ nÀtverksnivÄ. För en angripare ökar avsaknaden av isolering ytiden för attacker pÄ andra anvÀndare avsevÀrt.
- Analys av affÀrslogik. Kan man lura systemet och skapa virtuella maskiner gratis?
I detta projekt genomfördes arbetet enligt modellen "Gray-box": revisorerna interagerade med tjÀnsten med rÀttigheter som vanliga anvÀndare men hade delvis tillgÄng till API:ns kÀllkod och kunde specifikt stÀlla frÄgor till utvecklarna. Vanligtvis Àr detta den mest praktiska och samtidigt tillrÀckligt realistiska arbetsmodellen: intern information kan fortfarande samlas in av angripare, det Àr bara en frÄga om tid.
Identifierade sÄrbarheter
Innan revisorn börjar skicka olika payloads (den nyttolast som anvÀnds för att utföra attacken) till slumpmÀssiga stÀllen mÄste man förstÄ hur allt fungerar och vilken funktionalitet som erbjuds. Det kan verka som en meningslös uppgift, eftersom det i de flesta granskade omrÄden inte finns nÄgra sÄrbarheter. Men endast genom att förstÄ applikationens struktur och dess logik kan man hitta de mest komplexa attackvektorerna.
Det Àr viktigt att hitta platser som verkar misstÀnksamma eller skiljer sig avsevÀrt frÄn andra. Och den första farliga sÄrbarheten hittades faktiskt pÄ detta sÀtt.
IDOR
IDOR-sÄrbarheter (Insecure Direct Object Reference, osÀkra direkta objektreferenser) Àr en av de vanligaste formerna av sÄrbarheter inom affÀrslogik, som pÄ olika sÀtt lÄter obehöriga fÄ tillgÄng till objekt som de egentligen inte har tillgÄng till. IDOR-sÄrbarheter möjliggör Ätkomst till anvÀndardata av varierande kÀnslighetsnivÄ.
En typ av IDOR Àr att utföra ÄtgÀrder med systemobjekt (anvÀndare, bankkonton, varor i kundvagnen) genom att manipulera Ätkomstidentifierare för dessa objekt. Detta kan leda till de mest oförutsÀgbara konsekvenser. Till exempel kan man byta ut avsÀndarens konto för penningöverföringar, vilket gör att man kan stjÀla pengar frÄn andra anvÀndare.
I fallet med MCS upptÀckte revisorerna just en IDOR-sÄrbarhet relaterad till osÀkra identifierare. I anvÀndarens personliga konto anvÀndes UUID-identifikatorer för att fÄ tillgÄng till alla objekt, vilka verkade, enligt sÀkerhetsexperter, vara imponerande svÄra att knÀcka (det vill sÀga skyddade mot brute-force attacker). Men för vissa entiteter upptÀcktes det att vanliga förutsÀgbara nummer anvÀndes för att hÀmta information om anvÀndare i applikationen. Jag tror att ni förstÄr att man kunde Àndra anvÀndarens ID med ett, skicka begÀran igen och pÄ sÄ sÀtt fÄ information kring ACL (access control list, regler för Ätkomst till data för processer och anvÀndare).
Server Side Request Forgery (SSRF)
OpenSource-produkter Àr bra eftersom det finns ett stort antal forum med detaljerad teknisk beskrivning av problem och om ni har tur, beskrivningar av lösningar. Men denna medalj har en baksida: kÀnda sÄrbarheter Àr ocksÄ detaljerat beskrivna. Till exempel finns det utmÀrkta beskrivningar av sÄrbarheter pÄ OpenStack-forumet. och , som av nÄgon anledning inte verkar ÄtgÀrdas av nÄgon.
Vanlig funktionalitet i applikationer Àr möjligheten för anvÀndaren att skicka en lÀnk till servern, som servern sedan navigerar till (till exempel för att ladda upp en bild frÄn en angiven kÀlla). Vid otillrÀcklig filtrering av lÀnkar eller svar som returneras frÄn servern kan detta utnyttjas av illvilliga aktörer.
SSRF-sÄrbarheter kan kraftigt pÄskynda utvecklingen av en attack. En angripare kan fÄ:
- begrÀnsad Ätkomst till den attackerade lokala nÀtverket, till exempel bara till vissa segment av nÀtverket och över ett visst protokoll;
- full Ätkomst till det lokala nÀtverket, om en nedgradering frÄn applikationsnivÄ till transportnivÄ Àr möjlig, vilket i sin tur ger full kontroll över lastningen pÄ applikationsnivÄ;
- Ätkomst för att lÀsa lokala filer pÄ servern (om schema file:// stöds);
- och mycket mer.
I OpenStack har en kĂ€nd SSRF-sĂ„rbarhet med "blind" karaktĂ€r lĂ€nge funnits: nĂ€r man kontaktar servern fĂ„r man inget svar, men fĂ„r dĂ€remot olika typer av fel/fördröjningar, beroende pĂ„ resultatet av förfrĂ„gan. Baserat pĂ„ detta kan man utföra portskanningar pĂ„ vĂ€rdar i det interna nĂ€tverket, med alla följder som inte ska underskattas. Till exempel kan produkten ha en API för backoffice, tillgĂ€nglig endast frĂ„n det företagsnĂ€tverkets. Med dokumentation (tĂ€nk pĂ„ insiders) kan en angripare via SSRF fĂ„ tillgĂ„ng till interna metoder. Till exempel, om man lyckats fĂ„ en ungefĂ€rlig lista över anvĂ€ndbara URL:er, kan man anvĂ€nda SSRF för att gĂ„ igenom dem och utföra en förfrĂ„gan â i teorin överföra pengar frĂ„n konto till konto eller Ă€ndra grĂ€nser.
Detta Àr inte första gÄngen som en SSRF-sÄrbarhet upptÀckts i OpenStack. Tidigare fanns möjligheten att ladda upp ISO-bilder för VM via lÀnkar, vilket ocksÄ ledde till liknande följder. För nÀrvarande har denna funktion tagits bort frÄn OpenStack. Tydligen ansÄg gemenskapen att detta var den enklaste och mest pÄlitliga lösningen pÄ problemet.
Och i en offentligt tillgÀnglig rapport frÄn tjÀnsten HackerOne (h1) leder utnyttjandet av en icke-blind SSRF med möjlighet att lÀsa metadata om instansen till att fÄ Root-Ätkomst till hela Shopify-infrastrukturen.
I MCS upptÀcktes SSRF-sÄrbarheter pÄ tvÄ stÀllen med liknande funktionalitet, men de var praktiskt taget omöjliga att utnyttja pÄ grund av brandvÀggar och andra skydd. Hur som helst, MCS-teamet ÄtgÀrdade ÀndÄ detta problem, utan att vÀnta pÄ gemenskapen.
XSS istÀllet för att ladda upp "shells"
Trots hundratals genomförda studier Àr fortfarande XSS (Cross-Site Scripting-attack) den web-sÄrbarheten (eller ?).
Filuppladdning Àr en favoritplats för varje sÀkerhetsforskare. Det visade sig ofta att man kan ladda upp vilket skript som helst (asp/jsp/php) och köra kommandon pÄ operativsystemet; i penetrationstestarnas terminologi kallas det att "ladda upp en shell". Men populariteten av sÄdana sÄrbarheter fungerar Ät bÄda hÄll: de kom ihÄg och verktyg utvecklas mot dem, sÄ pÄ senare tid har sannolikheten för att "ladda upp en shell" nÀrmat sig noll.
Den attackerande gruppen (representerad av Digital Security) hade tur. Okej, i MCS kontrollerades innehÄllet i de uppladdade filerna pÄ serversidan, och endast bilder tillÀts. Men SVG Àr ocksÄ en bild. Vad kan vara farligt med SVG-bilder? Jo, att man kan integrera JavaScript-fragment i dem!
Det visade sig att de uppladdade filerna var tillgĂ€ngliga för alla anvĂ€ndare av MCS-tjĂ€nsten â vilket betyder att man kan attackera andra anvĂ€ndare av molnet, nĂ€mligen administratörerna.
Exempel pÄ injektion genom en XSS-attack med en phishing-inloggningsformulÀr.
Exempel pÄ utnyttjande av XSS-attacker:
- Varför försöka stjÀla sessionen (dessutom, nu har vi överallt HTTP-Only-cookies som skyddas mot stöld med js-skript), nÀr det uppladdade skriptet kan direkt kommunicera med resursens API? I sÄdana fall kan nyttolasten genom XHR-förfrÄgningar Àndra serverkonfigurationen, till exempel lÀgga till en öppen SSH-nyckel för angriparen och fÄ SSH-Ätkomst till servern.
- Om CSP-politiken (Content Security Policy) förbjuder integrering av JavaScript, kan angriparen klara sig utan det. Med ren HTML kan man skapa en falsk inloggningsformulÀr och stjÀla administratörens lösenord genom en sÄdan avancerad phishing: phishing-sidan för anvÀndaren visas pÄ samma URL, vilket gör det svÄrare för anvÀndaren att upptÀcka den.
- Till sist kan angriparen arrangera â genom att ange Cookies som Ă€r större Ă€n 4 kB. AnvĂ€ndaren behöver bara öppna lĂ€nken en gĂ„ng â och hela webbplatsen blir otillgĂ€nglig, tills man förstĂ„r att man speciellt mĂ„ste rensa webblĂ€saren: i övervĂ€ldigande fall kommer webbservern att vĂ€gra att ta emot en sĂ„dan klient.
LÄt oss övervÀga ett exempel pÄ ytterligare en identifierad XSS, denna gÄng med en mer subtil utnyttjande. TjÀnsten MCS tillÄter att gruppera brandvÀggsinstÀllningar. Den identifierade XSS fanns i gruppnamnet. Dess sÀrskiljande drag var att vektorn inte utlöste omedelbart, inte vid visning av reglerna, utan vid borttagning av gruppen:
Det vill sÀga, scenariot blev följande: en angripare skapar en brandvÀggsregel med "belastning" i namnet, administratören mÀrker det efter ett tag, initierar raderingsprocessen. Och just dÄ aktiveras den skadliga JS.
För att skydda mot XSS i laddade SVG-bilder (om de inte kan uteslutas) rekommenderade teamet Digital Security till MCS-utvecklarna:
- Att placera filer som laddas upp av anvÀndare pÄ en separat domÀn som inte har nÄgot gemensamt med "kakor". Skriptet kommer att köras i kontexten av en annan domÀn och kommer inte att utgöra nÄgot hot mot MCS.
- Att i serverns HTTP-svar returnera rubriken "Content-disposition: attachment". DÄ kommer filer att laddas ner av webblÀsaren och inte exekveras.
Dessutom finns det nu mÄnga sÀtt för utvecklare att mildra risken för XSS-exploatering:
- genom att anvÀnda flaggan "HTTP Only" kan sessionens "Cookies"-rubriker göras otillgÀngliga för skadlig JavaScript;
- kommer avsevÀrt att försvÄra utnyttjandet av XSS för angriparen;
- moderna mallmotorer, sÄsom Angular eller React, rensar automatiskt anvÀndardata innan de visas i anvÀndarens webblÀsare.
SÄrbarheter i tvÄfaktorsautentisering
För att öka sÀkerheten för konton rekommenderas anvÀndare alltid att aktivera 2FA (tvÄfaktorsautentisering). Detta Àr verkligen ett effektivt sÀtt att förhindra en angripare frÄn att fÄ Ätkomst till tjÀnsten om anvÀndarens uppgifter har komprometterats.
Men ger anvÀndning av den andra autentiseringsfaktorn alltid garantin för att kontot förblir sÀkert? I implementeringen av 2FA finns det sÄdana sÀkerhetsproblem:
- Grovt bruteforce av OTP-kod (engÄngskoder). Trots enkelheten att utnyttja, förekommer sÄdana fel som brist pÄ skydd mot bruteforce av OTP Àven hos stora företag: , .
- Svaga algoritmer för generering, till exempel möjligheten att förutsÀga nÀsta kod.
- Logiska fel, exempelvis möjligheten att begÀra nÄgon annans OTP pÄ sin egen telefon, som det hos Shopify.
I fallet MCS Àr 2FA implementerat baserat pÄ Google Authenticator och . SjÀlva protokollet har redan testats över tid, men implementeringen av kodverifieringen pÄ applikationssidan bör kontrolleras.
I MCS anvÀnds 2FA pÄ flera platser:
- Vid anvÀndarautentisering. HÀr finns skydd mot att gissa: anvÀndaren har bara ett fÄtal försök att ange engÄngslösenordet, sedan blockeras inmatningen under en tid. Detta blockerar möjligheten att genomföra en gissning av OTP.
- Vid generering av offline backupkoder för att genomföra 2FA, samt dess avaktivering. HÀr fanns inget skydd mot gissning, vilket gjorde det möjligt, om man hade lösenordet till kontot och en aktiv session, att regenerera backupkoder eller helt avaktivera 2FA.
Med tanke pÄ att backupkoderna fanns inom samma vÀrdeomrÄde som de engÄngslösenord som genererades av appen, var chansen att gissa en kod snabbt betydligt högre.
Processen av att gissa OTP för avaktivering av 2FA med hjÀlp av verktyget "Burp: Intruder".
Resultat
Ăverlag visade sig MCS som en sĂ€ker produkt. Under auditens gĂ„ng lyckades teamet av penetrationstestare inte fĂ„ tillgĂ„ng till kundernas VMs och deras data, och de hittade sĂ„rbarheterna Ă„tgĂ€rdades snabbt av MCS-teamet.
Men det Àr viktigt att notera att sÀkerhet Àr ett kontinuerligt arbete. TjÀnster Àr inte statiska, de utvecklas stÀndigt. Att utforma en produkt helt utan sÄrbarheter Àr omöjligt. Men man kan i tid hitta dem och minimera chansen för upprepning.
Nu Àr alla nÀmnda sÄrbarheter i MCS redan ÄtgÀrdade. För att minimera antalet nya och förkorta tiden de existerar, fortsÀtter plattformsteamet att göra följande:
- regelbundet genomföra revisioner av externa företag;
- underhÄlla och utveckla deltagandet;
- arbete med sĂ€kerhet. đ
KĂ€lla: habr.com
