GitBook: [#3136] No subject

This commit is contained in:
CPol 2022-04-28 14:00:21 +00:00 committed by gitbook-bot
parent 619a10d134
commit 6a1d031247
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
14 changed files with 10 additions and 10 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 62 KiB

After

Width:  |  Height:  |  Size: 113 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 113 KiB

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 74 KiB

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 8.4 KiB

View file

@ -2,7 +2,7 @@
## Architecture
![](<../../.gitbook/assets/image (651) (1).png>)
![](<../../.gitbook/assets/image (651) (1) (1).png>)
### ATC: web UI & build scheduler

View file

@ -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.

View file

@ -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!

View file

@ -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):

View file

@ -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 arent sufficient to identify it.

View file

@ -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.

View file

@ -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>