af SeerLight
Opbygning af enhver service omfatter nødvendigvis konstant arbejde med sikkerhed. Sikkerhed er en kontinuerlig proces, der inkluderer konstant analyse og forbedring af produktsikkerhed, overvågning af nyheder om sårbarheder og meget mere. Herunder revisioner. Audits udføres både internt og af eksterne eksperter, som radikalt kan hjælpe med sikkerheden, fordi de ikke er fordybet i projektet og har et åbent sind.
Artiklen handler om denne mest ligefremme opfattelse af eksterne eksperter, der hjalp Mail.ru Cloud Solutions (MCS)-teamet med at teste cloud-tjenesten, og om, hvad de fandt. Som en "ekstern kraft" valgte MCS firmaet Digital Security, kendt for sin høje ekspertise i informationssikkerhedskredse. Og i denne artikel vil vi analysere nogle interessante sårbarheder fundet som en del af en ekstern revision – så du undgår den samme rake, når du opretter din egen cloud-tjeneste.
Описание продукта
er en platform til opbygning af virtuel infrastruktur i skyen. Det inkluderer IaaS, PaaS og en markedsplads med færdige applikationsbilleder til udviklere. Under hensyntagen til MCS-arkitekturen var det nødvendigt at kontrollere produktets sikkerhed på følgende områder:
- beskyttelse af virtualiseringsmiljøets infrastruktur: hypervisorer, routing, firewalls;
- beskyttelse af kundernes virtuelle infrastruktur: isolering fra hinanden, herunder netværk, private netværk i SDN;
- OpenStack og dets åbne komponenter;
- S3 af vores eget design;
- IAM: projekter med flere lejere med en rollemodel;
- Vision (computer vision): API'er og sårbarheder ved arbejde med billeder;
- webgrænseflade og klassiske webangreb;
- sårbarheder af PaaS-komponenter;
- API af alle komponenter.
Måske er det alt, der er afgørende for videre historie.
Hvilken slags arbejde blev udført, og hvorfor var det nødvendigt?
En sikkerhedsrevision er rettet mod at identificere sårbarheder og konfigurationsfejl, der kan føre til lækage af personlige data, ændring af følsomme oplysninger eller forstyrrelse af tjenestens tilgængelighed.
Under arbejdet, som i gennemsnit varer 1-2 måneder, gentager revisorer potentielle angriberes handlinger og leder efter sårbarheder i klient- og serverdelene af den valgte tjeneste. I forbindelse med revisionen af MCS-skyplatformen blev følgende mål identificeret:
- Analyse af autentificering i tjenesten. Sårbarheder i denne komponent ville hjælpe til straks at komme ind på andres konti.
- At studere rollemodellen og adgangskontrol mellem forskellige konti. For en angriber er muligheden for at få adgang til en andens virtuelle maskine et ønskeligt mål.
- Sårbarheder på klientsiden. XSS/CSRF/CRLF/osv. Er det muligt at angribe andre brugere gennem ondsindede links?
- Serverside sårbarheder: RCE og alle former for injektioner (SQL/XXE/SSRF og så videre). Serversårbarheder er generelt sværere at finde, men de fører til, at mange brugere går på kompromis på én gang.
- Analyse af brugersegmentisolering på netværksniveau. For en angriber øger manglen på isolation i høj grad angrebsfladen mod andre brugere.
- Forretningslogikanalyse. Er det muligt at bedrage virksomheder og skabe virtuelle maskiner gratis?
I dette projekt blev arbejdet udført i henhold til "Gray-box"-modellen: revisorer interagerede med tjenesten med almindelige brugeres privilegier, men besad delvist API'ens kildekode og havde mulighed for at afklare detaljer med udviklerne. Dette er normalt den mest bekvemme, og samtidig ret realistiske arbejdsmodel: intern information kan stadig indsamles af en angriber, det er kun et spørgsmål om tid.
Sårbarheder fundet
Inden revisor begynder at sende forskellige nyttelaster (nyttelasten, der bruges til at udføre angrebet) til tilfældige steder, er det nødvendigt at forstå, hvordan tingene fungerer, og hvilken funktionalitet der leveres. Det kan virke som om det er en ubrugelig øvelse, for de fleste af de undersøgte steder vil der ikke være nogen sårbarheder. Men kun at forstå applikationens struktur og logikken i dens drift vil gøre det muligt at finde de mest komplekse angrebsvektorer.
Det er vigtigt at finde steder, der virker mistænkelige eller på en eller anden måde er meget forskellige fra andre. Og den første farlige sårbarhed blev fundet på denne måde.
IDOR
IDOR (Insecure Direct Object Reference) sårbarheder er en af de mest almindelige sårbarheder i forretningslogik, som gør det muligt for en eller anden at få adgang til objekter, som der faktisk ikke er adgang til. IDOR-sårbarheder skaber mulighed for at indhente information om en bruger af varierende grad af kritik.
En af IDOR-mulighederne er at udføre handlinger med systemobjekter (brugere, bankkonti, varer i indkøbskurven) ved at manipulere adgangsidentifikatorer til disse objekter. Dette fører til de mest uforudsigelige konsekvenser. For eksempel muligheden for at erstatte kontoen til afsenderen af midler, hvorigennem du kan stjæle dem fra andre brugere.
I tilfældet med MCS har revisorer netop opdaget en IDOR-sårbarhed forbundet med ikke-sikre identifikatorer. I brugerens personlige konto blev UUID-identifikatorer brugt til at få adgang til ethvert objekt, hvilket virkede, som sikkerhedseksperter siger, imponerende usikkert (det vil sige beskyttet mod brute force-angreb). Men for visse enheder blev det opdaget, at almindelige forudsigelige tal bruges til at få oplysninger om brugerne af applikationen. Jeg tror, du kan gætte på, at det var muligt at ændre bruger-id'et med én, sende anmodningen igen og dermed få information uden om ACL (adgangskontrolliste, dataadgangsregler for processer og brugere).
Server Side Request Forgery (SSRF)
Det gode ved OpenSource-produkter er, at de har et enormt antal fora med detaljerede tekniske beskrivelser af de problemer, der opstår, og hvis du er heldig, en beskrivelse af løsningen. Men denne mønt har en bagside: kendte sårbarheder er også beskrevet i detaljer. For eksempel er der vidunderlige beskrivelser af sårbarheder på OpenStack-forummet и , som ingen af en eller anden grund har travlt med at ordne.
En almindelig funktionalitet ved applikationer er muligheden for, at brugeren kan sende et link til serveren, som serveren klikker på (for eksempel for at downloade et billede fra en specificeret kilde). Hvis sikkerhedsværktøjer ikke filtrerer selve linkene eller svarene, der returneres fra serveren til brugerne, kan en sådan funktionalitet nemt bruges af angribere.
SSRF-sårbarheder kan i høj grad fremme udviklingen af et angreb. En angriber kan få:
- begrænset adgang til det angrebne lokale netværk, for eksempel kun gennem bestemte netværkssegmenter og ved hjælp af en bestemt protokol;
- fuld adgang til det lokale netværk, hvis nedgradering fra applikationsniveau til transportniveau er muligt og som et resultat fuld belastningsstyring på applikationsniveau;
- adgang til at læse lokale filer på serveren (hvis file:///-skemaet understøttes);
- og meget mere.
En SSRF-sårbarhed har længe været kendt i OpenStack, som er "blind" af natur: når du kontakter serveren, modtager du ikke svar fra den, men du modtager forskellige typer fejl/forsinkelser, afhængigt af resultatet af anmodningen . På baggrund af dette kan du udføre en portscanning på værter på det interne netværk, med alle de deraf følgende konsekvenser, som ikke skal undervurderes. For eksempel kan et produkt have en back-office API, der kun er tilgængelig fra virksomhedens netværk. Med dokumentation (glem ikke insiders) kan en angriber bruge SSRF til at få adgang til interne metoder. For eksempel, hvis du på en eller anden måde var i stand til at få en omtrentlig liste over nyttige URL'er, så ved hjælp af SSRF kan du gå dem igennem og udføre en anmodning - relativt set, overføre penge fra konto til konto eller ændre grænser.
Det er ikke første gang, en SSRF-sårbarhed er blevet opdaget i OpenStack. Tidligere var det muligt at downloade VM ISO-billeder fra et direkte link, hvilket også førte til lignende konsekvenser. Denne funktion er nu blevet fjernet fra OpenStack. Tilsyneladende betragtede samfundet dette som den enkleste og mest pålidelige løsning på problemet.
Og i offentligt tilgængelig rapport fra HackerOne-tjenesten (h1), udnyttelse af en ikke længere blind SSRF med mulighed for at læse instansmetadata fører til root-adgang til hele Shopify-infrastrukturen.
I MCS blev SSRF-sårbarheder opdaget to steder med lignende funktionalitet, men de var næsten umulige at udnytte på grund af firewalls og andre beskyttelser. På en eller anden måde løste MCS-teamet dette problem alligevel uden at vente på fællesskabet.
XSS i stedet for at indlæse skaller
På trods af hundredvis af undersøgelser skrevet, år efter år er XSS (cross-site scripting) angreb stadig det mest websårbarhed (eller ?).
Filupload er et yndet sted for enhver sikkerhedsforsker. Det viser sig ofte, at du kan indlæse et vilkårligt script (asp/jsp/php) og udføre OS-kommandoer i pentesternes terminologi - "load shell". Men populariteten af sådanne sårbarheder virker i begge retninger: de huskes, og der udvikles midler mod dem, så for nylig er sandsynligheden for at "indlæse en skal" til nul.
Det angribende hold (repræsenteret af Digital Security) var heldige. OK, i MCS på serversiden blev indholdet af de downloadede filer kontrolleret, kun billeder var tilladt. Men SVG er også et billede. Hvordan kan SVG-billeder være farlige? Fordi du kan indlejre JavaScript-uddrag i dem!
Det viste sig, at de downloadede filer er tilgængelige for alle brugere af MCS-tjenesten, hvilket betyder, at det er muligt at angribe andre cloud-brugere, nemlig administratorer.
Et eksempel på et XSS-angreb på en phishing-loginformular
Eksempler på udnyttelse af XSS-angreb:
- Hvorfor prøve at stjæle en session (især fordi nu kun HTTP-cookies er overalt, beskyttet mod tyveri ved hjælp af js-scripts), hvis det indlæste script umiddelbart kan få adgang til ressource-API'en? I dette tilfælde kan nyttelasten bruge XHR-anmodninger til at ændre serverkonfigurationen, for eksempel tilføje angriberens offentlige SSH-nøgle og få SSH-adgang til serveren.
- Hvis CSP-politikken (indholdsbeskyttelsespolitik) forbyder JavaScript i at blive injiceret, kan en angriber klare sig uden det. Brug ren HTML til at oprette en falsk login-formular til webstedet og stjæle administratorens adgangskode gennem dette avancerede phishing: phishing-siden for brugeren ender på den samme URL, og det er sværere for brugeren at opdage det.
- Endelig kan angriberen arrangere — sæt cookies større end 4 KB. Brugeren behøver kun at åbne linket én gang, og hele webstedet bliver utilgængeligt, indtil brugeren tænker på at rense browseren specifikt: I langt de fleste tilfælde vil webserveren nægte at acceptere en sådan klient.
Lad os se på et eksempel på en anden opdaget XSS, denne gang med en mere smart udnyttelse. MCS-tjenesten giver dig mulighed for at kombinere firewall-indstillinger i grupper. Gruppenavnet var der, hvor XSS blev fundet. Dens ejendommelighed var, at vektoren ikke blev udløst med det samme, ikke når man ser listen over regler, men når man sletter en gruppe:
Det vil sige, at scenariet viste sig at være følgende: en angriber opretter en firewall-regel med "load" i navnet, administratoren bemærker det efter et stykke tid og starter sletningsprocessen. Og det er her den ondsindede JS virker.
For at MCS-udviklere skal beskytte mod XSS i uploadede SVG-billeder (hvis de ikke kan udelades), anbefalede Digital Security-teamet:
- Placer filer uploadet af brugere på et separat domæne, der ikke har noget at gøre med "cookies". Scriptet vil blive eksekveret i konteksten af et andet domæne og vil ikke udgøre en trussel mod MCS.
- Send "Content-disposition: attachment"-headeren i serverens HTTP-svar. Så vil filerne blive downloadet af browseren og ikke eksekveret.
Derudover er der nu mange måder tilgængelige for udviklere til at mindske risiciene ved XSS-udnyttelse:
- ved at bruge "Kun HTTP"-flaget kan du gøre sessions-"Cookies"-headere utilgængelige for ondsindet JavaScript;
- vil gøre det meget sværere for en angriber at udnytte XSS;
- moderne skabelonmotorer såsom Angular eller React renser automatisk brugerdata, før de udsendes til brugerens browser.
To-faktor autentificeringssårbarheder
For at forbedre kontosikkerheden rådes brugerne altid til at aktivere 2FA (to-faktor-godkendelse). Dette er faktisk en effektiv måde at forhindre en hacker i at få adgang til en tjeneste, hvis brugerens legitimationsoplysninger er blevet kompromitteret.
Men garanterer brug af en anden godkendelsesfaktor altid kontosikkerhed? Der er følgende sikkerhedsproblemer i implementeringen af 2FA:
- Brute-force søgning af OTP-koden (engangskoder). På trods af betjeningens enkelhed støder store virksomheder også på fejl som manglende beskyttelse mod OTP brute force: , .
- Svag generationsalgoritme, for eksempel evnen til at forudsige den næste kode.
- Logiske fejl, såsom evnen til at anmode om en andens OTP på din telefon, som dette fra Shopify.
I tilfælde af MCS er 2FA implementeret baseret på Google Authenticator og . Selve protokollen er allerede blevet tidstestet, men implementeringen af kodeverifikation på applikationssiden er værd at tjekke.
MCS 2FA bruges flere steder:
- Ved autentificering af brugeren. Der er beskyttelse mod brute force: brugeren har kun få forsøg på at indtaste et engangskodeord, derefter blokeres indtastningen i et stykke tid. Dette blokerer muligheden for brute-force valg af OTP.
- Når du genererer offline backup-koder for at udføre 2FA, samt deaktiverer den. Her blev der ikke implementeret nogen brute force-beskyttelse, hvilket gjorde det muligt, hvis du havde en adgangskode til kontoen og en aktiv session, at regenerere backup-koder eller deaktivere 2FA helt.
I betragtning af, at backupkoderne var placeret i det samme område af strengværdier som dem, der blev genereret af OTP-applikationen, var chancen for at finde koden på kort tid meget højere.
Processen med at vælge en OTP for at deaktivere 2FA ved hjælp af "Burp: Intruder"-værktøjet
Outcome
Generelt ser MCS ud til at være sikkert som et produkt. Under revisionen var det testende team ikke i stand til at få adgang til klient-VM'er og deres data, og de fundne sårbarheder blev hurtigt rettet af MCS-teamet.
Men her er det vigtigt at bemærke, at sikkerhed er et kontinuerligt arbejde. Tjenester er ikke statiske, de er i konstant udvikling. Og det er umuligt at udvikle et produkt helt uden sårbarheder. Men du kan finde dem i tide og minimere chancen for, at de gentager sig.
Nu er alle de nævnte sårbarheder i MCS allerede blevet rettet. Og for at holde antallet af nye på et minimum og reducere deres levetid, fortsætter platformteamet med at gøre dette:
- regelmæssigt udføre revisioner af eksterne virksomheder;
- understøtte og udvikle deltagelse;
- engagere sig i sikkerhed. 🙂
Kilde: www.habr.com