Sikkerhetsrevisjon av skyplattformen MCS

SkyShip Dusk av SeerLight

Bygging av enhver tjeneste involverer nødvendigvis kontinuerlig arbeid med sikkerhet. Sikkerhet er en kontinuerlig prosess som inkluderer løpende analyse og forbedring av produktets beskyttelse, overvåking av nyheter om sårbarheter, og mye mer. Dette inkluderer også revisjoner. Revisjoner gjennomføres både med interne ressurser og av eksterne eksperter, som kan gi betydelig hjelp med sikkerheten, da de ikke er dypt involvert i prosjektet og har et friskt blikk.

Artikkelen handler om dette friske blikket fra eksterne eksperter, som hjalp Mail.ru Cloud Solutions (MCS) med å teste skyttjenesten, og hva de fant. Som «eksterne krefter» valgte MCS selskapet Digital Security, kjent for sin høye ekspertise innen informasjonssikkerhet. I denne artikkelen vil vi gjennomgå noen interessante sårbarheter som ble oppdaget i løpet av den eksterne revisjonen – slik at du unngår de samme feilene når du lager din skyttjeneste.

Produktbeskrivelse

Mail.ru Cloud Solutions (MCS) er en plattform for bygging av virtuell infrastruktur i skyen. Den inkluderer IaaS-er, PaaS-er, og et marked for ferdige applikasjonsbilder for utviklere. Med tanke på MCSs arkitektur var det nødvendig å sjekke sikkerheten til produktet innen følgende områder:

• beskyttelse av virtualiseringsmiljøets infrastruktur: hypervisorer, ruting, brannmurer;
• beskyttelse av kundens virtuelle infrastruktur: isolasjon fra hverandre, inkludert nettverksisolasjon, private nettverk i SDN;
• OpenStack og dets åpne komponenter;
• Egenutviklet S3;
• IAM: flere leietakerprosjekter med rollemodell;
• Vision (maskinsyn): API-er og sårbarheter ved arbeid med bilder;
• webgrensesnitt og klassiske webangrep;
• sårbarheter i PaaS-komponenter;
• API-er for alle komponenter.

Kanskje det viktigste for den videre historien – er alt.

Hvilke arbeider ble utført og hvorfor er de nødvendige?

Sikkerhetsrevisjon er rettet mot å avdekke sårbarheter og konfigurasjonsfeil som kan føre til lekkasje av personlig informasjon, modifikasjon av sensitiv informasjon eller brudd på tilgjengeligheten av tjenester.

I løpet av arbeidet, som varer i gjennomsnitt 1-2 måneder, gjentar revisorer handlingene til potensielle angripere og leter etter sårbarheter i både klient- og serverdelen av den valgte tjenesten. I konteksten av revisjonen av den skybaserte plattformen MCS ble følgende mål definert:

1. Analyse av autentisering i tjenesten. Sårbarheter i denne komponenten kunne umiddelbart gi tilgang til andres kontoer.
2. Studie av rollemodellen og tilgangsbegrensninger mellom forskjellige kontoer. For en angriper er muligheten til å få tilgang til en annen virtuell maskin et ønskelig mål.
3. Sårbarheter i klientdelen. XSS/CSRF/CRLF/etc. Finnes det muligheter for å angripe andre brukere via ondsinnede lenker?
4. Sårbarheter i serverdelen: RCE og diverse injeksjoner (SQL/XXE/SSRF osv.). Server-sårbarheter er vanligvis vanskeligere å finne, men de fører til kompromittering av flere brukere på en gang.
5. Analyse av isolering av brukersegmenter på nettverksnivå. For en angriper øker mangel på isolasjon angrepsflaten betydelig for andre brukere.
6. Analyse av forretningslogikk. Kan man lure bedriften til å opprette virtuelle maskiner gratis?

I dette prosjektet ble arbeidet utført med en «Gray-box» modell: revisorer interagerte med tjenesten med privilegier som vanlige brukere, men hadde delvis tilgang til kildekoden til API-en og muligheten til å avklare detaljer med utviklerne. Vanligvis er dette den mest praktiske, men også realistiske arbeidsmodellen: intern informasjon kan fortsatt samles av en angriper, det er bare et spørsmål om tid.

