Den første sikkerhedsfejl i Kubernetes blev opdaget

kubernetes-logo

Kubernetes blev langt det mest populære cloudcontainersystem. Så faktisk det var kun et spørgsmål om tid, indtil hans første store sikkerhedsfejl blev opdaget.

Og sådan var det, for for nylig Den første store sikkerhedsfejl i Kubernetes blev frigivet under CVE-2018-1002105, også kendt som mislykket med optrapning af privilegier

Denne store fejl i Kubernetes er et problem, da det er et kritisk CVSS 9.8 sikkerhedshul. I tilfælde af den første store Kubernetes sikkerhedsfejl.

Fejloplysninger

Med et specielt designet anmodningsnetværk kan enhver bruger oprette en forbindelse igennem fra applikationsprogrammeringsgrænsefladeserveren (API) Kubernetes til en backend-server.

Når den er etableret, en hacker kan sende vilkårlige anmodninger over netværksforbindelsen direkte til den backend hvor målet til enhver tid er den server.

Disse anmodninger godkendes med TLS-legitimationsoplysningerne (Transport Layer Security) fra Kubernetes API-server.

Endnu værre er, at i standardkonfigurationen kan alle brugere (godkendt eller ej) køre API-opdagelsesopkald, der giver mulighed for denne eskalering af privilegiet af angriberen.

Med hvilken derefter kan enhver, der kender dette hul, benytte lejligheden til at overtage kommandoen over deres Kubernetes-klynge.

I øjeblikket er der ingen nem måde at opdage, om denne sårbarhed blev brugt tidligere.

Da der foretages uautoriserede anmodninger over en etableret forbindelse, vises de ikke i Kubernetes API-serverreviseringslogfiler eller serverloggen.

Kubernetes_Sikkerhed

Anmodninger vises i kubelet-logfiler eller samlet API-server, men de adskiller sig fra korrekt autoriserede anmodninger og proxyanmodninger via Kubernetes API-server.

Misbrug denne nye sårbarhed i Kubernetes det ville ikke efterlade åbenlyse spor i logfilerne, så nu når Kubernetes-bugten er eksponeret, er det kun et spørgsmål om tid, indtil den bruges.

Med andre ord sagde Red Hat:

Privilegerings eskaleringsfejlen tillader enhver uautoriseret bruger at få fulde administratorrettigheder på enhver computernode, der kører i en Kubernetes-pod.

Dette er ikke kun et tyveri eller en åbning for at injicere ondsindet kode, det kan også reducere applikations- og produktionstjenester inden for en organisations firewall.

Ethvert program, inklusive Kubernetes, er sårbart. Kubernetes-distributører frigiver allerede rettelser.

Red Hat rapporterer, at alle sine Kubernetes-baserede produkter og tjenester, herunder Red Hat OpenShift Container Platform, Red Hat OpenShift Online og Red Hat OpenShift Dedicated er berørt.

Red Hat begyndte at levere patches og serviceopdateringer til berørte brugere.

Så vidt vides, brugte ingen sikkerhedsbruddet til at angribe endnu. Darren Shepard, chefarkitekt og medstifter af Rancher-laboratoriet, opdagede fejlen og rapporterede den ved hjælp af Kubernetes-rapporteringsprocessen for sårbarhed.

Hvordan kan jeg rette denne fejl?

Heldigvis er en løsning til denne fejl allerede frigivet. I hvilken kun bedt om at udføre en Kubernetes-opgradering så de kan vælge nogle af Kubernetes-patchede versioner v1.10.11, v1.11.5, v1.12.3 og v1.13.0-RC.1.

Så hvis du stadig bruger en af ​​Kubernetes v1.0.x-1.9.x-versionerne, anbefales det, at du opgraderer til en fast version.

Hvis de af en eller anden grund ikke kan opdatere Kubernetes og de vil stoppe denne fiasko, det er nødvendigt, at de udfører følgende proces.

Du skal stoppe med at bruge serveraggregater API eller fjerne pod exec / attach / portforward tilladelser til brugere, der ikke skal have fuld adgang til kubelet API.

Jordan Liggitt, Google-softwareingeniør, der fik fejlen, sagde, at disse foranstaltninger sandsynligvis vil være skadelige.

Så den eneste rigtige løsning mod denne sikkerhedsfejl er at udføre den tilsvarende Kubernetes-opdatering.


Efterlad din kommentar

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *

*

*

  1. Ansvarlig for data: AB Internet Networks 2008 SL
  2. Formålet med dataene: Control SPAM, management af kommentarer.
  3. Legitimering: Dit samtykke
  4. Kommunikation af dataene: Dataene vil ikke blive kommunikeret til tredjemand, undtagen ved juridisk forpligtelse.
  5. Datalagring: Database hostet af Occentus Networks (EU)
  6. Rettigheder: Du kan til enhver tid begrænse, gendanne og slette dine oplysninger.