Sikkerhedsmæssige faldgruber i IBM’s cloud-infrastruktur
Et demonstreret angreb fra cybersikkerhedsanalytikere i IBMs cloud-infrastruktur var i stand til at få adgang til den interne server, der blev brugt til at opbygge databasebilleder til kundeimplementeringer.
Sikkerhedsanalytikere undersøgte for nylig IBM Clouds database-as-a-service-infrastruktur og fandt flere sikkerhedsproblemer, der gav dem adgang til den interne server, der blev brugt til at opbygge databaseafbildninger til kundeimplementeringer. Det demonstrerede angreb fremhæver nogle almindelige sikkerhedstilsyn, der kan føre til kompromittering af forsyningskæden i cloud-infrastrukturen.
Angrebet blev udviklet af analytikere fra sikkerhedsfirmaet Wiz og kombinerede en sårbarhed i eskalering af privilegier i IBM Cloud Databases for PostgreSQL-tjenesten med legitimationsoplysninger i klartekst spredt rundt i miljøet og alt for tilladelig intern netværksadgangskontrol, der tillod lateral bevægelse inde i infrastrukturen.
PostgreSQL er et tiltalende mål i cloud-miljøer
Wiz’ revision af IBM Cloud Databases for PostgreSQL var en del af et større forskningsprojekt, der analyserede PostgreSQL-implementeringer på tværs af større cloud-udbydere, der tilbyder denne databasemotor som en del af deres administrerede database-as-a-service-løsninger. Tidligere i år fandt og afslørede Wiz-analytikerne også sårbarheder i PostgreSQL-implementeringerne af Microsoft Azure og Google Cloud Platform (GCP).
Open source PostgreSQL relationel databasemotor har været under udvikling i over 30 år med vægt på stabilitet, høj tilgængelighed og skalerbarhed. Dette komplekse stykke software blev imidlertid ikke designet med en tilladelsesmodel, der er egnet til cloudmiljøer med flere lejere, hvor databaseforekomster skal isoleres fra hinanden og fra den underliggende infrastruktur.
PostgreSQL har kraftfulde funktioner, hvorigennem administratorer kan ændre serverfilsystemet og endda udføre kode gennem databaseforespørgsler, men disse operationer er usikre og skal begrænses i delte cloud-miljøer. I mellemtiden skal andre administratorhandlinger såsom databasereplikering, oprettelse af kontrolpunkter, installation af udvidelser og hændelsesudløsere være tilgængelige for kunderne, for at tjenesten skal være funktionel. Derfor var cloud-tjenesteudbydere (CSP’er) nødt til at komme med løsninger og foretage ændringer i PostgreSQLs tilladelsesmodel for at aktivere disse muligheder, selv når kunder kun opererer med begrænsede konti.
Eskalering af privilegier via SQL-injektion
Mens de analyserede IBM Clouds PostgreSQL-implementering, kiggede Wiz-analytikerne på den logiske replikeringsmekanisme, der er tilgængelig for brugerne. Denne funktion blev implementeret ved hjælp af flere databasefunktioner, herunder en kaldet create_subscription, der ejes og udføres af en databasesuperbruger kaldet ibm.
Da de inspicerede koden for denne funktion, bemærkede analytikerne en SQL-injektionssårbarhed forårsaget af forkert sanering af de argumenter, der blev sendt til den. Dette betød, at de kunne overføre vilkårlige SQL-forespørgsler til funktionen, som derefter ville udføre disse forespørgsler som ibm-superbruger. Analytikerne udnyttede denne fejl via PostgreSQL COPY-sætningen til at udføre vilkårlige kommandoer på den underliggende virtuelle maskine, der var vært for databaseforekomsten og åbnede en omvendt skal.
Med en shell på Linux-systemet begyndte de at foretage en vis rekognoscering for at forstå deres miljø, såsom at liste kørende processer, kontrollere aktive netværksforbindelser, inspicere indholdet af /etc/passwd-filerne, der viser systemets brugere og køre en portscanning på det interne netværk for at opdage andre servere. Den brede havnescanning fangede IBM’s sikkerhedsteam, der kontaktede Wiz-teamet for at spørge om deres aktiviteter.
“Efter at have diskuteret vores arbejde og delt vores tanker med dem, gav de os venligt tilladelse til at forfølge vores forskning og yderligere udfordre sikkerhedsgrænser, hvilket afspejler organisationens sunde sikkerhedskultur,” sagde Wiz-teamet.
Gemte legitimationsoplysninger fører til angreb i forsyningskæden
De indsamlede oplysninger, såsom miljøvariabler, fortalte analytikerne, at de var i en Kubernetes (K8s) pod-container, og efter at have søgt i filsystemet fandt de et K8s API-adgangstoken, der var gemt lokalt i en fil kaldet /var/run/secrets/kubernetes.io/serviceaccount/token. API-tokenet tillod dem at indsamle flere oplysninger om K8s-klyngen, men det viste sig, at alle pods var knyttet til deres konto og fungerede under det samme navneområde. Men det var ikke en blindgyde.
K8s er et containerorkestreringssystem, der bruges til softwareinstallation, hvor containere normalt implementeres fra afbildninger – forudbyggede pakker, der indeholder alle de filer, der er nødvendige for, at en container og dens forudkonfigurerede tjenester kan fungere. Disse billeder gemmes normalt på en containerregistreringsserver, der kan være offentlig eller privat. I tilfælde af IBM Cloud var det et privat containerregister, der krævede godkendelse.
Analytikerne brugte API-tokenet til at læse konfigurationerne af bælgene i deres navnerum og fandt adgangsnøglen til fire forskellige interne containerregistre i disse konfigurationsfiler. Beskrivelsen af denne nyligt fundne nøgle i IBM Clouds identitets- og adgangsstyrings-API (IAM) antydede, at den havde både læse- og skriverettigheder til containerregistrene, hvilket ville have givet analytikerne mulighed for at overskrive eksisterende billeder med useriøse.
Det viste sig imidlertid, at nøglebeskrivelsen var unøjagtig, og de kunne kun downloade billeder. Dette adgangsniveau havde sikkerhedsmæssige konsekvenser, men det udgjorde ikke en direkte trussel mod andre IBM Cloud-kunder, så analytikerne skubbede fremad.
Objektbeholderafbildninger kan indeholde en masse følsomme oplysninger, der bruges under udrulningen og senere bliver slettet, herunder kildekode, interne scripts, der henviser til yderligere tjenester i infrastrukturen, samt legitimationsoplysninger, der er nødvendige for at få adgang til dem. Derfor besluttede analytikerne at downloade alle billeder fra registreringstjenesten og bruge et automatiseret værktøj til at scanne dem efter hemmeligheder, såsom legitimationsoplysninger og API-tokens.
“For at kunne scanne efter hemmeligheder udpakket vi billederne og undersøgt kombinationen af filer, der udgjorde hvert billede,” siger analytikerne. “Containerbilleder er baseret på et eller flere lag; hver kan utilsigtet indeholde hemmeligheder. For eksempel, hvis en hemmelighed findes i et lag, men slettes fra det følgende lag, ville den være helt usynlig inde fra beholderen. Scanning af hvert lag separat kan derfor afsløre yderligere hemmeligheder.”
JSON-manifestfilerne med containerbilleder har en “historie” -sektion, der viser historiske kommandoer, der blev udført under byggeprocessen for hvert billede. I flere sådanne filer fandt analytikerne kommandoer, der havde adgangskoder sendt til dem som kommandolinjeargumenter. Disse omfattede adgangskoder til en IBM Cloud intern FTP-server og et build artefaktlager.
Endelig testede analytikerne, om de kunne få adgang til disse servere inde fra deres container, og det viste sig, at de kunne. Denne alt for tilladte netværksadgang kombineret med de udpakkede legitimationsoplysninger tillod dem at overskrive vilkårlige filer i build-artefaktlageret, der bruges af den automatiserede IBM Cloud-buildproces til at oprette containerbilleder. Disse billeder bruges derefter i kundeimplementeringer, hvilket åbner døren for et forsyningskædeangreb.
“Vores forskning i IBM Cloud Databases for PostgreSQL forstærkede det, vi lærte af andre cloud-leverandører, at ændringer til PostgreSQL-motoren effektivt introducerede nye
sårbarheder over for tjenesten,” siger analytikerne. “Disse sårbarheder kunne have været udnyttet af en hacker som en del af en omfattende udnyttelseskæde, der kulminerede i et forsyningskædeangreb på platformen.”
Lektioner for andre organisationer
Selvom alle disse problemer allerede er blevet rapporteret privat til og rettet af IBM Cloud-teamet, er de ikke unikke for IBM. Ifølge Wiz-teamet er problemet med “spredte hemmeligheder” almindeligt på tværs af alle cloud-miljøer.
Automatiserede build- og implementeringsarbejdsgange efterlader ofte hemmeligheder forskellige steder såsom konfigurationsfiler, Linux-bash-historik, journalfiler og så videre, som udviklere glemmer at slette, når implementeringen er afsluttet. Desuden uploader nogle udviklere ved et uheld hele deres .git- og CircleCI-konfigurationsfiler til produktionsservere. Glemte hemmeligheder, der ofte findes af Wiz-teamet, inkluderer cloud-adgangsnøgler, adgangskoder, CI / CD-legitimationsoplysninger og API-adgangstokens.
Et andet udbredt problem, der spillede en afgørende rolle i IBM Cloud-angrebet, er manglen på streng adgangskontrol mellem produktionsservere og interne CI / CD-systemer. Dette giver ofte angribere mulighed for at bevæge sig sideværts og få et dybere fodfæste i en organisations infrastruktur.
Endelig kan private containerregistre give et væld af oplysninger til angribere, der går ud over legitimationsoplysninger. De kan afsløre oplysninger om kritiske servere inde i infrastrukturen eller kan indeholde kode, der afslører yderligere sårbarheder. Organisationer bør sørge for, at deres containerregistreringsløsninger håndhæver korrekt adgangskontrol og afgrænsning, sagde Wiz-teamet.
Kilde: CSO
Foto: