Service Exploits

A service is a program running in the background, accepting input or doing periodic work. When a vulnerable service runs as root, exploiting it gives command execution as root. This is the counterpart to Kernel Exploits: instead of attacking the kernel, attack a privileged process running on top of it. It sits at the same spot on the Privilege Escalation triage list.

Identify Services Running as Root

ps aux | grep "^root"

^root anchors the match to the process owner column, so the list is only processes actually running as root. Local-only services bound to 127.0.0.1 matter as much as network-facing ones, since access is already local.

Enumerate Program Versions

An exploit search is only as good as the version fed to it. Pin the version of each interesting process:

<program> --version
<program> -v
dpkg -l | grep <program>     # Debian/Ubuntu
rpm -qa | grep <program>     # RHEL/CentOS

A Script Instead of a Named Daemon

ps aux | grep "^root" sometimes turns up an interpreter running a small custom script, python3 /opt/something.py or similar, rather than a package with its own --version. The interpreter’s version is not what matters; the vulnerability almost always lives in a third-party library the script imports, not the few lines of app code wrapping it.

Read the script if it is readable, and note every third-party import. The library name is often narrow enough that searching it directly (searchsploit <library>, or the exact import name plus “exploit”/“CVE”) surfaces a match with little noise. Confirm rather than assume: pin the installed version before trusting a name match.

pip3 show <library>
pip3 list 2>/dev/null | grep -i <library>
python3 -c "import pkg_resources; print(pkg_resources.get_distribution('<library>').version)"

Check that version against the CVE’s affected range before spending time on the exploit. A name match against a patched version is a dead end.

Find Matching Exploits

Same sources as any exploit hunt: SearchSploit, Google, GitHub.

searchsploit <program> <version>

Read what the exploit needs before running it, then compile and run. As with kernel exploits, prefer building on the target when the exploit is sensitive to local ABI or headers, per the compile-on-target reasoning in Kernel Exploits.

Worked Example: MySQL as root

The recurring case is a database daemon running as root:

root  6933  ... /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=root

mysqld running as root can be driven to execute system commands through a User Defined Function (UDF) loaded from a shared object, ending in a SUID root shell. The full method (compiling raptor_udf2, installing the function, and select do_system(...) to drop a +s bash) is in MySQL Privilege Escalation, the vector Pebbles used.

Checklist

• ps aux | grep "^root" to list root-owned processes.
• Version each interesting one (--version, dpkg -l, rpm -qa).
• searchsploit / Google / GitHub for a matching local exploit.
• Watch stability: like kernel exploits, service exploits can be one-shot or crash the process.