af SeerLight
Opbygning af enhver service indebærer nødvendigvis konstant arbejde med sikkerhed. Sikkerhed er en kontinuerlig proces, der involverer løbende analyse og forbedring af produktets beskyttelse, overvågning af nyheder omkring sårbarheder og meget mere. Inklusive — revisioner. Revisioner udføres både af interne ressourcer og eksterne eksperter, som kan gøre en væsentlig forskel for sikkerheden, da de ikke er nedsænket i projektet og har et objektivt syn.
Denne artikel handler om denne objektive synsvinkel fra eksterne eksperter, der hjalp Mail.ru Cloud Solutions (MCS) med at teste cloudtjenesten, og hvad de fandt. Som 'eksterne kræfter' valgte MCS virksomheden Digital Security, der er kendt for sin høje ekspertise inden for it-sikkerhed. I denne artikel vil vi gennemgå nogle interessante sårbarheder, der blev fundet under den eksterne revision — så du ikke opnår de samme faldgruber, når du opretter din egen cloudtjeneste.
Produktbeskrivelse
er en platform til opbygning af virtuel infrastruktur i skyen. Den inkluderer IaaS'er, PaaS'er, en markedsplads for færdige applikationsbilleder til udviklere. I betragtning af MCS's arkitektur var det nødvendigt at kontrollere sikkerheden af produktet inden for følgende områder:
- beskyttelse af virtualiseringsmiljøets infrastruktur: hypervisorer, routing, firewalls;
- beskyttelse af kundernes virtuelle infrastruktur: isolering fra hinanden, herunder netværket, private netværk i SDN;
- OpenStack og dets åbne komponenter;
- S3 udviklet in-house;
- IAM: multitenant-projekter med rollemodel;
- Vision (maskinlæring): API og sårbarheder ved billedbehandling;
- webgrænseflade og klassiske webangreb;
- sårbarheder i PaaS-komponenter;
- API for alle komponenter.
Måske er det hele, der er væsentligt for den videre historie.
Hvilke opgaver blev der udført, og hvorfor er de vigtige?
Sikkerhedsrevision er rettet mod at identificere sårbarheder og konfigurationsfejl, der kan føre til lækage af personlige oplysninger, ændring af følsomme informationer eller overtrædelse af tjenesters tilgængelighed.
I løbet af arbejdet, der i gennemsnit varer 1-2 måneder, gentager revisorerne handlingerne fra potentielle angribere og leder efter sårbarheder i den valgte tjenestes klient- og serverside. I forbindelse med revisionen af MCS's cloudplatform blev følgende mål angivet:
- Analyse af autentificering i tjenesten. Sårbarheder i denne komponent ville kunne give direkte adgang til andres konti.
- Undersøgelse af rollemodellen og adskillelse af adgang 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/etc. Er der mulighed for at angribe andre brugere via ondsindede links?
- Sårbarheder på serversiden: RCE og forskellige injektioner (SQL/XXE/SSRF osv.). Serversårbarheder er generelt sværere at finde, men de kan kompromittere mange brugere på én gang.
- Analyse af isolationen af brugersegmenter på netværksniveau. For en angriber øger manglen på isolation angrebsoverfladen markant for andre brugere.
- Analyse af forretningslogik. Kan man bedrage systemet og oprette virtuelle maskiner gratis?
I dette projekt blev arbejdet udført efter modellen 'Gray-box': revisorerne interagerede med tjenesten med privilegier som almindelige brugere, men havde delvist adgang til API-kildekoden og kunne afklare detaljer med udviklerne. Dette er som regel den mest bekvemme og realistiske arbejdsmodel: intern information kan stadig blive samlet af en angriber, det er kun et spørgsmål om tid.
Fundne sårbarheder
Før revisoren begynder at sende forskellige payloads (den nyttige belastning, der bruges til angreb) til tilfældige steder, er det nødvendigt at forstå, hvordan alt fungerer, og hvilken funktionalitet der tilbydes. Det kan virke som en nytteløs opgave, for de fleste af de undersøgte steder vil ikke vise nogen sårbarheder. Men kun forståelsen af applikationens struktur og dens arbejdslogik kan muliggøre opdagelsen af de mest komplekse angrebsvektorer.
Det er vigtigt at finde steder, der virker mistænkelige eller som adskiller sig markant fra andre. Den første farlige sårbarhed blev netop fundet på sådan vis.
IDOR
IDOR-sårbarheder (Insecure Direct Object Reference, usikre direkte objektreferencer) er en af de mest almindelige typer sårbarheder i forretningslogik, der på en eller anden måde giver adgang til objekter, som man faktisk ikke har tilladelse til at tilgå. IDOR-sårbarheder muliggør at få oplysninger om brugere med varierende grader af kritikalitet.
En af varianterne af IDOR er at udføre handlinger med systemobjekter (brugere, bankkonti, varer i indkøbskurven) ved at manipulere med adgangsidentifikatorer til disse objekter. Dette kan føre til de mest uforudsigelige konsekvenser. For eksempel muligheden for at ændre kontoen, der sender penge, hvilket kan bruges til at stjæle fra andre brugere.
I tilfælde af MCS opdagede auditorer netop en IDOR-sårbarhed relateret til usikre identifikatorer. I brugerens kontrolpanel blev der anvendt UUID-identifikatorer til at få adgang til alle objekter, som virkede, som sikkerhedseksperterne siger, uovervindelige (dvs. beskyttede mod brute force-angreb). Men det blev opdaget, at for bestemte entiteter blev der brugt almindelige forudsigelige numre til at få oplysninger om brugere af applikationen. Jeg tror, du kan gætte, at man kunne ændre bruger-ID'et med én, sende forespørgslen igen og dermed få oplysninger uden om ACL (access control list, adgangskontrolregler for data til processer og brugere).
Server Side Request Forgery (SSRF)
OpenSource-produkter er gode, fordi der er et væld af fora med detaljerede tekniske beskrivelser af opståede problemer, og hvis du er heldig, med beskrivelser af løsninger. Men denne medalje har en bagside: kendte sårbarheder er også detaljeret beskrevet. For eksempel findes der på OpenStack-forummet fremragende beskrivelser af sårbarheder og , som der af en eller anden grund ikke er nogen, der skyndter sig med at rette.
En almindelig funktionalitet i applikationer er muligheden for, at brugeren kan sende et link til serveren, som serveren så besøger (f.eks. for at hente et billede fra den angivne kilde). Ved utilstrækkelig filtrering af links eller svar, der returneres fra serveren til brugerne, kan denne funktionalitet nemt udnyttes af angribere.
SSRF-sårbarheder kan væsentligt fremme udviklingen af angreb. En angriber kan opnå:
- begrænset adgang til det angrebne lokale netværk, for eksempel kun til bestemte segmenter af netværket og via en bestemt protokol;
- fuld adgang til det lokale netværk, hvis der er mulighed for nedgradering fra applikationslag til transportlag, hvilket medfører fuld kontrol over belastningen på applikationslaget;
- adgang til læsning af lokale filer på serveren (hvis file:///-skemaet understøttes);
- og meget mere.
I OpenStack har den blinde SSRF-sårbarhed længe været kendt: når du kontakter serveren, får du ikke et svar fra den, men derimod forskellige typer fejl/forsinkelser afhængigt af resultatet af anmodningen. Baseret på dette kan der udføres portscanning på værter i det interne netværk, med alle de konsekvenser, som ikke bør undervurderes. For eksempel kan produktet have en API til backoffice, der kun er tilgængelig fra det virksomhedsnette. Med dokumentation (huske insidere) kan en angriber via SSRF tilgå interne metoder. For eksempel, hvis man på en eller anden måde har fået en omtrentlig liste over nyttige URL'er, kan man ved hjælp af SSRF udføre anmodninger til dem — for eksempel overføre penge fra én konto til en anden eller ændre grænser.
Dette er ikke første gang, en SSRF-sårbarhed er blevet opdaget i OpenStack. Tidligere var der en mulighed for at uploade VM ISO-billeder via direkte links, hvilket også førte til lignende konsekvenser. I øjeblikket er denne funktion fjernet fra OpenStack. Tilsyneladende mente fællesskabet, at det var den nemmeste og mest pålidelige løsning på problemet.
Og i den offentligt tilgængelige rapport fra HackerOne (h1) fører udnyttelse af en ikke-blind SSRF med mulighed for at læse metadata fra instanser til at opnå root-adgang til hele Shopify-infrastrukturen.
I MCS blev der fundet SSRF-sårbarheder på to steder med lignende funktionalitet, men de var stort set umulige at udnytte på grund af firewalls og andre beskyttelser. Alligevel løste MCS-holdet denne problematik uden at vente på fællesskabet.
XSS i stedet for at uploade 'shells'
På trods af hundredvis af skrevne undersøgelser er XSS (cross-site scripting) stadig den web-sårbarhed (eller ?).
Filupload er et yndlingssted for enhver sikkerhedsforsker. Det viser sig ofte, at man kan uploade vilkårlige scripts (asp/jsp/php) og udføre systemkommandoer, i pentesteres terminologi kaldet "at uploade en shell". Men populariteten af sådanne sårbarheder virker i begge retninger: de bliver husket, og der udvikles værktøjer imod dem, så sandsynligheden for at "uploade en shell" nærmer sig nul i disse dage.
Angrebsteamet (i skikkelse af Digital Security) var heldige. OK, i MCS blev indholdet af de uploadede filer kontrolleret på serversiden, og kun billeder var tilladt. Men SVG er også et billede. Hvad kan være farligt ved SVG-billeder? At man kan integrere JavaScript-kode i dem!
Det viste sig, at de uploadede filer var tilgængelige for alle brugere af MCS-tjesten — hvilket betyder, at man kan angribe andre cloud-brugere, nemlig administratorer.
Eksempel på indsprøjtning ved hjælp af en XSS-attack phishing loginformular
Eksempler på udnyttelse af XSS-angreb:
- Hvorfor forsøge at stjæle en session (især nu hvor der er HTTP-Only cookies, der er beskyttet mod tyveri med js-scripts), når det uploadede script direkte kan tilgå API'en for ressourcen? I dette tilfælde kan payload'en via XHR-forespørgsler ændre serverkonfigurationen, for eksempel ved at tilføje angribernes åbne SSH-nøgle og få SSH-adgang til serveren.
- Hvis CSP-politikken (Content Security Policy) forhindrer indsprøjtning af JavaScript, kan angriberen klare sig uden det. Ved ren HTML kan der laves en falsk loginformular, der stjæler administratorens adgangskode via et så avanceret phishing-angreb: phishing-siden vises for brugeren på den samme URL, hvilket gør det sværere for brugeren at opdage.
- Endelig kan angriberen lave — ved at sende cookies, der er større end 4 KB. Det er nok for brugeren at åbne linket én gang — og hele webstedet bliver utilgængeligt, indtil man forstår, at man skal rydde browseren. I de fleste tilfælde vil webserveren nægte at acceptere en sådan klient.
Lad os overveje et eksempel på endnu en identificeret XSS, denne gang med en mere snedig udnyttelse. Tjenesten MCS tillader at samle firewallindstillinger i grupper. Den opdagede XSS var i gruppenavnet. Dens særhed var, at vektoren ikke blev aktiveret med det samme, ikke ved at se listen over regler, men ved at slette gruppen:
Det vil sige, at scenariet så ud, som følger: en angriber opretter en firewallregel med "byrde" i navnet, administratoren opdager det efter nogen tid og starter processen med at slette det. Og her træder den skadelige JS i kraft.
For at beskytte mod XSS i uploadede SVG-billeder (hvis de ikke kan undgås) har Digital Security-teamet anbefalet udviklerne af MCS:
- At placere filer, der uploades af brugere, på et separat domæne, der ikke har noget at gøre med "cookie". Scriptet vil blive udført i konteksten af et andet domæne og vil ikke udgøre en trussel mod MCS.
- I serverens HTTP-svar skal der gives overskriften "Content-disposition: attachment". Så vil filerne blive downloaded af browseren i stedet for at blive udført.
Derudover er der nu mange måder for udviklere til at afbøde risikoen for udnyttelse af XSS:
- med hjælp af flaget "HTTP Only" kan sessionens "Cookie"-overskrifter gøres utilgængelige for skadelig JavaScript;
- vil betydeligt komplicere udnyttelsen af XSS for en angriber;
- moderne skabelonmotorer som Angular eller React renser automatisk brugergenererede data, før de vises i brugerens browser.
Sårbarheder ved to-faktor autentificering
For at øge sikkerheden for konti anbefales det altid at aktivere 2FA (to-faktor autentificering) for brugerne. Faktisk er det en effektiv måde at forhindre en angriber i at få adgang til tjenesten, hvis brugerens legitimationsoplysninger er kompromitteret.
Men giver brugen af den anden autentificeringsfaktor altid garanti for beskyttelse af kontoen? Der kan opstå sikkerhedsproblemer i implementeringen af 2FA:
- Bruteforce af OTP-kode (engangs-koder). På trods af enkelheden ved udnyttelse, er sådanne fejl, som mangel på beskyttelse mod bruteforce af OTP, til stede selv hos store virksomheder: , .
- Svage genereringsalgoritmer, for eksempel muligheden for at forudse den næste kode.
- Logiske fejl, som muligheden for at anmode om en andens OTP på sin egen telefon, som det er hos Shopify.
I tilfælde af MCS er 2FA implementeret baseret på Google Authenticator og . Selve protokollen er allerede blevet testet over tid, men implementationen af kodekontrol på applikationssiden bør kontrolleres.
I MCS anvendes 2FA flere steder:
- Ved brugerens autentificering. Der er beskyttelse mod brute-force: brugeren har kun et begrænset antal forsøg på at indtaste den engangskode, hvorefter indtastningen blokkeres i en periode. Dette forhindrer muligheden for at gennemføre en brute-force angreb på OTP.
- Ved generering af offline backup-koder til udførelse af 2FA samt ved deaktivering af den. Her er der ikke implementeret beskyttelse mod brute-force, hvilket tillod, at man med adgang til kontoens adgangskode og en aktiv session kunne regenerere backup-koder eller deaktivere 2FA helt.
I betragtning af at backup-koderne lå i samme værdibånd som de genererede OTP fra applikationen, var chancen for at gætte en kode på kort tid betydeligt højere.
Processen for gætning af OTP til deaktivering af 2FA ved hjælp af værktøjet 'Burp: Intruder'
Resultat
Generelt viste MCS som produkt sig at være sikkert. I løbet af revisionen lykkedes det pentest-teamet ikke at få adgang til kundernes VM og deres data, og de fundne sårbarheder blev hurtigt rettet af MCS-teamet.
Men det er vigtigt at bemærke, at sikkerhed er et kontinuerligt arbejde. Tjenester er ikke statiske, de udvikler sig konstant. At udvikle et produkt uden sårbarheder er umuligt. Men man kan opdage dem i tide og minimere chancen for gentagelse.
Nu er alle de nævnte sårbarheder i MCS allerede rettet. For at minimere antallet af nye og reducere deres eksistensperiode fortsætter platformteamet med at gøre følgende:
- gennemføre regelmæssige revisioner af eksterne virksomheder;
- opretholde og udvikle deltagelse;
- arbejde med sikkerhed. 🙂
Kilde: habr.com
