Neighborhood Watch Bypass

This objective is located on the outside door of the data center. The data center has a perimeter fence that has a hole in the east side. Come in through the hole and head around to the door to find Kyle Parrish and the Neighborhood Fire Alarm System terminal. Kyle lets us know that the fire alarm keeps going off for no reason and we are locked out of the system. We need to regain access so the fire alarm will function normally again.

The terminal prompt lays out the objective: Find a way to bypass current restrictions and elevate to fire saftey admin privileges. Then run the specified command "/etc/firealarm/restore_fire_alarm" to restore the system to normal operation.

At its core, this is a privilege escalation challenge. So the first thing we need to do is get a lay of the land and inspect common vectors for privilege escalation:

• SUID/GUID binaries
• SUDO misconfigurations
• Weak file permissions
• Misconfigured Cron jobs
• Etc...

Sometimes users have special sudo permissions specified in a sudoers file. This could grant us permission to run specific commands with SUDO. Looking at the sudoers files in /etc/ shows that our user "chiuser" has an entry, however we don't have permission to see what the entry is...

Moving on to another common vector: Weak File Permissions. For this priv esc vector I want to find files that "chiuser" can execute or write. To do this you can use the find command:

find / -writable
find / -executable

Now as expected there are MANY files that our "chiuser" can execute or write, but I'm looking for files that are not ordinary files you expect to see on any Linux system. I'm looking for files specific to this machine. Scanning over this I noticed a shell script that looked interesting: /usr/local/bin/system_status.sh

This file is interesting because it looks like someone created it specifically for this Fire Alarm system. Running it looks like it checks the status of the system and prints out some diagnostic data:

Even more important is that it looks like chiuser has permission to run this with SUDO!

Now that we have a lead, lets look at the source code of the system_status.sh script.

#!/bin/bash
echo "=== Dosis Neighborhood Fire Alarm System Status ==="
echo "Fire alarm system monitoring active..."
echo ""
echo "System resources (for alarm monitoring):" 
free -h
echo -e "\nDisk usage (alarm logs and recordings):"
df -h
echo -e "\nActive fire department connections:"
w
echo -e "\nFire alarm monitoring processes:"
ps aux | grep -E "(alarm|fire|monitor|safety)" | head -5 || echo "No active fire monitoring processes detected"
echo ""
echo "🔥 Fire Safety Status: All systems operational"
echo "🚨 Emergency Response: Ready"
echo "📍 Coverage Area: Dosis Neighborhood (all sectors)"

The code, as expected, calls some commands to get status and diagnostic information about the system, but it does so with relative paths... For example it gets the free disk space and usage information using the "df -h" command. Since there is no absolute path for "df", the system must use the PATH environment variable to lookup which executable to run. If this PATH is misconfigured, we can possibly create our own executable to run instead of the one in the script.

🏠 chiuser @ Dosis Neighborhood ~ 🔍 $ env | grep PATH
PATH=/home/chiuser/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

There is a glaring vulnerability here! Notice how the first entry in the PATH is the chiuser home directory? The system must look in our own home directory (/home/chiuser/bin) for executables when they are run without an absolute path! If we create an executable here with the same name as one in the system_status.sh script, we can trick it into running our command instead of intended one.

The first step to exploiting this misconfiguration is to pick an executable in system_status.sh. I will use "w" for my exploit. I created a file named "w" in /home/chiuser/bin and set the permissions to be world-executable.

touch /home/chiuser/bin/w && chmod +x /home/chiuser/bin/w

Now as a proof of concept I used nano to edit the "w" executable to be a bash script that just prints out "INJECTED" followed by the user that executed the script (whoami).

#!/bin/bash
echo "INJECTED!"
whoami

Now run the system_status.sh script and check the output for the INJECTED text... We proved our technique worked and the injected commands run as root! Now to convert the PoC script into a full blown privilege escalation exploit, edit the "w" script to simply call /bin/bash. This will spawn a shell running as root!

#!/bin/bash
/bin/bash

Just run the system_status.sh as sudo to gain a root shell.

Before running the script to complete the challenge, I wanted to look at what made this exploit possible. First there was the sudoers entry that allowed chiuser to run the system_status.sh script as root with no password. With root access we can now read the /etc/sudoers.d/chiuser file.

root@f1b50d7e9185:/home/chiuser# cat /etc/sudoers.d/chiuser
chiuser ALL=(root) NOPASSWD: /usr/local/bin/system_status.sh

Second, the status script uses relative paths for the commands, meaning the system uses PATH to find the executable to run. Lastly, the PATH variable is configured to search a path our user has write access to (/home/chiuser/bin) before any other path. This is a good example of chaining a few misconfigurations together for an exploit.

Now just run the script "/etc/firealarm/restore_fire_alarm" to complete the objective.