Merge pull request #393 from Hacking-the-Cloud/pull_all_images_locally

Cloned all images locally

content/aws/general-knowledge/aws_organizations_defaults.md

@@ -65,14 +65,14 @@ Many AWS services include specific features that have the capability to scope to
 
 ## Helpful Diagram
 
-![image](https://github.com/WebbinRoot/hackingthe.cloud/assets/74038921/e5edf877-5175-4d7d-895c-6aa8389c9207)
+![image](../../images/aws/general-knowledge/aws_organizations_defaults/aws-organizations-diagram.png)
 Trusted Access & Delegated Administration
 
 ## Trusted Access
 
 These organization integrated features are in an "off" state by default. Trusted access is the act of the management account turning "on" the organization integrated features. For example, even if a member account is part of an organization, they will not be able to increase the scope of IAM Access Analyzer to the organization until the management account enables trusted access for IAM Access Analyzer for the organization. On a technical level, the act of turning "on" an organization-integrated feature via trusted access allows the feature to make roles in member accounts to carry out its tasks. There is an AWS CLI command the management account can run to enable one of these organization-integrated features and list those that are present as seen below:
 
-![image](https://github.com/WebbinRoot/hackingthe.cloud/assets/74038921/66525d6d-a365-4603-ac9e-04124ff7ebfb)
+![image](../../images/aws/general-knowledge/aws_organizations_defaults/access-analyzer.png)
 
 !!! Note 
     Trusted access is enabled via the management account and allows IAM Access Analyzer to reach into all member accounts to achieve its objective.
@@ -81,7 +81,7 @@ These organization integrated features are in an "off" state by default. Trusted
 
 Delegated Administration is pretty much like trusted access, but is from the perspective of a member account. In delegated administration, the user allows one of the member accounts to execute an organization-integrated feature on the AWS organization, essentially "delegating" the "administration" of that feature to that member account. We would say that a member account is "a delegated administrator for service ABC (ex. IAM Access Analyzer)." The CLI command to see all delegated administrators in an organization is shown below. If you are a member account, and call this API, and your AWS account is listed in the output, than that is a good way to confirm you are in a delegated admin account. Note again that a delegated admin is **for a specific service** so rather than searching through every single feature to see what you are a delegated admin for, you can call the API shown below to see what specific feature you are a delegated admin for.
 
-![image](https://github.com/WebbinRoot/hackingthe.cloud/assets/74038921/3deec4a3-363a-48c0-a075-432d078f68a7)
+![image](../../images/aws/general-knowledge/aws_organizations_defaults/delegated-admin.png)
 
 Besides the ability to run specific organization-integrated features, note that the member account also in general **gains access to numerous read-only APIs**. For example, note how [this](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-accounts.html) CLI command states that a "delegated administrator" can run it. While a default member account can only see itself and the management account in an organization, a delegated administrator can potentially see all AWS accounts in the organization. 
 

content/azure/abusing-managed-identities.md

@@ -24,36 +24,36 @@ A Managed Identity can be a System or User identity. A System identity is bound
 First we enable the managed identity for the web application:
 
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-20.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-20.png))
 
 Once enabled, we are given the possibility to configure the roles assigned for this identity (i.e: permissions granted to the service that we enabled the identity for).
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-21.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-21.png)
 
 Lastly, we assign one or more roles (which is a set of permissions) for that identity. A role can be assigned at Subscription level, Resource group, Storage Account, Vault or SQL and it propagates “downwards” in the Azure architecture layer.
 
 The default Owner, owning the resource, and Contributor, read/write content of the resource, roles have the most permissions.
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/1.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/1.png)
 
 Under each role, we can see in details what permissions are included. Azure allows also to configure custom roles in case the built-in ones are not suitable for your case.
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-22.png?w=1024)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-22.webp)
 
 Similarly, to see who has permissions granted for a give resource, we can check that under the Access Control (IAM) -> View access to this resource.
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-23.png?w=1024)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-23.webp)
 
 So in our case, we should see under the Storage Account that the web application has Reader and Data Access:
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-24.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-24.png)
 
 
 ## Next steps
 
 Now that we have the basics of how Managed Identity works, let’s see how can we exploit this. Since the web application has access to the storage account, and we compromised the web application, we should be able to get as well access to the storage account. Long story short, we get the same permissions that the resource we compromised had. Based on how poorly the Identity roles are assigned, it could even be the case that the permissions are assigned at Subscription level, effectively granting us access to all resources inside it!
 
-![Azure Managed Identities](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/media/organize-resources/scope-levels.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/scope-levels.png)
 
 While in our case it looks that the permissions are proper (we are limiting access only to the Storage Account that we need access to) and limit the roles to Reader and Data Access (instead of Contributor or Owner), there is still a catch. Our web app needs permissions only to the “images” container, but the managed identity configured has enough permissions to list the access keys to the whole Storage Account granting us access to any other containers hosted in the same account. 
 
@@ -64,7 +64,7 @@ Abusing the command injection on the web app, we can make a curl request to the
 ```bash
 curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER
 ```
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-25.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-25.png)
 
 
 Using the Azure Powershell module, we can connect to Azure with the access token: 
@@ -75,7 +75,7 @@ PS> Connect-AzAccount -AccessToken <access_token> -AccountId <client_id>
 
 Once connected, you should see details about the Subscription and Tenant that the Managed Identity we are impersonating has access to. Using the Get-AzResource Azure Powershell cmdlet, we can check which resources inside the subscription we can access:
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-26.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-26.png)
 
 
 To list the roles assigned to the managed, we can use the Azure Powershell cmdlet Get-AzRoleAssignment. This cmdlet requires additionally a graph token which we can get from the https://graph.microsoft.com/ endpoint, but also the permission to list roles and permissions for identities which our Identity does not have.
