Sunday, 21 June 2020

Riving a router stuck in an infinite reboot loop

When doing wireless security research, you need enough devices to test and confirm your findings. Results have to be practical, after all. Due to COVID-19, this became more tedious: access to the lab is being limited, making it harder to test many devices.

Because I wanted some extra devices to hack play around with, I realized that I still had a router from my ISP. The problem is that I bricked that router more than a year ago: stuck in an infinite reboot loop, after accidentally including a backtick ` into the wrong field. This menacing backtick likely caused some start-up process to fail, trigger a reboot of the router. I didn't want to bother with calling the ISP and explaining that yes, I already rebooted it — in fact it rebooted a thousand times already — before getting it replaced. So I simply used my own router instead.

But now it became interesting to get that router working. So how can we revive it? Pressing the reset button in various ways, and for more than 30 seconds, had no effect. That's not good... On the bright side, the router did seem to briefly be operating before it reboots. Maybe that gives enough time to quickly navigate to the management interface and reset the field? Unfortunately not, the management interface is operational for just one second.

My solution was to make a script to detect when the router is operational, and within the available section automatically navigate the management interface, reset some options, and hope that will fix it. To immediately detect when the router is being (briefly) operational, I wrote the following scapy script:

The above script rapidly sends ARP requests for the IP of the router. Once an ARP reply is received the scrip exits. This needs to be run as root because we're using raw packet injection.

One the router is accessible, we need to rapidly navigate to its management page, log in, and try to reset it from there. Luckily, with selenium we can do exactly that:

The above code only worked after tweaking the sleep calls. If the were even a tiny bit longer, the router would already be rebooting. If they were shorter, the page wouldn't have loaded yet. After a few attempts, this managed to reset the router!

The router did behave unusual after this reset. Wi-Fi was working in the 5 GHz band, but not in the 2.4 GHz band, and some other strange behaviour. This was fixed by manually resetting the router a second time. Probably when we reset the router for the first time it rebooted in the middle of resetting its configuration, which resulted in an inconsistent configuration. Anyway, now everything worked, without having to make annoying calls to the ISP.

Wednesday, 25 September 2019

Accessing and Inspecting Draft IEEE Standards

This is going to be a quick blog post on how you can access IEEE standards. I'll also show how you can follow ongoing discussions, at least to some extend.

Why Inspect Drafts

Security protocols tend to fail when they are developed behind closed doors. They also fail when it's too hard to join discussions. We saw this with WPA3: its Dragonfly handshake was standardized in the IEEE 802.11 standard back in 2011, and there was little involvement of security researchers at the time. Only when attempts were made to standardize Dragonfly for TLS, was there significant feedback and criticism due to the much more open nature of TLS.

Official Solutions

Technically, anyone can give comments on draft IEEE standards by paying money. This is called the IEEE-SA Public Review. During a period of 60 days, you can buy a draft version of the standard. You can then submit a comment, and the working group that is responsible for the standard is required to give a reply:
"The Working Group will consider your comments and provide a response. You will be able to view the responses in the IEEE SA Public Review system."
While this is something, most researchers won't use this. The biggest obstacle is that you don't know whether it will be interesting to analyze the standard before buying it. A lot of times you take a quick skim at a new standard, and come to the conclusion that there's nothing worth to research. This can have multiple reasons: the standard looks secure, it's outside your area of expertise, researching it will be more time consuming than expected, and so on.

One might assume that another option is becoming an IEEE member. However, IEEE membership alone does not give access to standards under development. And even if it did, it would have the same problem as the IEEE-SA Public Review: few will become a member merely to quickly take a look at a standard.

Published standards can be downloaded for free after 6 months through the IEEE GET Program. While this is certainly useful, waiting 6 months is too much. After this time it's no longer possible to influence the standards, and vendors will already be implementing it.

Unofficial Solution: Send a Mail!

There's one other way to research and discuss upcoming IEEE standards:
  1. Most working groups (802.11, 802.15, 802.19, etc) publicly host their their working documents. This includes presentations that propose new extensions, draft amendments, meeting notes, and so on. You can search through these with google using "search terms site:mentor.ieee.org". It can be difficult to understand amendments this way, but it allows you to determine what they are working on, and if it would be interesting to research.
  2. If there is something you want to give feedback on, or research in more detail, you can try emailing the people that are working on it. E-mail addresses should be available in the documents you find on mentor.ieee.org Hopefully they can then bring you up-to-date on the latest progress in the draft standard.
This unfortunately isn't an official solution. You need some luck with finding and understanding publicly available documents, and finding IEEE members that want to discuss things with you. Nevertheless, this has worked for me in the past. Already having done research in this area will help (e.g. research on already published versions of the standard).

A Better Future?

Before dashing out too much criticism, let's remember a similar situation in academia: a large number of papers are locked behind paywalls. We're slowly changing this by having more open access policies, but unfortunately large and systematic change takes time. The same will be true for industry standards: major changes will take time. Fortunately, there are some steps we can take right now: researchers can contact the IEEE, or more precisely IEEE members that are working on new standards, and ask for access to draft standards. Likely they'll be happy to discuss things and get feedback, and this might slowly result in more collaboration.

Perhaps one solution is that members of organizations such as the International Association for Cryptologic Research (IACR) can become IEEE members without having to pay fees. Or at least have a membership type where you can only inspect standards. Such collaborations would make it easier for academics to inspect standards, while still having some control over who can access them.

Wednesday, 27 June 2018

WPA3: A Missed Opportunity

Almost half a year ago, the Wi-Fi Alliance made a press release announcing they were working on WPA3. In a previous blog post, I discussed the four main features that were mentioned in this press release. Today, the WPA3 certification program is finally released publicly. Unfortunately, only one of the four initially announced features are a mandatory part of WPA3.

The WPA3 Certification Program

First, it's important to know WPA3 is a so-called certification program. It's not a new standard or protocol. Instead, the Wi-Fi CERTIFIED WPA3 program specifies which existing standards (e.g. protocols) a product must support. If a product correctly implements these standards, it can use the "Wi-Fi CERTIFIED WPA3" label. In other words, this label indicates that the device passed a whole bunch of tests, meaning it will be interoperable with other devices that obtained the WPA3 certified label.

So what are the features that a WPA3 certified device must support? Initially, the press release at the beginning of this year suggested that WPA3 would require support of four major features. Summarized, these features consisted of a new handshake called dragonfly (which is resistant against dictionary attacks), an easy method to securely add new devices to a network, some basic protection when using open hotspots, and finally increased key sizes. Unfortunately, the WPA3 certification program only mandates support of the new dragonfly handshake. That's it. The other features are either optional, or a part of other certification programs. I fear that in practice this means manufacturers will just implement the new handshake, slap a "WPA3 certified" label on it, and be done with it.

But what happened exactly to the other three promised features? First, the technology to easily and securely add new devices to a network will be certified under the Wi-Fi CERTIFIED Easy Connect program. Second, improved security features for open hotspots (based on unauthenticated encryption) will be tested for interoperability under the Wi-Fi CERTIFIED Enhanced Open program. This means that if you buy a device that is WPA3 capable, there is no guarantee whatsoever that it supports these two features. Third, the increased key sizes are an optional part of the WPA3 certification. More precisely, only when using WPA3-Enterprise are the increased key sizes mandatory. Note that WPA3-Enterprise refers to enterprise authentication, where the login credentials are for example a username and password (instead of a simple pre-shared key in home networks). Finally, the key sizes that are used to encrypt traffic after connecting to a network aren't required to be increased at all.

It's also worth mentioning that WPA3 will mandate support of Protected Management Frames (PMF). But that's not surprising: WPA2 also mandates support of PMF since the beginning of this year. Note that PMF prevents deauthentication attacks, and also offers other benefits. That said, I'm quite sure people will find new ways to bypass PMF and still forcibly disconnect clients from a network.

To summarize, here's an overview of new features that are and aren't part of WPA3:
  1. The dragonfly handshake (also called Simultaneous Authentication of Equals) is a mandatory part of WPA3. So if in the future you select "WPA3-Personal" in your home router, you will be using this handshake. This means dictionary attacks against the handshake will be longer be possible.
  2. The replacement of Wi-Fi Protected Setup (WPS) will be called Wi-Fi Easy Connect. It is based on the Device Provisioning Protocol (DPP). It is not part of WPA3.
  3. To provide unauthenticated encryption when connecting to an open hotspot, the Wi-Fi Alliance introduced Wi-Fi Enhanced Open. The standard behind this marketing term is Opportunistic Wireless Encryption. It is not part of WPA3. Note that even if opportunistic encryption is being used, it is trivial for an attacker to set up a rogue AP and intercept all traffic.
  4. WPA3-Enterprise networks will support key sizes that offer the equivalent of 192-bit security. But the increased key sizes are only required during the authentication stage. Moreover, the WPA3-Enterprise mode is an optional part of WPA3.
All combined, this means that the only required part of WPA3 is the new dragonfly handshake. While this handshake is an improvement over the old 4-way handshake of WPA2, the Wi-Fi Alliance could have improved security a lot more, by also making the other features a mandatory part of WPA3. It seems the Wi-Fi Alliance focused on keeping WPA3 easy to implement for vendors, but not on improving the security of users.

Conclusion

The Wi-Fi Alliance missed an opportunity to truly improve the security of Wi-Fi networks. Instead, due to the vague press release earlier this year, and the closed discussions afterwards, most users were left confused and unsure about what will and won't be part of WPA3. In particular, even though the press release promised several good enhancements, only one of them is mandatory under WPA3. Indeed, only the dragonfly handshake is mandatory. While this handshake is an improvement over the old 4-way handshake of WPA2, they could have done a lot more. As a result, the WPA3 certification program is a missed opportunity that could have truly improved Wi-Fi security.

Minor update: it is worth noting that vendors may step up and still implement all the other security features. In particular, I hope most vendors will nevertheless implement Wi-Fi Enhanced Open and/or Wi-Fi Easy Connect.