Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - S3, Athena & Glacier Enum

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

S3

Amazon S3 to usługa, która pozwala przechowywać duże ilości danych.

Amazon S3 zapewnia wiele opcji do osiągnięcia ochrony danych w spoczynku. Opcje obejmują Uprawnienia (Polityka), Szyfrowanie (po stronie klienta i serwera), Wersjonowanie kubełka i Usuwanie oparte na MFA. Użytkownik może włączyć dowolną z tych opcji, aby zapewnić ochronę danych. Replikacja danych to wewnętrzne udogodnienie AWS, gdzie S3 automatycznie replikuje każdy obiekt we wszystkich strefach dostępności, i organizacja nie musi tego włączać w tym przypadku.

Dzięki uprawnieniom opartym na zasobach, można zdefiniować uprawnienia dla podkatalogów kubełka osobno.

Wersjonowanie kubełka i usuwanie oparte na MFA

Gdy wersjonowanie kubełka jest włączone, każda akcja próbująca zmienić plik wewnątrz pliku spowoduje wygenerowanie nowej wersji pliku, zachowując również poprzednią zawartość tego samego pliku. W związku z tym nie nadpisze ona jego zawartości.

Co więcej, usuwanie oparte na MFA uniemożliwi usunięcie wersji pliku w kubełku S3 oraz wyłączenie wersjonowania kubełka, dzięki czemu atakujący nie będzie mógł zmieniać tych plików.

Dzienniki dostępu do S3

Możliwe jest włączenie logowania dostępu do S3 (domyślnie wyłączone) do niektórego kubełka i zapisanie dzienników w innym kubełku, aby dowiedzieć się, kto ma dostęp do kubełka (oba kubełki muszą znajdować się w tej samej regionie).

Podpisane adresy URL S3

Możliwe jest wygenerowanie podpisanego adresu URL, który zazwyczaj może być używany do dostępu do określonego pliku w kubełku. Podpisany adres URL wygląda tak:

https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa

Można utworzyć adres URL z wstępnym podpisem z wiersza poleceń, używając poświadczeń podmiotu mającego dostęp do obiektu (jeśli konto, którego używasz, nie ma dostępu, zostanie utworzony krótszy adres URL z wstępnym podpisem, ale będzie on bezużyteczny)

aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'

Jedynym wymaganym uprawnieniem do wygenerowania adresu URL z wstępnym podpisem jest uprawnienie udzielane, więc dla poprzedniej komendy jedynym wymaganym uprawnieniem przez podmiot jest s3:GetObject

Możliwe jest również tworzenie adresów URL z wstępnym podpisem z innymi uprawnieniami:

import boto3
url = boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
ExpiresIn=3600
)

Mechanizmy szyfrowania S3

DEK oznacza klucz szyfrowania danych i jest to klucz zawsze generowany i używany do szyfrowania danych.

Szyfrowanie po stronie serwera przy użyciu zarządzanych kluczy S3, SSE-S3

Ta opcja wymaga minimalnej konfiguracji, a całe zarządzanie używanymi kluczami szyfrowania jest zarządzane przez AWS. Wszystko, co musisz zrobić, to przesłać swoje dane, a S3 zajmie się wszystkimi innymi aspektami. Każdy kubeł w koncie S3 otrzymuje klucz kubełka.

  • Szyfrowanie:

  • Dane obiektu + utworzony zwykły DEK --> Zaszyfrowane dane (przechowywane wewnątrz S3)

  • Utworzony zwykły DEK + Klucz główny S3 --> Zaszyfrowany DEK (przechowywany wewnątrz S3) i zwykły tekst jest usuwany z pamięci

  • Deszyfrowanie:

  • Zaszyfrowany DEK + Klucz główny S3 --> Zwykły DEK

  • Zwykły DEK + Zaszyfrowane dane --> Dane obiektu

Należy zauważyć, że w tym przypadku klucz jest zarządzany przez AWS (rotacja tylko co 3 lata). Jeśli używasz własnego klucza, będziesz mógł rotować, dezaktywować i stosować kontrolę dostępu.

Szyfrowanie po stronie serwera przy użyciu zarządzanych kluczy KMS, SSE-KMS

Ta metoda pozwala S3 na korzystanie z usługi zarządzania kluczami do generowania kluczy szyfrowania danych. KMS daje znacznie większą elastyczność w zarządzaniu kluczami. Na przykład możesz dezaktywować, rotować i stosować kontrolę dostępu do CMK oraz monitorować ich użycie za pomocą AWS Cloud Trail.

  • Szyfrowanie:

  • S3 żąda kluczy danych od KMS CMK

  • KMS używa CMK do wygenerowania pary zwykłego DEK i zaszyfrowanego DEK i wysyła je do S3

  • S3 używa zwykłego klucza do zaszyfrowania danych, przechowuje zaszyfrowane dane i zaszyfrowany klucz, a następnie usuwa z pamięci zwykły klucz

  • Deszyfrowanie:

  • S3 prosi KMS o zdeszyfrowanie zaszyfrowanego klucza danych obiektu

  • KMS deszyfruje klucz danych za pomocą CMK i odsyła go do S3

  • S3 deszyfruje dane obiektu

