Raspberry Pi WiFi CTF Lab Experiment Results

This past Saturday, I hosted a Wifi CTF at Big Block Brewery in Carnation WA. This was my first experiment where I could gather information about how other folks perceive my CTF. A big challenge for me is discovering what’s discoverable to participants. Running this lab would help me learn if this project is viable. The big questions are:

  1. Will the lab work- are the vulnerabilities & scoring system reliable?
  2. Will participants be able to figure out the IP network of the wifi network and discover targets for exploitation?
  3. What kind of after-action reporting can I generate?

Did the lab work?

Yes! I arrived at about 12:20pm and had the lab up and running by about 12:55. I had a small bobble- when I arrived, it looked like I may have brought the wrong pi for the CTF: the hostname on the access point reverted back to “ansibledest.local” and only had 8 commands in it’s history. But it turned out that there was just a hostname bug in the latest build. LED animations fired up when I powered on which meant it had to have my Vulnerable AP code on there.

6 people signed up for the lab in advance of the event. 5 showed up and we ended up having 2 additional pub patrons join. I left the lab up till roughly 5pm. Here are some basic statistics from the ctf admin’s ui:

Were participants able to figure out the IP addressing?

This was a little unclear to me.

The group was able to score- so they obviously found and exploited things, but I did talk folks through the idea of a “Default Gateway” and how to look on their devices to figure out their own system’s IP and the target system. Did I taint the data? I’m not sure. I suspect a couple folks port scanned & targeted their own laptops during a network scan. I’m concerned that my presence may have been a necessary to give folks a pointer on what to explore.

What kind of after-action reporting can I generate?

I pulled logs off the vulnerable access point and did some rough analysis. Logs included the raw webserver logs as well as the database I use to track scoring & exploit attempts.

Over the course of the event, there were 7 participants with 466 exploit attempts and 28 solves. 10 out of the 23 challenges were solved by the participants. One participant- Sl0hth2 successfully achieved remote root on the access point. Sl0hth2 also was the first to successfully score in several CTF challenges, which gave him scoring bonuses. A general question would be- how many clients did we see attach/reattach? Here are some DHCP metrics:

DHCP Lease attempts

204 of 280 DHCP entries (73%) are from a test device that periodically attached and detached from the network, which gave participants an opportunity to sniff & crack a 4 way handshake. The participant per-registration dhcp traffic was only ~76 events.

Scoring Milestones

I ran a report of the First-blood modifier bonuses- which helps you get a feel for who got most “first strike” points as well as an intuition into what classes of challenges people scored on.

First Blood Scoring Modifications

Now we’re ready to look into what the attack traffic was during the event. The largest volume of attack traffic was SQL injection. There is a login page and a user database query page that can be targeted for exploitation. I’ve put some effort into designing the database to be resilient to data destruction attacks- so it’s utility for “gaining root” on the device is limited. For many people, SQL injection is the ‘hello world’ of security exploitation- so I have some challenges that can be used for scoring.

SQL Injection Attacks

Next was command injection. The solution has a web page that vends access to the ping utility. Command injection can be used to run arbitrary commands on the device- and it presents an entrypoint for doing some enumeration of the host system’s configuration and getting some remote command access.

The next most popular attack was XSS. Again- low utility for remote compromise, but a good way to grab some points.

XSS Attacks

Next we have some file-based attacks. Here we’re starting to see evidence that participants were able to modify the file system and get it to execute attacker-controlled/created code:

File-based attacks

Finally we have some information disclosure attacks. We get evidence that participants were able to navigate to and interrogate some high value exploitation assets on the system:

So in summary, we had 154 attack attempts. Most of the focus was on Command Injection, SQL injection & XSS. Given the scoring distribution, it’s not surprising how few folks

Information Disclosure attacks

Next Steps

I’ll be sending a note out to the participants giving folks their own scoring data if I have it.

I have a few bugs logged at https://github.com/CaptainMcCrank/wifi-ctf-bugs that I’ll increment.

I had a few more feature ideas: The web app needs to present signals of successful exploitation to the participants. I’ve put more effort into the LED- which draws walk-ons but gets little inspection by participants.

There are some edits to the documentation that need to be pursued.

I hope to have a new build ready for some testing by the end of this week. I’m looking for another location to run a beta test. If you want to partner, please reach out. You can connect with me on linked in: https://www.linkedin.com/in/patrickmccanna/