Blog post

Time to KRACK the security patches out again

Created:  20 Oct 2017
Updated:  20 Oct 2017
Author:  Andrew A
Patched computer

On Monday morning, the NCSC woke up to something of a frenzy about the impending publication of research that had found weaknesses in the Wi-Fi networks that we previously thought to be secure. It quickly became clear that KRACK (key reinstallation attacks) could affect pretty much all the Wi-Fi devices in homes and offices throughout the world.

As you'd imagine, our technical research teams immediately got to work, trying to understand the potential attacks and the associated impact. We followed-up our initial press statement with some guidance for enterprise, small business and home users, suggesting some immediate steps to protect yourself and your organisation.

One thing that quickly became clear (thanks in part to the detailed research paper and FAQs published by Vanhoef and Piessens) was that once again the answer is to apply security patches, in this case to all wireless devices. It took me back to the earlier WannaCry ransomware attacks that spread like wildfire across the Internet and around enterprise networks. WannaCry didn't infect systems that had already been patched that month, and patching was the most effective mitigation against that ransomware.


Patching is a fact of life in the digital age

Anyone that's ever worked with us at the NCSC will know that we constantly stress the importance of patching. We use the phrases 'aggressive' and 'automatic' patching so often that we sound like a stuck record. However, there are many legitimate reasons why security patches don't get applied. Dr Kami Vaniea from the University of Edinburgh's School of Informatics discussed some of these at CyberUK 2016 (you can read the full paper here), and my colleagues refer to a list of reasons for not patching started by Wendy Nather. This assumption - that patching is difficult and risky - can result in patching being delayed or (in some cases) not done at all.

There are always going to be security vulnerabilities in complex technologies and devices. You may be familiar with the concept of a 'Friday afternoon car', which is a car built in a bit of a rush just before the weekend. So it probably hasn't been made with the same attention to detail as those built earlier in the week. Computers - like cars - are designed and built by humans, so there's a similar concept of 'Friday afternoon code'. As humans, programmers and designers will occasionally make mistakes, and even more occasionally, one of these mistakes will allow an attacker to misuse the technology. This leaves us with having to deal with the likes of KRACK and WannaCry.

There are tools and techniques the security industry has created to help developers write better code, and automatically detect and fix common mistakes. However, developers - being human - will accidentally write vulnerable code, allowing attackers a way in. For the time being, we'll need to use security patches to apply fixes to a lot of the technology in our lives.


Patching needs to be 'business as usual'

Each time one of these 'superstar' bugs hits the headlines, IT departments end up rushing around desperately fixing any systems that have been attacked, and patching everything else. Yes, patching can be difficult, and it's annoying for the people trying to get on with their Internet-connected lives when devices and services need to be restarted to fix them. Wouldn't it be great if everything quietly updated itself - automatically and reliably - at a convenient time?

Some technology already does this. My home laptop and smartphone are automatically updated each month. As far as I can tell, my Wi-Fi router, IoT thermostat and games console all do the same. When KRACK came along, it turned out that my laptop and home router had already patched themselves a few days before. And I knew my smartphone would be patched as part of the next scheduled monthly update. That's not all the technology in my life, but it's a good start.

Things get a bit more complicated at work. Suddenly there's a lot more equipment that needs patching, and much of it has to be done manually which makes it more difficult. Mike H has blogged about the need to update laptop firmware to keep it secure and the challenges and practicalities of actually doing so, and that's just one of the many types of technology that an enterprise has to look after. Instead of having to manually patch, we need to be at a point where devices 'patch themselves' in a way that is both secure and reliable enough for us to not have to worry about it.


So what do I do until then?

There are a few things that you can do now to make your connected life easier:

  • Choose devices and software that support easy or automatic security updates.
  • Check that a vendor actually releases regular security patches and will commit to doing so for the amount of time you expect to keep the device.
  • Configure your devices to automatically apply all security updates to devices rather than leaving a human in the loop who may accidentally forget to deploy an important patch. Audit and monitoring tools can give you confidence that patches are being reliably applied.
  • If you use a contracted service provider to manage your IT, make sure the contract includes a shared risk statement so that they are willing to install all security patches when they become available. In doing this you will be accepting the small chance of a patch going wrong.
  • If you use public cloud services, confirm that the cloud provider makes a clear commitment to patching their services promptly.

