Cloud

We just launched our brand new pierce inventory which has wide variety of antique jewellery collection. Order before we run out of the stock. Category: Cloud Solver: rgw, linaScience Flag: HTB{f0rg3ry_t0_IMDS_1s_fun!!!} Writeup We get an IP address and run a full port scan with host detection (nmap -p- -A). We see three open ports: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | [...] 8000/tcp open http Werkzeug httpd 2.0.3 (Python 3.8.10) |_http-title: Site doesn't have a title (application/json). |_http-favicon: Unknown favicon MD5: 05D7D8C4C62484FB5DB1C78E05D739A1 | http-methods: | Supported Methods: OPTIONS DELETE PUT POST HEAD GET |_ Potentially risky methods: DELETE PUT |_http-server-header: Werkzeug/2.0.3 Python/3.8.10 9000/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-title: Pierce Shopping | http-methods: |_ Supported Methods: GET HEAD |_http-server-header: Apache/2.4.41 (Ubuntu) When requesting port 8000, we get the JSON response {"Server":"Localstack","Status":"running"}. We find out that Localstack [1] is a fully functional local cloud stack. It seems like port 8000 is its exposed management port. Since access to the management port is unauthenticated by default, we use the AWS CLI tool [2] to interact with it: ...

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!} Writeup We get an IP address and run a full port scan with host detection (nmap -A -p-) and see a few open ports: PORT STATE SERVICE REASON VERSION 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’ve installed our Kubernetes cluster inside a steam powered computer, however there’s a lot of smoke, therefore we think a bolt is missing. Could you please investigate? Category: cloud Solver: t0b1 Flag: HTB{dOn7_3Xpo53_Ku83L37} Writeup According to the challenge description, we will face a Kubernetes cluster which we will have to exploit. Using nmap, we find the following open ports, most of which appear to be known Kubernetes ports: 22/tcp - ssh 2379/tcp - etcd 2380/tcp - etcd 8443/tcp - Kubernetes API (normally on port 6433) 10249/tcp - Kubelet API 10250/tcp - Kubelet API 10256/tcp - Kube-Proxy health check First, we do some basic checks against the Kubernetes API port. A curl -k https://10.129.228.17/livezreturns ok. That shows the Kubernetes is alive and running. Next, we check whether the anonymous user has too much access rights by running curl -k -X GET -H 'Accept: application/json' https://10.129.228.17:8443/api/v1/namespaces/default/pods/. However, that is not the case, as we receive a message that the anonymous user is not allowed to list the pods. ...