Tackling Security Vulnerabilities in VPN-based

Wireless Deployments
* #,1 * * *
Lookman Fazal , Sachin Ganu , Martin Kappes , A. S. Krishnakumar , P. Krishnan
*
Avaya Labs Research
233 Mt. Airy Road, Basking Ridge, NJ 07920, USA
#
WINLAB, Rutgers University
73 Brett Rd, Piscataway, NJ 08854, USA
Email: [email protected], [email protected],{mkappes, ask, pk}@avaya.com

Abstract— Current “best practice” recommendations for known security problems [9]. It is expected that 802.11i-based
enterprise wireless deployments suggest the use of VPNs from a devices will reach the marketplace soon. However, it will take
wireless client for both authentication and privacy. In this paper, a while before 802.11i is widely deployed.
we demonstrate a security issue with such deployments, which we
refer to as the hidden wireless router vulnerability. This Non-routable IP
vulnerability is inherent in the VPN-based wireless LAN addresses here
architecture, and leads to unsuspecting clients becoming conduits
for an attack, exploiting features readily available in popular
operating systems like Windows and Linux. We describe the AP
attack scenario, and possible solutions for both detecting and Wireless
Corporate
locating such hidden wireless routers. Our solutions include a Intranet
Clients
range of possibilities stretching from purely passive to active VPN
probing methods, and Access Point-based solutions. We describe server
our techniques and results of our implementation and AP
Firewalls,
experiments. IDS, etc.
Keywords: Wireless LANs, Security, VPNs, Hidden wireless router,
Vulnerability. Internet

Figure 1. Current Wireless Deployment Strategy

I. INTRODUCTION
With the proliferation of 802.11- cards, and laptops with in- In the meantime, many enterprises are using a VPN-based
built 802.11- chipsets [1], the demand and feasibility of architecture as the “best practice” method to secure their
universal access to wireless networks is a reality. Adequate wireless networks [10][11]. As shown in Figure 1, the wireless
security has been a major issue in the deployment of enterprise and wired networks are separated using a VPN server. Clients
wireless networks. It has been long understood that direct are configured to use WEP to associate with access points
wireless access to the corporate intranet defeats the deployment (APs); however, it is assumed that WEP does not provide any
of security tools like firewalls and intrusion detection systems specific level of security. Upon association, the client obtains a
(IDSs) that are designed to protect the enterprise network from non-routable IP address (e.g., 192.168.1.32) using DHCP. The
the Internet [2]. Wireless is also an easily accessed “open” client then initiates a VPN connection to the VPN server (e.g.,
medium, inviting attacks from anybody physically close to (i.e., 192.168.1.1). The VPN client on the user’s laptop is usually the
within radio range of) the enterprise location. same client that the user employs to access the corporate
network remotely (e.g., from home). After appropriate
Initial deployments of 802.11 networks used wired authentication and key exchanges, a secure tunnel is
equivalent privacy (WEP) to secure communication. It is well established for communication and access to the corporate
understood now that WEP has serious drawbacks and is Intranet. Establishing the VPN requires per-user authentication.
inadequate for security [3][4][5][6]. In response to the need for Clearly, all benefits of VPNs (security, privacy, etc.) are
security in wireless networks, the IEEE 802.11 working group obtained with this setup. In particular, the packets on the air are
instituted Task Group i to produce a security upgrade for the encrypted, and provide as good privacy as IPSec does.
802.11 standard. This new standard, namely 802.11i [7], is
based on 802.1X port-based authentication [8] for users and The VPN-based architecture is motivated by its simplicity,
devices, and addresses most of the issues with WEP. In the ability to deploy using existing hardware and software, and
particular, 802.11i provides per-user authentication, per-session the familiarity of most IT organizations with the underlying
(cryptographically) strong key(s), and other desirable features. technology and tools, namely IPSec/PPTP-based VPNs.
802.11i has undergone some revisions to incorporate fixes to Specifically, most corporations have implemented and gained
1
Portions of this work were done when S. Ganu was visiting Avaya Labs.

IEEE Communications Society 100 0-7803-8533-0/04/$20.00 (c) 2004 IEEE

