Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The previous article walks through how they got access to the binaries for reverse engineering. This article goes into the actual reverse engineering, vulnerability discovery and exploitation of a printer.

The Printer Job Language (PJL) is used for switching printer information at the job level and sharing information about a job to the host machine. PRET is an open source tool for interacting with PJL but excludes many of the vendor specific options. Since this tends to be an externally facing protocol, attackers love to hit this.

While reversing, they wanted to find a list of PJL functions; they found these in the hydra binary. When auditing the different functions (no symbols but lots of useful strings and error messages), they found an undocumented function called LDLWELCOMESCREEN.

This command allowed for an arbitrary file to be written with arbitrary content, since it suffers from a directory traversal vulnerability. From an exploitability perspective, they had a few problems though. First, the file is only a tmp file, meaning that it gets deleted after its purpose has been served. Secondly, the file cannot already exist.

To get around the first issue, we can write more than 0x400 to the PJL. At 0x400 bytes, the buffer is flushed by writing it to the file. If we keep this stream open after the flush, then the file will not be deleted until after the stream has closed.

The second issue is pretty stumping though: how do we overwrite something for code execution if it cannot already exist? While auditing the file system they noticed a set of crash handlers called ABRT. According to the documentation, ABRT can have custom hooks that are executed in a directory when some event occurs. This happens for ALL files in a directory; this is perfect since we can add a file to get executed!

To add insult to injury, the post-event handler runs with root permissions. At this point, there is a way to get code execution (via the crash handler) but how do we trigger a crash? Since the device has several really old binaries, they found they could trigger a remote crash in Apache via a bug in awk. However, there are likely many other ways to trigger a crash.

For the final payload, they had to use bash commands to disable the firewall, configure SSH to work without authentication and a few other things. After writing the file and triggering the crash, SSH was started, allowing the researchers to authenticate!

During Pwn2Own, the exploit failed due to an SSH error they had not seen during testing. As a result, they used a backup script that used netcat to connect instead. Having a backup plan was a wonderful idea to make this work! Overall, amazing research to turn small bugs into game over!