Funnet sårbarheter

Før revisoren begynner å sende forskjellige payloads (nyttelast for å gjennomføre angrepet) til tilfeldige steder, er det nødvendig å forstå hvordan alt fungerer, og hvilken funksjonalitet som finnes. Det kan virke som en unyttig aktivitet, siden det i de fleste undersøkte steder ikke vil være noen sårbarheter. Men kun forståelsen av applikasjonens struktur og logikken i dens drift vil gi mulighet til å finne de mest komplekse angrepsvektorene.

Det er viktig å finne steder som virker suspekte eller som avviker betydelig fra andre. Og den første farlige sårbarheten ble faktisk funnet på akkurat denne måten.

IDOR

IDOR-sårbarheter (Insecure Direct Object Reference, usikre direkte objektreferanser) er en av de vanligste typene sårbarheter innenfor forretningslogikk, som på en eller annen måte lar uautoriserte få tilgang til objekter de ikke har tillatelse til å se. IDOR-sårbarheter gir mulighet til å hente informasjon om brukere med variabel kritikalitet.

En variant av IDOR er å utføre handlinger med systemobjekter (brukere, bankkonti, produkter i handlekurven) ved manipulasjon av tilgangsidentifikatorer til disse objektene. Dette kan føre til de mest uforutsigbare konsekvenser. For eksempel kan det gi mulighet til å bytte senderkonto for pengeoverføringer, og dermed stjele penger fra andre brukere.

I MCS-tilfellet oppdaget revisorer akkurat en IDOR-sårbarhet relatert til usikre identifikatorer. I brukerens personlige område ble UUID-identifikatorer brukt for å få tilgang til alle objekter, som virket, som sikkerhetsfagfolk sier, imponerende ubrytelige (det vil si beskyttet mot brute-force-angrep). Men for bestemte entiteter ble det oppdaget at vanlige forutsigbare tall ble brukt for å hente informasjon om brukerne av applikasjonen. Jeg tror du kan gjette at man kunne endre bruker-ID-en med én, sende forespørselen på nytt og på den måten få informasjon utenom ACL (access control list, datatilgangsregler for prosesser og brukere).

Server Side Request Forgery (SSRF)

OpenSource-produkter er gode fordi det finnes et enormt antall foruminnlegg med detaljerte tekniske beskrivelser av problemer som oppstår, og hvis du er heldig, også med beskrivelser av løsninger. Men denne medaljen har en bakside: kjente sårbarheter er også grundig dokumentert. For eksempel finnes det flotte beskrivelser av sårbarheter på OpenStack-forumet. [XSS] og [SSRF], som ingen ser ut til å være ivrige etter å fikse.

En vanlig funksjonalitet i applikasjoner er muligheten for brukeren å sende en lenke til serveren, som serveren deretter oppholder seg på (for eksempel for å laste opp et bilde fra en angitt kilde). Med utilstrekkelig filtrering av sikkerhetsmidler for de faktiske lenkene eller responsene som serveren gir til brukerne, kan ondsinnede aktører enkelt utnytte slik funksjonalitet.

SSRF-sårbarheter kan sterkt fremme utviklingen av angrepet. Angriperen kan få:

