Secret of Meow Olympurr
Description
Jaga reached Meow Olympurr and met some native Meows. While cautious at first, they warmed up and shared that they have recently created a website to promote tourism! However, the young Meows explained that they are not cy-purr security trained and would like to understand what they might have misconfigured in their environments. The young Meows were trying to get two different environments to work together, but it seems like something is breaking.... Log a cy-purr security case by invoking the mysterious function and retrieve the secret code!
d2p9lw76n0gfo0.cloudfront.net
Finding the Azure Blob Storage
We are provided with a CloudFront page, https://d2p9lw76n0gfo0.cloudfront.net.
I initially tried scanning the page for any hidden files or directories but didn't have any luck with that. But looking at the 404 error page raised some suspicions as an image failed to load.
This is due to mixed content - an HTTP image is being loaded on an HTTPS page, and modern browsers do not allow this.
The image URL is interesting - it uses a CORS-Anywhere proxy running at http://18.141.147.115:8080 to add CORS headers to the resource from https://meowolympurr.z23.web.core.windows.net/images/ohno.jpg.
The resource being fetched is an Azure Blob Storage URL for the meowolympurr account. Let's visit the 404 error page again, this time on the meowolympurr.z23.web.core.windows.net blob storage.
This time, the same error image is fetched with a Shared Access Signature (SAS) token, and an HTML comment hints at using the SAS token to access the website's source code.
The content in the index.html page is similar to what was hosted on the CloudFront page, except for a new paragraph at the end of the page.
The SSRF Rabbit Hole
This new URL appears to be a dynamic site! All it does is fetch the URL provided in the url GET parameter, and return the fetched response.
Such an SSRF may prove useful, but we are not yet sure of the environment this code is running in, and most importantly, we don't have the source code. Nonetheless, I spent some time trying to hit potential internal resources with the SSRF but had no luck.
Heading over to the root URL of https://olympurr-app.azurewebsites.net, we see that this is an Azure functions application.
While Azure VMs have access to a metadata server, this is not applicable to a serverless function. It seems that the SSRF itself might not be so useful after all.
A Very Sassy Challenge
We previously found a SAS token and a hint to access the website's source code, so let's see if we could find the source code of this function somewhere.
Let's start with listing the containers available. We can do this using the List Containers operation of the Blob Service REST API. Simply specify comp=list, and append the SAS token:
https://meowolympurr.blob.core.windows.net/?comp=list&sv=2017-07-29&ss=b&srt=sco&sp=rl&se=2022-12-12T00:00:00Z&st=2022-09-01T00:00:00Z&spr=https&sig=UE2%2FTMTAzDnyJEABpX4OYFBs1b1uAWjwEEAtjeQtwxg%3D
This gives us the following list of containers.
Once we have the container name, we could use the List Blobs operation to list the blobs under the specified container. For example, the following lists all blobs under the $web container.
https://meowolympurr.blob.core.windows.net/$web?restype=container&comp=list&sv=2017-07-29&ss=b&srt=sco&sp=rl&se=2022-12-12T00:00:00Z&st=2022-09-01T00:00:00Z&spr=https&sig=UE2%2FTMTAzDnyJEABpX4OYFBs1b1uAWjwEEAtjeQtwxg%3D
The $web container contains the static files served to us at the start of the challenge.
The dev container, on the other hand, contained an interesting readme.md file.
Using the same SAS token, we can head over to /dev/readme.md to read it.
I Find Your Lack of Sauce... Disturbing
We are finally one step closer to getting the coveted sauce code for the function app!
It looks like we got our hands on some Azure credentials, and yet another SAS token. Using the tenant ID, application ID and client secret, we can login through the Azure CLI.
The Azure CLI provides a very convenient resource API that allows us to list all resources using the az resource list command. Here's the result of running that command.
It looks like this service principal has access to a different storage account, by the name of meowvellousappstorage. After discovering this storage blob name, we can use the provided SAS token to access the scm-releases container:
https://meowvellousappstorage.blob.core.windows.net/scm-releases?restype=container&comp=list&sv=2018-11-09&sr=c&st=2022-09-01T00%3A00%3A00Z&se=2022-12-12T00%3A00%3A00Z&sp=rl&spr=https&sig=jENgCFTrC1mYM1ZNo%2F8pq1Hg9BO1VLbXlk%2FpABrK4Eo%3D
This container contains a single ZIP file, scm-latest-olympurr-app.zip, which contains the source code of the function.
This contains the source code of the function app.
Goodbye Bill, Hello Jeff
Taking a look at the source code, we see that a secret is obtained from an Azure key vault and used as the secret access key for an AWS session.
As stated previously in the readme.md, the service principal account we have access to "has the same privileges as the function app". This means that we should be able to retrieve this secret from the key vault.
Next, an AWS lambda function by the name of event-webservice is invoked.
Before we proceed with exploring AWS, we need to log in by configuring the access key ID and secret access key we just found in our AWS CLI.
Great! Now we can take a look at the user policies attached to our user to gain a better understanding of our privileges.
As we already know, we can invoke lambda functions. Let's try to invoke the event-webservice function to see its output.
Hmm, this function does not return much useful information. Not providing a valid payload also results in an exception, but we can't see much from the response.
Log Me In
Three of the actions listed in the policy allow us to retrieve logs from the logs API.
Viewing the logs of the function's execution may provide us with more insights.
To begin, we can list the log groups available. The /aws/lambda/event-webservice log group contains the logs of our previously invoked function, but there are several other interesting log groups as well.
The last log group, /aws/lambda/internal-secret-of-MeowOlympurr-webservice, is very suspicious indeed! Let's take a look at its log streams.
The log stream names are in the format <YYYY>/<MM>/<DD>/[$LATEST]<HASH>.
There are a bunch of logs from recent runs in November and December, but these all had the same message.
The earliest log event was in September, which seemed the most out of place since it took place almost a full 2 months prior to the next log stream.
This time, we get the message "secrets returned in response". Looks like this function does return something useful after all. Let's try to invoke the corresponding function, internal-secret-of-MeowOlympurr-webservice.
Sure enough, the flag is in the response!
Conclusion
In conclusion, I am too lazy to write one so ChatGPT did it for me.
Last updated
Was this helpful?