when can we expect to see update for this https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/
Posted 1 year ago
I opened a case and called our Rep and was told there will be a patch by the end of the day.
Maybe thats why the Ruckus website is absent of any mentioning the security flaw - probably not posting anything until they have a fix. Pretty damn late to the party if you ask me.
Maybe switching our campus wifi infrastructure to Ruckus was a BAD idea last year. Fortunately I only started with a few buildings. If they don't put out a patch ASAP, it's good riddance Ruckus and Hello Aruba or someone else.
Maybe switching our campus wifi infrastructure to Ruckus was a BAD idea last year. Fortunately I only started with a few buildings. If they don't put out a patch ASAP, it's good riddance Ruckus and Hello Aruba or someone else.
Too bad they didn't tell by the end of which day..
Chatted with a rep who said there will be a "response" by the end of the day.
I, too, don't understand how you can have 2.5 months to come up with something and "wait til the end of the day" is what they came up with.
You KNOW there is a MAJOR issue. You KNOW your customers and competitors will be looking at your response. You know exactly WHEN the announcement will be made. And yet, you have NOTHING available.
"At Ruckus Support, we value Security above all else. The WPA2 vulnerabilities were just released to the public, but Ruckus engineers have had this information for much longer and have been working tirelessly to address, correct, and test patches for all of our systems. We will have these available very soon. Thank you for your patience, we want to make sure we get this one right."
There, took me 2 minutes.
I, too, don't understand how you can have 2.5 months to come up with something and "wait til the end of the day" is what they came up with.
You KNOW there is a MAJOR issue. You KNOW your customers and competitors will be looking at your response. You know exactly WHEN the announcement will be made. And yet, you have NOTHING available.
"At Ruckus Support, we value Security above all else. The WPA2 vulnerabilities were just released to the public, but Ruckus engineers have had this information for much longer and have been working tirelessly to address, correct, and test patches for all of our systems. We will have these available very soon. Thank you for your patience, we want to make sure we get this one right."
There, took me 2 minutes.
I'll bet they copy and paste that for email replies......
You're hired!
Dear
Please help with a firmware update for the ZF7363 and ZF7321 models for this new vulnerability found in WPA-2. Is there any way to contact them or all those who are registered will we get an email automatically when they have the update to know that is already available?
Please help with a firmware update for the ZF7363 and ZF7321 models for this new vulnerability found in WPA-2. Is there any way to contact them or all those who are registered will we get an email automatically when they have the update to know that is already available?
You will probably want to open a case or check back here to see if they get one out today.
Brad
Brad
(Edited)
ok, thanks
Michael Brado, Official Rep
Hello! Let's please use this one thread to communicate until formal Ruckus response is posted please, thanks.
Here is what I can tell you after all the other Wi-Fi company announcements that should elliviate some concerns.
Here is what I can tell you after all the other Wi-Fi company announcements that should elliviate some concerns.
(Edited)
Michael, I think you are in the wrong thread. The thread you just linked to is this very thread.
What other thread? that is this thread...
I am literally face-palming at this point.
Two+ months to get something together and this guy can't even reply in the right thread.
So what is it you can tell us? I'm confused by your statement.
Edited for more face-palm. Are you guys serious right now?
Michael Brado, Official Rep
The issue is related to 802.11r (fast bss-transition) to enhance roaming, which if disabled on WLANs
eliminates vulnerability to attack of AP-to-client traffic. The krackattacks.com site describe it as:
“it works by exploiting a four-way handshake that's used to establish a key for encrypting traffic. During the third step, the key can be resent multiple times. When it's resent in certain ways, a cryptographic nonce can be reused in a way that completely undermines the encryption.”
WPA2/AES - attacker can decrypt and replay wi-fi packets.
WPA2/Auto-TKIP - attacker can decrypt, replay and inject frames
It requires that the attacker be physically in range of your APs, performing a man-in-the-middle impersonation
of a true AP mac address.
WLAN configuration options on WLANs, default setting is 802.11r Fast Roaming disabled. (SZ 3.5.1).
This is a Client vulnerability issue. A man-in-the-middle with AP sending your SSID and using your AP
MAC address. If one of your clients joins this malicious AP, there is a hole in the client that allows the
client to connect even if the passphrase is not correct(!).
After this happens this, and only this single client, can be sniffed.
Our product is designed to alert Admins if such a rogue AP is present. Only AP manufacturers who use their
APs as RAPs in Mesh (ie connecting to Guest WLAN) are vulnerable (as Aruba stated).
Things to think about:
1) all current certs and Wi-Fi passwords are still secure (attacker doesn't get the pw)
2) AES does not allow for code injection (tkip does, don't use it).
3) Android 6 has more issues that might make this attack easier.
4) Disabling 802.11r will mitigate the attack
5) Patching either side (client or distribution system) stops the attack from happening on WLAN
6) MITM attacks can happen if attacker inserts a new cert, end user is prompted with cert error.
7) Do not move to WEP
Still waiting for a corporate Security message I can post to Support and will share here. Thanks.
eliminates vulnerability to attack of AP-to-client traffic. The krackattacks.com site describe it as:
“it works by exploiting a four-way handshake that's used to establish a key for encrypting traffic. During the third step, the key can be resent multiple times. When it's resent in certain ways, a cryptographic nonce can be reused in a way that completely undermines the encryption.”
WPA2/AES - attacker can decrypt and replay wi-fi packets.
WPA2/Auto-TKIP - attacker can decrypt, replay and inject frames
It requires that the attacker be physically in range of your APs, performing a man-in-the-middle impersonation
of a true AP mac address.
WLAN configuration options on WLANs, default setting is 802.11r Fast Roaming disabled. (SZ 3.5.1).
This is a Client vulnerability issue. A man-in-the-middle with AP sending your SSID and using your AP
MAC address. If one of your clients joins this malicious AP, there is a hole in the client that allows the
client to connect even if the passphrase is not correct(!).
After this happens this, and only this single client, can be sniffed.
Our product is designed to alert Admins if such a rogue AP is present. Only AP manufacturers who use their
APs as RAPs in Mesh (ie connecting to Guest WLAN) are vulnerable (as Aruba stated).
Things to think about:
1) all current certs and Wi-Fi passwords are still secure (attacker doesn't get the pw)
2) AES does not allow for code injection (tkip does, don't use it).
3) Android 6 has more issues that might make this attack easier.
4) Disabling 802.11r will mitigate the attack
5) Patching either side (client or distribution system) stops the attack from happening on WLAN
6) MITM attacks can happen if attacker inserts a new cert, end user is prompted with cert error.
7) Do not move to WEP
Still waiting for a corporate Security message I can post to Support and will share here. Thanks.
(Edited)
This is welcome but where are the patches to eliminate the AP side vuln, at big dog paris we were promised a much more responsive Ruckus when it comes to software updates. The fact that the likes of Mikrotik and Ubiquiti have fixes out already is not showing Ruckus in a good light. The other big players in our field have patches as well as an official response out already. The ball has been dropped. Is someone going to pick it up and save the match?
Given the information above, it does not constitute waiting 6 of your PDT working hours (2PM PDT) to produce what was given. There isn't enough clarification given to soundly say simply disabling 802.11r on a Ruckus products will fix the issue either - this was not the full scope of the vulnerability. At this point in the day I am worried about the dismissive tone and action to the issue. I hope the formal security message doesn't ring this way as well.
Put simply, most other vendors have a fix or at the very least a statement as of hours ago on this. Regardless of how critical other vendors thought this would be they have addressed their end. I don't resonate with updating our endpoints instead, turning off the 802.11r feature on our devices, or anything other than fixing the vulnerability through firmware. You should have already deployed your new firmware/patches and put your obligation to rest. It's concerning this is not remotely the case.
Put simply, most other vendors have a fix or at the very least a statement as of hours ago on this. Regardless of how critical other vendors thought this would be they have addressed their end. I don't resonate with updating our endpoints instead, turning off the 802.11r feature on our devices, or anything other than fixing the vulnerability through firmware. You should have already deployed your new firmware/patches and put your obligation to rest. It's concerning this is not remotely the case.
Has anyone thought about the possibility that they might not have been notified until today? Has anyone seen evidence that RW was notified 2 months ago? This whole thread seems to expect that given 8 hours notice a company can analyze a vulnerability, patch code, do complete regression testing, and release patches.
They are a major player in the wireless market. They've said all major players were notified a couple of months ago. I can't see any possibility where someone forgot a company in the top 5, based on market share.
(Edited)
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
They were given notice at the same time as every other company.
They were given notice at the same time as every other company.
And even if they work, there should be at LEAST one security nerd there who would have seen the initial announcement and started salivating at figuring out what the root of the vulnerability was. As has been noted, some vendors even broke "embargo" and fixed this more than a month ago (OpenBSD was scolded, Mikrotik apparently was not). If Ruckus doesn't have one of "those guys", god help us.
Here's what the message to management should be, and it should STING:
Here's what the message to management should be, and it should STING:
- Ubiquiti had a fix before you
- Ubiquiti sent an email blast to customers before you informing them of the vulnerability and the fix
- Mikrotik had a fix before you - yes, the Latvians beat you too
- Both companies called out above are seen as barely beyond consumer grade stuff in some circles (and in some Ruckus sales pitches)
- All the enterprise vendors had a fix out before you (but Ubiquiti is the one that should embarrass you)
- Many of your customers read about this elsewhere and are aware that you had the information about this problem in-hand back in August
Michael Brado, Official Rep
The first official advisory is from our Cloudpath ES Security product team:
https://support.ruckuswireless.com/documents/2039-faq-security-advisory-cp-101617-802-11r-vulnerabil...
https://support.ruckuswireless.com/documents/2039-faq-security-advisory-cp-101617-802-11r-vulnerabil...
(Edited)
I don't mean to pile-on, now that there is an official response, but...
This advisory is full of grammatical errors, contradictions, and the very first line expresses doubt this is even a problem. Waiting all this time to come out with this just furthers the idea that there was no plan and someone started slapping this response together at 8am this morning.
This advisory is full of grammatical errors, contradictions, and the very first line expresses doubt this is even a problem. Waiting all this time to come out with this just furthers the idea that there was no plan and someone started slapping this response together at 8am this morning.
Michael Brado, Official Rep
New updated copy received from PM and posted, thanks.
Abhi Maras, Employee
Thanks for the comments David. Please note this is a Cloudpath response and Cloudpath is not involved in the 4 way WPA2 handshake. Please do look out for a more comprehensive update that will cover Access Points and Controllers soon.
Is there an ETA for the update to be posted?
Michael Brado, Official Rep
Please view security bulletin posted this afternoon:
https://support.ruckuswireless.com/documents/2040-faq-security-bulletin-101617-wpa2-vulnerability-kr...
https://support.ruckuswireless.com/documents/2040-faq-security-bulletin-101617-wpa2-vulnerability-kr...
Michael, maybe you can clear up some confusion for me on this. In the bulletin above, Ruckus is saying: "No Ruckus products are affected unless deployed in Mesh or Point-to-Point topologies, or
802.11r is enabled."
However, a blog post, also from Ruckus, says the following:
If vulnerabilities exist on both sides of the 4-way handshake, and vendors need to patch them to make them secure (and Ruckus uses WPA)... ??? The blog post and the official statement appear to be contradicting each other. I'd prefer NOT to go back and tell my bosses that I was wrong with what I told them last night.
Thanks,
However, a blog post, also from Ruckus, says the following:
- Vulnerabilities exist on both sides of the 4-way handshake relationship (client and AP) and both sides need to be patched.
- Until client vendors provide updates, disabling 802.11r can help mitigate the attack by eliminating one source of vulnerability (Fast BSS Transitions, otherwise known as 802.11r roaming).
If vulnerabilities exist on both sides of the 4-way handshake, and vendors need to patch them to make them secure (and Ruckus uses WPA)... ??? The blog post and the official statement appear to be contradicting each other. I'd prefer NOT to go back and tell my bosses that I was wrong with what I told them last night.
Thanks,
This is my first touch with Ruckus.
A month ago, I inherited a position in a company where the wireless network is done with 6x Ruckus R500 Wireless APs.
Yesterday I contacted Ruckus support and they promised firmware by the end of the day. I have to say, that first impression I got from Ruckus is not an enterprise class and will probably move to ubiquiti.
A month ago, I inherited a position in a company where the wireless network is done with 6x Ruckus R500 Wireless APs.
Yesterday I contacted Ruckus support and they promised firmware by the end of the day. I have to say, that first impression I got from Ruckus is not an enterprise class and will probably move to ubiquiti.
Well, you better get used to reboot your AP's from time to time then..
I have no problem rebooting APs every now and then. I do have a problem not knowing if/when my network is secure.
Just to be clear here, any Ruckus update will not secure your network. It will fix KRACK vulnerabilities with regards to mesh and the use of 802.11r. There are much broader steps that are required to ensure your networks are secure like updating all clients to ensure they have had their respective KRACK patches applied, after all the majority of the vulnerabilities are client based. You should also look at implementing an WIDS/WIPS system (be it the embedded solution of a controller or standalone) to alert against malicious rougue AP's as this will be a tell tale sign of a potential attack using KRACK.
Here is a good URL on availability of client device patches: https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/
Here is a good URL on availability of client device patches: https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/
Patching APs against vulnerabilities is a part of a network security. I don't see Ruckus delivering.
(Edited)
Robert, it doesn't matter if they own the whole picture or not, they have demonstrated they don't care about ANY of it.
I think you're being a little harsh here. Yes they were late to the party with regards to an announcement vs many of the other enterprise vendors. However, they are not the only ones who are yet to release patch firmware. Cisco for example has currently only one level of controller firmware with a fix for all AP types, 8.3.130.0. All others show as TBD. If i have something in the next day or so then i will be satisfied (not happy) about the response time on firmware but i still find the delay on an announcement, especially when it didn't include a date/time for firmware release to be unacceptable.
I don't think he is too harsh here, cause the are sitting on it since july. Yes he should blame cisco also but we are here about ruckus. As I wrote I have some expection to an enterprise support:
1. No out of office notification if someone mails to your security contact ([email protected])
This E-mail has to go to an high priorized and monitored queue in an ticket
system,
2. That your support people and partners would inform one or two day's before
the public disclosure.
3. That you have the right communication for all your customers ready and put
it in the right time on the right places (webside, newsletter, twitter...)
4. That you have your firmware fixes ready to deploy and if it is possible
some advanced monitoring ready for this issue and for broken clients.
and nothing had happened. If they would know from the problem since yesterday we can discuss, but not sitting since months on it....
1. No out of office notification if someone mails to your security contact ([email protected])
This E-mail has to go to an high priorized and monitored queue in an ticket
system,
2. That your support people and partners would inform one or two day's before
the public disclosure.
3. That you have the right communication for all your customers ready and put
it in the right time on the right places (webside, newsletter, twitter...)
4. That you have your firmware fixes ready to deploy and if it is possible
some advanced monitoring ready for this issue and for broken clients.
and nothing had happened. If they would know from the problem since yesterday we can discuss, but not sitting since months on it....
Yesterday I opened a support case about poor wifi performance after upgrading to the latest firmware. A tech promised to call me today at 3pm. Well, no call at 3pm, 4pm or 5pm. Replied to email I got ([email protected]) and guess what? Got out of office reply! I'm speechless.
Michael Brado, Official Rep
Sorry Kari, bad TSE! Don't make promises you can't keep, but if something did come up today, out of office should direct all current customers to please contact us and ask to be re-queued to TSEs currently on shift to take over!
I can say from experience, that sometimes other reps get copied on your case with Ruckus and I have gotten an out-of-office reply and still got answered.
Sorry Michael, didnt have any reply from Ruckus and could not wait longer. I went ahead and downgraded firmware of my APs. Very very bad mark for Ruckus.
https://forums.ruckuswireless.com/ruckuswireless/topics/r500-slow-troughput-high-latency-high-packet...
https://forums.ruckuswireless.com/ruckuswireless/topics/r500-slow-troughput-high-latency-high-packet...
hi,
I have read the Ruckus Security Advisory and also
https://theruckusroom.ruckuswireless.com/wi-fi/2017/10/16/commonsense-approach-uncommon-problem/ and many other stuff.
This all show ruckus in a very bad light. Can we still trust?
Ruckus was informed many weeks/months ago about this issue and the disclosure date.
But the customers was left alone!!
I was informed since two day's (CET timezone) about this issue. I waited for
the public disclosure yesterday and opened a case at ruckus cause no information
about it was found online.
All other major vendors did have the updates ready and informed their customers
at the same time the issue was going public. They had their communication ready
and send it out to their partners and customers at the right time.
Ruckus didn't they don't even inform the partners!!
What I as customer with contract and as partner has expected:
1. No out of office notification if someone mails to your security contact ([email protected])
This E-mail has to go to an high priorized and monitored queue in an ticket
system,
2. That your support people and partners would inform one or two day's before
the public disclosure.
3. That you have the right communication for all your customers ready and put
it in the right time on the right places (webside, newsletter, twitter...)
4. That you have your firmware fixes ready to deploy and if it is possible
some advanced monitoring ready for this issue and for broken clients.
What I now expect:
1. really fast update availability, even for older systems and without contract*
2. transparent communication what went wrong and why
3. better documentation and reporting how to fix the problem in our company's,
not even on the wireless system side:
* How to detect clients with this problem
* For which clients are updates available
I'm located in germany, the public disclosure was now nearly 24hour away,
even the radio stations here broadcast informations about this issue faster
then you.
At this morning the German Federal Office for Information Security has send out
an public announcement that all people should update their clients and
accesspoints / routers if possible or contact their vendors for updates.
The phones are ringing with customers, cto's and so on. All want to have a
status about this issue and a dead line then it is fixed.
Yes the major problem are the client's, but the accespoints and controllers
should be fixed also and I expect that I get some help from my wireless system
to detect the problem on the clients if I have a managed wireless solution
not one single accesspoint.
Our company has already rolled out the patcheѕ for our clients.
Even microsoft has the patches already in place.
For me it looks like ruckus has ignored the advisory and now the
try to react on it. This has nothing todo with enterprise support!!
There is absolute no excuse for this!!
For me the trust in your security support is gone, and there must
be very good arguments that we will stay with ruckus after our contract
ended.
* cause how it was happend (see what I expected)
I have read the Ruckus Security Advisory and also
https://theruckusroom.ruckuswireless.com/wi-fi/2017/10/16/commonsense-approach-uncommon-problem/ and many other stuff.
This all show ruckus in a very bad light. Can we still trust?
Ruckus was informed many weeks/months ago about this issue and the disclosure date.
But the customers was left alone!!
I was informed since two day's (CET timezone) about this issue. I waited for
the public disclosure yesterday and opened a case at ruckus cause no information
about it was found online.
All other major vendors did have the updates ready and informed their customers
at the same time the issue was going public. They had their communication ready
and send it out to their partners and customers at the right time.
Ruckus didn't they don't even inform the partners!!
What I as customer with contract and as partner has expected:
1. No out of office notification if someone mails to your security contact ([email protected])
This E-mail has to go to an high priorized and monitored queue in an ticket
system,
2. That your support people and partners would inform one or two day's before
the public disclosure.
3. That you have the right communication for all your customers ready and put
it in the right time on the right places (webside, newsletter, twitter...)
4. That you have your firmware fixes ready to deploy and if it is possible
some advanced monitoring ready for this issue and for broken clients.
What I now expect:
1. really fast update availability, even for older systems and without contract*
2. transparent communication what went wrong and why
3. better documentation and reporting how to fix the problem in our company's,
not even on the wireless system side:
* How to detect clients with this problem
* For which clients are updates available
I'm located in germany, the public disclosure was now nearly 24hour away,
even the radio stations here broadcast informations about this issue faster
then you.
At this morning the German Federal Office for Information Security has send out
an public announcement that all people should update their clients and
accesspoints / routers if possible or contact their vendors for updates.
The phones are ringing with customers, cto's and so on. All want to have a
status about this issue and a dead line then it is fixed.
Yes the major problem are the client's, but the accespoints and controllers
should be fixed also and I expect that I get some help from my wireless system
to detect the problem on the clients if I have a managed wireless solution
not one single accesspoint.
Our company has already rolled out the patcheѕ for our clients.
Even microsoft has the patches already in place.
For me it looks like ruckus has ignored the advisory and now the
try to react on it. This has nothing todo with enterprise support!!
There is absolute no excuse for this!!
For me the trust in your security support is gone, and there must
be very good arguments that we will stay with ruckus after our contract
ended.
* cause how it was happend (see what I expected)
Amen to that.
Yes, they could have been out faster - but as the statement now say, it's only an issue if you turned on 802.11r on your SSID's or use Mesh networks (which, I hope, you don't).
How can you ask Ruckus to list what clients are affected??
Calm down, and be professional - there has been tons of security issues in IT in the past, and the world is not ending due to that.
If you have customers that rely on WPA only, then they deserve to be under attack.
How can you ask Ruckus to list what clients are affected??
Calm down, and be professional - there has been tons of security issues in IT in the past, and the world is not ending due to that.
If you have customers that rely on WPA only, then they deserve to be under attack.
I"m sorry, but I don't agree with this. No one in this thread has asked Ruckus to list what clients are affected. The issue most have is Ruckus took so long to even acknowledge there was an issue.
@Steven.
Yes, the post above, in which this is a reply to, asks:
Yes, the post above, in which this is a reply to, asks:
* How to detect clients with this problemRuckus can never be the one to provide that info.
* For which clients are updates available
btw there is github repo maintaining a list of vendor responses: https://github.com/kristate/krackinfo . Go to Vendor Response Matrix and see client updates.
Regards,
Alex
Regards,
Alex
I think there should be a way, have you taken a look what other vendors do:
Q: Can I detect if someone is attacking my network or devices?
A: Aruba software checks for replay counter mismatches on a per
client basis and will produce a log message if detection is triggered. The log message begins with “Replay Counter Mismatches“, followed by additional details.
Aruba has also released new RFProtect (WIDS) features and signatures to help detect attacks.
for example.
Also it should be no problem to build a list with patches for the major systems
and publish them.
If I read this right:
"Here, the client will install an all-zero encryption key instead of reinstalling the real key."
They work with an all-zero key can this not be detected from the wirless system?
Q: Can I detect if someone is attacking my network or devices?
A: Aruba software checks for replay counter mismatches on a per
client basis and will produce a log message if detection is triggered. The log message begins with “Replay Counter Mismatches“, followed by additional details.
Aruba has also released new RFProtect (WIDS) features and signatures to help detect attacks.
for example.
Also it should be no problem to build a list with patches for the major systems
and publish them.
If I read this right:
"Here, the client will install an all-zero encryption key instead of reinstalling the real key."
They work with an all-zero key can this not be detected from the wirless system?
"Be professional ... If you have customers that rely on WPA only, then they deserve to be under attack."
Wow Jakob, do you work at Ruckus?
I appreciate they finally took the time to tell us not to worry about anything unless you use features that are turned off by default, or mesh networking </sarcasm>. Thanks for assuming most costumers don't care as they would rarely deploy a mesh network, right?
https://www.ruckuswireless.com/rucktionary/mesh-networking-and-smartmesh
http://www.ruckussecurity.com/Smart-Mesh-Networking.asp
http://ruckus-www.s3.amazonaws.com/pdf/appnotes/bpg-wireless-mesh.pdf
You can't flaunt it and be proud of this as a value add, and then chastise customers for using it when there's a security issue you have no urgency to address.
Wow Jakob, do you work at Ruckus?
I appreciate they finally took the time to tell us not to worry about anything unless you use features that are turned off by default, or mesh networking </sarcasm>. Thanks for assuming most costumers don't care as they would rarely deploy a mesh network, right?
https://www.ruckuswireless.com/rucktionary/mesh-networking-and-smartmesh
http://www.ruckussecurity.com/Smart-Mesh-Networking.asp
http://ruckus-www.s3.amazonaws.com/pdf/appnotes/bpg-wireless-mesh.pdf
You can't flaunt it and be proud of this as a value add, and then chastise customers for using it when there's a security issue you have no urgency to address.
That blog post ("the ruckus room") is embarrassing. They don't even mention if they have a fix in the pipeline. Telling their customers who use "mesh" to "turn it off" is stupid. It's a feature, don't be surprised if people use it.
That blog post ("the ruckus room") is embarrassing. They don't even mention if they have a fix in the pipeline. Telling their customers who use "mesh" to "turn it off" is stupid. It's a feature, don't be surprised if people use it.
Does anyone know how 7731 bridges are affected by this?
Michael Brado, Official Rep
For 7731, P300, and mesh deployments, there is noknown workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,CVE-2017-13080, and CVE-2017-13081. However, because Ruckus products useCCMP for Mesh and bridging connectivity, exploitation of these vulnerabilities ismade significantly difficult, as per Section 6.1 of the KeyReinstallation Attacks: Forcing Nonce Reuse in WPA2 report.
Regarding 7731: So there goes an otherwise fully functional, still going strong, work horse bridge between our two offices? Discontinued product = no patch?
Or..?
Or..?
The 7731 has reached End of Sale but has NOT reached the End of Software Development. Ruckus owes us a patch for the 7731's.
I would like an update on this for the 7731 as well. The Security Advisory only mentions a patch for the P300, nothing about the 7731.
They've updated the bulletin to include the 7731. No date set for the fix but it is on the list.
https://ruckus-www.s3.amazonaws.com/pdf/security/faq-security-advisory-id-101617-v1.2.txt
https://ruckus-www.s3.amazonaws.com/pdf/security/faq-security-advisory-id-101617-v1.2.txt
I'm sure this will not be a popular comment but, I think some of these comments are blown way out of proportion. I also am not happy about Ruckus's delay of response and available firmware updates given the lead time they've been given. But they don't have it. I wouldn't apply the new code immediately anyway until some of you bled on it. I'm willing to bet that most of us have bigger security issues to deal with than a proof of concept hack on a single device, which requires them to be physically on-site, setup a rogue AP and write there own code for the exploit, as the code to exploit the vulnerablity isn't in the wild, then they might gain access to someones facebook feed. LOL
In addition can I borrow some of your budget dollars so I can jump vendors whenever I'm unhappy with their performance. Thats a luxury that I cannot afford, time or money wise. :)
In addition can I borrow some of your budget dollars so I can jump vendors whenever I'm unhappy with their performance. Thats a luxury that I cannot afford, time or money wise. :)
I hope you don't work in an industry where you need to meet compliance or privacy regulations Todd, because the effort or proximity required for the attack doesn't mean anything at all to the overseeing organizations. I would imagine folks interested in taking advantage of this already have a wifi pineapple and a kali linux machine - maybe even some code to work off of now that smarter nerds know exactly how this all works. It's not hard to make a business case to deploy new WAPs when you already own the expensive ones from the vendor that is slow to respond to security incidents.
Hi Jesse, please don't take this comment as me defending Ruckus, it isn't, but if you are 'unlucky' enough to work in a sector that requires yo to meet privacy and or compliance regulations then you most likely have a fully functioning and very highly tuned WIDS/WIPS which will give you more protection to this issue than some of the other guys posting on here.
On the basis that all this vendor bashing seems to be falling on deaf ears, on the basis that no one other than Michael from the vendor has bothered to comment on their own forum and we still dont have a patch. I would suggest that the tit for tat between users is pointless.
Remember, we all want the same thing.
Maybe we would be better spending our time offering advice to each other on how to mitigate the threat in the meat time until a patch is released because ultimately, it will come out before anyone on this thread has a chance to switch vendor.
On the basis that all this vendor bashing seems to be falling on deaf ears, on the basis that no one other than Michael from the vendor has bothered to comment on their own forum and we still dont have a patch. I would suggest that the tit for tat between users is pointless.
Remember, we all want the same thing.
Maybe we would be better spending our time offering advice to each other on how to mitigate the threat in the meat time until a patch is released because ultimately, it will come out before anyone on this thread has a chance to switch vendor.
Robert,
I'm not "unlucky" because I have regulations to keep in mind. You would be lucky if your users just browse Facebook all day like Todd. Just because you are subject to regulations doesn't mean you have additional budget/staff to put a WIDS/WIPS in place, they typically spend that on a robust properly configured AP (that gets timely support). In our case we don't administer every customer network post sales cycle. The only thing more frustrating than how Ruckus has handled this is the people trivializing their commitment to the issue and it's resolution.
Follow me here... Their official release plays down the vulnerability and then says:
"Ruckus will be releasing security patches to address all above mentioned vulnerabilities. It is recommended that customers upgrade their network(s) with these patches as soon as they become available."
If it isn't a big deal, and doesn't affect your customers, why patch it at all - ever? Because it IS worth fixing... Sometime... When you decide to switch partners in this case, it's not because a patch isn't available at that moment, it's because of the damage done.
I'm not "unlucky" because I have regulations to keep in mind. You would be lucky if your users just browse Facebook all day like Todd. Just because you are subject to regulations doesn't mean you have additional budget/staff to put a WIDS/WIPS in place, they typically spend that on a robust properly configured AP (that gets timely support). In our case we don't administer every customer network post sales cycle. The only thing more frustrating than how Ruckus has handled this is the people trivializing their commitment to the issue and it's resolution.
Follow me here... Their official release plays down the vulnerability and then says:
"Ruckus will be releasing security patches to address all above mentioned vulnerabilities. It is recommended that customers upgrade their network(s) with these patches as soon as they become available."
If it isn't a big deal, and doesn't affect your customers, why patch it at all - ever? Because it IS worth fixing... Sometime... When you decide to switch partners in this case, it's not because a patch isn't available at that moment, it's because of the damage done.
Hi Jesse, apologies if i offended you, my comment was not meant to. There may be a few people trivialising this issue but no more than there are people blowing out of proportion.
This is my opinion:
Is it a valid vulnerability? Yes.
Does it need to be patched? Yes.
Even after the patch is the full threat nullified? Not unless you have 100% governance over every client on your WLAN's and can ensure they are all patched.
Is it relatively difficult to actually take advantage of? Yes.
Even if you are attacked, is it likely to cause a large scale security breach? Unless you are unlucky enough to have them capture traffic on a single MiTM attack for a user who is sending sensitive data upstream on an unpatched client, in an areas serviced by unpatched mesh AP's or a WLAN configured with 802.11r, no.
I appreciate it is annoying, and i have had to answer questions today from my customers about how long it has taken Ruckus to post an advisory and how long it will take for a patch but thats part of being in tech. There's a serious security treat almost every month, this month its WiFi's turn.
Yes Ruckus' comms haven't been what would be expected of a top enterprise WiFi vendor, and im sure that many of us will be having conversations with our reps over the coming days but hopefully they will learn from this.
This is my opinion:
Is it a valid vulnerability? Yes.
Does it need to be patched? Yes.
Even after the patch is the full threat nullified? Not unless you have 100% governance over every client on your WLAN's and can ensure they are all patched.
Is it relatively difficult to actually take advantage of? Yes.
Even if you are attacked, is it likely to cause a large scale security breach? Unless you are unlucky enough to have them capture traffic on a single MiTM attack for a user who is sending sensitive data upstream on an unpatched client, in an areas serviced by unpatched mesh AP's or a WLAN configured with 802.11r, no.
I appreciate it is annoying, and i have had to answer questions today from my customers about how long it has taken Ruckus to post an advisory and how long it will take for a patch but thats part of being in tech. There's a serious security treat almost every month, this month its WiFi's turn.
Yes Ruckus' comms haven't been what would be expected of a top enterprise WiFi vendor, and im sure that many of us will be having conversations with our reps over the coming days but hopefully they will learn from this.
Robert,
None taken really, and I agree with your points above. I think it's another question of industry whether or not the big issue is if you could potentially snoop something significant in clear text to bring down the organization. In our case it isn't really about that.
The thing about regular security threats in IT is that you typically spend your money with folks you expect to fix things in a timely manner and exhibit exceptional communication. I don't think we hit either of those marks as we can both agree. So do you stick with somebody that predominately works in the industry they have a lackluster response in? Is this due to all the mergers, etc that have happened over the past year with them? I don't know, nor frankly do I care. I expect more from the company than device up-time.
None taken really, and I agree with your points above. I think it's another question of industry whether or not the big issue is if you could potentially snoop something significant in clear text to bring down the organization. In our case it isn't really about that.
The thing about regular security threats in IT is that you typically spend your money with folks you expect to fix things in a timely manner and exhibit exceptional communication. I don't think we hit either of those marks as we can both agree. So do you stick with somebody that predominately works in the industry they have a lackluster response in? Is this due to all the mergers, etc that have happened over the past year with them? I don't know, nor frankly do I care. I expect more from the company than device up-time.
@Jesse,If you are in a place where they need secure connections, you don't care about WPA - then you run VPN on top, of use applications that use SSL connections between peers, making sure you don't rely on encryption between the wifi endpoints.Heck, Apple enforced all App-connections to backend servers use SSL encryption, this summer, so you as a customer know that Apps now don't rely on encryption on the wire itself.
Hell, that is what all users do on 99% of all hospitality locations around the world on a daily basis.
We see customers that just moved from WEP to WPA because their old creditcard terminals did not support other than WEP..
So, if it's not more important than that, maybe we should help remind the customers that they need to make sure the Apps they use are secure...
Hell, that is what all users do on 99% of all hospitality locations around the world on a daily basis.
We see customers that just moved from WEP to WPA because their old creditcard terminals did not support other than WEP..
So, if it's not more important than that, maybe we should help remind the customers that they need to make sure the Apps they use are secure...
Jakob,
Don't assume I am only talking about guest wifi. I haven't said anything to imply that.
Do you know how VPNs actually work? I don't often use them inside of the same network over wifi <eye roll>.
That's really the key distinction here... It doesn't matter if they are using WEP/WPA/WPA2... That's not to say it's a good idea to be using anything other than WPA2. The attack surface is still there for properly configured access point(s). Where's my new firmware?
Not every application utilizes encryption to their back end, especially when the service is LAN side. I have said this repeatedly, but it is yet another question of your industry, and what applications you require to operate.
The customers don't typically know anything about their application other than its business value to them and the fact that they need it for operations. Even if they do care, they may not have a choice between secure/insecure applications to provide security over the wire regardless of price.
Don't assume I am only talking about guest wifi. I haven't said anything to imply that.
Do you know how VPNs actually work? I don't often use them inside of the same network over wifi <eye roll>.
That's really the key distinction here... It doesn't matter if they are using WEP/WPA/WPA2... That's not to say it's a good idea to be using anything other than WPA2. The attack surface is still there for properly configured access point(s). Where's my new firmware?
Not every application utilizes encryption to their back end, especially when the service is LAN side. I have said this repeatedly, but it is yet another question of your industry, and what applications you require to operate.
The customers don't typically know anything about their application other than its business value to them and the fact that they need it for operations. Even if they do care, they may not have a choice between secure/insecure applications to provide security over the wire regardless of price.
Jesse,
All I'm saying is: If security is that important for your customers, that they are calling you even before the scope of this vulnerability is out in the open (it's still a lab case), then they should already be using Apps that use SSL communication directly between the client app and the backend.
Oh, and if you've read the krack site, it's mostly a clientside issue
All I'm saying is: If security is that important for your customers, that they are calling you even before the scope of this vulnerability is out in the open (it's still a lab case), then they should already be using Apps that use SSL communication directly between the client app and the backend.
Oh, and if you've read the krack site, it's mostly a clientside issue
I work at a university. Should I tell all our students to use VPN? While for sensitive information requiring VPN use should be done, it's not practical in all situations.
I think another aspect of this is the PR side. When the CIO says they have people asking "does this affect us" it shouldn't require a long explanation of "yes, but only if you're not using VPN, not using secure apps, etc etc.
I think another aspect of this is the PR side. When the CIO says they have people asking "does this affect us" it shouldn't require a long explanation of "yes, but only if you're not using VPN, not using secure apps, etc etc.
Jakob,
You can play Ruckus' cards all you want. "It's still a lab case..." Really? If I could prove there was another WPA2 vulnerability to where you could steal the PSK, but it wasn't in the wild yet, would you expect Ruckus to have a patch before somebody packaged up in a nice little tool for script kiddies? Would you care if you could just update Windows to mitigate the new threat? Apparently you wouldn't, and that makes you incompetent and naive in network security. I won't address your other noise again about apps using SSL.
Nobody is arguing that we shouldn't have to patch our clients, but even they have stated to patch BOTH. Well we can't do that yet. According to the latest word that will be two weeks away at the earliest for 'some' devices. Now we are waiting on a managers response about how everything is just fine, so long as 'xyz' is in place, or not in use. That's not acceptable. If you wanted to reassure everyone of the risks to certain features and the network safety otherwise, that should have been in the day one security brief assuring us of this with an ETA date on the firmware releases and which models.
An example of how to respond correctly (even spelling out which things aren't effected if that's your stance):
https://help.ubnt.com/hc/en-us/articles/115013737328-Ubiquiti-Devices-KRACK-Vulnerability
You can play Ruckus' cards all you want. "It's still a lab case..." Really? If I could prove there was another WPA2 vulnerability to where you could steal the PSK, but it wasn't in the wild yet, would you expect Ruckus to have a patch before somebody packaged up in a nice little tool for script kiddies? Would you care if you could just update Windows to mitigate the new threat? Apparently you wouldn't, and that makes you incompetent and naive in network security. I won't address your other noise again about apps using SSL.
Nobody is arguing that we shouldn't have to patch our clients, but even they have stated to patch BOTH. Well we can't do that yet. According to the latest word that will be two weeks away at the earliest for 'some' devices. Now we are waiting on a managers response about how everything is just fine, so long as 'xyz' is in place, or not in use. That's not acceptable. If you wanted to reassure everyone of the risks to certain features and the network safety otherwise, that should have been in the day one security brief assuring us of this with an ETA date on the firmware releases and which models.
An example of how to respond correctly (even spelling out which things aren't effected if that's your stance):
https://help.ubnt.com/hc/en-us/articles/115013737328-Ubiquiti-Devices-KRACK-Vulnerability
Playing Ruckus' card - Really? Gezus..
All I'm saying is: keep the perspective! This thread is going nuts over how all wifi is suddenly useless, when facts is, it's not!This thread is going nuts over how all security is suddenly compromised and peoples highly secret communications is at risk, and I'm simply pointing out: It the communications it that secret, you should have other security measures in place!
I'm not fond if how Ruckus is handling this either, but stop making the world come to and end over this, when in fact it's not.
All I'm saying is: keep the perspective! This thread is going nuts over how all wifi is suddenly useless, when facts is, it's not!This thread is going nuts over how all security is suddenly compromised and peoples highly secret communications is at risk, and I'm simply pointing out: It the communications it that secret, you should have other security measures in place!
I'm not fond if how Ruckus is handling this either, but stop making the world come to and end over this, when in fact it's not.
I wouldn't say 'the world', I'd say Ruckus' reputation.
Michael Brado, Official Rep
Thank you valued Customers and Partners for your patience as final action plans have been worked out.
(In response to questions such as “where is my patch” and “why is this taking so long”?)
Providing patches for affected products is our first concern and we understand its urgency to your business. We expect patches for most firmware releases to be available on October 30th, with all patches to be completed by November 15th. In the interim, the following steps will minimize risk:
- Disable 802.11rwherever enabled. This step eliminates the short-term need for patches to Ruckus infrastructure in all but the two scenarios described below.
- Enable rogue detectionmechanisms and ensure clients connecting to a rogue AP are de-authenticated.
- Patch client devices asthose patches become available. Unpatched clients will continue to be a risk tonetwork security, regardless of what other steps are taken.
With the above steps taken, two Ruckus use cases and products continue to pose a network security risk: meshed APs and point-to-point links. That risk is minimized through use of rogue AP detection and subsequent corrective action.
Full protection against KRACK will be assured once all infrastructure software has been updated (and 802.11r re-enabled) and all clients have been updated.
Note: Ruckus will provide software updates to anyone requesting them, regardless ofsupport contract status.
(In response to questions such as “where is my patch” and “why is this taking so long”?)
Providing patches for affected products is our first concern and we understand its urgency to your business. We expect patches for most firmware releases to be available on October 30th, with all patches to be completed by November 15th. In the interim, the following steps will minimize risk:
- Disable 802.11rwherever enabled. This step eliminates the short-term need for patches to Ruckus infrastructure in all but the two scenarios described below.
- Enable rogue detectionmechanisms and ensure clients connecting to a rogue AP are de-authenticated.
- Patch client devices asthose patches become available. Unpatched clients will continue to be a risk tonetwork security, regardless of what other steps are taken.
With the above steps taken, two Ruckus use cases and products continue to pose a network security risk: meshed APs and point-to-point links. That risk is minimized through use of rogue AP detection and subsequent corrective action.
Full protection against KRACK will be assured once all infrastructure software has been updated (and 802.11r re-enabled) and all clients have been updated.
Note: Ruckus will provide software updates to anyone requesting them, regardless ofsupport contract status.
(Edited)
Really? Sometime between October 30th and November 15th? Ruckus had known about this for how long? Has Ruckus bothered to see how quickly their competitors got patches out? Impressive to see how succinctly the ball has been dropped here.
Hi Michael,
have you seen my statement to this issue. I think your statement can be the seen as first step to bring it on track. Especially:
"Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status."
Plese take a look at my posting:
https://t.co/uVikcz9kRF
Can you give some statements to this?
Now tthe problem exists that ruckus was not ready for this problem. So let us not do
the fingerpointing let us find solutions. As described in my posting I see some expections:
1. really fast update availability, even for older systems and without contract*
2. transparent communication what went wrong and why
3. better documentation and reporting how to fix the problem in our company's,
not even on the wireless system side:
* How to detect clients with this problem
* For which clients are updates available
You have us shown point 1 about the speed we can discuss but it is
necessary that the patches are stable and working. So If you have startet with
the development too late the dates you announced are fine from my point if view.
Now my points 2 and 3 is missing. Can you tell us something about it and can you make it public please?
To get the trust from your userbase it is necessary to show us what went wrong and why and what will be take in place to prevent this happening the next time.
have you seen my statement to this issue. I think your statement can be the seen as first step to bring it on track. Especially:
"Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status."
Plese take a look at my posting:
https://t.co/uVikcz9kRF
Can you give some statements to this?
Now tthe problem exists that ruckus was not ready for this problem. So let us not do
the fingerpointing let us find solutions. As described in my posting I see some expections:
1. really fast update availability, even for older systems and without contract*
2. transparent communication what went wrong and why
3. better documentation and reporting how to fix the problem in our company's,
not even on the wireless system side:
* How to detect clients with this problem
* For which clients are updates available
You have us shown point 1 about the speed we can discuss but it is
necessary that the patches are stable and working. So If you have startet with
the development too late the dates you announced are fine from my point if view.
Now my points 2 and 3 is missing. Can you tell us something about it and can you make it public please?
To get the trust from your userbase it is necessary to show us what went wrong and why and what will be take in place to prevent this happening the next time.
Note: Ruckus will provide software updates to anyone requesting them, regardless ofsupport contract status.
How exactly would this happen, should I open a ticket for our contract-less ZD5000 controllers, and Ruckus will provide update images?
@Michael Brado
As per your earlier statement "Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status"
Can you please explain the process of how to perform software updates on ZD's with expired contracts. Who we may have to contact etc etc.
I have the following ZD's i'd like to upgrade when the patches are made available approx. Oct 30.
ZD 1106 9.8
ZD 1200 9.9
ZD 1200 9.13
As per your earlier statement "Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status"
Can you please explain the process of how to perform software updates on ZD's with expired contracts. Who we may have to contact etc etc.
I have the following ZD's i'd like to upgrade when the patches are made available approx. Oct 30.
ZD 1106 9.8
ZD 1200 9.9
ZD 1200 9.13
Michael Brado, Official Rep
Hi All,
The WPA2 patch firmware will also be provided to customers who don't currently
have active support contracts, * but you will need to create a "Guest" account on our
Support portal. Please do this in advance if you don't have one now.
All Guest users should to be able to access/read the Ruckus Warranty and Software
License Agreement on our Programs page for example, which is Published with Available
to Anyone status:
https://support.ruckuswireless.com/programs
Login and test the above link, or if prompted to login, please Register with us here:
https://support.ruckuswireless.com/registration
First patch firmware will be made available on Monday (10/30/17). Thanks and best
regards.
The WPA2 patch firmware will also be provided to customers who don't currently
have active support contracts, * but you will need to create a "Guest" account on our
Support portal. Please do this in advance if you don't have one now.
All Guest users should to be able to access/read the Ruckus Warranty and Software
License Agreement on our Programs page for example, which is Published with Available
to Anyone status:
https://support.ruckuswireless.com/programs
Login and test the above link, or if prompted to login, please Register with us here:
https://support.ruckuswireless.com/registration
First patch firmware will be made available on Monday (10/30/17). Thanks and best
regards.
Hi Michael, you say that "firmware will be provided to customers who dont currently have active support contracts" but i see no mention of this in the RN's. So, for example, how would i go about applying 9.10.2 to a ZD that has expired support contract? I cant initiate the upgrade because i have an expired support entitlement file on the controller.
Michael Brado, Official Rep
ZD firmware with WPA2 patches are not restricted to Premium support accounts. Just create a guest account on our Support site to download them.
Licensing/Entitlement that is ordinarily enforced in order to perform an upgrade on a ZD, that checks with our server, will provide No Entitlement Required
for 30 days.
All current ZD customers can take advantage of this opportunity for upgrades.
Please try an upgrade Robert, and confirm you could do so ok? (meaning our 30 days open entitlement is working)
Licensing/Entitlement that is ordinarily enforced in order to perform an upgrade on a ZD, that checks with our server, will provide No Entitlement Required
for 30 days.
All current ZD customers can take advantage of this opportunity for upgrades.
Please try an upgrade Robert, and confirm you could do so ok? (meaning our 30 days open entitlement is working)
(Edited)
Thanks Michael, I'll get this checked out. Just a couple more questions on this if its ok:
When did the 30 days timer start?
For the entitlement check, what if the ZD doesn't have access to check with the server and the local license file has expired?
Realize im throwing curve balls but we have multiple customers who all have very different scenarios.
When did the 30 days timer start?
For the entitlement check, what if the ZD doesn't have access to check with the server and the local license file has expired?
Realize im throwing curve balls but we have multiple customers who all have very different scenarios.
I thought I'd update my question with my own answer and explain the process I had to perform on the ZD's without support contracts so I could patch them for the krack attack.
I contacted Ruckus Support via https://support.ruckuswireless.com/contact-us I started an online chat session and explained the scenario. The rep I originally spoke to said he would have to escalate it to the engineers and someone would contact me. Within a very short period of time (can't recall but it was fast), someone reached out to me via email to let me know they'd contact me by phone in 15 mins. I explained the situation, then replied to their original email with my ZD serial numbers.
They replied a short time later with 3 entitlement files (aka support contracts) and I could upload those to the Administer >> Support tabs on each ZD.
Two of the entitlement files were for one day only (they were the oldest ZD's I had without a support contract. I had to follow the support path which mean updating from 9.8.x -> 9.9.x ->9.10.x -> 9.12 -> 10.0.1.0 (or something very similar, refer to the update documents to see the exact path you need to follow)
The rep told me they would expire in one day whether or not I would use them and he wanted me to perform the first update with him over the phone so he knew it was going to work. Once I performed the first update successfully I let the rep go so I could let him assist other people. It took a bit of time to follow the support path but I was able to successfully upgrade the ZD's without support contract thanks to the Support Team at Ruckus.
The ZD's support contract expired on the next day but everything was up to date. The third support contract was for a bit longer, but none of them was for 30 days.
I have to say, I am not a fan of the 10.0.x UI... I really miss the dash board with all the important info like Serial Number, Software Version, Up Time and the customized widgets we could setup. The important factor is the systems are now protected.
Regardless, the updates were successful thanks to Ruckus for letting us do that!
I contacted Ruckus Support via https://support.ruckuswireless.com/contact-us I started an online chat session and explained the scenario. The rep I originally spoke to said he would have to escalate it to the engineers and someone would contact me. Within a very short period of time (can't recall but it was fast), someone reached out to me via email to let me know they'd contact me by phone in 15 mins. I explained the situation, then replied to their original email with my ZD serial numbers.
They replied a short time later with 3 entitlement files (aka support contracts) and I could upload those to the Administer >> Support tabs on each ZD.
Two of the entitlement files were for one day only (they were the oldest ZD's I had without a support contract. I had to follow the support path which mean updating from 9.8.x -> 9.9.x ->9.10.x -> 9.12 -> 10.0.1.0 (or something very similar, refer to the update documents to see the exact path you need to follow)
The rep told me they would expire in one day whether or not I would use them and he wanted me to perform the first update with him over the phone so he knew it was going to work. Once I performed the first update successfully I let the rep go so I could let him assist other people. It took a bit of time to follow the support path but I was able to successfully upgrade the ZD's without support contract thanks to the Support Team at Ruckus.
The ZD's support contract expired on the next day but everything was up to date. The third support contract was for a bit longer, but none of them was for 30 days.
I have to say, I am not a fan of the 10.0.x UI... I really miss the dash board with all the important info like Serial Number, Software Version, Up Time and the customized widgets we could setup. The important factor is the systems are now protected.
Regardless, the updates were successful thanks to Ruckus for letting us do that!
Hi Michael, so i have an old lab ZD5000 that is running 9.8.2.0 build 15. I can go direct to 9.10.2.0.53 so i have to go via a 9.9 load. This seems to be being blocked at the moment.
Thanks Jeff, im a bit concerned with the 1 day support file as this means we have to contact support on the day that we plan to do the upgrade and get the file before we can start but if we have a scheduled upgrade window this puts unnecessary pressure on. Will give it a shot and see how it goes!
The rep from Ruckus said if the support contract expired before we could upgrade the ZD's to just contact them again and they can extend the support contract for a bit longer with a new entitlement file.
We do residential homes and small businesses so the impact wasn't high risk to our clients. The businesses knew it was important enough that a 4 minute or less interruption was worth the small downtime.
The third ZD support contract was extended for longer than a day (not saying how much longer)... not sure if this was a mistake but don't want to get the rep into trouble if he extended past the time frame he was suppose to create it for. It's for our lab ZD so it will be put to good use.
We do residential homes and small businesses so the impact wasn't high risk to our clients. The businesses knew it was important enough that a 4 minute or less interruption was worth the small downtime.
The third ZD support contract was extended for longer than a day (not saying how much longer)... not sure if this was a mistake but don't want to get the rep into trouble if he extended past the time frame he was suppose to create it for. It's for our lab ZD so it will be put to good use.
Thanks again Jeff, the majority of our customers are hotels so the outage will be longer and our window for upgrade will be fixed.
Appreciate your responses as someone who has been through the process.
Appreciate your responses as someone who has been through the process.
Michael Brado, Official Rep
Hello, our VP announced overnight that the ZD entitlement server will allow upgrades thru January 31st, 2018.
This should be active now Robert and community.
This should be active now Robert and community.
Michael Brado, Official Rep
Greetings,
Ourdevelopers/QA beat the projected schedule for a WPA2 KRACK fixed version
of ZoneFlex for the 7731 PtMTPbridges. These files are now available for download
from the Support portal at theseURLs. The KRACK Support Resource Center has also
been updated with this releaseinformation.
ZoneFlex 7731 Release9.2.0.0.181 (GA Refresh6) Release Notes:
https://support.ruckuswireless.com/products/20-zoneflex-7731#documents
ZF7731 Firmware 9.2.0.0.181(+WPA2 KRACK patches):
https://support.ruckuswireless.com/software/1546-zf7731-firmware-9-2-0-0-181-wpa2-krack-patches
Ruckus Wireless KRACK SupportResource Center:
https://support.ruckuswireless.com/krack-ruckus-wireless-support-resource-center
Ourdevelopers/QA beat the projected schedule for a WPA2 KRACK fixed version
of ZoneFlex for the 7731 PtMTPbridges. These files are now available for download
from the Support portal at theseURLs. The KRACK Support Resource Center has also
been updated with this releaseinformation.
ZoneFlex 7731 Release9.2.0.0.181 (GA Refresh6) Release Notes:
https://support.ruckuswireless.com/products/20-zoneflex-7731#documents
ZF7731 Firmware 9.2.0.0.181(+WPA2 KRACK patches):
https://support.ruckuswireless.com/software/1546-zf7731-firmware-9-2-0-0-181-wpa2-krack-patches
Ruckus Wireless KRACK SupportResource Center:
https://support.ruckuswireless.com/krack-ruckus-wireless-support-resource-center
Cannot download the update from my guest support account due to :
"That file is only available to Premium Support users."
despite Ruckus statement "Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status".
Am I missing something or have Ruckus not made the file available?
"That file is only available to Premium Support users."
despite Ruckus statement "Note: Ruckus will provide software updates to anyone requesting them, regardless of support contract status".
Am I missing something or have Ruckus not made the file available?
Max O'Driscoll, AlphaDog
I'm guessing you have to do the "requesting" bit.
Michael Brado, Official Rep
Hello, my mistake when I posted the 7731 code yesterday. No premium support
contract required, but you do need to have a guest account / be registered.
The access permissions are corrected now. Please try your download again.
Thanks and best regards.
contract required, but you do need to have a guest account / be registered.
The access permissions are corrected now. Please try your download again.
Thanks and best regards.
(Edited)
Interested to know if anyone has had any response from Ruckus about older versions of code and if patches will be available. Their official announcement on when a patch will be available only goes back to 9.10
https://support.ruckuswireless.com/krack-ruckus-wireless-support-resource-center?_ga=2.221041560.149...
https://support.ruckuswireless.com/krack-ruckus-wireless-support-resource-center?_ga=2.221041560.149...
Do you have anything running that will not support 9.10?
Edit: Would be if you have ZoneFlex 7025 AP's running...
Edit: Would be if you have ZoneFlex 7025 AP's running...
(Edited)
Yes, i know of a couple of customers which are 9.7 and also do not have software support.
And if Ruckus provide an upgrade for free to 9.10, your only concern is: Are there any AP's running on their systems that is not supported on 9.10..
If upgrade to 9.10 is free. My concern is how to get the customer to 9.10 if they have unsupported AP's like 7025. Especially as there is no longer the 7055 which was a halfway house in the respect that it was supported on older versions and spanned the gap to H500.
I guess you will have to reach out to Ruckus when it's released on monday, if the path is not clear, and your customers are stuck on old systems.Or you have to explain your customers that they are on many-year-old systems that is simply way out of support.. and should be written off years ago.
Jakob, im curious why you say they should have been written off many years ago when you know nothing about the use case of the networks. What makes you think that a customer should upgrade their wireless infrastructure just because the manufacturer decides that they will drop support for hardware they have replaced if it is still performing the job that it was purchased to do?
If they have 7025 AP's, it was End Of Sale'd on may 31 2015, end EOL'ed nov. 30 2014.That is 3 years ago.While 'the job they were bought to perform' might still be valid, you've known for 3 years that this product is EOL.Your luck, though, is that the model is still under support for another year - have they bought support? You write: No.
If Ruckus put's out upgrades for systems without valid support contracts, they are in luck - but you've gotta admit:
1: They are on 3+ year old system2: They have not bought into support
How in the world do they think they can expect support?
Anyway, they 7025 does not even, as far as I know, support 802.11r, so they flaw is not even on their system!They have to make sure the clients are updated.
If Ruckus put's out upgrades for systems without valid support contracts, they are in luck - but you've gotta admit:
1: They are on 3+ year old system2: They have not bought into support
How in the world do they think they can expect support?
Anyway, they 7025 does not even, as far as I know, support 802.11r, so they flaw is not even on their system!They have to make sure the clients are updated.
Reg. 'written off'.
Here in Europe, at least, it's common practice to make sure IT equipment is written off within 3 years. You simply budget with a replacement after 3 years.You can hope not to have to spend the budget, but it's good practice to have the budget.
Here in Europe, at least, it's common practice to make sure IT equipment is written off within 3 years. You simply budget with a replacement after 3 years.You can hope not to have to spend the budget, but it's good practice to have the budget.
And will you be replacing all of the newly installed AC Wave 1 installations in 2 years time when Ruckus drops support for the full range after AX is released?
Whether they have support or not is irrelevant if the hardware is stopping them from upgrading.
Jokob, i'm based in the UK and have worked enough around Europe to know that it is not common place at all. Maybe in certain verticals, large enterprise for example, yes. But a blanket statement that its common place for the budget to replace IT equipment every 3 years, especially if still functioning perfectly adequately, i find hard to believe.
There are other flaws that just 802.11r. There is Mesh and there is the option on the wireless vendor to introduce additional measures in AP firmware to mitigate client side vulnerabilities by rejecting variations in the replay counters from that stored by the AP for example. As far as I know Ruckus hasn't confirmed exactly what will be released as part of the patch yet. You cant always ensure all clients are updated especially with guest networks.
Anyways, we are getting away from the point here, my question was simply to ask if anyone had had conversations with Ruckus about older versions of firmware that 9.10.
Whether they have support or not is irrelevant if the hardware is stopping them from upgrading.
Jokob, i'm based in the UK and have worked enough around Europe to know that it is not common place at all. Maybe in certain verticals, large enterprise for example, yes. But a blanket statement that its common place for the budget to replace IT equipment every 3 years, especially if still functioning perfectly adequately, i find hard to believe.
There are other flaws that just 802.11r. There is Mesh and there is the option on the wireless vendor to introduce additional measures in AP firmware to mitigate client side vulnerabilities by rejecting variations in the replay counters from that stored by the AP for example. As far as I know Ruckus hasn't confirmed exactly what will be released as part of the patch yet. You cant always ensure all clients are updated especially with guest networks.
Anyways, we are getting away from the point here, my question was simply to ask if anyone had had conversations with Ruckus about older versions of firmware that 9.10.
(Edited)
I find this discussion a bit hilarious :-) I've been working in IT in Finland for over 15 years, seen a wide variety of companies from small to large. It's highly unlikely to replace wlan APs every three years. Or switches, or storage arrays or servers. Laptops and mobile phones usually.
Anyways, I bought Asus RT-N56U for home in early 2011. At first it was missing some nice-to-have functions, which I emailed Asus. And guess what? After a while they released new FW with the featrures I had asked for. And FWs kept on coming. The latest FW was released in March 2017, over 6 years after I bough the device.
Couple of weeks back I emailed Asus asking if they are releasing firmware to address WPA2 krack, and yes, they are although they couldn't give me the date yet. :-) Now that I call customer care. No registrations, no support agreements, just go to the website, download and update. No doubt, my next home AP will be Asus. Not because they'd be technically ahead of others, but because they listen and care about their customers.
Anyways, I bought Asus RT-N56U for home in early 2011. At first it was missing some nice-to-have functions, which I emailed Asus. And guess what? After a while they released new FW with the featrures I had asked for. And FWs kept on coming. The latest FW was released in March 2017, over 6 years after I bough the device.
Couple of weeks back I emailed Asus asking if they are releasing firmware to address WPA2 krack, and yes, they are although they couldn't give me the date yet. :-) Now that I call customer care. No registrations, no support agreements, just go to the website, download and update. No doubt, my next home AP will be Asus. Not because they'd be technically ahead of others, but because they listen and care about their customers.
Michael Brado, Official Rep
We have now posted WPA2 KRACK patched ZoneDirector 9.7.2, 9.8.3, and will have 9.9.1 by 10/22/17, as earlier than 10.x mentioned.
Michael Brado, Official Rep
David Ogden