Ensuring that patching becomes business as usual is a big ask, but it's something that we all need to start now if we haven't already. I look forward to the day when users and enterprise administrators don't need to retrospectively react to a new vulnerability like we've seen this week, and instead have confidence that things will just get on and fix themselves.


Andrew A
Cloud Security Research Lead - NCSC


John D - 20 Oct 2017
Recognising that it may have been taken as read, one key aspect that isn't mentioned at all in this article is the need for all patches to have been tested, and qualified, before being applied. This needs to be a joint activity between the vendor (who one would assume has an accredited management system addressing how they modify their software) and the end user (to demonstrate there are no compatibility issues with the patch and all other installed software on that device). If we're going to push for automated patching, then we also need to be pushing for automated testing (something more than checking the device reboots after the patch).
Andrew A - 25 Oct 2017
We’re finding on more modern IT systems that we can rely on the vendors more to test their updates thoroughly on our behalf. We can make this easier for ourselves by choosing products that are certified against the underlying platform, including apps that have come through the Store on iOS/Android or apps that meet the platforms’s compliance standards such as Microsoft’s App Certification Program.

Of course we still see reports every now and then of a patch breaking things for some people. As you suggest, that needs to be more than just seeing if it installs and the device reboots. We take the approach of patching a small percentage of pilot user devices automatically a few days before the majority. There’s a small risk that a few users may be inconvenienced however it thoroughly tests the effectiveness of the updates before they go to the majority. While it’s not the answer for everyone, we’re choosing to acknowledge that the vendor will have done most of the effort for us and hence we just doing some informal testing to detect the edge cases.
John A - 24 Oct 2017
I'd love to follow the advice in this blog, but it rather underplays the fact that the manufacturers of most devices will never make patches available. What do you reckon the odds are of ever seeing a patch for any of my 1st generation iPad, Sony Xperia E1 mobile, Tesco Hudl 2 tablet or Amazon Kindle 3 e-reader; all of which otherwise still do their jobs adequately?
Andrew A - 25 Oct 2017
As you’ve noticed, unfortunately some vendors are much better than others at patching devices after they’ve sold them to us.

Enterprises often already consider how well the devices and services they’re buying will be supported in the future. As that expectation increases then hopefully it will become more common in the consumer space too. Ultimately though our only way to influence this is to vote with our feet – if a vendor won’t commit upfront to keeping our devices updated and/or working then maybe we need to go to their competitors instead.
Kieran McAuliffe - 02 Nov 2017
This morning I reviewed the IOS 11.1 release notes which include the KRACK patch. The notes clearly state which devices the fix is applicable for except for the Wi-Fi KRACK notes. What is unclear is either not all IOS devices were vulnerable or the patch covers only later models.

Apple support when contacted played down this detail "I consulted this with one of our sites senior advisors and he confirmed this for me, believe me (SIC) you don’t need to worry about this security problem affecting your device"

Many will upgrade and patch as required and assume the fix covers the vulnerability but as John A mentioned not all devices will be included. My first generation Ipad I accept will not be upgraded but why do vendors offer the latest software upgrade but potentially not includes the fixes for all devices?

Andy P - 10 Nov 2017
The security contents document ( says that the fix applies to iPhone 7 and newer. Whilst we can only speculate on why that is, it might be that they’re still working on fixes for other hardware.

We know that for all vendors patching firmware and drivers – as in this case – can be challenging in general, as often these codebases are supplied by third parties and so support takes a little longer, or support lifetimes are slightly different than the product they feature in. Longer term, we need to get better as an industry at addressing this, but it’s a complex problem that has roots equally in procurement and contracting, as well as engineering and development. So it’s likely to take some time!
Stuart smiles - 03 Nov 2017
Perhaps a chat with vendors / resellers of equipment about quality of goods and requirements to keep safe could result in encouragement to get patches available in a timely manner, and some sort of dispute resolution process where patches are too slow or unavailable for devices such as CPE routers, core to security of consumers?
If the router is supplied as part of the service (free) does that limit the costs for impairment to what the consumer paid I.e. £0.00 ? As seemed to be default will refund what you paid for that part of the service...

What about older devices for which support is not available, such as older routers, firewalls etc that are eol'd by vendors, should there be free security updates required to sell in UK going forward or replacement service?

Leads to question of should software (and patching of it) be included under the NIS directive? And how a swift resoulution process can be achieved.
NCSC Communications Team - 31 Aug 2018
This blog is now closed to comments.

Was this blog post helpful?

We need your feedback to improve this content.

Yes No