Szyfrowanie po stronie serwera przy użyciu kluczy dostarczonych przez klienta, SSE-C

Ta opcja daje możliwość dostarczenia własnego klucza głównego, który być może już jest używany poza AWS. Twój dostarczony przez klienta klucz zostanie wysłany wraz z danymi do S3, gdzie S3 przeprowadzi dla Ciebie szyfrowanie.

  • Szyfrowanie:

  • Użytkownik wysyła dane obiektu + Klucz klienta do S3

  • Klucz klienta jest używany do zaszyfrowania danych, a zaszyfrowane dane są przechowywane

  • zasolona wartość HMAC klucza klienta jest również przechowywana do przyszłej weryfikacji klucza

  • klucz klienta jest usuwany z pamięci

  • Deszyfrowanie:

  • Użytkownik wysyła klucz klienta

  • Klucz jest weryfikowany względem przechowywanej wartości HMAC

  • Dostarczony przez klienta klucz jest następnie używany do deszyfrowania danych

Szyfrowanie po stronie klienta przy użyciu KMS, CSE-KMS

Podobnie jak w przypadku SSE-KMS, ta metoda również wykorzystuje usługę zarządzania kluczami do generowania kluczy szyfrowania danych. Jednak tym razem KMS jest wywoływany przez klienta, a nie S3. Szyfrowanie odbywa się po stronie klienta, a zaszyfrowane dane są następnie wysyłane do S3 w celu przechowywania.

  • Szyfrowanie:

  • Klient żąda klucza danych od KMS

  • KMS zwraca zwykły DEK i zaszyfrowany DEK z CMK

  • Oba klucze są wysyłane z powrotem

  • Klient następnie szyfruje dane za pomocą zwykłego DEK i wysyła do S3 zaszyfrowane dane + zaszyfrowany DEK (który jest zapisany jako metadane zaszyfrowanych danych wewnątrz S3)

  • Deszyfrowanie:

  • Zaszyfrowane dane z zaszyfrowanym DEK są wysyłane do klienta

  • Klient prosi KMS o zdeszyfrowanie zaszyfrowanego klucza za pomocą CMK, a KMS odsyła zwykły DEK

  • Klient może teraz odszyfrować zaszyfrowane dane

Szyfrowanie po stronie klienta przy użyciu kluczy dostarczonych przez klienta, CSE-C

Korzystając z tego mechanizmu, możesz użyć dostarczonych przez siebie kluczy i użyć klienta AWS-SDK do zaszyfrowania danych przed ich wysłaniem do S3 w celu przechowywania.

  • Szyfrowanie:

  • Klient generuje DEK i szyfruje dane zwykłe

  • Następnie, używając własnego niestandardowego CMK, szyfruje DEK

  • przesyła zaszyfrowane dane + zaszyfrowany DEK do S3, gdzie są przechowywane

  • Deszyfrowanie:

  • S3 wysyła zaszyfrowane dane i DEK

  • Ponieważ klient już ma CMK użyty do zaszyfrowania DEK, deszyfruje DEK, a następnie używa zwykłego DEK do deszyfrowania danych

Wyliczanie

Jednym z tradycyjnych głównych sposobów kompromitacji organizacji AWS zaczyna się od kompromitacji publicznie dostępnych kubełków. Możesz znaleźć narzędzia do wyliczania publicznych kubełków na tej stronie.

# Get buckets ACLs
aws s3api get-bucket-acl --bucket <bucket-name>
aws s3api get-object-acl --bucket <bucket-name> --key flag

# Get policy
aws s3api get-bucket-policy --bucket <bucket-name>
aws s3api get-bucket-policy-status --bucket <bucket-name> #if it's public

# list S3 buckets associated with a profile
aws s3 ls
aws s3api list-buckets

# list content of bucket (no creds)
aws s3 ls s3://bucket-name --no-sign-request
aws s3 ls s3://bucket-name --recursive

# list content of bucket (with creds)
aws s3 ls s3://bucket-name
aws s3api list-objects-v2 --bucket <bucket-name>
aws s3api list-objects --bucket <bucket-name>
aws s3api list-object-versions --bucket <bucket-name>

# copy local folder to S3
aws s3 cp MyFolder s3://bucket-name --recursive

