WPA2 KRACK Attack. Huge new security bug that pretty much everyone needs to solve


Certainly would be nice if Rachio products were updated to no longer have this but as I’m 90% sure they are affected clients.


A new version of WPASupplicant has already been released on many platforms and here are the pertinent CVE entries:
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.


Yes please let us know when a security patch has been released for this exploit. Thankfully I just had my sprinklers blown out for winter so I can turn my controller off until a patch is released.


Hey @Brett and @Squeekstyle-

All messages between the Rachio Gen 1 or Gen2 controller and our servers are encrypted, meaning an attacker cannot look at this data. We regularly perform internal controller audits to check for and prevent vulnerabilities. For more information on our security measures, check out this support article. For more information on what is and is not affected- there are good articles here and here! A highlight from those resources below…

The attacker can intercept some of the traffic between your device and your router. If traffic is encrypted properly using HTTPS, an attacker can’t look at this traffic.

McKynzee :rachio:


Actually if you check things out there are ways to strip the SSL out once you’re a MITM. Granted its a pretty benign thing to have people snooping on sprinkler traffic but this is probably something that should be fixed. I’m betting these things are linux based and thus a new version of WPASupplicant needs to be brought into the fold.

If the units at all can fall back upon http streams if the https doesn’t work for some reason then there are even bigger issues.


Hi Brett,

Thank you for your concern on this. A few things to reassure you:

We don’t use linux and don’t use wpa_supplicant which is the most affected by the vulnerabilities that were disclosed by KRACK.
We don’t use HTTP/HTTPS for communications with our servers so tools like sslstrip that try to trick a user into downgrading from HTTPS to HTTP wouldn’t work.


I guess that would make sense in that hardware capable of running Linux would be overkill for the sprinkler head. Good to know its direct HTTPS only which does help. I’ll be jerking my AP out and replacing it because the company doesn’t have plans for updating it in a timely fashion. Out with the Linksys and in with a Ubiquiti unit.


not capable of running linux? There is such a high percentage chance that is running some embedded variant or custom modified version on the hardware.

None of the responses I have seen so far are adequate - this is why iot stuff is laughed at.

get with the hardware vendor and have someone who knows what they’re doing actually look at the exploit and CONFIRM with the technical details that the exploit doesn’t the way the low level wifi handling works, or confirm that it could be exploited and post details of plans to FIX IT with mitigating steps to take during the wait.

the responses i’ve seen on twitter of “don’t worry” and the responses here are not adequate.

The help page article linked above WPA2 KRACK Attack. Huge new security bug that pretty much everyone needs to solve
is pretty weak

for the gen1 the hardware vendor has responded with the appropriate technical details, but no guidance on how patches or upgrades to the underlying OS are pushed by rachio, is this automatic? does the user need to do something?

for the gen 2…nothing, consulting with the people who developed and have an understanding of the actual hardware and the low level software. So there is no answer as to if this vulnerability affects gen2. It is disingenuous to tell customers not to worry without telling them the truth.

you can say AS WE UNDERSTAND IT NOW there is little reason to be concerned in the immediate future as you would have to be specifically targeted.

The ripples of this vulnerability are going to last a long time. because it is brand new it will take some time for attackers figure out ways to utilize in a broader attach sense, by that time the responsible companies will have patched it and it will just be attacking the leftover internet of things crap that don’t take this sort of thing seriously.

this is going to be a long lasting attack vector that should be taken seriously. is someone going to hack you tomorrow? probably not. is the rachio data “important” even if someone possibly exploited “just your sprinkler times” i’ve seen mentioend is all thats at risk…not true. can rachio say with certain and provide techincal proof that this can’t be exploited to gain access to your network and wreak havoc on your home network computuers?

having a fast and transparent and technically sound response to a vulnerability that affects pretty much everyone should be a layup for a company that provides a technical product with a web service and app. look into it, provide mitigating advice in mean time, provide fix or technical confirmation that your device is not vulnerable. very easy.

the issue with IoT devices like this is they outsource the hardware and the lowlevel software taht goes on it. or use some COTS hardware with little concern over security items as long as they can sell their service/product. They don’t ever anticipate it changing or needing to change it or update the device OS/firmware.

The responses to a bug like this should shape consumers opinions of the companies they choose to do business with. If a company is silent on this bug, or tells you it’s not a big deal and doesn’t explain how they’ll fix it, or how they are CERTAIN it doesn’t affect their product, then you should be very wary of doing business with that company in the future, because they just don’t have your best interest in mind.

if they don’t want to talk about it, they don’t make a clear statement on it outlining actions being taking or technical confirmations. it doesn’t take much to spin up a lot of iot type of products. get some hardware platform, hack it up to do what you need, and then get web dev guys to make some backend with bootstrap and data visualization libraries then get some app devs and you have a business. notice in there the lack of focus on security or protecting user data…it’s optional to some. then something like this happens, and this is where consumers need to look at these responses and decide for themselves if you feel comfortable


