From c74a7d545d16a051e2c53b46732720fe47cc5d35 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 12 Feb 2026 13:06:13 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a --- .../aws-s3-athena-and-glacier-enum.md | 154 +++++++++--------- 1 file changed, 77 insertions(+), 77 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md index b6705fd9f..049594887 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md @@ -4,36 +4,36 @@ ## S3 -Amazon S3 to usługa, która pozwala **przechowywać duże ilości danych**. +Amazon S3 to usługa, która pozwala na **przechowywanie dużych ilości danych**. -Amazon S3 oferuje wiele opcji, aby osiągnąć **ochronę** danych w spoczynku. Opcje te obejmują **Uprawnienia** (Polityka), **Szyfrowanie** (po stronie klienta i serwera), **Wersjonowanie kubełków** oraz **usuwanie** oparte na **MFA**. **Użytkownik może włączyć** dowolną z tych opcji, aby osiągnąć ochronę danych. **Replikacja danych** to wewnętrzna funkcja AWS, w której **S3 automatycznie replikuje każdy obiekt we wszystkich Strefach Dostępności**, a organizacja nie musi jej włączać w tym przypadku. +Amazon S3 oferuje wiele opcji zapewnienia **ochrony** danych w spoczynku. Opcje obejmują **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** oraz **MFA** **based delete**. **Użytkownik może włączyć** dowolną z tych opcji, aby zapewnić ochronę danych. **Replikacja danych** jest wewnętrzną funkcją AWS, gdzie **S3 automatycznie replikuje każdy obiekt we wszystkich Availability Zones** i organizacja nie musi jej w tym przypadku włączać. -Dzięki uprawnieniom opartym na zasobach możesz definiować uprawnienia dla podkatalogów swojego kubełka osobno. +With resource-based permissions, you can define permissions for sub-directories of your bucket separately. -### Wersjonowanie kubełków i usuwanie oparte na MFA +### Bucket Versioning and MFA based delete -Gdy wersjonowanie kubełków jest włączone, każda akcja, która próbuje zmienić plik wewnątrz pliku, wygeneruje nową wersję pliku, zachowując również poprzednią zawartość tego samego. Dlatego nie nadpisze jego zawartości. +When bucket versioning is enabled, any action that tries to alter a file inside a file will generate a new version of the file, keeping also the previous content of the same. Therefore, it won't overwrite its content. -Ponadto, usuwanie oparte na MFA zapobiegnie usunięciu wersji pliku w kubełku S3 oraz wyłączeniu wersjonowania kubełków, więc atakujący nie będzie mógł zmienić tych plików. +Moreover, MFA based delete will prevent versions of file in the S3 bucket from being deleted and also Bucket Versioning from being disabled, so an attacker won't be able to alter these files. -### Dzienniki dostępu S3 +### S3 Access logs -Możliwe jest **włączenie logowania dostępu S3** (które domyślnie jest wyłączone) do niektórego kubełka i zapisanie logów w innym kubełku, aby wiedzieć, kto uzyskuje dostęp do kubełka (oba kubełki muszą znajdować się w tym samym regionie). +It's possible to **enable S3 access login** (which by default is disabled) to some bucket and save the logs in a different bucket to know who is accessing the bucket (both buckets must be in the same region). -### Pre-signed URLs S3 +### S3 Presigned URLs -Możliwe jest wygenerowanie pre-signed URL, który zazwyczaj może być używany do **uzyskania dostępu do określonego pliku** w kubełku. **Pre-signed URL wygląda tak**: +It's possible to generate a presigned URL that can usually be used to **access the specified file** in the bucket. A **presigned URL looks like this**: ``` https://.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 ``` -URL z wcześniejszym podpisem może być **stworzony z cli przy użyciu poświadczeń podmiotu mającego dostęp do obiektu** (jeśli konto, którego używasz, nie ma dostępu, zostanie utworzony krótszy URL z wcześniejszym podpisem, ale będzie bezużyteczny) +Presigned URL można **utworzyć z poziomu cli przy użyciu credentials principala mającego dostęp do object** (jeśli konto, którego używasz, nie ma dostępu, zostanie utworzony krótszy presigned URL, ale będzie bezużyteczny) ```bash aws s3 presign --region 's3:///' ``` > [!NOTE] -> Jedynym wymaganym uprawnieniem do wygenerowania presigned URL jest przyznane uprawnienie, więc dla poprzedniego polecenia jedynym wymaganym uprawnieniem przez podmiot jest `s3:GetObject` +> Jedynym wymaganym uprawnieniem do wygenerowania presigned URL jest uprawnienie, które jest nadawane, więc dla poprzedniego polecenia jedynym uprawnieniem potrzebnym przez principal jest `s3:GetObject` -Możliwe jest również tworzenie presigned URLs z **innymi uprawnieniami**: +It's also possible to create presigned URLs with **other permissions**: ```python import boto3 url = boto3.client('s3').generate_presigned_url( @@ -42,99 +42,99 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'}, ExpiresIn=3600 ) ``` -### Mechanizmy szyfrowania S3 +### S3 Encryption Mechanisms -**DEK oznacza Klucz Szyfrowania Danych** i jest kluczem, który zawsze jest generowany i używany do szyfrowania danych. +**DEK oznacza Data Encryption Key** i jest to klucz, który jest zawsze generowany i używany do szyfrowania danych.
-Szyfrowanie po stronie serwera z kluczami zarządzanymi przez S3, SSE-S3 +Server-side encryption with S3 managed keys, SSE-S3 -Ta opcja wymaga minimalnej konfiguracji, a zarządzanie kluczami szyfrowania jest realizowane przez AWS. Wszystko, co musisz zrobić, to **przesłać swoje dane, a S3 zajmie się wszystkimi innymi aspektami**. Każdemu koszykowi w koncie S3 przypisany jest klucz koszyka. +Ta opcja wymaga minimalnej konfiguracji, a całym zarządzaniem kluczami szyfrowania zajmuje się AWS. Wszystko, co musisz zrobić, to **wgrać swoje dane, a S3 zajmie się resztą**. Każdy bucket w koncie S3 otrzymuje bucket key. -- Szyfrowanie: -- Dane obiektu + utworzony jawny DEK --> Szyfrowane dane (przechowywane w S3) -- Utworzony jawny DEK + Klucz Główny S3 --> Szyfrowany DEK (przechowywany w S3) i jawny tekst jest usuwany z pamięci -- Deszyfrowanie: -- Szyfrowany DEK + Klucz Główny S3 --> Jawny DEK -- Jawny DEK + Szyfrowane dane --> Dane obiektu +- Encryption: +- Object Data + created plaintext DEK --> Encrypted data (stored inside S3) +- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) and plain text is deleted from memory +- Decryption: +- Encrypted DEK + S3 Master Key --> Plaintext DEK +- Plaintext DEK + Encrypted data --> Object Data -Proszę zauważyć, że w tym przypadku **klucz jest zarządzany przez AWS** (rotacja tylko co 3 lata). Jeśli użyjesz własnego klucza, będziesz mógł rotować, dezaktywować i stosować kontrolę dostępu. +Proszę zauważyć, że w tym przypadku **klucz jest zarządzany przez AWS** (rotacja tylko co 3 lata). Jeśli użyjesz własnego klucza, będziesz mógł rotować, wyłączać i stosować kontrolę dostępu.
-Szyfrowanie po stronie serwera z kluczami zarządzanymi przez KMS, SSE-KMS +Server-side encryption with KMS managed keys, SSE-KMS -Ta metoda pozwala S3 korzystać 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ć kontrole dostępu do CMK oraz monitorować ich użycie za pomocą AWS Cloud Trail. +Ta metoda pozwala S3 korzystać z KMS do generowania data encryption keys. KMS daje znacznie większą elastyczność w zarządzaniu kluczami. Na przykład możesz wyłączać, rotować i stosować kontrolę dostępu do CMK oraz audytować ich użycie za pomocą AWS Cloud Trail. -- Szyfrowanie: -- S3 żąda kluczy danych od KMS CMK -- KMS używa CMK do generowania pary DEK jawny i DEK szyfrowany i wysyła je do S3 -- S3 używa jawnego klucza do szyfrowania danych, przechowuje szyfrowane dane i szyfrowany klucz oraz usuwa z pamięci jawny klucz -- Deszyfrowanie: -- S3 prosi KMS o deszyfrowanie szyfrowanego klucza danych obiektu -- KMS deszyfruje klucz danych za pomocą CMK i wysyła go z powrotem do S3 -- S3 deszyfruje dane obiektu +- Encryption: +- S3 request data keys from KMS CMK +- KMS uses a CMK to generate the pair DEK plaintext and DEK encrypted and send them to S£ +- S3 uses the paintext key to encrypt the data, store the encrypted data and the encrypted key and deletes from memory the plain text key +- Decryption: +- S3 ask to KMS to decrypt the encrypted data key of the object +- KMS decrypt the data key with the CMK and send it back to S3 +- S3 decrypts the object data
-Szyfrowanie po stronie serwera z kluczami dostarczonymi przez klienta, SSE-C +Server-side encryption with customer provided keys, SSE-C -Ta opcja daje Ci możliwość dostarczenia własnego klucza głównego, którego możesz już używać poza AWS. Twój klucz dostarczony przez klienta zostanie następnie wysłany z danymi do S3, gdzie S3 wykona szyfrowanie za Ciebie. +Ta opcja daje możliwość dostarczenia własnego master key, którego możesz już używać poza AWS. Twój customer-provided key jest wysyłany wraz z danymi do S3, gdzie S3 wykonuje szyfrowanie za Ciebie. -- Szyfrowanie: -- Użytkownik wysyła dane obiektu + Klucz Klienta do S3 -- Klucz klienta jest używany do szyfrowania danych, a szyfrowane dane są przechowywane -- również przechowywana jest sól HMAC klucza klienta dla przyszłej walidacji klucza -- klucz klienta jest usuwany z pamięci -- Deszyfrowanie: -- Użytkownik wysyła klucz klienta -- Klucz jest walidowany w stosunku do przechowywanej wartości HMAC -- Klucz dostarczony przez klienta jest następnie używany do deszyfrowania danych +- Encryption: +- The user sends the object data + Customer key to S3 +- The customer key is used to encrypt the data and the encrypted data is stored +- a salted HMAC value of the customer key is stored also for future key validation +- the customer key is deleted from memory +- Decryption: +- The user send the customer key +- The key is validated against the HMAC value stored +- The customer provided key is then used to decrypt the data
-Szyfrowanie po stronie klienta z KMS, CSE-KMS +Client-side encryption with 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ływane przez klienta, a nie przez S3. Szyfrowanie odbywa się po stronie klienta, a szyfrowane dane są następnie wysyłane do S3 w celu przechowywania. +Podobnie jak w SSE-KMS, tutaj także używany jest KMS do generowania data encryption keys. Tym razem jednak 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 przechowania. -- Szyfrowanie: -- Klient żąda klucza danych od KMS -- KMS zwraca jawny DEK i szyfrowany DEK z CMK -- Oba klucze są wysyłane z powrotem -- Klient szyfruje dane za pomocą jawnego DEK i wysyła do S3 szyfrowane dane + szyfrowany DEK (który jest zapisywany jako metadane szyfrowanych danych w S3) -- Deszyfrowanie: -- Szyfrowane dane z szyfrowanym DEK są wysyłane do klienta -- Klient prosi KMS o deszyfrowanie szyfrowanego klucza za pomocą CMK, a KMS wysyła z powrotem jawny DEK -- Klient może teraz deszyfrować szyfrowane dane +- Encryption: +- Client request for a data key to KMS +- KMS returns the plaintext DEK and the encrypted DEK with the CMK +- Both keys are sent back +- The client then encrypts the data with the plaintext DEK and send to S3 the encrypted data + the encrypted DEK (which is saved as metadata of the encrypted data inside S3) +- Decryption: +- The encrypted data with the encrypted DEK is sent to the client +- The client asks KMS to decrypt the encrypted key using the CMK and KMS sends back the plaintext DEK +- The client can now decrypt the encrypted data
-Szyfrowanie po stronie klienta z kluczami dostarczonymi przez klienta, CSE-C +Client-side encryption with customer provided keys, CSE-C -Korzystając z tego mechanizmu, możesz wykorzystać własne dostarczone klucze i użyć klienta AWS-SDK do szyfrowania danych przed wysłaniem ich do S3 w celu przechowywania. +Korzystając z tego mechanizmu, możesz użyć własnych kluczy i klienta AWS-SDK, aby zaszyfrować dane przed wysłaniem ich do S3. -- Szyfrowanie: -- Klient generuje DEK i szyfruje jawne dane -- Następnie, używając własnego niestandardowego CMK, szyfruje DEK -- przesyła szyfrowane dane + szyfrowany DEK do S3, gdzie są przechowywane -- Deszyfrowanie: -- S3 wysyła szyfrowane dane i DEK -- Ponieważ klient już ma CMK użyty do szyfrowania DEK, deszyfruje DEK, a następnie używa jawnego DEK do deszyfrowania danych +- Encryption: +- The client generates a DEK and encrypts the plaintext data +- Then, using it's own custom CMK it encrypts the DEK +- submit the encrypted data + encrypted DEK to S3 where it's stored +- Decryption: +- S3 sends the encrypted data and DEK +- As the client already has the CMK used to encrypt the DEK, it decrypts the DEK and then uses the plaintext DEK to decrypt the data
-### **Enumeracja** +### **Enumeration** -Jednym z tradycyjnych głównych sposobów kompromitacji organizacji AWS jest kompromitacja koszyków publicznie dostępnych. **Możesz znaleźć** [**enumeratory publicznych koszyków na tej stronie**](../aws-unauthenticated-enum-access/#s3-buckets)**.** +One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.** ```bash # Get buckets ACLs aws s3api get-bucket-acl --bucket @@ -229,16 +229,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### dual-stack -Możesz uzyskać dostęp do koszyka S3 przez punkt końcowy dual-stack, używając nazwy punktu końcowego w stylu hostowanym wirtualnie lub w stylu ścieżki. Są one przydatne do uzyskiwania dostępu do S3 przez IPv6. +Możesz uzyskać dostęp do bucketu S3 przez endpoint dual-stack, używając nazwy w stylu virtual hosted-style lub path-style. Są one przydatne do dostępu do S3 przez IPv6. -Punkty końcowe dual-stack używają następującej składni: +Dual-stack endpoints 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 **nadużywać uprawnień S3, aby eskalować uprawnienia**: +Na poniższej stronie możesz sprawdzić, jak **abuse S3 permissions to escalate privileges**: {{#ref}} ../aws-privilege-escalation/aws-s3-privesc/README.md @@ -266,19 +266,19 @@ Na następnej stronie możesz sprawdzić, jak **nadużywać uprawnień S3, aby e ### S3 HTTP Cache Poisoning Issue -[**Zgodnie z tym badaniem**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) możliwe było buforowanie odpowiedzi z dowolnego koszyka, tak jakby należała do innego. Mogło to być nadużywane do zmiany na przykład odpowiedzi plików javascript i kompromitacji dowolnych stron korzystających z S3 do przechowywania statycznego kodu. +[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) można było buforować odpowiedź dowolnego bucketu, tak jakby należała do innego. Mogło to być wykorzystane do zmiany, na przykład, odpowiedzi plików javascript i skompromitowania dowolnych stron używających S3 do przechowywania statycznego kodu. ## Amazon Athena -Amazon Athena to interaktywny serwis zapytań, który ułatwia **analizowanie danych** bezpośrednio w Amazon Simple Storage Service (Amazon **S3**) **przy użyciu** standardowego **SQL**. +Amazon Athena to interaktywna usługa zapytań, która ułatwia **analizowanie danych** bezpośrednio w Amazon Simple Storage Service (Amazon **S3**) **przy użyciu** standardowego **SQL**. -Musisz **przygotować tabelę DB relacyjną** w formacie treści, która ma się pojawić w monitorowanych koszykach S3. Następnie Amazon Athena będzie mogła zapełnić DB z logów, abyś mógł ją zapytać. +Musisz **przygotować relacyjną tabelę DB** ze strukturą danych odpowiadającą zawartości, która pojawi się w monitorowanych bucketach S3. Następnie Amazon Athena będzie w stanie zapełnić DB danymi z logów, abyś mógł je zapytać. -Amazon Athena obsługuje **możliwość zapytania danych S3, które są już zaszyfrowane**, a jeśli jest to skonfigurowane, **Athena może również zaszyfrować wyniki zapytania, które mogą być następnie przechowywane w S3**. +Amazon Athena obsługuje możliwość **zapytania danych S3, które są już zaszyfrowane**, a jeśli jest tak skonfigurowana, **Athena może także zaszyfrować wyniki zapytania, które następnie można przechowywać w S3**. -**To szyfrowanie wyników jest niezależne od podstawowych danych S3**, co oznacza, że nawet jeśli dane S3 nie są zaszyfrowane, wyniki zapytania mogą być zaszyfrowane. Kilka punktów, o których warto pamiętać, to to, że Amazon Athena obsługuje tylko dane, które zostały **zaszyfrowane** przy użyciu **następujących metod szyfrowania S3**, **SSE-S3, SSE-KMS i CSE-KMS**. +**To szyfrowanie wyników jest niezależne od zaszyfrowania samych danych S3**, co oznacza, że nawet jeśli dane S3 nie są zaszyfrowane, wyniki zapytań mogą być zaszyfrowane. Kilka rzeczy, które warto wiedzieć: Amazon Athena obsługuje tylko dane zaszyfrowane za pomocą następujących metod szyfrowania S3: **SSE-S3, SSE-KMS, and CSE-KMS**. -SSE-C i CSE-E nie są obsługiwane. Oprócz tego ważne jest, aby zrozumieć, że Amazon Athena będzie wykonywać zapytania tylko przeciwko **zaszyfrowanym obiektom, które znajdują się w tym samym regionie co samo zapytanie**. Jeśli musisz zapytać dane S3, które zostały zaszyfrowane przy użyciu KMS, to użytkownik Athena potrzebuje określonych uprawnień, aby umożliwić mu wykonanie zapytania. +SSE-C i CSE-C nie są obsługiwane. Dodatkowo ważne jest zrozumienie, że Amazon Athena uruchomi zapytania tylko przeciwko **zaszyfrowanym obiektom, które znajdują się w tym samym regionie co samo zapytanie**. Jeśli potrzebujesz zapytać dane S3 zaszyfrowane przy użyciu KMS, to użytkownik Athena będzie wymagał określonych uprawnień, aby móc wykonać zapytanie. ### Enumeration ```bash @@ -302,7 +302,7 @@ aws athena get-prepared-statement --statement-name --work-group # Run query aws athena start-query-execution --query-string ``` -## Odniesienia +## Źródła - [https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3](https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3) - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html)