GitBook: [#3136] No subject
BIN
.gitbook/assets/image (651) (1) (1) (1) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 113 KiB |
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 74 KiB |
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 8.4 KiB |
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Architecture
|
||||
|
||||
![](<../../.gitbook/assets/image (651) (1).png>)
|
||||
![](<../../.gitbook/assets/image (651) (1) (1).png>)
|
||||
|
||||
### ATC: web UI & build scheduler
|
||||
|
||||
|
|
|
@ -236,7 +236,7 @@ kubectl port-forward pod/mypod 5000:5000
|
|||
|
||||
### **Hosts Writable /var/log/ Escape**
|
||||
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)**,**If you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)\*\*,\*\*If you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
|
||||
This is basically because the when the **Kube-API tries to get the logs** of a container (using `kubectl logs <pod>`), it **requests the `0.log`** file of the pod using the `/logs/` endpoint of the **Kubelet** service.\
|
||||
The Kubelet service exposes the `/logs/` endpoint which is just basically **exposing the `/var/log` filesystem of the container**.
|
||||
|
||||
|
@ -537,7 +537,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security
|
|||
|
||||
An admission controller is a piece of code that **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
|
||||
|
||||
![](<../../../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
|
||||
![](<../../../.gitbook/assets/image (651) (1) (1) (1) (1) (1).png>)
|
||||
|
||||
If an attacker somehow manages to **inject a Mutationg Adminssion Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
</details>
|
||||
|
||||
{% hint style="danger" %}
|
||||
****
|
||||
****<img src="../.gitbook/assets/image (651).png" alt="" data-size="original">****
|
||||
|
||||
**Bug bounty tip**: sign up for **Intigriti**, a premium **bug bounty platform created by hackers, for hac**kers! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to $100,000!
|
||||
|
||||
|
|
|
@ -70,7 +70,7 @@ Therefore, if an attacker **injects** a **HEAD** request, like in this images:
|
|||
|
||||
Then, **once the blue one is responded to the attacker**, the next victims request is going to be introduced in the queue:
|
||||
|
||||
![](<../.gitbook/assets/image (651) (1) (1) (1) (1) (1).png>)
|
||||
![](<../.gitbook/assets/image (651) (1) (1) (1) (1) (1) (1).png>)
|
||||
|
||||
Then, the **victim** will **receive** the **response** from the **HEAD** request, which is **going to contain a Content-Length but no content at all**. Therefore, the proxy **won't send this response** to the victim, but will **wait** for some **content**, which actually is going to be **response to the yellow request** (also injected by the attacker):
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ To request a PTR record, clients use the name form "\<Service>.\<Domain>". The *
|
|||
|
||||
The part of the PTR record to the **left** of the colon is its **name**, and the part on the **right** is the **SRV** **record** to which the PTR record points. The **SRV** record lists the target **host** and **port** where the **service** instance can be reached. For example, the next image shows a "test.\_ipps.\_tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:
|
||||
|
||||
![](<../.gitbook/assets/image (651) (1) (1) (1).png>)
|
||||
![](<../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
|
||||
|
||||
Therefore, the **name of the SRV** record is **like** the **PTR** record **preceded** by the **\<Instance>** name (test in this case). The **TXT** has the **same** **name** as the **SRV** record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.
|
||||
|
||||
|
|
|
@ -17,6 +17,6 @@ In Arduino, after connecting the cables (pin 2 to 11 to JTAG pins and Arduino GN
|
|||
Configure **"No line ending" and 115200baud**.\
|
||||
Send the command s to start scanning:
|
||||
|
||||
![](<../../.gitbook/assets/image (651) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (651) (1) (1) (1).png>)
|
||||
|
||||
If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.
|
||||
|
|
|
@ -51,7 +51,7 @@ Note that in order to **see all the handles of all the processes, the SeDebugPri
|
|||
|
||||
To see the handles of a process, right click in the process and select Handles:
|
||||
|
||||
![](<../../.gitbook/assets/image (651).png>)
|
||||
![](<../../.gitbook/assets/image (651) (1).png>)
|
||||
|
||||
You can then right click on the handle and **check the permissions**:
|
||||
|
||||
|
@ -298,7 +298,7 @@ In a real scenario you probably **won't be able to control the binary** that is
|
|||
{% endhint %}
|
||||
|
||||
In this example you can find the code of a possible exploit for _C:\users\username\desktop\client.exe_.\
|
||||
The most interesting part of this code is located in `GetVulnProcHandle`. This function will **start fetching all the handles**, then it will **check if any of them belongs to the same PID** and if the handle belongs to a **process**. If all these requirements are completed (an accessible open process handle is found) , it try to **inject and execute a shellcode abusing the handle of the process**. \
|
||||
The most interesting part of this code is located in `GetVulnProcHandle`. This function will **start fetching all the handles**, then it will **check if any of them belongs to the same PID** and if the handle belongs to a **process**. If all these requirements are completed (an accessible open process handle is found) , it try to **inject and execute a shellcode abusing the handle of the process**.\
|
||||
The injection of the shellcode is done inside the **`Inject`** function and it will just **write the shellcode inside the privileged process and create a thread inside the same process** to execute the shellcode).
|
||||
|
||||
```c
|
||||
|
@ -512,7 +512,7 @@ In a real scenario you probably **won't be able to control the binary** that is
|
|||
|
||||
In this example, **instead of abusing the open handle to inject** and execute a shellcode, it's going to be **used the token of the privileged open handle process to create a new one**. This is done in lines from 138 to 148.
|
||||
|
||||
Note how the **function `UpdateProcThreadAttribute`** is used with the **attribute `PROC_THREAD_ATTRIBUTE_PARENT_PROCESS` and the handle to the open privileged process**. This means that the **created process thread executing **_**cmd.exe**_** will have the same token privilege as the open handle process**.
|
||||
Note how the **function `UpdateProcThreadAttribute`** is used with the **attribute `PROC_THREAD_ATTRIBUTE_PARENT_PROCESS` and the handle to the open privileged process**. This means that the **created process thread executing \_cmd.exe**\_\*\* will have the same token privilege as the open handle process\*\*.
|
||||
|
||||
```c
|
||||
#include <windows.h>
|
||||
|
|