Odds are that they didn’t want to pay for hardware capable of booting a full linux as they also probably don’t need that much OS. Odds are good that its running freeRTOS or something similar to that…

That’s not how this bug works. Its a man in the middle attach in which you are able to view the traffic inside of the stream. The thing here is that this stream on a Rachio is double encrypted. Its encrypted via SSL and via WPA2. This KRACKED bug possibly breaks WPA2 however the SSL encryption will remain which protects things much more. Also no one is using their Rachio to connect to so if you have fixed KRACKED in your access point you should be entirely safe. Honestly @dgp has provided a pretty reasoned and intelligent response. I do still however think that Rachio would be best served by writing up a slightly more fleshed out version of this and putting it up as an announcement on their site for a while to help make people feel better.


so, you keep saying capable of booting linux, but there are very tiny footprint/resource requirement variants of linux that are meant for embedded platforms. The only reason linux matters in this conversation is because you brought up WPAsupplicant. so whether they use linux or not or even some rtos doesn’t matter, it will be in the implementation of the driver for wifi chipset.

that’s the issue with something like this, it seems unclear that they even know what they use because they outsourced that level of development, yet they feel comfortable telling you not to worry.

at this point they have not talked about what chipset they use or confirmed that the driver software for it regardless of whatever operating system it utilizes. They’ve just said “don’t worry”

do you know for certain that if a rachio was hypothetically exploited that this access could not be used to learn other network information and escalate network access? do you know if rachio polls anything on the local network for some reason? what about in a power loss scenario, how does the initialization happen, is there a window there? have you wiredsharked the traffic in and out of the rachio? was there some independent third party security audit of this device in general? when they say they do security audit periodically, what does that really mean? now granted these are all low probability and targeted, but WHO KNOWS is the point and until rachio confirms it and shows their work regarding it, everyone should be aware and cautious.

rachio should take a position more inline with being transparent and informing their customers. some social media person who doesn’t have technical background should not be assuaging concerns regarding something like this. a guy that used to run a lawn service tried to contact me to discuss. And I don’t mean that disrespectfully, but this is a different kind of customer support.

wrong, this needs to be fixed on both client and access point sides

all this to say I don’t think there is any immediate risk and there may be little long term risk, depending on a bunch of under the hood stuff that the end customer’s CAN’T KNOW unless they open sourced the software on the device. I’m very tempted to go rip apart my rachio and start reverse engineering it to determine chipsets and try to understand more about what the hardware is doing and see if there’s any exposed uarts etc and find information and security stress in other ways. but why should I when the company that makes it shoudl be able to provide clear answers or guidance regarding a very specific exploit that is now out there.

how many rachio’s exist in the wild? how would an attacher know you have a rachiio to try to exploit. someone would have to be “coming for you” to attempt it. so all of these things are very improbable. but security through obscurity is not good practice. For anyone reading this who is not that technically inclined, go take a look at shodan.io and google around about how that works. educate yourself a little and demand more of iot product developers. read about how webcams being used as a botnet for DDOSing… i’m not saying that’s what’s happening here, but cavalier attitude about security things for these types of devices is never useful, and as a consumer you are ultimately responsible for your security, and a lot of companies that you pay money to, couldn’t care less unless it becomes a PR problem.

rachio is making a mistake here with how they’ve handled it so far and it’s disappointing because it’s functionally a good product and one of the very very few iot products i’ve let into my world.

sadly this response is one of the reasons why I haven’t adopted more iot devices.



As someone that worked on both the hardware and the code that runs on the Gen1 and Gen2 hardware I can tell you we don’t run any form of linux.

I apologize if you feel the response so far has not been adequate. Please keep in mind that the frontline support people are not experts in this field and it’s not often that they have to respond to customers concerning issues like this. Also it’s very hard to word a statement about something like this that reassures non-technical people while at the same time gives all the finer details that people like you and me want to know to assess the situation for ourselves.

We have been getting together with the wifi hardware vendors and working out how gen1 and gen2 are affected and what we need to do going forward. For Gen1 the wifi vendor put out a statement pretty quickly and that’s what you see linked in our page. For Gen2 we just got a response from the wifi vendor saying they are identifying the issues in their implementation of WPA and will be supplying us with an update.

You’ve written a lot about how we bought an off the shelf solution threw some code on top and put it out there. Again, as someone that worked on this I can tell you nothing is further from the truth. In the IoT world there are only a few options on the parts you can use for the wifi side of a product and all of them use proprietary firmware (software for hardware) provided by the vendor that only they can update. This is true even in the open source world; If you’re using wifi on Linux or Android you’re using proprietary software that only the vendor of your wifi chip can update.

