Yesterday, the media exploded with news of the new Krack attack against WPA2. What’s Krack? While it sounds like a new designer drug, it’s short for – Key Reinstallation Attacks.
What’s that mean in English? Due to a flaw in the WPA2 protocol, a determined attacker can target and break the 4-way handshake and compromise the unique session keys. They can force reuse of a key, and intercept (as well as potentially modify) unencrypted traffic. The full whitepaper is here.
The good news, such as it is:
- This is not a remote attack – the attacker needs to be in range of the affected Wifi connection
- At this point, there is no evidence of these attacks in the wild. Caveat, at this point.
There have been a couple of reports suggesting that WPA2 should be disabled in lieu of WPA or (ack) WEP. These are not better options, as a general rule. WEP in particular is vulnerable far beyond the WPA2 protocol issues.
What can we do, and what should our user base do?
- As soon as there’s a patch available, take advantage of it.
- Watch your vendors – who is patching quickly, and who is not? If your vendor is months behind the curve, why? It may be time to look at other options.
- Wired connections are immune. This should go without saying – this includes tethering directly to mobile devices, not tethering via WiFi.
- You’re already horribly suspicious of free public WiFi, right? Double that paranoia.
- If you must use a public WiFi, do not do so without using a VPN or other traffic encryption mechanism. Split tunnel VPN is not your friend here – configure a full tunnel VPN connection
- Bring your physical security staff into the conversation. They will be integral in observation of potential attackers in the sphere of your physical presence. (Have you checked how far your WiFi signal is traveling lately? Consider checking…)
CERT has a complete list of vendors and their known status here.
Questions, comments, things I haven’t thought about? Reach out, I’d love to hear from you. Twitter @TheTokenFemale at any time.
One of the most common questions I get is, “Where does attack traffic come from?”. I want to present a quick and dirty answer, just to show you how diverse illicit traffic sources are.
To give you a glimpse into that, here is a list of the top 20 ISPs, based on the number of unique malicious source IP addresses who touched one of my HoneyPoint deployments in a single 24 hour period.
9 korea telecom
6 dynamic distribution ip’s for broadband services ojsc rosteleom, regional branch “urals”
5 chinanet jiangsu province network china telecom no.31,jingrong street beijing 100032
5 china mobile communications corporation mobile communications network operator in china internet service provider in china
4 chinanet jiangsu province network china telecom 260 zhongyang road,nanjing 210037
3 zenlayer inc
3 jsc rostelecom regional branch “siberia”
3 broadband multiplay project, o/o dgm bb, noc bsnl bangalore
As you can see by the above, the list is pretty diverse. It covers sources in many countries and across both domestic and foreign ISPs. In my experience, the list is also pretty dynamic, at least in terms of the top 10-20 ISPs. They tend to spike and fall like waves throughout different time periods. One of these days, maybe I will get around to visualizing some of that data to get a better view of the entropy around it. But, for now, I hope this gives you an idea of the diversity in sources of attacks.
The diversity also makes it very difficult to baseline log activity and such. As such, there may be some effective risk reduction in blocking ISPs by netblock, if your organization can tolerate the risk associated with doing so. But, more on that in another post. Hit me up on Twitter (@lbhuston) and let me know what your firm’s experience with that type blocking has been; if you’ve tried it or are doing it today. I’d love to hear if it reduced log noise, made traffic modeling easier or led to any specific risk reductions.
Thanks for reading!
Since I began working at MSI several years ago I have been able to study the behaviors of organizations of various sizes in terms of information security.
Sort of a forced march through “infosec cyber-anthropology”.
One thing that has always surprised me is the number of comparatively large organizations – often ones with significant IT staffing in the form of networking, database and sysadmin staff – who do NOT have dedicated security staff.
This to me is a lot like expecting the postmen, utility crews, trash workers, and all the rest of the specialist priesthood that keeps our immediate environment working, to also pick up the slack and do police work on the side.
As in all bureaucracies, IT staff can be very turf-conscious. In some cases the hiring of dedicated security staff is clearly actively resisted by existing groups. Threatened sysadmins will claim that they can handle any security issues – often as long as they have the right tools. And that plays into the “magical thinking” that security product vendors are quite willing to cultivate in the minds of management: “Don’t hire people – buy my stuff! Burn enough money on my altar and the evil will be held at bay.”
I believe strongly this is the road to hell – or at least career death for executive management when the inevitable breach occurs.
Ask those Equifax execs.
Gardens need gardeners. Your information security environment will be an illusion if there are not people who truly care about it and feel a moral obligation to protect your organization and the information that customers entrust to you. That obligation includes questioning things as they supposedly are and not believing that what your SIEM says is necessarily the truth.
No “managed security services provider” is going to do this for you. Only loyal, engaged and actively concerned staff who have a clear sense of local mission can provide such care.
It is a level of care you would want for yourself and for your family.
Provide it to your customers.