# delete
aws s3 rb s3://bucket-name –-force

# download a whole S3 bucket
aws s3 sync s3://<bucket>/ .

# move S3 bucket to different location
aws s3 sync s3://oldbucket s3://newbucket --source-region us-west-1

# list the sizes of an S3 bucket and its contents
aws s3api list-objects --bucket BUCKETNAME --output json --query "[sum(Contents[].Size), length(Contents[])]"

# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
##JSON policy example
{
"Id": "Policy1568185116930",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1568184932403",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome",
"Principal": "*"
},
{
"Sid": "Stmt1568185007451",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome/*",
"Principal": "*"
}
]
}

# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name> # Way 1 to get the ACL
aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://acl.json

aws s3api get-object-acl --bucket <bucket-name> --key flag #Way 2 to get the ACL
aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-policy file://objacl.json

##JSON ACL example
## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
{
"Owner": {
"DisplayName": "<DisplayName>",
"ID": "<ID>"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL

dual-stack

Możesz uzyskać dostęp do kubełka S3 poprzez punkt końcowy dual-stack, korzystając z nazwy punktu końcowego w stylu hostowanym wirtualnie lub w stylu ścieżki. Są one przydatne do dostępu do S3 poprzez IPv6.

Punkty końcowe dual-stack używają następującej składni:

  • bucketname.s3.dualstack.aws-region.amazonaws.com

  • s3.dualstack.aws-region.amazonaws.com/bucketname

Privesc

Na następnej stronie możesz sprawdzić, jak wykorzystać uprawnienia S3 do eskalacji uprawnień:

pageAWS - S3 Privesc

Nieuwierzytelniony dostęp

pageAWS - S3 Unauthenticated Enum

Eksploatacja po dostępie do S3

pageAWS - S3 Post Exploitation

Trwałość

pageAWS - S3 Persistence

Inne podatności S3

Problem z zatruciem pamięci podręcznej HTTP S3

Zgodnie z tą analizą możliwe było zatruwanie pamięci podręcznej odpowiedzi dowolnego kubełka, jak gdyby należała do innego. Można było to wykorzystać do zmiany na przykład odpowiedzi plików JavaScript i naruszenia dowolnych stron, korzystając z S3 do przechowywania statycznego kodu.

Amazon Athena

Amazon Athena to interaktywna usługa zapytań, która ułatwia analizę danych bezpośrednio w usłudze Amazon Simple Storage Service (Amazon S3) za pomocą standardowego SQL.

Musisz przygotować tabelę bazy danych relacyjnej z formatem treści, która pojawi się w monitorowanych kubełkach S3. Następnie Amazon Athena będzie w stanie zapełnić bazę danych z logów, aby można było ją zapytać.

Amazon Athena obsługuje możliwość zapytania danych S3, które są już zaszyfrowane, a jeśli jest skonfigurowana w ten sposób, Athena może również zaszyfrować wyniki zapytania, które można następnie przechowywać w S3.

To szyfrowanie wyników jest niezależne od zapytywanych danych S3, co oznacza, że nawet jeśli dane S3 nie są zaszyfrowane, wyniki zapytania mogą być zaszyfrowane. Należy pamiętać, że Amazon Athena obsługuje tylko dane, które zostały zaszyfrowane za pomocą następujących metod szyfrowania S3: SSE-S3, SSE-KMS i CSE-KMS.

SSE-C i CSE-E nie są obsługiwane. Ponadto ważne jest zrozumienie, że Amazon Athena będzie wykonywać zapytania tylko przeciwko zaszyfrowanym obiektom znajdującym się w tej samej regionie co samo zapytanie. Jeśli chcesz zapytać dane S3, które zostały zaszyfrowane za pomocą KMS, konieczne są określone uprawnienia dla użytkownika Atheny, aby umożliwić mu wykonanie zapytania.

Wyliczenie

# Get catalogs
aws athena list-data-catalogs

# Get databases inside catalog
aws athena list-databases --catalog-name <catalog-name>
aws athena list-table-metadata --catalog-name <catalog-name> --database-name <db-name>

# Get query executions, queries and results
aws athena list-query-executions
aws athena get-query-execution --query-execution-id <id> # Get query and meta of results
aws athena get-query-results --query-execution-id <id> # This will rerun the query and get the results

# Get workgroups & Prepared statements
aws athena list-work-groups
aws athena list-prepared-statements --work-group <wg-name>
aws athena get-prepared-statement --statement-name <name> --work-group <wg-name>

# Run query
aws athena start-query-execution --query-string <query>

Odnośniki

Zacznij od zera i zostań ekspertem w hakowaniu AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousAWS - SQS EnumNextAWS - STS Enum

Last updated