Both Gen1 and Gen2 support over the air updates. Both can receive updates to their OS, application code and the previously mentioned wifi firmware. Both have received updates since they were launched and will be receiving updates to address issues like this.

Regarding KRACK itself:
Almost all implementations of WPA are affected by the “handshake” issues because everyone followed the specifications. Everyone has to follow the specifications to get their products certified. For Linux and Android the problem is much worse as their WPA implementation contains extra bugs that amplify the problem. We do not use that WPA implementation.

KRACK is an attack against a wifi client (in this case a Gen1 or Gen2 controller). So if someone successfully uses the exploits they will be able to see traffic between that client and the access point it’s connected to. This is undesirable but for our controllers there isn’t a lot of data going back and forth and none of it is sensitive data. For the most part the controllers use a single connection to our servers. That connection is encrypted and at connection time we validate the identity of both the controller and the server.

The demo video on youtube that shows an attacker downgrading match.com from HTTPS to HTTP is worrying but we don’t use HTTPS and we don’t connect to our server in such a way that an attacker can force us to not use SSL/TLS. It’s encrypted or nothing. Then on top of that we are validating that both ends of the connection are who we think they are.

If you have any more technical questions or concerns I’ll be happy to answer them.



Thanks Daniel,
Excellent detail for we geeks… Steve


thanks for a little more detail.

what we’ve learned:
OTA updates are possible.
Gen1 vendor has confirmed IT IS AFFECTED and a patch will be needed - timeline for update TBD
Gen2 no vendor confirmation yet on if affected - TBD

even I, the pain in the butt guy pushing for more clarity, admit this is low risk to rachio users. I don’t expect them to answer, a simple “our technical staff is reviewing and we will update with findings as soon as possible” type of statement along with a “this appears to be low risk to current rachio users, but we will confirm” sentiment. The statement on the help page is along this lines and not bad, but there were people getting support responses saying nothing was going to be done and don’t worry about it. This sounds like technical knowledge behind the scenes determining low risk being filtered through non-technical support as no biggie. which is a failure to the customers to not have a clear response and having support who don’t understand or who shouldn’t be making statements freelancing and having people think their device is not affected when it is. Risk determination being separate of this and really up to the end user if they are willing to accept the risk, not the company. Even daniels statement earlier in this thread were a little “these aren’t the droids you’re looking for” esentially saying “here’s how it’s not that risky” not answering the question of if the rachio hardware is actually affected. surprise, one version is and i’d bet dollars to donuts the gen2 is also.

outstanding questions:
is there a way to view the current software version of OS/firmware/application for the hardware, in the website or mobile app? is there a changelog for the hardware software?

it has been made clear that the demo put together by the researchers who found this vulnerability used it in conjunction with moxie’s sslstrip to show a simple example. the SSLstrip aspect of this example wouldn’t apply to the rachio hardware. It keeps being mentioned that comms are “encrypted” between rachio and server. Are there more details on this encryption? is it military grade (lol, that’s a joke). i mean sha-1 is technically “encrypted” but…are you using some standard well tested protocols? or is it a home rolled solution?

it was mentioned that there are periodic security audits. What are the specifics of this?

I think it’s pretty easy to always over deliver with the technical details with how something like this is being handled, up front and clear. people who are not techincal will glaze over it or skip to the TL;DR portion to get a warm fuzzy, but people who want specifics can have them. unless you think your customers are dumb or dont’ care and will blame you for a vulnerability that’s not your fault.

you should tweet about them and make them available easily on facebook or blogs or whatever other social media market stuff you do. it builds trust, builds a stronger brand, and company. Being legit and transparent is the best form of marketing. look at ubiquiti’s response to this on twitter (@ubnt), (people are posting vids of them updating like it’s a party or something) pretty straightforward if you’re legit. They made themselves stronger with this and nobody had to pull any teeth to get information on what was happening regarding this vulnerability…

thanks for dialogue. will be watching for updates on twitter and blog.



A quick search shows that they have already published the security that they have on top of the WPA2 encryption. I don’t get how we know that we’ve probably got an issue in the first layer of our protection but we know that while we work on that you will be safe because of our encryption and the way our tools work. Even good detail on how they work was provided. You keep spouting stuff like you’ve read a lot of blogs on this material but you seem to be missing some key understanding of the underlying protocols.

If you don’t trust SSL and/or TLS then you may as well just quit using the internet for anything other than public matters.



Pretty much every WPA implementation is affected to some degree. So Gen2 is also probably affected to some degree but until we know more it’d just be speculation and I don’t think that helps anyone.
The best advice I can give related to WPA itself is to make sure you’re using AES-CCMP as the encryption setting as that is more difficult to manipulate.

Being a pain in the butt is fine and I understand your concern. The support guys were trying their best to reassure people and gave out a bit of a mixed message.

