FYI, As it seems relevant here, below is excerpted from 'Cloudpath FAQ Security Advisory 10-16-17_v2', which posted yesterday.
Best, Rich -=-=-=-=-= How can Cloudpath help? While this issue is severe and must be remediated, please note that there are much easier ways to compromise the network. Below are the steps we recommend you take: 1) If you are using Cloudpath to onboard devices, do redirect users to the portal page that gives them more information about this weakness and urge them to upgrade their BYOD and guest devices to the latest firmware (generating awareness is the important) 2) Via Cloudpath’s device configuration settings, enforce OS auto-upgrade on all IT-owned devices. 3) Via Cloudpath’s workflow branches, identify and redirect more risky devices (Android, Linux etc.) to portal page to perform OS upgrade. You can also check for the firmware version on those devices and limit/block access if the firmware is old. Alternatively, you can put affected devices on a limited guest VLAN or role and even block plain HTTP for those devices. 4) If on a EAP-TLS network, enable server side certificate validation to make sure your clients join the ‘correct’ SSID or network and they do not join a spoofed AP. Do I need to revoke the certificates, are keys compromised? The weakness allows a man in the middle to overwrite the keys in the WAP2 4-way handshake which enables for data visibility and the original keys themselves are not compromised. Because of this we do not think it is necessary to revoke the certificates, however revoking the certificates does force the users to re-onboard and that forces users to accept terms and conditions and also view any notification that you put on the captive portal including limiting access to severely affected devices. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