@@ -98,18 +98,18 @@ key2    vcZiPzJp[...]ZkKvA==        Full 3/12/20...
 
 If the above command returns two keys, than it means that our identity had permissions to list them. Let’s use these keys in Azure Storage Explorer and see if there are other containers stored on the same account. In the Azure Storage Explorer, we click the connect icon and select storage account or service.
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-27.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-27.png)
 
 On the second step, this time we select the Account name and key option:
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-28.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-28.png)
 
 For the Account name we use the name that we enumerated in the Get-AzResource step, while for the key we can use either of the two we found:
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-29.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-29.png)
 
 Once we connect, on the left side menu we should find a new storage account, we see 2 containers: the images container used by the web app, but also another one containing the flag. 
 
-![Azure Managed Identities](https://0xpwn.files.wordpress.com/2022/03/image-30.png)
+![Azure Managed Identities](../images/azure/abusing-managed-identities/image-30.png)
 
 And that’s it! We have just seen how abusing a command injection into a web app, we discovered that it had a managed identity associated to it. After we got the JWT access token, we connected to Azure using the Azure Powershell and enumerated the resources that we have access to. The improper permissions set for the Managed Identity allowed us to read the access key for the whole Storage Account and discover another private container that was not referenced anywhere, containing the flag sensitive information. 

content/azure/anonymous-blob-access.md

@@ -20,7 +20,7 @@ description: Finding and accessing files stored in Azure Storage Accounts withou
 - Queues
 - VM disks
 
-![Azure Storage Account](https://www.partech.nl/-/media/habitat/images/blog/azure-storage-account/azure-storage-types.ashx?mw=900&hash=555BFCDE52A79D19432AA476A2935234)
+![Azure Storage Account](../images/azure/anonyous-blob-access/Azure%20Storage%20Types.png)
 
 For this tutorial, we will focus on the Blobs section. Blobs are stored within a container, and we can have multiple containers within a storage account. When we create a container, Azure will ask on the permissions that we grant for public access. We can chose between:
 

content/azure/soft-deleted-blobs.md

@@ -21,43 +21,43 @@ In this tutorial we will see how data that has been deleted from a private Stora
 For the sake of this tutorial, we will pretend to be a developer that uses the connection string and saves it in a config file/source code deployed to Azure. Additionally, the web application deployed has a command injection vulnerability. 
 We can find the connection string of a Storage Account in the Azure portal as shown below:
 
-![Storage Account Keys](https://0xpwn.files.wordpress.com/2022/03/image-4.png?w=1024)
+![Storage Account Keys](../images/azure/soft-deleted-blobs/image-4.webp)
 
 Now, the problem here is that we are giving access to the whole storage account by passing the connection string into the web app. Azure supports granular access for specific containers, for a limited amount of time, or event for a specific file within the container! But for convenience (or lack of knowledge), a developer might deploy the connection string for the entire storage account. Don’t be that developer.
 
 The second part of this tutorial is about recovering deleted blobs. By default, when creating a storage container using the Portal, the Soft Deletion is enabled with 7 days retention time. Now image that you got access to a storage account with tens of containers, and someone at some point mistakenly uploaded an SSH key to one of these containers and than deleted it without being aware of the 7 day retention day “feature”. 
 
-![Soft Deleted Blob](https://0xpwn.files.wordpress.com/2022/03/image-5.png)
+![Soft Deleted Blob](../images/azure/soft-deleted-blobs/image-5.png)
 
 ## Exploiting Soft Deleted Blobs
 Now, to exploit this vulnerability we navigate to the web application vulnerable to command injection and start poking around. Listing the files in the current directory, we can find among other the source code in the app.py:
 
-![Files](https://0xpwn.files.wordpress.com/2022/03/image-6.png)
+![Files](../images/azure/soft-deleted-blobs/image-6.png)
 
 Listing the contents of this file, we can see there is a connection string stored inside (our placeholder has been replaced at runtime with the actual value of the container):
 
-![Source code](https://0xpwn.files.wordpress.com/2022/03/image-7.png)
+![Source code](../images/azure/soft-deleted-blobs/image-7.png)
 
 Inside the Microsoft Azure Container Explorer, we specify that we want to connect to a storage account
 
-![Storage Account explorer](https://0xpwn.files.wordpress.com/2022/03/image-8.png)
+![Storage Account explorer](../images/azure/soft-deleted-blobs/image-8.png)
 
 And that we want to use a Connection String
 
-![Connection String](https://0xpwn.files.wordpress.com/2022/03/image-9.png)
+![Connection String](../images/azure/soft-deleted-blobs/image-9.png)
 
 And we paste the value of the conn_str variable that we found in the source code, and connect:
 
-![Connection info](https://0xpwn.files.wordpress.com/2022/03/image-10.png)
+![Connection info](../images/azure/soft-deleted-blobs/image-10.png)
 
 On the left side menu, a new storage account should show up. Navigate to the Blob Containers -> images and open it:
 
-![Container](https://0xpwn.files.wordpress.com/2022/03/image-11.png)
+![Container](../images/azure/soft-deleted-blobs/image-11.png)
 
 At first glance, it seems that nothing of interest is stored here. Remember the flag that we accidentally uploaded? Change the view to Active and soft deleted blobs:
 
-![Files](https://0xpwn.files.wordpress.com/2022/03/image-12.png)
+![Files](../images/azure/soft-deleted-blobs/image-12.png)
 
 And voila! Right click -> Undelete
 
-![Flag](https://0xpwn.files.wordpress.com/2022/03/image-13.png)
+![Flag](../images/azure/soft-deleted-blobs/image-13.png)