av SeerLight
Å bygge en hvilken som helst tjeneste inkluderer nødvendigvis konstant arbeid med sikkerhet. Sikkerhet er en kontinuerlig prosess som inkluderer konstant analyse og forbedring av produktsikkerhet, overvåking av nyheter om sårbarheter og mye mer. Inkludert revisjoner. Tilsyn utføres både internt og av eksterne eksperter, som i stor grad kan hjelpe med sikkerheten fordi de ikke er fordypet i prosjektet og har et objektivt syn.
Artikkelen handler om dette mest enkle synet til eksterne eksperter som hjalp Mail.ru Cloud Solutions (MCS)-teamet med å teste skytjenesten, og om hva de fant. Som en "ekstern styrke" valgte MCS selskapet Digital Security, kjent for sin høye ekspertise innen informasjonssikkerhetskretser. Og i denne artikkelen vil vi analysere noen interessante sårbarheter funnet som en del av en ekstern revisjon – slik at du unngår samme rake når du lager din egen skytjeneste.
Описание продукта
er en plattform for å bygge virtuell infrastruktur i skyen. Den inkluderer IaaS, PaaS og en markedsplass med ferdige applikasjonsbilder for utviklere. Med tanke på MCS-arkitekturen var det nødvendig å sjekke sikkerheten til produktet på følgende områder:
- beskyttelse av infrastrukturen til virtualiseringsmiljøet: hypervisorer, ruting, brannmurer;
- beskyttelse av kundenes virtuelle infrastruktur: isolasjon fra hverandre, inkludert nettverk, private nettverk i SDN;
- OpenStack og dens åpne komponenter;
- S3 av vårt eget design;
- IAM: prosjekter med flere leietakere med et forbilde;
- Visjon (datasyn): APIer og sårbarheter ved arbeid med bilder;
- nettgrensesnitt og klassiske nettangrep;
- sårbarheter i PaaS-komponenter;
- API for alle komponenter.
Kanskje det er alt som er avgjørende for videre historie.
Hva slags arbeid ble utført og hvorfor var det nødvendig?
En sikkerhetsrevisjon er rettet mot å identifisere sårbarheter og konfigurasjonsfeil som kan føre til lekkasje av personopplysninger, endring av sensitiv informasjon eller forstyrrelse av tjenestetilgjengelighet.
Under arbeidet, som varer i gjennomsnitt 1-2 måneder, gjentar revisorer handlingene til potensielle angripere og ser etter sårbarheter i klient- og serverdelene av den valgte tjenesten. I forbindelse med revisjonen av MCS-skyplattformen ble følgende mål identifisert:
- Analyse av autentisering i tjenesten. Sårbarheter i denne komponenten vil bidra til å umiddelbart komme inn på andres kontoer.
- Studerer rollemodell og tilgangskontroll mellom ulike kontoer. For en angriper er muligheten til å få tilgang til andres virtuelle maskin et ønskelig mål.
- Sårbarheter på klientsiden. XSS/CSRF/CRLF/etc. Er det mulig å angripe andre brukere gjennom ondsinnede lenker?
- Sårbarheter på serversiden: RCE og alle slags injeksjoner (SQL/XXE/SSRF og så videre). Serversårbarheter er generelt vanskeligere å finne, men de fører til kompromisser for mange brukere samtidig.
- Analyse av brukersegmentisolasjon på nettverksnivå. For en angriper øker mangelen på isolasjon angrepsflaten mot andre brukere.
- Forretningslogikkanalyse. Er det mulig å lure bedrifter og lage virtuelle maskiner gratis?
I dette prosjektet ble arbeidet utført i henhold til "Gray-box"-modellen: revisorer samhandlet med tjenesten med privilegiene til vanlige brukere, men hadde delvis kildekoden til API og hadde muligheten til å avklare detaljer med utviklerne. Dette er vanligvis den mest praktiske, og samtidig ganske realistiske arbeidsmodellen: intern informasjon kan fortsatt samles inn av en angriper, det er bare et spørsmål om tid.
Sårbarheter funnet
Før revisor begynner å sende ulike nyttelaster (nyttelasten som brukes til å utføre angrepet) til tilfeldige steder, er det nødvendig å forstå hvordan ting fungerer og hvilken funksjonalitet som tilbys. Det kan virke som om dette er en ubrukelig øvelse, for på de fleste av de undersøkte stedene vil det ikke være noen sårbarheter. Men bare å forstå strukturen til applikasjonen og logikken i driften vil gjøre det mulig å finne de mest komplekse angrepsvektorene.
Det er viktig å finne steder som virker mistenkelige eller er veldig forskjellige fra andre på en eller annen måte. Og den første farlige sårbarheten ble funnet på denne måten.
IDOR
IDOR (Insecure Direct Object Reference) sårbarheter er en av de vanligste sårbarhetene i forretningslogikk, som lar en eller annen få tilgang til objekter som det faktisk ikke er tillatt tilgang til. IDOR-sårbarheter skaper muligheten for å innhente informasjon om en bruker av ulik grad av kritikkverdighet.
Et av IDOR-alternativene er å utføre handlinger med systemobjekter (brukere, bankkontoer, varer i handlekurven) ved å manipulere tilgangsidentifikatorer til disse objektene. Dette fører til de mest uforutsigbare konsekvensene. For eksempel muligheten for å erstatte kontoen til avsenderen av midler, der du kan stjele dem fra andre brukere.
Når det gjelder MCS, oppdaget revisorer nettopp en IDOR-sårbarhet knyttet til ikke-sikre identifikatorer. I brukerens personlige konto ble UUID-identifikatorer brukt for å få tilgang til alle objekter, som virket, som sikkerhetseksperter sier, imponerende usikkert (det vil si beskyttet mot brute force-angrep). Men for visse enheter ble det oppdaget at vanlige forutsigbare tall brukes for å få informasjon om brukerne av applikasjonen. Jeg tror du kan gjette at det var mulig å endre bruker-IDen med én, sende forespørselen på nytt og dermed få informasjon utenom ACL (tilgangskontrollliste, datatilgangsregler for prosesser og brukere).
Server Side Request Forgery (SSRF)
Det som er bra med OpenSource-produkter er at de har et stort antall fora med detaljerte tekniske beskrivelser av problemene som oppstår og, hvis du er heldig, en beskrivelse av løsningen. Men denne mynten har en bakside: kjente sårbarheter er også beskrevet i detalj. For eksempel er det fantastiske beskrivelser av sårbarheter på OpenStack-forumet и , som av en eller annen grunn ingen har det travelt med å fikse.
En vanlig funksjonalitet for applikasjoner er muligheten for brukeren til å sende en lenke til serveren, som serveren klikker på (for eksempel for å laste ned et bilde fra en spesifisert kilde). Hvis sikkerhetsverktøy ikke filtrerer selve koblingene eller svarene som returneres fra serveren til brukerne, kan slik funksjonalitet enkelt brukes av angripere.
SSRF-sårbarheter kan i stor grad fremme utviklingen av et angrep. En angriper kan få:
- begrenset tilgang til det angrepne lokale nettverket, for eksempel bare gjennom visse nettverkssegmenter og ved bruk av en bestemt protokoll;
- full tilgang til det lokale nettverket, hvis nedgradering fra applikasjonsnivå til transportnivå er mulig, og som et resultat full lasthåndtering på applikasjonsnivå;
- tilgang til å lese lokale filer på serveren (hvis file:///-skjemaet støttes);
- og mye mer.
En SSRF-sårbarhet har lenge vært kjent i OpenStack, som er "blind" av natur: når du kontakter serveren får du ikke svar fra den, men du får forskjellige typer feil/forsinkelser, avhengig av resultatet av forespørselen . Basert på dette kan du utføre en portskanning på verter på det interne nettverket, med alle påfølgende konsekvenser som ikke bør undervurderes. Et produkt kan for eksempel ha en back-office API som bare er tilgjengelig fra bedriftsnettverket. Med dokumentasjon (ikke glem innsidere) kan en angriper bruke SSRF for å få tilgang til interne metoder. For eksempel, hvis du på en eller annen måte var i stand til å få en omtrentlig liste over nyttige URL-er, kan du ved å bruke SSRF gå gjennom dem og utføre en forespørsel - relativt sett, overføre penger fra konto til konto eller endre grenser.
Dette er ikke første gang en SSRF-sårbarhet har blitt oppdaget i OpenStack. Tidligere var det mulig å laste ned VM ISO-bilder fra en direkte lenke, noe som også førte til lignende konsekvenser. Denne funksjonen er nå fjernet fra OpenStack. Tilsynelatende anså samfunnet dette som den enkleste og mest pålitelige løsningen på problemet.
Og i offentlig tilgjengelig rapport fra HackerOne-tjenesten (h1), utnyttelse av en ikke lenger blind SSRF med mulighet til å lese instansmetadata fører til root-tilgang til hele Shopify-infrastrukturen.
I MCS ble SSRF-sårbarheter oppdaget to steder med lignende funksjonalitet, men de var nesten umulige å utnytte på grunn av brannmurer og annen beskyttelse. På en eller annen måte løste MCS-teamet dette problemet uansett, uten å vente på fellesskapet.
XSS i stedet for å laste skjell
Til tross for hundrevis av studier skrevet, år etter år er XSS (cross-site scripting) angrep fortsatt det meste nettsårbarhet (eller ?).
Filopplasting er et favorittsted for enhver sikkerhetsforsker. Det viser seg ofte at du kan laste et vilkårlig skript (asp/jsp/php) og utføre OS-kommandoer, i terminologien til pentesters - "load shell". Men populariteten til slike sårbarheter fungerer i begge retninger: de huskes og det utvikles midler mot dem, slik at sannsynligheten for å "laste et skall" nylig har en tendens til null.
Det angripende laget (representert av Digital Security) var heldige. OK, i MCS på serversiden ble innholdet i de nedlastede filene sjekket, kun bilder var tillatt. Men SVG er også et bilde. Hvordan kan SVG-bilder være farlige? Fordi du kan bygge inn JavaScript-snutter i dem!
Det viste seg at de nedlastede filene er tilgjengelige for alle brukere av MCS-tjenesten, noe som betyr at det er mulig å angripe andre skybrukere, nemlig administratorer.
Et eksempel på et XSS-angrep på et phishing-påloggingsskjema
Eksempler på XSS-angrepsutnyttelse:
- Hvorfor prøve å stjele en økt (spesielt siden HTTP-bare informasjonskapsler er overalt, beskyttet mot tyveri ved hjelp av js-skript), hvis det innlastede skriptet umiddelbart kan få tilgang til ressurs-API? I dette tilfellet kan nyttelasten bruke XHR-forespørsler til å endre serverkonfigurasjonen, for eksempel legge til angriperens offentlige SSH-nøkkel og få SSH-tilgang til serveren.
- Hvis CSP-policyen (policy for innholdsbeskyttelse) forbyr JavaScript fra å bli injisert, kan en angriper klare seg uten. Bruk ren HTML, lag et falskt påloggingsskjema for nettstedet og stjel administratorens passord gjennom denne avanserte phishing: phishing-siden for brukeren ender opp på samme URL, og det er vanskeligere for brukeren å oppdage den.
- Endelig kan angriperen ordne — angi informasjonskapsler som er større enn 4 KB. Brukeren trenger bare å åpne lenken én gang, og hele siden blir utilgjengelig inntil brukeren tenker å spesifikt rense nettleseren: i de aller fleste tilfeller vil webserveren nekte å akseptere en slik klient.
La oss se på et eksempel på en annen oppdaget XSS, denne gangen med en mer smart utnyttelse. MCS-tjenesten lar deg kombinere brannmurinnstillinger i grupper. Gruppenavnet var der XSS ble oppdaget. Dets særegne var at vektoren ikke ble utløst umiddelbart, ikke når du ser på listen over regler, men når du sletter en gruppe:
Det vil si at scenariet viste seg å være følgende: en angriper oppretter en brannmurregel med "load" i navnet, administratoren legger merke til det etter en stund og starter sletteprosessen. Og det er her den ondsinnede JS fungerer.
For MCS-utviklere, for å beskytte mot XSS i nedlastede SVG-bilder (hvis de ikke kan forlates), anbefalte Digital Security-teamet:
- Plasser filer lastet opp av brukere på et eget domene som ikke har noe med "informasjonskapsler" å gjøre. Skriptet vil bli utført i sammenheng med et annet domene og vil ikke utgjøre en trussel mot MCS.
- Send "Content-disposition: attachment"-overskriften i serverens HTTP-svar. Da vil filene lastes ned av nettleseren og ikke kjøres.
I tillegg er det nå mange måter tilgjengelig for utviklere for å redusere risikoen ved XSS-utnyttelse:
- ved å bruke «bare HTTP»-flagget kan du gjøre «Cookies»-overskrifter for økter utilgjengelige for ondsinnet JavaScript;
- vil gjøre det mye vanskeligere for en angriper å utnytte XSS;
- moderne malmotorer som Angular eller React renser automatisk brukerdata før de sendes ut til brukerens nettleser.
Tofaktorautentiseringssårbarheter
For å forbedre kontosikkerheten anbefales brukere alltid å aktivere 2FA (tofaktorautentisering). Dette er faktisk en effektiv måte å forhindre at en angriper får tilgang til en tjeneste hvis brukerens legitimasjon har blitt kompromittert.
Men garanterer bruk av en andre autentiseringsfaktor alltid kontosikkerhet? Det er følgende sikkerhetsproblemer i implementeringen av 2FA:
- Brute-force-søk av OTP-koden (engangskoder). Til tross for enkelheten i operasjonen, støter også store selskaper på feil som mangel på beskyttelse mot OTP brute force: , .
- Svak generasjonsalgoritme, for eksempel muligheten til å forutsi neste kode.
- Logiske feil, for eksempel muligheten til å be om andres OTP på telefonen din, som dette fra Shopify.
Når det gjelder MCS, er 2FA implementert basert på Google Authenticator og . Selve protokollen er allerede tidstestet, men implementeringen av kodeverifisering på applikasjonssiden er verdt å sjekke.
MCS 2FA brukes flere steder:
- Ved autentisering av brukeren. Det er beskyttelse mot brute force: brukeren har bare noen få forsøk på å skrive inn et engangspassord, deretter blokkeres inngangen en stund. Dette blokkerer muligheten for brute-force valg av OTP.
- Når du genererer offline sikkerhetskopikoder for å utføre 2FA, samt deaktiverer den. Her ble det ikke implementert brute force-beskyttelse, noe som gjorde det mulig, hvis du hadde et passord til kontoen og en aktiv økt, å regenerere backup-koder eller deaktivere 2FA helt.
Tatt i betraktning at reservekodene var plassert i samme område av strengverdier som de genererte av OTP-applikasjonen, var sjansen for å finne koden på kort tid mye høyere.
Prosessen med å velge en OTP for å deaktivere 2FA ved å bruke "Burp: Intruder"-verktøyet
Resultat
Totalt sett ser MCS ut til å være trygt som produkt. Under tilsynet klarte ikke det testende teamet å få tilgang til klient-VM-er og deres data, og sårbarhetene som ble funnet ble raskt rettet av MCS-teamet.
Men her er det viktig å merke seg at sikkerhet er et kontinuerlig arbeid. Tjenester er ikke statiske, de er i konstant utvikling. Og det er umulig å utvikle et produkt helt uten sårbarheter. Men du kan finne dem i tide og minimere sjansen for at de gjentar seg.
Nå er alle de nevnte sårbarhetene i MCS allerede fikset. Og for å holde antallet nye på et minimum og redusere levetiden deres, fortsetter plattformteamet å gjøre dette:
- regelmessig gjennomføre revisjoner av eksterne selskaper;
- støtte og utvikle deltakelse;
- engasjere seg i sikkerhet. 🙂
Kilde: www.habr.com