experience with telecommuter access to corporate networks path the packets take from the laptop to the corporate intranet
over IPSec, and adding wireless access is viewed as only an goes through the Ethernet interface and directly into the
additional profile for an end-user. Most laptops also have IPSec Intranet. Now, assume that this laptop has network address
clients already installed to enable telecommuter access. IPSec
secures only IP traffic, but given the access patterns of most Corporate
users, this is currently not a severe restriction. The changes VPN server
Intranet
needed for implementing the deployment architecture shown in
Private IP
Figure 1 are only incremental, which is also a significant factor LAN; switched
in its favor. While the requirements of 802.11i can be network
implemented as software upgrades on APs, the general
expectation is that performance reasons would necessitate Ethernet A A
hardware upgrades. The current expectation is also that most
enterprises would wait for some time to ensure amortizing the
cost of current 802.11 hardware before considering upgrades.
HWR, H Rogue, R
Therefore, using VPNs to secure enterprise wireless networks
is a viable option and a recommended practice that is and will
be used.
1. Connects via 1. Uses WEP to get
While VPN authentication and encryption mechanisms are Ethernet a private address,
strong, the current architecture remains vulnerable to attacks if 2. Gets a private e.g., 192.168.a.b
the VPN server can be bypassed. In this paper, we describe and address 192.168.c.d 2. Sets next-hop to
demonstrate how the use of dual interface (i.e., wired and for wireless be 192.168.c.d
wireless interfaces) machines, such as standard laptops, can interface.
compromise wireless security if standard operating system 3. Has NAT enabled.
features are intentionally, unintentionally or maliciously
activated. This loophole essentially opens up the network to
attacks such as “war-driving” [12], the “parking lot scenario” Figure 2. The hidden wireless router vulnerability
[2], and attacks from unprotected lobbies and floors in
companies. translation (NAT) enabled on it. (Later in this section, we
elaborate on how this can be easily set up.) Suppose a rogue
The remainder of this paper is organized as follows. In client, R, forwards its packets to H. These packets (and all
Section II we present in detail the vulnerability in the responses) will find their way between R and the corporate
deployment architecture from Figure 1. In Section III we intranet via H, bypassing the VPN server. Since the rogue R
outline several solutions to prevent such attacks. The solutions only needs WEP to associate with an AP and get a private IP
are based on techniques ranging from pure monitoring to active address, it has successfully broken into the corporate intranet.
detection. We also present simple software features that, when We refer to this scenario as the hidden wireless router (or
added to current APs, can help resolve the loopholes. We HWR) vulnerability, since the legitimate laptop H is acting as a
present some simple experiments and practical observations in hidden router with or without its knowledge. Notice that since
Section IV and conclude in Section V. H is simultaneously a legitimate client and a NAT router, the
hidden wireless router vulnerability does not depend on 802.1X
II. THE HIDDEN WIRELESS ROUTER (HWR) being enabled on the Ethernet jacks.
Most wireless devices, and in particular, wireless-enabled The possible seriousness of the vulnerability is
laptops have dual network interface cards (dual-NICs), e.g., compounded by the observation that it is rather trivial to enable
they have an in-built 802.11 chipset and also an Ethernet a dual-NIC laptop to be a NAT router. Many operating systems
adapter for obtaining network connectivity. Many enterprises (e.g., Linux, Windows, etc.) allow users to turn on NAT. Since
provide both Ethernet jacks and an 802.11- network using the many end-clients are Windows machines, we remark on how
architecture from Figure 1 for providing users with network NAT can be enabled to make such a machine a potential hidden
access within their location. Users may connect to an Ethernet wireless router. In Windows (e.g. 2000 and XP versions),
jack, or the wireless network and its VPN server, or both. connection sharing can be enabled on the wired interface with
Usually, the Ethernet jacks are “open” (i.e., require no the wireless interface as the “local network.” This
authentication), but can be enabled for 802.1X authentication. automatically sets an address of 192.168.0.1 for the wireless
Implicitly, the architecture from Figure 1 assumes for its interface. One can then configure the wireless interface to use
security that all wireless clients will access the network through DHCP. This does not remove “internet connection sharing” and
the VPN server, and tries to ensure this by providing users with allows the wireless interface to obtain its address from the
only a non-routable IP address upon association with an AP. DHCP server, completing the setup. (Note that re-configuring
The problem lies in this implicit assumption. Consider the the wireless interface to use DHCP is not essential. In
scenario from Figure 2, where a dual-NIC laptop, H, is particular, as long as both the rogue and the machine H are
associated with an AP and has obtained a private IP address. associated with an AP, the rogue R can assume an IP address in
However, the user has connected the laptop to an Ethernet jack the subnet of client H’s private IP address (e.g., an IP address
and obtained a routable IP address on the wired interface. The of 192.168.0.5) and route packets to H enabling the attack;
these packets will be, under normal circumstances, forwarded

IEEE Communications Society 101 0-7803-8533-0/04/$20.00 (c) 2004 IEEE

from R to H since the APs and the switches connecting them III. POSSIBLE SOLUTIONS TO THE HWR PROBLEM
essentially do Layer-2 forwarding. We observe that it should be In this section, we will describe different approaches to
possible for machines to get set up in this configuration in a tackling the HWR problem, namely monitor-based and Access
number of ways: getting hacked at public networks, via viruses Point-based solutions. While monitor-based solutions are
and worms, a simple misconfiguration by users, not actively aimed at detecting, locating and controlling HWRs in a reactive
adjusting the configuration between home use and corporate manner, Access Point-based solutions are proactive methods
use, etc. In particular, the conceptual hidden wireless router that prevent HWRs from operating at all. It should be noted
problem remains; it is the ease of activating it - potentially that all monitor-based solutions described here could also be
without the user’s knowledge - that makes this a potential high implemented in the Access Points whereas the converse is not
risk. true.
We make some observations related to the HWR As outlined above, the HWR problem stems from two facts.
vulnerability: Firstly, when securing wireless local area networks with a
• First, viewing only the associations and DHCP activity, VPN, a non-authenticated station may be able to associate with
one would not see anything unusual in how the rogue R a wireless Access Point. Secondly, a (legitimate) dual-homed
and the hidden wireless router H are connected to the machine may be connected to both the wireless network and
network; in-built wireless cards in laptops would may forward traffic from the wireless network to the wired
exhibit precisely such an association behavior if the network and vice-versa. Clearly, mandating that wireless
user has left the card in the appropriate profile. clients must either not forward traffic or be connected to the
wired network as well would solve the problem. Software
• Second, the rogue R and the client H do not need to be could be put on clients (e.g., bundled with the VPN clients) to
within radio range; in particular, the packets from the warn users when connection sharing is detected, and such
rogue R should get switched to H over the corporate software could also enforce disabling IP packet forwarding on
intranet switched network connecting the APs. This client machines. However, while client-based solutions provide
indicates that the HWR vulnerability is likely more some deterrent, they can very hard to enforce in a foolproof
serious than the well-understood rogue access point way. Therefore, we will focus our attention on non-client-based
issue that requires an “insider” to have connected an solutions.
unauthorized access point2 to a corporate Ethernet jack.
• Third, we have presented the discussion in the context A. Monitoring-Based Solutions
of two physical interfaces on the laptop, a wired and a In this section, we will present solutions based on
wireless interface, when the VPN client is not used monitoring the traffic in the wireless network. We will refer to
(since the laptop is connected through the wired such devices as sniffers [13][15]. The sniffers may be passive
interface). However, the problem does exist even with and purely listen to the air [13], or they may additionally be
a purely wireless laptop, depending on the VPN client stations in the wireless network.
used for connection. For example, we have observed
that enabling connection sharing on the logical PPTP 1) Detecting HWR
interface with Microsoft’s PPTP client will allow In the HWR scenario, security is compromised since a non-
packets from the (unprotected) private address wireless VPN-authenticated station can gain access to the enterprise
interface to get NAT-routed to the VPN tunnel. (Also network bypassing the VPN server. In other words, VPN-
see Section IV.) However, many VPN clients disallow protected wireless access is “safe” if all traffic from the
split tunneling and will reject packets on the wireless network is getting consolidated at the VPN server
unprotected interface, and should, therefore, not pose since, in this case, traffic from non-authenticated stations is
an issue when the VPN is active (on the wireless dropped. Therefore, monitoring cross-traffic, i.e., traffic from a
interface). wireless station that is not destined to the VPN server but to
another wireless station, is the key to detecting HWRs.
While the focus of this document is on the HWR-scenario,
we would like to mention that similar threats arise if bridging While the cross traffic is similar to ad hoc traffic, it does
or other forwarding mechanisms are used. (An experiment not stand out as such since both stations are operating in the
using a bridge will be described in Section IV.) The solutions infrastructure mode. Cross-traffic can be easily identified by a
in Section III can be easily adapted for these other forwarding sniffer observing only MAC headers of the 802.11-frames. By
mechanisms as well. observing traffic, and communicating amongst themselves, the
sniffers can learn the MAC addresses of all connected wireless
stations and APs. Cross traffic is all traffic in which the source
and destination addresses are wireless stations. Alternatively,
the sniffer could be configured with a list of permissible MAC
destination addresses such as those of the VPN server or
2 address of the gateway to the VPN server. We conclude that a
Note that the rogue access point problem really requires intentional
subversion of corporate policies in getting unauthorized hardware connected sniffer can identify cross traffic even if it is not in possession of
to the network, as opposed to the HWR vulnerability that can arise from, e.g., the WEP-encryption key of the wireless network since the
software misconfigurations. In fact, one could argue that the rogue access frame headers are transmitted in the clear. While a discussion
point is more a wired authentication vulnerability as opposed to a wireless of whether cross-traffic is useful and should be permitted at all
vulnerability that should be tackled by authentication mechanisms like 802.1X
or its derivates.

