Forskere med Microsoft Security Response Center (MSRC) og Orca Security trakk tilbake denne uken om en kritisk sårbarhet i Microsoft Azure Cosmos DB som påvirker funksjonen Cosmos DB Jupyter Notebooks. Feilen for ekstern kjøring av kode (RCE) gir et portrett av hvordan svakheter i autentiseringsarkitekturen til skybaserte og maskinlæringsvennlige miljøer kan brukes av angripere.
Kalt CosMiss av Orcas forskningsteam, koker sårbarheten ned til en feilkonfigurasjon i hvordan autorisasjonshoder håndteres, som lar uautentiserte brukere få lese- og skrivetilgang til Azure Cosmos DB Notebooks, og injisere og overskrive kode.
Kort sagt, hvis en angriper hadde kjennskap til en Notebooks 'forwardingId', som er UUID for Notebook Workspace, ville de ha hatt fulle tillatelser på Notebook, inkludert lese- og skrivetilgang, og muligheten til å endre filsystemet til beholderen som kjører notatboken», skrev Lidor Ben Shitrit og Roee Sagi fra Orca i en teknisk nedgang av sårbarheten. "Ved å modifisere beholderfilsystemet – også kalt dedikert arbeidsområde for midlertidig hosting for bærbare datamaskiner – var vi i stand til å skaffe RCE i bærbare beholdere."
Azure Cosmos DB, en distribuert NoSQL-database, er designet for å støtte skalerbare apper med høy ytelse med høy tilgjengelighet og lav ventetid. Blant bruken er for IoT-enhetstelemetri og analyse; sanntids detaljhandelstjenester for å kjøre ting som produktkataloger og AI-drevne personaliserte anbefalinger; og globalt distribuerte applikasjoner som strømmetjenester, hente- og leveringstjenester og lignende.
I mellomtiden er Jupyter Notebooks et åpen kildekode interaktivt utviklermiljø (IDE) som brukes av utviklere, dataforskere, ingeniører og forretningsanalytikere for å gjøre alt fra datautforskning og datarensing til statistisk modellering, datavisualisering og maskinlæring. Det er et kraftig miljø bygget for å lage, utføre og dele dokumenter med levende kode, ligninger, visualiseringer og fortellende tekst.
Orca-forskere sier at denne funksjonaliteten gjør en feil i autentiseringen i Cosmos DB Notebooks spesielt risikabelt, siden de "brukes av utviklere til å lage kode og ofte inneholder svært sensitiv informasjon som hemmeligheter og private nøkler innebygd i koden."
Feilen ble introdusert på sensommeren, funnet og avslørt til Microsoft av Orca i begynnelsen av oktober, og fikset innen to dager. Patchen krevde ingen handling fra kundene for å rulle ut på grunn av den distribuerte arkitekturen til Cosmos DB.
Ikke det første sårbarheten funnet i Cosmos
Den innebygde integrasjonen av Jupyter Notebooks i Azure Cosmos DB er fortsatt en funksjon i forhåndsvisningsmodus, men dette er definitivt ikke den første publiserte feilen som finnes i den. Fjorårets forskere med Wiz.io oppdaget en kjede av feil i funksjonen som ga enhver Azure-bruker full admintilgang til andre kunders Cosmos DB-forekomster uten autorisasjon. På den tiden rapporterte forskere at store merker som Coca-Cola, Kohler, Rolls-Royce, Siemens og Symantec alle hadde databasenøkler eksponert.
Risikoen og virkningene av denne siste feilen kan diskuteres mer begrenset i omfang enn den forrige på grunn av en rekke faktorer MSRC la ut i en blogg publisert tirsdag.
I følge MSRC-bloggen ble den utnyttbare feilen avslørt i omtrent to måneder etter at en oppdatering i sommer i et backend-API resulterte i at forespørsler ikke ble autentisert på riktig måte. Den gode nyheten er at sikkerhetsteamet gjennomførte en grundig undersøkelse av aktiviteten og fant ingen tegn til angripere som utnyttet feilen på det tidspunktet.
"Microsoft gjennomførte en undersøkelse av loggdata fra 12. august til 6. oktober og identifiserte ingen brute force-forespørsler som skulle indikere ondsinnet aktivitet," skrev en MSRC-talsperson, som også bemerket at 99.8 % av Azure Cosmos DB-kunder ennå ikke bruker Jupyter Notebooks.
Ytterligere å redusere risikoen er det faktum at videresendings-IDen som brukes i Orca proof-of-concept har en svært kort levetid. Notatbøker kjøres i et midlertidig notatbokarbeidsområde som har en maksimal levetid på én time, hvoretter alle dataene i det arbeidsområdet slettes.
"Den potensielle innvirkningen er begrenset til lese-/skrivetilgang til offerets notatbøker i løpet av tiden deres midlertidige notatbokarbeidsområde er aktivt," forklarte Microsoft. "Sårbarheten, selv med kunnskap om forwardingId, ga ikke muligheten til å kjøre notatbøker, automatisk lagre notatbøker i offerets (valgfrie) tilkoblede GitHub-lager eller tilgang til data i Azure Cosmos DB-kontoen."