• begrenset tilgang til det angrepne lokale nettverket, for eksempel bare til bestemte nettverkssegmenter og via et bestemt protokoll;
• full tilgang til det lokale nettverket, hvis det er mulig å nedgradere fra applikasjonsnivå til transportnivå, og dermed full kontroll over belastningen på applikasjonsnivå;
• tilgang til å lese lokale filer på serveren (hvis file:/// schema støttes);
• og mye mer.

I OpenStack har en SSRF-sårbarhet lenge vært kjent med en "blind" karakter: når du kontakter serveren får du ikke noe svar, men du mottar ulike typer feil/ventetid, avhengig av resultatet av forespørselen. Basert på dette kan man gjennomføre portskanning på verter i det interne nettverket, med alle følger som ikke bør undervurderes. For eksempel kan det være et API for back-office, tilgjengelig kun fra det lokale nettverket. Med dokumentasjon ( Ikke glem innsiderne) kan en angriper bruke SSRF for å kontakte interne metoder. For eksempel, hvis det på en eller annen måte har lykkes å får en omtrentlig liste over nyttige URL-er, kan man bruke SSRF for å navigere gjennom dem og utføre forespørselen - for å si det slik, overføre penger fra en konto til en annen eller endre grenser.

Dette er ikke første gang SSRF-sårbarhet er oppdaget i OpenStack. Tidligere var det mulig å laste opp ISO-bilder av VM-er via direkte linker, noe som også førte til lignende konsekvenser. Denne funksjonen er nå fjernet fra OpenStack. Muligens anså fellesskapet dette som den enkleste og mest pålitelige løsningen på problemet.

Og i dette en offentlig tilgjengelig rapport fra tjenesten HackerOne (h1) fører utnyttelse av ikke-blind SSRF med mulighet for å lese metadata av instansen til å oppnå Root-tilgang til hele Shopify-infrastrukturen.

I MCS ble det oppdaget SSRF-sårbarheter på to steder med lignende funksjonalitet, men de var praktisk talt umulige å utnytte på grunn av brannmurer og andre beskyttelser. Uansett har MCS-teamet fikset dette problemet, uten å vente på fellesskapet.

XSS i stedet for å laste opp "shells"

Til tross for hundrevis av skrevne studier, er XSS (Cross-Site Scripting-angrep) fremdeles den mest utbredte web-sårbarheten (eller angrepet?).

Filopplasting er et yndet sted for enhver sikkerhetsforsker. Det viser seg ofte at man kan laste opp vilkårlige skript (asp/jsp/php) og utføre OS-kommandoer, i terminologien til pentestere kalt å «laste opp en shell». Men populariteten til slike sårbarheter fungerer begge veier: folk husker dem og utvikler verktøy mot dem, så sannsynligheten for å «laste opp en shell» har de siste årene nærmet seg null.

Angrepslaget (representert av Digital Security) hadde flaks. Greit, i MCS ble innholdet av de opplastede filene kontrollert på serveren; kun bilder ble tillatt. Men SVG er også et bilde. Hva kan være farlig med SVG-filer? Det at man kan integrere JavaScript-fragmenter i dem!

Det viste seg at de opplastede filene var tilgjengelige for alle brukere av MCS-tjenesten — noe som betyr at man kunne angripe andre brukere av skyen, nemlig administratorer.

Eksempel på injeksjon via en XSS-angrep phishing-logginn-skjema.

Eksempler på utnyttelse av XSS-angrep:

• Hvorfor prøve å stjele en økt (spesielt siden det nå er HTTP-Only-cookies beskyttet mot tyveri via js-skript) når det opplastede skriptet kan kommunisere direkte med ressursens API? I så fall kan nyttelasten gjennom XHR-forespørslene endre serverkonfigurasjonen, for eksempel legge til en åpen SSH-nøkkel for angriperen og oppnå SSH-tilgang til serveren.
• Hvis CSP-politikken (Content Security Policy) forbyr injeksjon av JavaScript, kan angriperen klare seg uten det. Med kun HTML kan man lage en falsk innloggingsform og stjele administratorpassordet gjennom en slik avansert phishing-teknikk: phishing-siden for brukeren vises på samme URL, noe som gjør det vanskeligere for brukeren å oppdage.
• Til slutt kan angriperen utføre en klient-DoS — ved å sette Cookies til en størrelse større enn 4 kB. Brukeren trenger bare å åpne lenken én gang — og hele nettstedet blir utilgjengelig, inntil man innser at man må tømme nettleseren sin: i de fleste tilfeller vil webserveren nekte å ta imot en slik klient.

La oss se på eksempelet med enda en oppdaget XSS, denne gangen med en mer utspekulert utnyttelse. Tjenesten MCS lar deg gruppere brannmurinnstillinger. Det var XSS i navnet på gruppen. Dens spesialitet var at vektoren ikke ble aktivert umiddelbart, ikke ved visning av regeloversikten, men ved sletting av gruppen:

Det vil si, scenariet ble følgende: en angriper lager en brannmurregel med «belastning» i navnet, administratoren legger merke til det etter en stund, og initierer prosessen med å slette det. Og da slår den skadelige JS inn.

Utviklerne av MCS anbefalte for å beskytte mot XSS i opplastede SVG-bilder (hvis de ikke kan unngås):

• Å plassere filer som lastes opp av brukere på et separat domene, som ikke har noe med «kakene» å gjøre. Skriptet vil bli utført i konteksten av et annet domene og vil ikke utgjøre en trussel mot MCS.
• Å gi headeren «Content-disposition: attachment» i HTTP-serverens svar. Da vil filene bli lastet ned av nettleseren i stedet for å bli utført.

I tillegg er det nå mange metoder tilgjengelige for utviklere for å dempe risikoen for utnyttelse av XSS:

• ved hjelp av flagget «HTTP Only» kan sesjonsheaderne «Cookies» gjøres utilgjengelige for skadelig JavaScript;
• en riktig implementert CSP-politikk vil betydelig komplisere utnyttelse av XSS for en angriper;
• moderne malere, som Angular eller React, renser automatisk brukerdata før de vises i brukerens nettleser.

Sårbarheter i tofaktorautentisering

For å øke sikkerheten til kontoene anbefales det alltid at brukerne aktiverer 2FA (tofaktorautentisering). Faktisk er dette en effektiv måte å hindre en angriper i å få tilgang til tjenesten hvis brukerens legitimasjon er kompromittert.

Men gir alltid bruk av den andre autentiseringsfaktoren garanti for at kontoen forblir sikker? I implementeringen av 2FA kan det oppstå følgende sikkerhetsproblemer:

• Grovt gjettingsangrep på OTP-koden (engangskodene). Til tross for enkelheten i utnyttelsen, finnes slike feil, som mangel på beskyttelse mot bruteforce OTP, også hos store selskaper: tilfellet Slack, tilfellet Facebook.
• En svak genereringsalgoritme, for eksempel muligheten til å forutsi neste kode.
• Logiske feil, som muligheten til å be om noen andres OTP på sin egen telefon, slik som det var hos Shopify.

I tilfelle MCS er 2FA implementert på basis av Google Authenticator og Duo. Selve protokollen er allerede testet over tid, men implementeringen av koden på applikasjonssiden bør sjekkes.

I MCS brukes 2FA flere steder:

• Ved autentisering av brukeren. Det er beskyttelse mot brute-force angrep her: brukeren har bare et begrenset antall forsøk med engangspassordet, deretter blir inntastingen blokkert i en periode. Dette hindrer muligheten for å gjette OTP gjennom brute-forcing.
• Ved generering av offline backup-koder for å utføre 2FA, samt når denne deaktiveres. Her var det ikke implementert noen bruksbeskyttelse, noe som tillot, med riktig passord for kontoen og en aktiv økt, å regenerere backup-koder eller deaktivere 2FA helt.

Gitt at backup-kodene lå innen samme verdiområde som de genererte OTP-ene, var sjansen for å gjette koden på kort tid betydelig høyere.

Prosessen med å gjette OTP for å deaktivere 2FA ved hjelp av verktøyet «Burp: Intruder».

Resultatet

Totalt sett har MCS som produkt vist seg å være sikkert. I løpet av revisjonen klarte pentest-teamet ikke å få tilgang til kundens VM-er og deres data, og de identifiserte sårbarhetene ble raskt utbedret av MCS-teamet.

Men det er viktig å merke seg at sikkerhet er en kontinuerlig prosess. Tjenester er ikke statiske, de utvikler seg stadig. Å utvikle et produkt helt uten sårbarheter er umulig. Men man kan oppdage dem i tide og redusere sjansen for at de oppstår igjen.

Nå er alle de nevnte sårbarhetene i MCS allerede utbedret. For å gjøre antallet nye sårbarheter minimalt og redusere tiden de eksisterer, fortsetter plattformteamet å gjøre følgende:

• gjennomføre regelmessige revisjoner med eksterne selskaper;
• opprettholde og utvikle deltakelsen i Bug Bounty-programmet til Mail.ru Group;;
• arbeide med sikkerhet. 🙂

Kilde: habr.com