Azure - Anonymous Blob Access

content/azure/anonymous-blob-access.md

@@ -0,0 +1,69 @@
+---
+author: andrei8055
+title: Anonymous Blob Access
+description: Finding and accessing files stored in Azure Storage Accounts without authentication.
+---
+
+Originally Research: [0xPwN Blog - Create an Azure Vulnerable Lab: Part #1 – Anonymous Blob Access](https://0xpwn.wordpress.com/2022/03/05/setting-up-an-azure-pentest-lab-part-1-anonymous-blob-access/) 
+
+"Storage Accounts" is the service provided by Azure to store data in the cloud. A storage account can used to store:
+
+- Blobs
+- File shares
+- Tables
+- 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)
+
+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:
+
+- Private Access – no anonymous access is allowed
+- Blob Access – we can access the blobs anonymously, as long as we know the full URL (container name + blob name)
+- Container Access – we can access the blobs anonymously, as long we know the container name (directory listing is enabled, and we can see all the files stored inside the container)
+
+As you might have guessed, granting Container Access permission can be easily abused to download all the files stored within the container without any permissions as the only things required to be known are the storage account name and the container name, both of which can be enumerated with wordlists.
+
+## Exploiting Anonymous Blob Access
+
+Now, there are thousands of articles explaining how this can be abused and how to search for insecure storage in Azure, but to make things easier I’ll do a TL:DR. One of the easiest way is to use MicroBurst, provide the storage account name to search for, and it’ll check if the containers exists based on a wordlist saved in the Misc/permutations.txt:
+
+```
+PS > import-module .\MicroBurst.psm1
+PS> Invoke-EnumerateAzureBlobs -Base 0xpwnstorageacc
+Found Storage Account - 0xpwnstorageacc.blob.core.windows.net
+Found Container - 0xpwnstorageacc.blob.core.windows.net/public
+Public File Available: https://0xpwnstorageacc.blob.core.windows.net/public/flag.txt
+```
+
+Alternatively adding ```?restype=container&comp=list``` after the container name:
+```
+https://<storage_account>.blob.core.windows.net/<container>?restype=container&comp=list
+```
+Output:
+```
+
+<EnumerationResults ContainerName="https://0xpwnstorageacc.blob.core.windows.net/public">
+	<Blobs>
+		<Blob>
+			<Name>flag.txt</Name>
+			<Url>
+https://0xpwnstorageacc.blob.core.windows.net/public/flag.txt
+</Url>
+			<Properties>
+				<Last-Modified>Sat, 05 Mar 2022 18:02:14 GMT</Last-Modified>
+				<Etag>0x8D9FED247B7848D</Etag>
+				<Content-Length>34</Content-Length>
+				<Content-Type>text/plain</Content-Type>
+				<Content-Encoding/>
+				<Content-Language/>
+				<Content-MD5>lur6Yvd173x6Zl1HUGvtag==</Content-MD5>
+				<Cache-Control/>
+				<BlobType>BlockBlob</BlobType>
+				<LeaseStatus>unlocked</LeaseStatus>
+			</Properties>
+		</Blob>
+	</Blobs>
+	<NextMarker/>
+</EnumerationResults>
+```

content/azure/soft-deleted-blobs.md

@@ -0,0 +1,58 @@
+---
+author: andrei8055
+title: Soft Deleted Blobs
+description: Recovering and accessing files in private Storage Accounts that have been deleted.
+---
+
+
+Orginally posted on [0xPwN Blog - Create an Azure Vulnerable Lab: Part #3 – Soft Deleted Blobs](https://0xpwn.wordpress.com/2022/03/09/create-an-azure-vulnerable-lab-part-3-soft-deleted-blobs/)
+
+In this tutorial we will see how data that has been deleted from a private Storage Account Container can still be a risk in some cases. Even if we know the full path of resources uploaded to a private container, Azure requires authentication to be accessed. To provide access we can choose between:
+
+- A shared access signature (SAS) – is a URI that grants restricted access to an Azure Storage container. Use it when you want to grant access to storage account resources for a specific time range without sharing your storage account key.
+- A connection string includes the authorization information required for your application to access data in an Azure Storage account at runtime using Shared Key authorization.
+- Managed Identities
+
+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)
+
+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)
+
+## 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)
+
+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)
+
+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)
+
+And that we want to use a Connection String
+
+![Connection String](https://0xpwn.files.wordpress.com/2022/03/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)
+
+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)
+
+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)
+
+And voila! Right click -> Undelete
+
+![Flag](https://0xpwn.files.wordpress.com/2022/03/image-13.png)