You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
```platform.system()``` and ```platform.release()``` are similar to ```uname -o``` and ```uname -r```. On a stock Kali install it will generate the following values.
Does it really take 10 minutes? Yes, it takes a little bit to get everything setup. You can take this time to get familiar with your attackbox. This is an EC2 instance you can use for whatever you need during the CTF, particularly to catch shells.
142
142
@@ -153,31 +153,31 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
153
153
154
154
After waiting those 10 minutes, you finally have a target. You can navigate to the target_ip to see a GitLab instance. Log in using your player username and password.
From here, you can navigate around, explore the various projects, and more. You might even notice a little notification in the upper right hand corner.
This is interesting for a few reasons. Most notably, Ashley wants some help with building a Docker container as a part of the CI/CD pipeline. She also mentions a [gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html) file, which is the configuration for the [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) pipeline.
169
169
170
170
Building Docker images as a part of a CI/CD pipeline can have serious security implications and this is definitely worth looking into.
171
171
172
172
Before we can get to that fun, let's take a look at that gitlab-ci.yml file. Navigate there and make some changes (you can edit the file through the web browser if you prefer or you can clone the project locally).
This can tell us a few things that are very useful to us as attackers. First, on line 3, we see that the CI/CD pipeline is using the "docker" executor, meaning everything executes inside a Docker container somewhere. On line 6, we see that it is using an Ubuntu Docker image. And lines 20+ show us that our input is executing in this environment.
183
183
@@ -191,7 +191,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
191
191
192
192
SSH into your attack box and install a tool called `ncat`.
@@ -233,7 +233,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
233
233
234
234
The common location for the socket is at `/var/run/docker.sock`, let's go look for it.
235
235
236
-
236
+
237
237
238
238
There we go! They did mount the Docker socket! Let's use this to escape the container.
239
239
@@ -257,7 +257,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
257
257
python3 -c "import pty;pty.spawn('/bin/bash')"
258
258
```
259
259
260
-
260
+
261
261
262
262
Doesn't that looks so much better? We have an actual shell prompt now. This will be useful for interacting with the Docker socket. Speaking of which, let's see which Docker containers are running on the host.
263
263
@@ -277,7 +277,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
"Admin IAM Credentials are being stored in environment variables to be used with the GitLab runners". That sounds.....very interesting. The good news is that as an administrator, we can see those variables. Navigate to the `Settings` tab on the left and then click `CI/CD`. Next, click `Expand` on the `Variables` section.
310
310
311
-
311
+
312
312
313
313
An Access Key and a Secret Access Key! Let's see who they belong to (you can also do this [without logging to CloudTrail](https://hackingthe.cloud/aws/enumeration/whoami/) if you were so inclined).
314
314
@@ -318,7 +318,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
And with that we have achieved our objective! Congratulations on completing the CTF. Want to provide some feedback? Feel free to open a discussion on [GitHub](https://github.com/Hacking-the-Cloud/hackingthe.cloud/discussions/categories/ctf-discussion).
Copy file name to clipboardExpand all lines: content/aws/deprecated/stealth_perm_enum.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -71,5 +71,5 @@ There are some conditions to the enumeration, and they are defined below.
71
71
To perform the enumeration there is a script [here](https://github.com/Frichetten/aws_stealth_perm_enum). Setting the credentials as environment variables and then running the script will inform you what API permissions you have available to you.
72
72
73
73
<figuremarkdown>
74
-
{ loading=lazy }
74
+
{ loading=lazy }
Copy file name to clipboardExpand all lines: content/aws/enumeration/account_id_from_s3_bucket.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -59,4 +59,4 @@ found: 123456789123
59
59
The majority of this activity would only be logged to the calling account (the account you are running the tool with), however S3 data events and server access logging can be used to see the API activity. That being said, there is no immediate way to counter or prevent you from doing this. Additionally these requests could be spaced out over an extended period of time, further making it difficult to identify.
60
60
61
61
!!! Tip
62
-
Pair this with [Unauthenticated Enumeration of IAM Users and Roles](/aws/enumeration/enum_iam_user_role/)!
62
+
Pair this with [Unauthenticated Enumeration of IAM Users and Roles](https://hackingthe.cloud/aws/enumeration/enum_iam_user_role/)!
Copy file name to clipboardExpand all lines: content/aws/enumeration/loot_public_ebs_snapshots.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -10,15 +10,15 @@ For EC2 instances, files and data are typically stored in [Elastic Block Store](
10
10
11
11
EBS Snapshots have two availability settings, Private and Public. It is important to note that EBS does not utilize resource-based policies. If a snapshot is made public via the console or through Infrastructure as Code, it will be available to anyone with no additional controls.
A lot of instances of resource exposure (and subsequent [exploitation](/aws/exploitation/Misconfigured_Resource-Based_Policies/)) in AWS require knowing the ARN of the resource. This provides some level of security-by-obscurity, as the attacker needs to find the ARN through some means (In some cases this can also apply to [vulnerabilities in AWS services](https://securitylabs.datadoghq.com/articles/appsync-vulnerability-disclosure/) themselves).
17
+
A lot of instances of resource exposure (and subsequent [exploitation](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/)) in AWS require knowing the ARN of the resource. This provides some level of security-by-obscurity, as the attacker needs to find the ARN through some means (In some cases this can also apply to [vulnerabilities in AWS services](https://securitylabs.datadoghq.com/articles/appsync-vulnerability-disclosure/) themselves).
18
18
19
19
A somewhat unique trait of EBS snapshots is that, if they are set to public, the list of those EBS snapshots is publicly available through the AWS API. From the EC2 section in the AWS console, navigate to Elastic Block Store, Snapshots, and select `Public snapshots` from the drop down. This will show all publicly available EBS snapshots (you may have to scroll through to see an accurate count).
20
20
21
-
21
+
22
22
23
23
To pull this list in an easily consumable format you can use the following CLI command:
24
24
@@ -29,7 +29,7 @@ aws ec2 describe-snapshots --restorable-by-user-ids all
29
29
As of the time of this writing there are tens of thousands of snapshots exposed. As a bonus, it is possible to filter this list by account ID, allowing you to easily target specific accounts.
30
30
31
31
!!! Tip
32
-
This can be an easy, free (in terms of detection) check to look out for when exploiting AWS environments. If you steal IAM credentials, you can [determine the account](/aws/enumeration/get-account-id-from-keys/) they are tied to and check for exposed EBS snapshots.
32
+
This can be an easy, free (in terms of detection) check to look out for when exploiting AWS environments. If you steal IAM credentials, you can [determine the account](https://hackingthe.cloud/aws/enumeration/get-account-id-from-keys/) they are tied to and check for exposed EBS snapshots.
33
33
34
34
To search for all public EBS snapshots associated with an AWS account, use the following command:
description: How to take advantage of misconfigured AWS ECR private repositories.
5
5
---
6
6
7
-
AWS Elastic Container Registry (ECR) [private repositories](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Repositories.html) use resource-based policies to delineate which entities are permitted to push and pull containers. As a result, it is possible for these policies to be [misconfigured](/aws/exploitation/Misconfigured_Resource-Based_Policies/) and potentially abused. The following are some examples of possible misconfigurations and the required permissions needed to take advantage of them.
7
+
AWS Elastic Container Registry (ECR) [private repositories](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Repositories.html) use resource-based policies to delineate which entities are permitted to push and pull containers. As a result, it is possible for these policies to be [misconfigured](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/) and potentially abused. The following are some examples of possible misconfigurations and the required permissions needed to take advantage of them.
8
8
9
9
!!! Note
10
-
Aside from the [wildcard principal](/aws/exploitation/misconfigured_resource-based_policies/#the-principal-and-risks), you should also be mindful of overbroad permissions in general, such as permitting an entire AWS account to have access.
10
+
Aside from the [wildcard principal](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks), you should also be mindful of overbroad permissions in general, such as permitting an entire AWS account to have access.
11
11
12
12
## Understanding ecr:GetAuthorizationToken
13
13
14
-
A unique [requirement](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html#repository-policy-vs-iam-policy) to abusing misconfigured resource-based policies in ECR is [ecr:GetAuthorizationToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-authorization-token.html). The attacking entity must have this permission via an identity-based policy, it cannot be permitted via a resource-based policy (even if the `Action` element is `ecr:*`). For scenarios in which the policy has a [wildcard principal](/aws/exploitation/misconfigured_resource-based_policies/#the-principal-and-risks) and a broken policy, this is not a problem as you can create a role with the needed permission.
14
+
A unique [requirement](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html#repository-policy-vs-iam-policy) to abusing misconfigured resource-based policies in ECR is [ecr:GetAuthorizationToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-authorization-token.html). The attacking entity must have this permission via an identity-based policy, it cannot be permitted via a resource-based policy (even if the `Action` element is `ecr:*`). For scenarios in which the policy has a [wildcard principal](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks) and a broken policy, this is not a problem as you can create a role with the needed permission.
15
15
16
16
!!! Note
17
17
When interacting with an ECR private repository via the [Docker](https://github.com/docker/cli) cli, you use [ecr:GetLoginPassword](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html) to authenticate. This calls `ecr:GetAuthorizationToken` to provide the needed authorization.
Copy file name to clipboardExpand all lines: content/aws/exploitation/abusing-container-registry.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ hide:
26
26
IAM (Identity and Access Management) is a set of consents that attach to identities, or cloud resources, to authorize what they can actually do. This means EC2 resources, and others like it, also have identities that can change the infrastructure itself. 43.9% of organizations have internet-facing workloads containing secrets and credentials, as a result, identity and access management (IAM) has become more critical than ever.
This post is designed to show the impact of this attack technique and help security engineers and DevOps/SecOps to detect and understand the risks of ECR and other Container registries.
0 commit comments