Event RPE: The Broken Gear in the Watch

Events

RPE: The Broken Gear in the Watch

Date: January 14-16, 2020 | Location: DreamPort Facility in Columbia MD
Note: due to the explicit scope of this event, this is only scheduled to take place over one and a half days, but participants are welcome to plan for two full days.

Overview

Depending on the brand, there can be 17 or more parts in an automatic wristwatch (not digital naturally). Some websites claim that a typical Rolex contains "around two hundred and twenty parts". What happens when the smallest gear breaks? The watch might still work but how well? While we may sometimes prefer a tablet or laptop here at DreamPort, these watches can catch the eye, to raise the eyebrow sometimes all it takes is for you see the sticker price.

At DreamPort, firewalls, routers and switches are more our 'speed'. While they also seem to be slowing climbing in price, they are powered by firmware that can consist of hundreds of files and executables. But wait, think for a second, firmware powers so much more then you might think. At home it can power cameras, baby monitors, home automation and even appliances (Connected Refrigerator anyone?). At the office it can power the SCADA system, aspects of the power grid and even the elevator or security camera. When you choose a device to run on your network or in your building is price your primary driver? Do you consider the firmware of the device you are about to run? When you plug in for the first time and connect to the network do you check the version of the firmware image? Many will answer no because the process to update some type of firmware is convoluted.

When a gear malfunctions in a wristwatch it can be replaced. The process to find and repair the broken gear is not simple sometimes requiring tremendous skill, tools and techniques. Wikipedia claims that historically in England a watchmaker must undergo a 7 year apprenticeship and then join a guild before selling their first watch.

What about a vulnerable file in a firmware image? A firmware image can be upgraded, but it requires authors to cross-compile executables and build and compress (and maybe encrypt) the new image. Sometimes the original author may choose not to address vulnerabilities that have been discovered. What are we the user left to do? What if our mission(s) or business depend on that device? What's even worse is that as more and more products are available for same-day delivery, who tests these devices for vulnerabilities during the rush to market?

In this RPE, we want to test participant's abilities to find and mitigate vulnerabilities in open source embedded device firmware such as switches, routers and firewalls and other devices. During the actual event, participants should be prepared to analyze firmware images. These images will either contain known vulnerabilities or will have been modified by DreamPort personnel to include vulnerabilities. Participants must understand how to identify a file type and unpack a firmware image, sort through the files contained in the image (or live copy of the firmware) and identify candidate executables, scripts and configuration files for analysis both automated and manual.

Participants will be given a selection of firmware images to analyze at least 3 separate times. You should utilize your tool or approach to analyze as many images as you can and provide:

Description of the firmware type
Description of any required steps to unpack or mount
Listing or tree of all of the files found on the image
File names and description of any files deemed vulnerable (including descriptions of the vulnerability)
If possible, mitigation(s) you can develop

We will not provide any tools or software during this event. Participants must bring their own tools and computers. Teams should not bring any more than 5 personnel to DreamPort during this event but are free to coordinate with team members offsite.

Before you ask, this is not an exercise in how to use binwalk (or similar tools). We at DreamPort are huge fans of binwalk but the ultimate solution includes substantially more than what binwalk can do out of the box.

If vulnerabilities are identified, extra consideration will be given to any participants who can develop a mitigation technique for the discovered vulnerability. We are not looking for patches, but can you lessen the effect? Prevent follow-on exploitation? Participants may deploy firewall rules, alter configuration files, settings or even (if you come with the right tools) deploy new executables into the image to prevent successful exploitation of the vulnerabilities.

Participants will not be asked to analyze copyright protected firmware images. This type of analysis is typically restricted by end user license agreements (EULA).

Evaluation

Participants will be evaluated on their ability to:

Unpack firmware images for analysis
Identify vulnerabilities in files found in the firmware images
Develop mitigations for the vulnerabilities
Deploy mitigations to withstand exploitation by DreamPort personnel.

Candidate solutions must at a minimum support analysis of the following firmware image types:

TRX
GZip

Suggested Skills

Firmware Analysis
Linux live analysis
Vulnerability Scanning
Reverse Engineering (ELF, ARM, MIPS)
Virtualization (KVM)
Python/C/C++

Expected Solution

DreamPort is searching for not only a team who can perform this type of analysis but ultimately a tool that will automate the process. For participants who bring a tool to this RPE or are up to the challenge of development, there are no restrictions at this time on the environment for the tool development only that you must also provide detailed instructions on how to run your solution. We do not require sandbox execution of the firmware images we will provide but any team that can bring this capability will deserve extra consideration.