IEEE Communications Society 102 0-7803-8533-0/04/$20.00 (c) 2004 IEEE

in VPN-secured wireless networks is beyond the scope of this If the APs are instructed to add the MAC address of the HWR
document, we would like to point out that it is also possible to to a list of not-allowed stations and a disassociate message is
identify HWR-traffic in observed cross-traffic if the sniffer can sent to the HWR, it loses connectivity to the wireless network.
WEP-decrypt frames. This can be done using several methods. From the wired side, the network jack that the HWR connects
The sniffers could maintain a mapping between to may be disabled or routers and switches may be instructed
(source/destination) MAC and IP addresses in observed (non- not to forward traffic to this device.
broadcast) frames. A MAC address that occurs with more than
a single IP address indicates that a router may be present. If the Note that detecting and controlling HWRs is to some extent
MAC address is that of a wireless station, an HWR may be related to other issues in wireless LAN security like MAC/IP
present. It is also possible to specify a list of permissible address spoofing and its use in denial of service attacks. While
routers and have the sniffer report any non-specified devices some of the techniques described in this paper may be useful in
that appear to route traffic. Alternatively, if the destination tackling these problems, the discussion of such issues is beyond
(source) IP address is not in a permissible range (e.g., the the scope of this paper.
private IP address range for the wireless network), the source
(destination) MAC can be flagged as a rogue client and the B. Access Point-Based Solutions
destination (source) MAC as an HWR, if located in the While the monitor-based solutions provide protection
wireless network. against the HWR scenario, they are based on reacting to a
detected HWR as opposed to preventing an HWR from
While the approaches discussed above are passive, HWRs operating. If possible, the AP can prevent the HWR scenario by
can also be detected in an active manner, since unlike wired frame filtering based on MAC source and destination address.
NAT scenarios, in the HWR case we have access to the “other As outlined above, the AP may also take into account IP
side of the NAT”, namely the wireless medium and can send addresses such that this approach can either deny all or still
packets to the HWR on this interface. The sniffer in this case is allow cross-traffic. A common objection to AP-based access
associated and tries to establish a connection to a “honey pot” control lists is that they are hard to manage and are not
server in the wired network using a suspected HWR as the scalable. We note that this is not the case with our solution.
gateway. (In other words, the sniffer acts as a rogue client.) If a The list of permissible addresses is limited to a few entries
response is received, the device used as the gateway is (e.g., primary and backup VPN servers) and needs to change
identified as HWR. Furthermore, the “honey pot” can return only if the properties of the VPN server are changed
the IP source address of the received packet. Thus, the IP
address of the wired interface of the HWR is known. The
devices targeted by the sniffer can be all (active) stations or IV. EXPERIMENTS AND OBSERVATIONS
only the stations that have been marked suspect using the We performed experiments on two networks, N1 and N2 in
techniques described earlier in this section. Any device in the different locations. The first network N1 was protected by a
same subnet could also perform this task. The limitation of PPTP-based VPN mechanism, while the second network N2
probing the private address space is that this approach would was protected using an IPSec-based VPN mechanism (with
not capture HWRs that operate with an IP Address outside of split tunneling disabled). Our dual-interface laptop was running
the probed private address range. the Windows 2000 operating system.
2) Locating and Controlling HWRs
After a (potential) HWR has been identified, it is necessary A. Verifying the HWR vulnerability
to locate the HWR and to control it. If a monitor-based We connected laptop H to the wired network and it also
approach is pursued, the HWR can be located by using associated with an AP. The laptop H got a private IP address on
location-estimation techniques based on signal-strength the wireless side and a routable IP address on the wired side,
measurements, as for instance outlined in [14][15][16]. If an both through DHCP. By enabling connection sharing on the
active probing technique as outlined above has been wired interface of H, we turned the device into an HWR using
successfully applied, the HWR may also be located from the the technique outlined in Section II. The rogue station R (in our
wired side. By tracking the known IP address of the wired case, a Linux laptop) also associated with an AP and got a
interface of the HWR, the HWR’s whereabouts can be traced private IP address through DHCP. When not activating the
back to a switch-port/jack-number, which can be resolved to a VPN client on H, the rogue R exploited the HWR vulnerability
location. The IP address may also be mapped to a particular by setting its default gateway address as the IP address of H’s
user through a database. wireless interface. This worked in both networks N1 and N2
and even when R and H were associated with different APs.
The IP address can be used to pop up a message at the
machine or the user (if discovered) can be informed.
B. Exploiting Vulnerability Through Bridging
Sometimes, locating the device, informing the (unsuspecting)
user about the problem and fixing it from the client side may We also used the network bridging feature available in
take some time. In such cases, the HWR should also be modern operating systems for compromising the security of the
immediately disabled by non-client-based methods in order to wireless VPN-architecture. In this case, bridging was enabled
prevent further misuse. In this case, either the wireless or the on device H, between the wireless and the wired interfaces. The
wired network connection of the HWR needs to be disabled. rogue R used H as a bridge into the enterprise network by using
For the wireless side, the MAC-based access control feature as an IP address in the wired IP address space.
implemented in most APs could be used to contain the HWR.

