| LINUX |
| Moderator |
 |
|
| Joined: May 24, 2004 |
| Posts: 404 |
| Location: Caiman |
|
|
 |
|
 |
|
| Code: | Background: We have recently identified a new form of distributed wireless attack that appear to target central wired assets. We have named this ?phlooding? since it creates wireless floods of incoming authentication requests.
Two variations on a common attack model:
1) A series of simultaneous dictionary attacks against wireless APs in different locations launches a high rate of auth/login requests. While not enough to disable any of the individual APs, this created a ?phlood? of authentication requests to the central auth server, which is near the core of the wired network.
The auth server also supports VPNs, remote access and FTP services. If kept busy enough with ?phlooding?, the auth server might be unable to serve other client applications and user access could suffer. A server crash is also possible.
Customers will be able to identify this with two sets of AirMagnet Enterprise alarms. The individual attack points raise ?Dictionary Attack on EAP Method? alerts. The unusual pattern is correlated into a ?Day Zero? attack. Escalation and notification for each alarm can be customized to include SNMP, beeper, pager, IM, event log, syslog, automated wired-side blocking, etc.
2) One variation uses de-authentication attacks against stations (clients) in many locations instead of direct dictionary attack. Groups of legitimate users can be ?bumped off' the Wi-Fi network with a disassociation broadcast attack, dropping their connections and forcing them to re-connect and re-authenticate. Similar to #1 above, this creates a sudden burst of authentication requests.
This attack hits local wireless users (who lose network access) as well as threatening central auth services.
Distinct from #1, customers will see both ?DoS Dis-Assoc broadcast attack? and ?DoS De-Auth broadcast attack? alarms. Similar ?Day Zero? attack notification would be received via email, SNMP, etc ? plus visibility on the console
Discussion : this looks similar to long-standing wired-side attacks that flood servers, overflow buffers, or slow down service responses. Attackers would need some technical sophistication and coordinated timing. This does not require physical wired access to the customer network, but can be launched from outside buildings. (Most wired DDoS is across the public net from outside the corporate firewall.)
Other combinations are possible. This can also be done using 802.1x authentication floods (also known as incomplete authentication request). In this variation, the auth server challenges the client for certificates, but gets no response back from the client ? resulting in wasted server resources. We have also created single instances of attack #2 with less sophisticated tools: knocking everyone off our QA network with RF jammers, 2.4 GHz portable phones, and other non-Wi-Fi noise sources. Phlooding a network would require attackers to use these in a coordinated way.
We are aware of one unrelated case that created this same result: customer changed login passwords for several thousand employees over a weekend. When employees came in Monday morning, auth server was unable to handle request queue. This took several hours to work though.
Possible counter-measures:
Regional/local authentication architecture. Single centralized auth servers are generally easiest to maintain and manage, but are a single point of failure/attack. Even with a host standby system, these maybe vulnerable (since phlooding a downed primary server will roll all phlood traffic to the secondary). Regional or local auth servers (slaves or distributed) reduce this risk.
Certificate- based authentication. Some auth protocols ( TLS , TTLS , MS -CHAP) can reject incorrect/incomplete logins more quickly, since they are looking for certificates. These may withstand higher incoming request rates, and are not vulnerable to dictionary attacks.
Capacity testing. Customer can benchmark server performance thresholds. (Two RADIUS vendor each estimate their servers can handle 100+ requests/ second.) This may be much higher than max incoming rates from a few APs.
Priority queues within auth server. May have the option of setting higher priority for VPNs or other wired request types when the auth server is busy: check with RADIUS/LDAP vendor. This opens up a reverse-phlooding scenario, however, where an attack against VPNs or wired-side assets can block wireless users from connecting.
Throttled or slow AP request rates. Depending on AP vendor and settings, customer may be able to dial down auth request rates or cache user credentials. This may make phlooding impractical except on a large scale. (Consider trade-off of end user time-to-connect on this option.)
None of this reduces end user issues in #2 above. Attackers can still do a DoS attack and knock end users off local wireless connections. To handle this existing case, customers should continue to use existing tools: clear Wi-Fi policies, AirMagnet Enterprise triangulation to locate attackers, real-time alerting/alarming of high-priority intrusion attempts, Laptop and Spectrum Analyzer to track down devices, periodic site surveys to reduce persistent interference, etc.
|
testing ... |
|
Discussions
Tools
Content
Info
Membership:
Latest: 
New Today: 0
New Yesterday: 0
Overall: 9144
People Online:
Visitors: 57
Members: 0
Total: 57
