Sårbarheter i ingress-nginx som möjliggör kodexekvering och kontroll av Kubernetes-kluster

I det under utveckling projektet Kubernetes ingress-kontroller ingress-nginx har fyra sårbarheter upptäckts, som gör det möjligt att köra sin egen kod på servrar inom molnsystem som använder Kubernetes-plattformen och få full privilegierad åtkomst till Kubernetes-klustret. Problemen har tilldelats en kritisk risknivå (9,8 av 10). Forskarna som identifierade problemen gav sårbarheterna kodnamnet IngressNightmare och noterade att sårbarheterna påverkar cirka 43% av molnmiljöerna. Sårbarheterna har åtgärdats i versionerna ingress-nginx 1.11.5 och 1.12.1.

Ingress-kontrollern fungerar som en gateway och används i Kubernetes för att organisera åtkomst från det externa nätverket till tjänster inuti klustret. Kontrollen ingress-nginx är den mest populära och använder server NGINX för att vidarebefordra förfrågningar till klustret, dirigera externa förfrågningar och lastbalansera. Kubernetes-projektet tillhandahåller grundläggande ingress-kontroller för AWS, GCE och nginx, där den senare inte har något med kontrollern kubernetes-ingress att göra, vars underhåll hanteras av företaget F5/NGINX (de aktuella sårbarheterna påverkar inte projekt som utvecklas av NGINX-utvecklarna, omnämnandet av nginx i namnet ingress-nginx är endast relaterat till användningen av nginx som proxy).

Sårbarheterna gör det möjligt för en icke-autentiserad angripare att köra sin egen kod i kontexten av ingress-nginx-kontrollern, med möjlighet att skicka en förfrågan till Admission-webbhantverkaren. Under nätverksgenomsökningen har över 6500 sårbara Kubernetes-kluster upptäckts som använder offentligt tillgängliga sårbara kontroller med en öppen förfrågan hanterare för Admission.

I standardkonfigurationen kan kod som körs av angriparen få åtkomst till inställningarna för ingress-objektet, däribland lagras även autentiseringsuppgifter för att nå Kubernetes-servrar, vilket möjliggör privilegierad åtkomst till hela klustret. Som en säkerhetsåtgärd rekommenderas det att stänga av funktionen 'Validating Admission Controller' i ingress-nginx.

Admission-kontrolleren startas i en separat pod-miljö och utför kontroll av inkommande ingress-objekt innan de distribueras. Som standard accepterar webbhändelsen Admission förfrågningar utan autentisering från offentliga nätverk. Vid kontrollen skapar Admission-kontrolleren en konfiguration för http-servern nginx baserat på innehållet i det mottagna ingress-objektet och kontrollerar dess korrekthet.

Identifierade sårbarheter gör det möjligt att få in sina egna inställningar i nginx genom att skicka ett särskilt utformat ingress-objekt direkt till Admission-kontrolleren. Forskare har upptäckt att vissa egenskaper i kontrollförfrågningar som anges i fältet '.request.object.annotations' direkt sätts in i nginx-konfigurationen. Den genererade konfigurationen tillämpas inte, utan testas endast genom att köra körbar fil 'nginx' med alternativet '-t'.

Specifikt utförs insättning av externa data i konfigurationen för parametrarna 'mirror-target', 'mirror-host' (CVE-2025-1098), 'auth-tls-match-cn' (CVE-2025-1097) och 'auth-url' (CVE-2025-24514). Till exempel, i konfigurationsraden 'set $target {{ $externalAuth.URL }};' sätts istället för '{{ $externalAuth.URL }}' in den URL som anges i parametern 'auth-url'. Korrektheten av URL:en kontrolleras inte. Därmed kan en angripare skicka ett värde som 'http://example.com/#; inställningar' som URL och infoga sina egna inställningar i konfigurationsfilen.

För att köra godtycklig kod under kontrollen av konfigurationen med kommandot 'nginx -t' utnyttjade forskarna det faktum att utöver syntaxkontrollen laddar nginx bibliotek med moduler och öppnar filer som nämns i konfigurationen för att bedöma deras tillgänglighet. Bland annat laddas det delade bibliotek som anges i direktivet ssl_engine när direktivet behandlas. SSL-motorn.

För att ladda sitt bibliotek på Kubernetes-servern utnyttjade forskarna (CVE-2025-1974) det faktum att nginx vid behandling av stora förfrågningar sparar förfrågningskroppen i en temporär fil som omedelbart tas bort, men det finns en öppen filbeskrivare för denna fil i filsystemet '/proc'. Således kan man samtidigt skicka förfrågningar för att spara den temporära filen och initiera konfigurationskontrollen där sökvägen i direktivet 'ssl_engine' anger filbeskrivaren i filsystemet '/proc'.

För att en filbeskrivare ska vara tillgänglig under en längre tid kan värdet för "Content-Length" i begäran anges till ett betydligt högre värde än de faktiska överförda data (servern kommer att vänta på mottagning av de återstående data). En ytterligare svårighet är behovet av att gissa PID för processen och numret på filbeskrivaren kopplad till det laddade delade biblioteket, men eftersom det i containern vanligtvis används ett minimalt antal körande processer kan de nödvändiga värdena gissas genom att göra flera försök. Vid framgång och inladdning av ett insatt delat bibliotek kan angriparen få tillgång till de lagrade parametrarna inom pod-miljön, tillräckliga för att styra hela klustret.

För att kontrollera användningen av den sårbara ingress-nginx kan kommandot köras: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Källa: opennet.ru