CVE-2021-43858: MinIO Privilege Escalation Vulnerability

CVE-2021-43858 Overview

CVE-2021-43858 is a privilege escalation vulnerability in MinIO, a Kubernetes native application for cloud storage. Prior to version RELEASE.2021-12-27T07-23-18Z, a malicious client can hand-craft an HTTP API call that allows for updating policy for a user and gaining higher privileges. This flaw enables authenticated users to escalate their permissions beyond what was originally granted, potentially gaining administrative access to the MinIO deployment.

Critical Impact

Authenticated attackers can exploit this vulnerability to modify user policies and escalate privileges, potentially gaining full administrative control over MinIO storage infrastructure and all stored data.

Affected Products

• MinIO versions prior to RELEASE.2021-12-27T07-23-18Z
• MinIO deployments on Kubernetes environments
• MinIO standalone and distributed deployments

Discovery Timeline

• 2021-12-27 - CVE-2021-43858 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-43858

Vulnerability Analysis

This vulnerability represents a privilege escalation flaw (CWE-269) combined with improper authorization (CWE-863) in MinIO's administrative API handlers. The core issue stems from how the application processed user information updates through its HTTP API, specifically in the cmd/admin-handlers-users.go and cmd/iam-store.go files.

The vulnerable code path accepted a madmin.UserInfo structure during user creation or update operations. This structure contained policy information that could be manipulated by an authenticated client. By crafting a malicious request with arbitrary policy assignments, an attacker with low-level privileges could assign themselves administrative policies, effectively bypassing the intended authorization controls.

The attack requires network access and valid user credentials, but no additional user interaction is needed. Once exploited, the attacker gains the ability to read, modify, and delete any data stored in MinIO, as well as create additional privileged accounts for persistence.

Root Cause

The root cause lies in the improper handling of request body types in the user management API. The original implementation used madmin.UserInfo to unmarshal incoming JSON requests, which included policy fields that should not be user-controllable. This allowed authenticated users to include policy modifications in their requests, which were processed without adequate authorization checks.

The vulnerable code path directly accepted and applied policy changes from the request body without verifying whether the requesting user had the authority to make such policy modifications.

Attack Vector

The attack is executed over the network against MinIO's administrative API endpoints. An authenticated user with minimal privileges can craft a malicious HTTP request to the user update endpoint, including elevated policy assignments in the request body. The server processes these policy changes without proper authorization verification, granting the attacker escalated privileges.

// Security patch in cmd/admin-handlers-users.go - Fix user privilege escalation bug (#13976)
 	return
 }

-	var uinfo madmin.UserInfo
-	if err = json.Unmarshal(configBytes, &uinfo); err != nil {
+	var ureq madmin.AddOrUpdateUserReq
+	if err = json.Unmarshal(configBytes, &ureq); err != nil {
 	logger.LogIf(ctx, err)
 	writeErrorResponseJSON(ctx, w, errorCodes.ToAPIErr(ErrAdminConfigBadJSON), r.URL)
 	return
 }

-	if err = globalIAMSys.CreateUser(ctx, accessKey, uinfo); err != nil {
+	if err = globalIAMSys.CreateUser(ctx, accessKey, ureq); err != nil {
 	writeErrorResponseJSON(ctx, w, toAdminAPIErr(ctx, err), r.URL)
 	return
 }

Source: GitHub Commit Details

// Security patch in cmd/iam-store.go - Fix user privilege escalation bug (#13976)
}

// AddUser - adds/updates long term user account to storage.
-func (store *IAMStoreSys) AddUser(ctx context.Context, accessKey string, uinfo madmin.UserInfo) error {
+func (store *IAMStoreSys) AddUser(ctx context.Context, accessKey string, ureq madmin.AddOrUpdateUserReq) error {
 cache := store.lock()
 defer store.unlock()

Source: GitHub Commit Details

Detection Methods for CVE-2021-43858

Indicators of Compromise

• Unusual API calls to user management endpoints with policy modification parameters
• Unexpected privilege changes for existing MinIO user accounts
• Audit log entries showing users accessing resources beyond their original permissions
• New administrative accounts created by non-administrative users

Detection Strategies

• Monitor MinIO audit logs for user policy modification requests from low-privilege accounts
• Implement alerting on any changes to IAM policies outside of established change windows
• Review API access logs for requests to /minio/admin/v3/add-user with suspicious payload sizes
• Enable detailed request logging to capture full request bodies for forensic analysis

Monitoring Recommendations

• Enable and centralize MinIO server logs to a SIEM solution for real-time analysis
• Create baseline profiles of normal user management API activity and alert on deviations
• Implement network monitoring for unusual patterns in MinIO administrative traffic
• Regularly audit user privileges and compare against approved access control lists

How to Mitigate CVE-2021-43858

Immediate Actions Required

• Upgrade MinIO to version RELEASE.2021-12-27T07-23-18Z or later immediately
• Audit all existing user accounts and policies for unauthorized privilege escalation
• Review audit logs for any exploitation attempts prior to patching
• Rotate credentials for any accounts that may have been compromised

Patch Information

MinIO has released a security patch in version RELEASE.2021-12-27T07-23-18Z that addresses this vulnerability. The fix changes the accepted request body type from madmin.UserInfo to madmin.AddOrUpdateUserReq, removing the ability to apply policy changes through this API endpoint. Detailed patch information is available in the GitHub Security Advisory GHSA-j6jc-jqqc-p6cx and the associated pull request #13976.

Workarounds

• Add an explicit Deny rule to disable the password change API for users until patching is possible
• Implement network segmentation to restrict access to MinIO administrative endpoints
• Use a web application firewall to filter requests containing policy parameters to user management endpoints
• Temporarily restrict user creation and modification operations to verified administrative hosts only

# Configuration example - Add explicit Deny rule for password change API
# In your MinIO IAM policy configuration, add the following deny statement:
mc admin policy create myminio deny-user-changes '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "admin:CreateUser",
        "admin:DeleteUser", 
        "admin:EnableUser",
        "admin:DisableUser"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}'

# Apply the deny policy to all non-admin users
mc admin policy attach myminio deny-user-changes --user regularuser