Privilege Escalation on Embedded Linux
Landing a shell on an embedded Linux device often gives you a limited account, not root. Getting from there to full control is privilege escalation, and embedded systems offer a rich set of paths because they are frequently built with convenience ahead of hardening. Here are the escalation routes I check first, and what they say about the device.
Why Embedded Escalation Is Often Easy
Embedded Linux is still Linux, so the classic privilege-escalation techniques apply, but the environment tilts in the attacker’s favor. These systems are built by teams focused on shipping a working product, often reusing a vendor SDK, with security hardening low on the list. The result is a userland full of the shortcuts that escalation exploits.
Where a hardened server has had its SUID binaries pruned, its permissions tightened, and its services dropped to least privilege, an embedded device frequently has none of that. Many processes already run as root because it was easier, world-writable files abound, and old vulnerable binaries linger. Escalation is often a matter of checking the usual suspects and finding one of them open.
Enumerate First
Escalation starts with enumeration: systematically gathering the facts that reveal a path. Who am I, what can I run, what is misconfigured. On a constrained device the standard tooling may be missing, so I lean on built-in commands and a few targeted checks rather than a heavy enumeration script.
id; uname -a; cat /etc/*release 2>/dev/null ps w # what runs, and as whom ls -la /etc/passwd /etc/shadow
uid=1000(app) gid=1000(app) Linux device 3.10.14 #1 mips PID USER COMMAND 214 root /usr/sbin/httpd # web server running as root 311 app /usr/bin/cli
Already a lead: the web server runs as root. A vulnerability in a root process is a direct path to root, so a process list that shows services needlessly privileged is one of the first things I note. The kernel version is old too, which raises the possibility of a kernel exploit as a fallback.
SUID and SGID Binaries
SUID binaries run with the privileges of their owner regardless of who launches them, so a SUID-root binary that can be made to run arbitrary commands is an escalation. Embedded images often ship unnecessary SUID binaries, sometimes custom ones with exploitable behavior.
find / -perm -4000 -type f 2>/dev/null
/bin/busybox /usr/bin/passwd /usr/sbin/custom_helper # a vendor binary, SUID root
The interesting entry is custom_helper, a vendor-specific SUID-root binary. Vendor SUID binaries are prime targets because they are not battle-tested like the standard tools, and they frequently call out to a shell, trust an environment variable, or run another program by relative path, any of which can be turned into root.
Writable Files Owned by Root
A file that root reads or executes but that I can write is an escalation waiting to happen. World-writable scripts run by root, writable configuration that controls a root process, or a writable binary in root’s path all let a limited user influence what root does.
find / -writable -type f 2>/dev/null | grep -vE '^/(proc|sys|tmp|dev)' ls -la /etc/init.d/ /etc/cron* 2>/dev/null
/etc/init.d/custom_start # world-writable, runs as root at boot /www/cgi-bin/ # writable web root, served by root httpd
A world-writable init script that root runs at boot is a clean escalation: write a command into it and it executes as root on the next restart. The writable web root served by a root web server is another path, since dropping a script there may let me execute as root through the web interface.
Cron and Scheduled Tasks
Scheduled jobs running as root are a reliable escalation if I can influence what they run. A cron job that executes a script I can write, or that processes files in a directory I control, runs my code with root privileges on its schedule.
cat /etc/crontabs/root 2>/dev/null; ls -la /etc/cron.d 2>/dev/null
*/5 * * * * /usr/bin/backup.sh # backup.sh is writable by group 'app' -> we are in group app
A backup script that runs every five minutes as root and is writable by my group is an escalation on a timer. Appending a command that copies a shell to a SUID-root location, or adds my key, gives root within five minutes. Scheduled jobs are easy to overlook and easy to abuse when their scripts are not locked down.
Sudo and Capabilities
If sudo is present, its configuration may allow my user to run specific commands as root, and a command that can spawn a shell or write a file is enough. Linux capabilities on binaries are the modern equivalent, granting slices of root power that can sometimes be escalated.
sudo -l 2>/dev/null getcap -r / 2>/dev/null
User app may run: /usr/bin/tcpdump /usr/bin/python3 = cap_setuid+ep # python with setuid capability
Python carrying the setuid capability is an immediate win: a one-line script that sets the UID to zero and execs a shell gives root directly. A sudo entry for a command with a known shell escape works the same way. Both are convenience choices that hand a limited user the keys.
Vulnerable Services and Old Kernels
When configuration is tight, the software version becomes the path. Embedded devices run old kernels and old userland for years, so a privilege-escalation vulnerability that was patched upstream long ago may still be live here. The kernel version from enumeration is the lead.
Local kernel exploits are a fallback when the easier paths are closed, and on a device running a years-old kernel they are often available. The same goes for SUID userland with known flaws. This route is less clean than a misconfiguration and risks crashing the device, so I reach for it after the configuration checks, but on embedded targets it frequently works.
Exploiting a Root Process
The web server running as root, noted during enumeration, is worth attacking directly. A command-injection or file-write vulnerability in a process already running as root escalates without any of the file or scheduling tricks, because the privileged process does the work for me.
Embedded web interfaces are notorious for shelling out to system commands with user input, so a parameter that reaches a system call gives command execution as the web server’s user, which here is root. When a root process has an injectable input, that is often the shortest path, and it ties the network attack surface directly to full device control.
Chaining and Persistence
Often no single misconfiguration gives root, but a chain does: a writable config influences a service, which exposes a path to a SUID binary, which yields root. Enumeration gathers the pieces, and escalation is assembling them. Once root is achieved, the next concern is keeping it, which is its own topic, but the foothold is what makes persistence possible.
For the assessment, reaching root is the proof of impact, and the chain that got there is the finding. Each link, the world-writable script, the over-privileged service, the SUID helper, is a separate fix, and documenting the whole chain shows the team both how deep the problem goes and how breaking any link would have stopped it.
What It Says About the Device
Easy privilege escalation is a symptom of a userland built without hardening, and the fixes are well understood: run services as the least privilege they need rather than root, remove unnecessary SUID binaries, tighten file and directory permissions, lock down scheduled jobs, and keep the kernel and userland patched.
For a product team, the value of an escalation finding is that it reveals the systemic habit, convenience over least privilege, behind many individual issues. Addressing that habit, with a hardened build and a least-privilege default, closes not just the paths found but the ones the next assessment would find. Escalation difficulty is a good proxy for how seriously a device was hardened.
A Worked Escalation Chain
A real escalation often chains several small issues, and a worked example shows how. Starting as the limited app user, enumeration finds a world-writable script run by a root cron job every five minutes. Appending a single line that copies a shell and sets it SUID-root, then waiting one cron cycle, yields a root shell. No exploit, just one misconfiguration leveraged.
# app user appends to a root-run, world-writable cron script echo 'cp /bin/sh /tmp/rootsh; chmod 4755 /tmp/rootsh' >> /etc/cron.d/backup.sh # wait one cron cycle, then: /tmp/rootsh -p id
uid=1000(app) euid=0(root) # root shell obtained via a writable cron script
Each link in that chain is an ordinary embedded oversight, a world-writable file, a root cron job, a permissive umask, and individually none looks alarming. Combined, they are a clean path from a limited foothold to root. This is why escalation findings are reported as chains: fixing any single link, locking the script’s permissions, breaks the path, and showing the whole chain makes both the risk and the cheapest fix obvious.
Hardening Against Escalation
The defenses against embedded privilege escalation are well understood and mostly about discipline rather than new technology. Run each service as a dedicated unprivileged user instead of root, remove every SUID bit that is not strictly required, tighten file and directory permissions so nothing root relies on is writable by others, lock down scheduled jobs, and keep the kernel and userland patched.
The deeper fix is cultural: build the image with least privilege as the default rather than retrofitting it after an assessment finds the gaps. A hardened build that drops privileges, prunes SUID binaries, and sets restrictive permissions automatically closes not just the paths a test found but the ones the next test would find. Escalation difficulty is a reliable proxy for how seriously a device was hardened, and an easy escalation almost always signals a systemic convenience-over-security habit worth addressing at the build level.
Where This Fits
Testing how far an initial foothold can be escalated, and mapping the paths to root, is a core part of an embedded penetration test. If you want to know how easily a foothold on your device becomes full control, that is the kind of work we do at Berkner Tech.