Answers to questions:

  • In the current user application there isn’t. On our side we know the current versions of the firmware for each controller, even the ones that have never been powered up. I’m not sure change logs for the hardware/software are something we can give out.

  • The encryption is standard TLS just like HTTPS but we don’t use HTTPS. I can detail the cipher suites we use if you really want to know that stuff but the short version is: We use cipher suites that are currently considered strong. The server’s identity is verified by a certificate and the device verifies its identity to the server via a per-device certificate that is etched into it when it gets built. Getting in the middle to sniff the data wouldn’t be trivial. If someone did attempt to do it you would probably notice it when you get a notification from the app telling you the controller is offline as it will simply refuse to connect. (edit: This info is for Gen2, for Gen1 see http://blog.electricimp.com/)

  • We do internal audits and we have had third parties do audits to make sure we didn’t miss anything.

  • I’ll bring up your points about how this was handled over twitter etc.

  • When we do have updates to fix the issue you won’t have to actually do anything to install it. We schedule an update and when your controller isn’t doing anything it’ll grab the update and install it.



Hi Brett,

Thanks for linking that post. I think people are genuinely worried and just want answers really.
I’m just as worried as everyone else… I have 5 controllers :slight_smile:


I disagree, this is when you overdisclose, because you don’t know yet. This is largely the entire point of me even bothering to show up. I wouldnt’ have given a crap because the rachio is so nill risk regarding this bug, but I was just taking every inventory of every client thing I use to asses risk and prioritize updates (CLIENT brett, cause clients are more affected lol). I searched rachio on twitter and saw the lamest response to something like this and it fired me up because i am pretty discriminating about what I put on my network and fear for the average non-technical end user (like brett, lol) and most iot things don’t cut the mustard. I do remember that link that brett posted now because i looked at it when i purchased the rachio and felt comfortable with that.

I’m really not concerned about security of the rachio right now, even if it never got fixed it would probably still be acceptable risk for me, so I totally understand the initial response from a technical standpoint. But THERE IS AN ISSUE however small and low risk and it sucks to see a company tell it’s customers something iot device companies in general need to do a better job on security and not sweeping things under the rug. look at ring right now being sketchy and not answering and dodging questions because you can probably pretty easily use this exploit to take their cameras and stuff offline…oooh wee imagine ring sweating as a company if they can’t OTA patch it…

be early and transparent and don’t treat your customers like dummies and don’t tell them what is acceptable risk for them (except brett lol, just kidding brett i love you but congratulations you played yourself).

thanks for the ok responses after a lot of pushing.


This “security bug” situation is as confusing to me as evapotranspiration and precipitation rate is to some people.

What amazes me is we have irrigation system owners talking computer code and hacking on a forum for an irrigation controller.

Talk about worlds colliding!


Thanks for the passionate discussion everyone, I wanted to provide a tl;dr.

Our WiFi vendors for the Gen 1 and Gen 2 products have researched and identified patches for their WPA supplicants.

When these are available, the controllers will be updated through OTA.

All messages between Rachio products and our servers are encrypted to ensure all user data is secure and not visible to attackers.



So in the end you state that you agree with me but fear that I’m a non technical user… I guess all that time spent getting two bachelor’s degrees in computer hardware engineering and computer software engineering and spending time writing network transport code in classes was wasted. Boy not to mention the over a decade of experience designing and developing embedded systems…

Hopefully someday I’ll reach the l33t h4xz0r status that you’ve got. I’m glad to see that you’re finally starting to understand what was said a few messages ago and are coming down from your horse.


For those who want to get a better idea of what this is all about, here is a nice video dealing with some technical aspects in a more friendly matter:


The point, as I understand it, is that in order for this attack to work the network traffic has to be different each time the “key” is reset. What this means is that if someone has encoded “Hello” using the key and then encrypted “Aloha” using the same key; attacker would be able to figure out the key by applying xor to the two different streams, explanation @ 6:31 (link).

What to take from this:

  1. Each individual connection between the client and the router is encrypted seperately
    What this means: If someone cracks Rachio’s wifi encryption, they will only be able to see data from Rachio, all other devices on the network are still encrypted and Rachio does not reduce their security (your windows laptop is still safe).
  2. This does not affect other levels of encryption
    What this means: since rachio is using SSL to encrypt the data on top of the WPA2 wifi encryption, the attacker will only be able to get the SSL data stream, useless without a proper decryption key.
  3. Rachio is secure as is
    Explanation: Because rachio controller is only using SSL (never unencrypted data), data will be randomized due to use of a random symmetric session key and xor commands needed for KRACK to operate will yield random noise.

In conclusion: using HTTPS as much as possible is important (especially for your bank, email, etc…); worrying about your sprinkler for this attack is less so.