Introducing the RII pwn.college Dojo
- 1 day ago
- 7 min read
In collaboration with the excellent pwn.college team at Arizona State University (particular shout-outs to Yan, Connor, and Adam), we are excited to release the RII Dojo. For those unfamiliar with pwn.college, their cybersecurity education program is modeled after the martial arts progression, allowing learners to progress from a “‘white belt’ in cybersecurity through the journey to becoming a ‘blue belt’, able to approach (simple) cybersecurity competitions (CTFs) and wargames.” This is one of the best educational resources for the vulnerability research and reverse engineering (VR/RE) domain, and I personally recommend it when interviewing candidates for our VR/RE roles.
The RII Dojo complements the core educational material covered by other Dojos and adds a layer of complexity. It covers emulation, exploitation, and mock command and control (C2) of an EOL router via a publicized N-day vulnerability. This blog post is intended as the primary technical resource providing the background, requirements, and criteria necessary to complete the challenges.
As an educational resource that will be used in the future by other learners, pwn.college asks that you “do not post write-ups, walkthrough videos, and livestreams of challenge solutions to the internet.” We appreciate the same consideration for our Dojo.
The CVE and Firmware
CVE: CVE-2017-14948
Hardware/Firmware: DIR-868L Rev A, v1.12b04
Download: Vendor archived zip
The D-Link DIR-868L was end-of-life as of August 8, 2020 and is a responsible target with which to practice VR/RE skills. In order to set up a runnable, debuggable, interactive environment to develop an exploit, you must first emulate the firmware (challenge 1). After emulating the firmware, you will then develop an exploit specifically for CVE-2017-14948 and a C2 payload that conforms to the provided specifications (challenge 2).
You will provide an emulated target in challenge 1, against which our service level agreement (SLA) checker will test various functionality to validate emulation fidelity. The exact implementation of the SLA check is intentionally hidden from the learner, to discourage attempts to game the check. However, once your emulation solution is checked (and you’ve submitted the flag for challenge 1), you do not have to use it for challenge 2. In order to avoid environment (aka, “works on my box”) issues, we provide the emulated target that you will exploit and C2. To avoid the temptation to copy our provided emulator and submitting it as your solution, you must complete challenge 1 in order to unlock challenge 2.
Challenge 1: Emulation
This section provides you tips to emulate this particular firmware, a description of what types of things the SLA checker will test for, and a description of how to use the SLA checker. For this challenge your solution is expected at /home/hacker/start_emulation. The SLA check will not run until /home/hacker/start_emulation exits.
Tips for getting emulation going
When logging in to the vulnerable CGI process and attempting to use the intended functionality, you may get a message saying "no hard disk" when trying to access removable storage. This is expected behavior and does not require a workaround. We found a solution in our emulation to resolve that issue, but it was not relevant to the ability to exploit the CVE
The easiest QEMU network device to get the firmware working is the tap. As you do not have permission to set up a tap we provide the `run network` command that will stand one up for you. The “run” command operates with elevated privileges and has several options including setting up the network/firmware emulation and checking the solution.
Since we expect to run your solution as a script, the linux command `nohup` may be helpful. `nohup` allows a command to continue past the expiration of its terminal or shell. In `run check` we use the termination of your script to signal that it is time to start the SLA_checker.py. What may you want to exist for the checks?
With newer versions of `tar` and `binwalk`, they have implemented path traversal attack mitigations. This may impact the creation of your disk image. Double check symlinks if you are having issues.
SLA checker areas
Checking that it is full-system emulation (e.g., that multiple ports/processes are behaving as expected)
That authentication/login to the web page works as expected for both correct and incorrect credentials
That the webpage content of various pages is as expected
We assume the device is located on 192.168.0.1
Using the SLA checker
The SLA checker is initiated through the `run` command. The `run` command is very similar to the `vm` command used in several other dojos as well as this dojo. You use the command by typing `run <verb>`.
`run check` – Stops current emulation, restarts the network, then runs `/home/hacker/start_emulation` before running the SLA checker on your emulator
`run network` – Start the network VM and stand up a TAP you can attach to your QEMU instance
`run help` – Print a help message for the commands that are available
`run vm <verb>` – A wrapper around `vm` that enables a subset of the commands. Namely `start`, `restart`, and `connect`. The `vm` allows us to create taps to set up the network. Without it, not even root can create taps.
Challenge 2: Exploitation and C2
This section provides you tips about exploitation of the CVE, the specifications with which your C2 payload must conform, a description of what types of things the SLA checker will test for, and a description of how to use the SLA checker. For this challenge your solution is expected at `/home/hacker/run_attack`. The SLA Checker will not run until `/home/hacker/run_attack` exits. It is strongly recommended to run `run qemu` before running `run check` as issues have occurred in testing with just `run check`. You may see a `/challenge/bImage` file. This has the kernel modules that allow taps to be stood up and used. It is used for the `vm` commands.
Exploiting CVE-2017-14948
The CVE description and other public resources should make the attack vector for exploitation fairly clear. Although there are other CVEs on this device that could be exploited, we are specifically checking that you exploit this CVE.
Because the public description of the CVE makes the vulnerability clear, you might find reaching and triggering the vulnerable code to be more challenging than the exploit itself.
The exploit will deliver and trigger a C2 payload. How the C2 payload is delivered and triggered is up to you (e.g., hardcoded in the exploit code, delivered as a second stage payload to your stage 1 shellcode, dropped to disk and executed, executed in-memory as a shellcode blob).
The emulation must remain stable post-exploitation (this is basically a gimme because the CGI process handles each request in a separate, forked process).
Your exploit will be triggered by executing the file /home/hacker/run_attack. This file will be executed as part of the `run check` command.
C2 Specifications
Must bind on TCP port 1899 (can you find the easter egg in that port number?)
Must continue to accept connections until the “kill” command is issued
After accepting a connection, it reads input, expecting an authentication string
The expected authentication string (without double quotes) is “https://researchinnovations.com/careers”
If the input does not match the authentication string, the connection is closed
If the input matches the authentication string, enter a command loop
The command loop must support 3 commands. Each command received via input must be processed as a case-insensitive string
“Heartbeat”
C2 must respond with the string (without double quotes) “https://researchinnovations.com/blog”
“Exit”:
C2 will close and no longer respond on that socket
“Kill”:
C2 will close the socket, stop listening on port 1899, and no longer accept any new incoming connections. It will not kill other active connections
Other commands
C2 will do nothing. It will not respond and it will not close/kill the current connection(s).
Must be able to support multiple simultaneous connections
SLA Checker Areas
The SLA checker has three stages of checks: pre-exploitation, exploitation, and post-exploitation. The pre- and post-exploitation checks are identical
Pre- and Post-Exploitation
These checks are the same checks performed in the first emulation challenge. The purpose of these checks are to ensure the emulation environment is functioning prior to attempting exploitation, and to ensure there are no stability issues introduced by your exploitation or C2 payload. If pre-exploitation checks fail, try restarting the emulation. If pre-exploitations checks do not work after that, then let us know–an issue with these checks indicates an issue with the challenge environment and should not be the fault of any participant. If post exploitation fails, make sure your script does not cause a fatal crash or shutdown the firmware
Exploitation
The exploitation checks verify that the delivered C2 supports the expected functionality
Attempts to sign in with correct and incorrect passwords
Attempts to open multiple connections sequentially
Attempts to open multiple connections simultaneously
Attempts to send commands to different connections (including exit and kill)
Attempts to open new connections now that kill has been has been sent
Closes all remaining connection
Verifies exploit looks “correct”
Uses heuristics to check it is actually CVE-2017-14948 being exploited
This one is a little finicky. If it is the only one that fails, feel free to run check again
Using the SLA checker
Like the last challenge, the SLA checker is initiated through the `run` command. The `run` command is very similar to the `vm` command used in several other dojos as well as this dojo. You use the command by typing `run <verb>`.
`run check` – Runs SLA checker
`run qemu` – Runs the RII-provided firmware emulation in a QEMU vm. Will print “Emulation started” once it is finished booting
`run help` – Print a help message for the commands that are available
`run vm <verb>` – A wrapper around `vm` that enables a subset of the commands. Namely `start`, `restart`, and `connect`. The `vm` allows us to create taps to set up the network. Without it even root can not create taps.
You must start the emulated target with `run qemu` prior to checking your solution with `run check`.
Contacting Us
If you have any issues or questions about this Dojo, email dojo@researchinnovations.com and we will get back to you as soon as feasible. We will prioritize responding to bug reports and technical issues over requests for solution tips.
Contributors
A huge thank you to the following contributors who made this happen:
James Hutchins (RII): Emulation, C2, Exploit Development, Dojo Development, Infrastructure
Pwn.college team (Yan, Connor, Adam): Infrastructure Support
RJ Crandall: Concept, CVE Selection, Exploit Development, Blog Author
Daniel Gordon (RII): Blog Co-author, Testing and Validation
Jude O’Cain and Ben De’Pater (RII): Testing and Validation
