DEF CON 22 was my third DEF CON and the first time ever for the IoT Village and related "SOHOpelessly Broken" contests.
That year, I easily won both tracks of the competition with only a handful of hours spent analyzing and hacking routers. As anyone who’s ever attended DEF CON can tell you, there are roughly one billion options for how to spend the conference between talks, villages, workshops, and friends both old and new.
At DEF CON 23,
my participation at the IoT Village was as a speaker, and by DEF CON 24, I was busy running a
workshop on IoT hacking but was excited to hear that the SOHOpelessly Broken CTF had been made a black badge event for DC24. (The coveted black badge is awarded to a select few DEF CON contest winners each year, giving them lifetime free admission to DEF CON.)
When DEF CON 25 rolled around this year, I was on the fence about whether to spend my time competing in the SOHOpelessly Broken CTF, attending talks, or expanding my RF ninja skills at the wireless village.
By Friday afternoon, I decided to rally up some colleagues for IoT hacking fun in the CTF. To my surprise, the scoreboard was already full of high scores, including a team having all the flags very early on. The competition itself was a bit different this year than how it was set up back in 2014. It had grown drastically in size and organization; it now included a fancy CTF web application for contests to track their progress. This year, there were over 90 teams, more than half of which made it on the scoreboard.
From my perspective, there was also a big shift in the focus of the contest at DEF CON 22 versus DEF CON 25.
Back in 2014, the contest was focused on demonstrating an ability to exploit vulnerabilities in common embedded devices. This year, by contrast, a big portion of the contest revolved around just finding the target devices. Contestants this year were given a list of devices/flags and some vague instructions that you should not probe contest infrastructure or anything with an IP address where the last octet is greater than 10.
In 2014, there was also a CSRF bot that could click on any link from an authenticated context with all hack targets. While the CSRF bot was available again this year, it didn’t actually work for me in practice. In my testing, the system was often not requesting supplied URLs and didn’t seem to have an authenticated session with any devices. I asked several times about this since most systems could be trivially exploited via authenticated CSRF, and I was later told it was being looked at and that I didn’t need CSRF for the particular hack I was working on.
As it turns out, network discovery was considerably more difficult than it probably should have been.
One aspect of the difficulty was intended by the contest runners at ISE. (I will not discuss that here to avoid spoiling it for others.) The other source of difficulty, however, was that the consumer-grade hack targets could not take the stress of 90+ teams running nmap scans and sending random command injection and memory corruption exploit payloads. Devices were frequently offline, and as a contestant, there was no way to know if you couldn’t find a device because it was broken as opposed to if you were looking in the wrong place.
After mapping out the entire network of hack targets, we frequently had to ask for resets on various devices that would drop offline for whatever reason.
Yet another challenge we faced was that some devices had been modified by others. In one case, we achieved code execution on the target but could not access the flag. Upon conclusion of the contest, we asked the organizers what we had missed and were told that what we did should have worked.
In another case, after getting a shell, we found that the device had been modified such that the flag value no longer matched. In the first case (where the flag was inaccessible), we wasted several hours of work trying to figure out what we were missing when in fact we had apparently missed nothing.
For the second flag, I was able to show that the device had been modified and the points were awarded. The only other flag we didn’t submit was because the device was inaccessible the entire last day of the contest.
It is really great to see that there is so much more interest and expertise in the IoT security field now compared to 2014. This is a great trend, and I really hope to see even more teams competing in SOHOpelessly Broken next year at DEF CON, as well as at other events in between. The folks at ISE have really put in a lot of effort to make this a really great and educational event.
Throughout my time in the IoT Village, I lost track of how many times I heard someone exclaim “I got it!” or “That is so [expletive] cool!” I hope that many of these hackers will continue on their efforts by auditing their own home devices and advocating patching and password security best practices.
In the interest of giving back to SOHOpelessly Broken or anyone else looking to host a similar contest, I would like to make a few suggestions to improve the overall contest experience:
1. Virtualize the hack targets
SOHO devices are great for hacking, but they don’t handle load very well. This is a lesson I learned after my first Brainwashing Embedded Systems workshop in Australia. I have even already virtualized some of the equipment used in the CTF and would be more than happy to lend advice on how to make virtual hack targets. This gives the ability to easily reload the devices or even give contestants sandboxed hack targets.
2. Employ network monitoring
It was really frustrating when we couldn’t find hack targets only to learn that it was because they had failed. Using something like Nagios can notify the organizers when systems became unavailable and automatically perform resets.
3. Provide a network map
Rather than relying on contestants to enumerate the network and determine how to connect to various hack targets, I think it would be better to simply provide a network diagram. This allows contestants to spend less time wondering where devices are (and if they have crashed) and more time exploring exploits.
4. Add tiered flags
Currently, each device has a single flag which in most cases demonstrates complete control of the target. I have also noticed that many of the devices have multiple exploit chains that could lead to the flag but reveal different bits of information along the way.
For example, on one target it is possible to run canned exploit code for an unauthenticated memory corruption bug and directly get a shell, but it is also possible to leak the password from the device, login, and simply turn on telnet. Flags showing different levels of control or understanding of the devices can make things more interesting and allow more teams to get flags. I would suggest considering new flags like admin password, SSH credentials, WPA2 key, etc.
The contest was a lot of fun, and in the end, team VERT won third place with just 2 flags out of 18 left on the board due to technical problems as described above. Congratulations are in order for team Wolf emoji (
) for taking 1st place! I’m looking forward to the opportunity to compete again at DEF CON 26 and, hopefully, to leave with the top score this time!
