# TubeWarriors DEFCON 18 oCTF "2speed" Local Root Exploit ## Challenge description and overview of solution A complete write-up on the 2speed challenge (as intended, without local root exploitation) is documented in [DC18-oCTF-2speed](/DC18-oCTF-2speed). The 2speed (setuid root) binary generates a random value seeded by the current time and then compares that value (hex-encoded) to the first command line argument provided upon running the binary. If they match, it copies the first 33 bytes of a file called flag.txt in the current directory into a file in /tmp constructed with this time-seeded rand() output. By exploiting a race condition present in 2speed, we were able to symlink this filename to any location on disk and force the 2speed binary to write the first 33 bytes of the file "flag.txt" in the current directory to that path, as root. ## Local root vulnerability There are four components to this local-root vulnerability: 1. 2speed reads the file "flag.txt" from the current directory, rather than the specific directory where the flag orignially resided (/home/2speed/flag.txt) 1. 2speed is susceptable to a race condition in how it handles it's output file in /tmp/ - it should verify that the file does not exist prior to acting upon it. 1. 2speed follows symlinks when writing to it's temporary file in /tmp/ 1. 2speed is setuid root, allowing the previous two vulnerabilities to be used to write to any file root has access to. ### Exploiting these vulnerabilities for our fun and profit Using the above vulnerability, we automated the process of writing any content to any file remotely with a simple script. #### Initial payload We started by overwriting /etc/rc.d/rc.local to contain the line: ``` "chmod +s /usr/bin/vim" ``` The file **/etc/rc.d/rc.local** was selected because it will be executed upon system start-up (it was already marked as executable). The payload we chose would set the vim editor to be setuid root. As we were the only ones that knew this would happen, we could quickly take action and then remove the setuid bit from it. It was far in to everyone having a shell on the server, and most people had long-since abandoned any form of interactive shells due every team automating the killing of login sessions. Vim was unlikley to be used by other teams at this point. #### Executing our setuid vim payload As we could write 33 bytes to any location on disk, but not execute commands directly - we had limited avenues for code execution. When we decided that "tripping" over the server's power cable wasn't very neighborly, we opted to exploit CentOS's bloated kernel configuration and visit sysrq - that handy tool in your back pocket for when X and your framebuffer freezes up and you can reboot. * We enabled sysrq by writing **"1"** to **/proc/sys/kernel/sysrq** * We then sent the reboot command by writing **"b"** to **/proc/sysrq-trigger** * *We could have been a bit nicer and written "REISUB" to sysrq-trigger, to sync the disks and be a bit more graceful - but time was of the essense and we missed that step.* *Note:* Whenever our source file (flag.txt) contained less than 33 bytes, the output file would be padded with nulls at the end. In all cases, to avoid this from causing any trouble we padded the source file with newlines (0x0a) which cause no side-effects for shell scripts or writing to items in /proc/. * When the system rebooted, we then quickly used vim to add a SSH public-key to **/root/.ssh/authorized_keys**, and we also had to enable root login via ssh (**RootLogin yes** and **AllowUsers root** in **/etc/ssh/sshd_config**), and finally restart sshd via it's init script. * At this point, we removed the setuid bit from vim (**!chmod 0755 /usr/bin/vim** from vim's command line) and logged in as root via ssh. * We then changed the "mario" user's password, as we belived this to be tubewarriors management account. * For good measure, we wrote a loving message "Neg9 Loves You!" to **/etc/issue** and enabled sshd's pre-login banner via "**banner /etc/issue**" in **/etc/ssh/sshd_config** ---- CategoryWhitepapers