IEEE Communications Society 103 0-7803-8533-0/04/$20.00 (c) 2004 IEEE

C. Effect of Enabling VPN on the HWR Hidden Wireless Router Vulnerability for VPN-secured
In this experiment, we enabled the VPN client on H. In wireless local area networks. We presented methods to detect,
network N2, enabling the VPN client on H disrupted the control and prevent rogue terminals from exploiting this
operation of the HWR. We were also unable to ping H’s vulnerability. Our experimental results show that the behavior
wireless interface on its non-routable IP address, since all of enterprise users might result in a significant number (35% in
packets to the raw interface were dropped by the VPN client. In our test) of legitimately connected wireless terminals being
network N1, activating the PPTP-based VPN did seem to susceptible to becoming HWRs. Furthermore, the
disrupt the operation of the HWR; however, we could still ping implementation of our monitoring-based approach is suitable to
the non-routable IP address on H. After changing the default detect and control HWRs.
route on H to point to the default gateway for the wired subnet, In the future, we plan to incorporate the HWR vulnerability
H again acted as an HWR. detection techniques outlined in this paper into our platform for
monitoring enterprise wireless networks [15]. This prototype
D. HWR with Single Physical Interface implementation will also allow to locate and to deactivate
Inspired by the previous observation, in N2, we HWRs from both the wireless and the wired side.
disconnected H from the wired network and enabled
connection sharing between the PPTP interface and the REFERENCES
wireless interface. Laptop H now had only one physical [1] Intel Centrino, http://www.intel.com/home/notebook/centrino/
(wireless) interface active, with two logical interfaces. We [2] W. Arbaugh, N. Shankar, Y.C. Justin Wan, “Your 802.11 Wireless
found H operating as an HWR in this configuration with Network has no Clothes,” in Proc. of the First IEEE International
packets getting NAT-forwarded from the raw wireless interface Conference on Wireless LANs and Home Networks, December 2001.
to the PPTP interface. When the VPN was disabled and a [3] N. Borisov, I. Goldberg, D. Wagner, “Intercepting Mobile
packet was sent from R, the laptop H even prompted for VPN Communications: The Insecurity of 802.11,” in the Proc. of the 7th Intl.
enablement! Conf. on Mobile Computing and Networking, July 2001.
[4] S. Fluhrer, I. Mantin, and A. Shamir, “Weaknesses in the Key
Scheduling Algorithm of RC4,” in Proc. of the 8th Annual Workshop on
E. Detection of HWR Selected Areas in Cryptography, August 2001.
We also experimented with the monitor-based detection [5] A. Stubblefield, J. Ioannidis, A. Rubin, “Using the Fluhrer, Martin, and
techniques for HWRs as described in Section III.A. Shamir Attack to Break WEP,” in Proc. of the 2002 Network and
Specifically, we used the MAC and IP-address based method to Distributed Systems Security Symposium, February 2002.
detect cross-traffic and HWR-traffic. These methods did find a [6] Geier, Jim, 802.11 WEP: Concepts and Vulnerability, 802.11 Planet,
June, 2002, http://www.wi-fiplanet.com/tutorials/article.php/1368661.
HWR we placed into the network. We also used the active
probing-technique in combination with a “honey pot’’ server to [7] IEEE 802.11i standard, http:// grouper.ieee.org/groups/802/11/Reports/
tgi_update.htm.
detect the HWR. This method did identify the planted HWR
[8] IEEE 802.1x Port-Based Network Access Control standard,
and yielded its wired IP address as expected. http://www.ieee802.org/1/pages/802.1x.html.
[9] A. Mishra and W. A. Arbaugh, “An Initial Security Analysis of the IEEE
F. Estimating the Extent of the Vulnerability 802.1X Standard,'' Tech. Rep. CS-TR-4328, University of Maryland,
In network N2, we probed the wireless non-routable address College Park, February 2002.
space by sending 2 ping packets each spaced 0.2 seconds apart [10] VPN and WEP: Wireless 802.11 Security in a wireless environment,
http://www.intel.com/Ebusiness/pdf/it/wp021306.pdf.
and with a maximum wait of 1 second to each address. We
[11] Michigan Eng. CAEN Wireless Network, http://www.engin.umich.edu
found that 87 addresses responded. Usually, approximately 160 /caen/ network/wireless.
clients are authenticated with the wireless VPN server. As [12] Wireless WarDriving, http://www.personaltelco.net/index.cgi/War-
described earlier, authenticated machines in network N2 do not Driving.
respond to a ping to the raw interface. Therefore we conclude [13] Kismet Wireless Sniffer Homepage, www.kismetwireless.net.
that, in this case, approximately 35% of laptops are associated [14] P. Bahl, V. N. Padmanabhan, “RADAR: An In-Building RF-Based User
with an access point but not running a VPN client leaving them Location and Tracking System,” in Proc. of IEEE Infocom, March 2000.
vulnerable as HWRs, if connection sharing were to be enabled. [15] S. Ganu, A. S. Krishnakumar, P. Krishnan, “Infrastructure-based
location estimation in WLAN networks,” in Proceedings of the 2004
We conclude that the HWR vulnerability is indeed a threat IEEE Wireless Communications and Networking Conference, Atlanta,
to network security for wireless VPN installations that can be Georgia, March 2004.
detected and controlled by the procedures outlined in this [16] P. Krishnan, A. S.Krishnakumar, W. H. Ju, C. Mallows, S. Ganu, “A
paper. System for LEASE: Location Estimation Assisted by Stationary Emitters
for Indoor RF Wireless Networks,” in Proceedings of the 23rd IEEE
Conference on Communicaiton (INFOCOM), Hong Kong, March 2004.
V. CONCLUSION
Wireless VPNs are being increasingly deployed to secure
enterprise wireless networks. In this paper we described the

IEEE Communications Society 104 0-7803-8533-0/04/$20.00 (c) 2004 IEEE