Occasional Contributor II

Possible Security Flaw - Volunteer request

Currently troubleshooting with Aruba support an issue that may be a security flaw. I would like to verify the security flaw with other equipment/OS version/environments to make sure that it is a general security issue and not something specific to our environment or configuration.


Due to security concerns I would prefer to contact specific individuals that may be interested and have some time to test parameters. Please send me an email if you would like to test. It should not take longer than 1 hour to complete the test and the participants may be anonymous or not. No external connection or internet access is required so nobody will be connecting in to anyone else's network and you will not be required to disclose any internal information, just your findings and results. More than likely you will not need to setup any new SSID's. If you have a secured SSID via WPA encryption and an open SSID such as a Captive Portal or a Guest SSID it should suffice.


The results will remain undisclosed.


My email address: fdlogmein at gmail dot com




Occasional Contributor II

Re: Possible Security Flaw - Volunteer request

We found out what the issues was.
- If you have the "Prohibit IP Spoofing" option disabled (unchecked) in the Stateful Firewall Global settings tab.
- Client A connects to a secured SSID that requires either RADIUS authentication or a PSK authentication.
- Get Client A IP address and assign it to Client B.
- Disconnect Client A and connect Client B on an unsecured SSID with Client A's IP address, such as a Captive Portal SSID.
- Client B will be allowed to pass through traffic as if it were Client A which means Client B would potentially have full access to your internal network.
In our case the issue came up because we have very short DHCP lease times. DHCP IP's were being reassigned within a couple of hours. Legitimate clients appeared to not be able to connect. In fact what was happening was that many guest clients were attempting to connect in to our guest Captive Portal SSID and not authenticating. The IP's of clients that were in the pre-auth captive portal user role were being reassigned to valid internal users that were attempting to connect on a secured SSID. The clients on the secured SSID were being prohibited from communicating on the wireless network because they would have the same privilages as a Captive Portal pre-authentication user role.
Initially we thought this could be a security hole (the size of Nevada) but it is not a problem as long as the "Prohibit IP spoofing" option is enabled.


Search Airheads
Showing results for 
Search instead for 
Did you mean: