Penguin In the Wild

Can you figure out how to connect to this service?

Sometimes you'll want to modify the filesystem, add files, replace files, etc... The static_files section of the config allows you to do that without having to deal with disk images or tarballs.

This firmware requires you to make two static_files changes to get it working happily

Notes:

• We've removed the source for this one. Feel free to apply previous knowledge to understand what the system is trying to do!
• The pwn.college has plenty of RE tools if you prefer looking at the binaries themselves

The OpenIPC firmware we looked earlier almost runs in penguin out of the box, however, there is a slight problem. It turns out that this version of penguin's auto-device modeling gets a bit greedy and breaks a well-known device file.

For this challenge, you need to identify the broken model and disable it. You can comment out the entire feature (which is in static_patches/) from the patches part of config.yaml

To get the key for /challenge/solve, you'll need to pull up the web interface, set a password, and then get to the main status page.

The key for /challenge/solve is the Firmware Version string from the status.cgi page.

Note: We are always working to make penguin robust, but it is important for you to understand that this can happen! The goal of this exercise is to get you used to looking at log files!

Now that you've got the OpenIPC firmware rehosted, it's time to go on a (simulated) bug hunt! IoT devices can be vulnerable to command injection bugs, where a user can trick the system into executing commands. Your goal in this challenge is to find one of those endpoints in this system and figure how to use it to run commands (though this one is present by design, not as a bug).

OpenIPC presents an endpoint (Tools->Console) to run commands, but that appears to not work very well. There is, however, a different interface for running commands from the webserver. Can you find it?

The key for /challenge/solve is the endpoint of the URL you can use to execute uname and see its output (no arguments, just uname by itself).

Notes:

• The endpoint will be everything after http://localhost:PORT. E.g., /foo.php?bar=baz if the full URL was http://localhost:1080/foo.php?bar=baz
  • Your command should end with a newline (the meaning of this comment will be clear when you find the "vulnerable" endpoint)
  • The endpoint will start with a leading /
• You might want to run your project out of /tmp to avoid filing your homedir with analysis artifacts
• You can hit this endpoint with curl or wget if you want to avoid using the browser
• Maybe you'll find a real bug that differs from our solution. If so, disclose it responsibly to the development team!