Wireless Vendor Woes and Shame
(c) Ron DuFresne 2002
I heard a fine paper delivered here by Alan Clegg on his efforts to map
the local wireless infrastructure in the Raleigh/Durham/RTP area. Art
Ehuan, with Cisco Systems gave a backup talk on the threats faced and the
tools available to exploit these wireless streams spewing data freely into
the airwaves here. Much of these issues have been the topic of treads
in this and other security lists as well as covered in the various
systems/network security journals. Not having a need at present to
consider or deal with the woes of wireless toys, I have watched these
discussions and disclosures, and gathered together some of the more
enlightening material for the time I have to deal with these new toys
in some manner, if it be only to argue against their deployment in
areas we work and support.
Even though the weaknesses in WEP are now widely known, and some vendors
such as Cisco have developed and are deploying somewhat better proprietary
encryption and authorization protocols for 802.11b , it is shocking
to note and others have identified the lack of vendor accountability and
responsibility in offering these toys with safe default settings and
configurations[0]. Not only that, but manuals are sparse on covering
safe configurations, and most often the user/implementer has to dig deeply
into documentation stashed away on the CDROMS that accompany these
products to find anything on encryption and safe setup of these devices.
As Alan touched on in his talk, and Steven Connelly pointed out in his
preview of this article: "most manuals don't explain what/why there are
different channels and as a result most admins just use the default ones
which in the case of a crowded city is quite detrimental to basic
performance (as shown in Shipley's defcon talk where something like 80% of
the APs in downtown SF were all on the same channel.)" The
emphasis it seems is on plug and pray technology. And the stress on PnP
here is not on it working when plugged, as it most often does anyways, but
the praying that you are not 'discovered' too quickly and exploited for
deploying toys that just are not really safe for the times. As seems
always is the case, technology is out pacing our abilities to deal with
the ramifications of it's deployment. Neither Lucent nor Cisco are
responsible with the tools they are pushing to market as regards safe
default setups and configurations. And, we are unaware of any vendor
offerings that do any better in an accountable and/or responsible manner.
Granted an admin or any other user setting up such equipment and
applications should certainly check their configurations and settings.
Yet, being that this information is tucked far under the documentation
hood, deep enough many without specific insights into the workings of
their new toys, and also considering the weaknesses of WEP and even the
newer proprietary encryption/authentication methods folks like Cisco are
pushing out, the burden rests in the vendor realm to provide safest
default setups possible. Shame on these folks!
Alan pointed out the severity of the "problem" in just our local area by
mapping out not only many private home wireless deployments, also
various corporate ones as well as some local government AP's , many without even WEP enabled, but found at least one
highly visible federal government contractor with a wireless AP deployed,
again, *without* even WEP enabled![1] This even after the 9/11 attacks
and recent supposed focus upon security.
Of course, even with WEP enabled, the way the 802.11b protocol is setup
and the fact that it's spewed into the airwaves means that valuable
network information is leaked in just the management packets. SSID's, IP
address info, and more can be gleaned from only management packets.
There is no protection from passive sniffing of these packets due to
network segmenting and the concept is pretty much not applicable to
wireless Ethernet transmissions. Additionally, neither speaker mentioned
there are known weaknesses in the SNMP implementations of many of these
devices subjecting them to further exploit wireless networks via less
passive intrusion and DDOS attempts.
While most often signals are limited to 300 feet or so, better receiving
antennas can put a sniffer or active attacker miles away. Alan showed one
off the shelf antenna he purchased that gave him up to a 2.5 mile radius.
there are other capabilities that can be even more affective then what Mr.
Clegg demonstrated. Steven Hume at Novell , recently
noted in one of the security mailing lists:
Anyone interested in the Pringles antenna :-
http://www.oreillynet.com/cs/weblog/view/wlg/448
Using this they claim they could get 11mbps over 10 miles!
Mr. Hume additionally pointed folks here:
a good article covers many of the points raised plus more:
http://www.extremetech.com/print_article/0,3428,a=13880,00.asp
This includes additional pointers to wireless mapping efforts in various
other US cities. Afterall, wireless mapping has been going on for
sometime now. The issues related to wireless roll outs have been known and
available for sometime. What the Clegg and Ehuan papers disclose is how
little attention has been paid by NC IT personnel to these issues, even
those tasked with securing their infrastructures. There discussions
were meant as a heads up to those maintaining the network infrastructures
for their prospective organizations. These people either are not paying
attention to the issues and implications of their network roll outs and
ventures, due to time or knowledge/training constraints or lack the
skills to do so. It also demonstrates a failing in many network security
policies for these companies and ineffective network security auditing
procedures and practices. Our key admins and corporate security folks
are lagging by at least a full year to this information and it's
availability! Not that this separates them from those folks tasked with
such matters in various other locations about the country that much.
Alan's findings are pretty much representative of the findings of others
throughout the US in their wireless mapping research, something on the
order of what Jason Costomiris reported a few months back;
From: Jason Costomiris
Subject: My Saturday with Netstumbler...
Date: Tue, 5 Mar 2002 17:06:30 -0500
...
Highlights of my findings:
- Only 23.53% of APs found were using WEP
- 80.77% of Linksys APs used the default SSID, "linksys"
- 2 out of the 3 Apple AirPort base stations had WEP turned on
Detailed findings follow:
Percentage of Total APs by vendor:
Addtron 3 2.52%
AMI 2 1.68%
Agere (Orinoco/Lucent) 47 39.50%
Apple 3 2.52%
Cisco (Aironet) 20 16.81%
D-Link 4 3.36%
Linksys 26 21.85%
Netgear 2 1.68%
SMC 2 1.68%
Other 10 8.40%
--------------------------------------
Total 119
WEP Usage By Vendor:
Clear WEP % Using WEP
Addtron 3 0 0.00%
AMI 2 0 0.00%
Agere 37 10 21.28%
Apple 1 2 66.67%
Cisco 11 9 45.00%
D-Link 4 0 0.00%
Linksys 21 5 19.23%
Netgear 2 0 0.00%
SMC 1 1 50.00%
Other 9 1 10.00%
-----------------------------------------------
Total 91 28 23.53%
APs With Default SSID By Vendor:
Default SSID Other SSID % With Default
Addtron 2 1 66.67%
AMI 1 1 50.00%
Agere 1 46 2.13%
Apple 0 3 0.00%
Cisco 1 19 5.00%
D-Link 2 2 50.00%
Linksys 21 5 80.77%
Netgear 0 2 0.00%
SMC 1 1 50.00%
Other 0 10 0.00%
--------------------------------------------------------
Total 29 90 24.37%
Tracing and tracking these connections is going to be a very difficult
matter for those wishing to seek legal restitution for active intrusions,
considering the MAC spoofing as well as the ability of long distance,
mobile sniffing and attack vectors. Additionally, considering the issue
that these intrusions do not need cross traditional wired boundaries, this
limits logging to primarily the network that would be compromised in such
attacks. Tracing an attacker would require many of the same illegal tools
used to apprehend Mitnick in Raleigh in February of 1995, a task that
required months of research and work for the FBI and various law
enforcement folks across the US during Mitnick's rampage of intrusions of
the period. Tsutomu Shimonura working with authorities, relied upon
illegal, at least then, devices to triangulate and trace Mitnick's
location to the Hotel within the Raleigh area during the manhunt.
Another perspective on information traversing the airwaves comes from an
article in the local papers recently here, The Durham herald Sun, Sunday
April 14 2002, titled: Nanny-cams make homes vulnerable, reprinted from
the New York Times, by John Schwartz. The article relates the current use
of X10 and XCam2 devices being heavily marketed on the web as home
security and small business solutions. These wireless devices are
sniffable in the same fashion as wireless networking devices are,
offering the sniffer full video feedback, they incorporate no encryption
what-so-ever. The authors talked to Clifford S. Fishman a law professor at
the Catholic University of America and an author himself of a leading work
on surveillance law, Wiretapping and Eavesdropping. Professor Fishman
mentions there are clear laws on such eavesdropping, most current laws
deal with the interceptions of sound, not video, and most are geared
towards the telephone systems and their signal processing. While I'm
certainly not a lawyer, a quick review of current state law here in North
Carolina shows most criminal computer laws are also geared more towards
wired technology. This suggests that any attempts to prosecute the
interception and or interference of wireless technology might well be
precedent setting, and certainly difficult to enforce on those passively
sniffing traffic from parking lots or roadways as Mr. Clegg's mapping work
in this area and the work of others in various parts of the country. Not
to mention that the vast majority of computer related intrusions and
"interferences" never make it to the attention of those enforcing the
laws in existence.
This last fact is partially related to the high damage costs that must be
shown to get the legal authorities to take note and action, and partially
dues to how few officers handle already high case-loads in computer
criminal activity . Also, many companies do not wish their
security intrusions to be aired publically, which often happens when such
incidents are reported to legal enforcement authorities, leading to the
oft discussed lack of trust of those institutions to deal with such
matters in less then corporately embarrassing manner. Then again, as
already stated, even when intrusions cross different physical boundaries
they are hard enough to trace via wired systems. Few network/systems
crackers really make it before the legal system to be dealt with. It's
all quite disheartening as one delves into the issues and ramifications,
especially when, as is quite often witnessed, these criminals end up
rewarded for their illegal actions with jobs and contracts, often from the
very firms and organizations they have violated.
VPN tunnels are often suggested to help overcome some of the ills of wired
as well as wireless connectivity. And while I agree, I'm going to add a
rant that has become common in alot of talks and papers I have been
putting forth recently. VPN's work very well, when both systems
incorporate secure policies at both ends of the tunnel. We are talking
about the 'weakest link in the security chain' issue here. Far to
frequently I have recently been observing users tunneling into their
company LANS via VPN tunnels without any anti-viri software on the remote
system. Additionally I've seem these same systems not closing routes
outside the tunnel to other external resource. These are home and laptop
systems running no personal firewall systems, that are connecting directly
to the Internet outside the tunnels domain and the protection of the
remote LANS security devices and their corporate security polices.
In such situations my route into the corporate LAN, where I an attacker
would be via these exposed and unprotected systems. I gain control of the
client side of the VPN and then use it's open tunnel to enter the
corporate resources. I'd look exactly like the user with permission to do
so, and this would likely not attract much attention because that users
system, though under my control, is allowed such access. VPN tunnels on
laptops and home systems that do not incorporate secure practices and
policies on the client systems are basically open backdoors for exploit.
Mr. Ehuan's discussion concluded with a number of strategies to help lock
up wireless communications to a degree, and they were all well and
good. Many of those are additionally covered in the referenced links
for this paper. I'll leave it to the reader to do their research and
identify these practices and procedures for themselves. Yet, it must
be restated here that since the management packets still traverse the
airwaves in clear text, even if encryption is enabled and VPN tunnels are
provided for bridging the corporate firewall, and as there are no real
boundaries upon those transmissions like we see with wired subnets, there
is still a large amount of information leakage with the 802.11b protocol
and these toys on the market. This is probably what prompted the
following article on Lawrence Livermore National Laboratory's decisiveness
on wireless LANs:
SANS NEWSBITES The SANS Weekly Security News Overview Volume 4, Number 6
February 6, 2002
--31 January 2002 Lawrence Livermore Bans Wireless LANs
Lawrence Livermore National Laboratory, a national defense technology
research lab in California, has banned the use of wireless local area
networks (LANs) due to security concerns. A lab spokesman said that
Los Alamos National Laboratory might introduce a wireless network
ban as well.
http://cgi.zdnet.com/slink?169109
Summary:
The whole 802.11b and WEP implementation was a design disaster. Its
present implementations are further hindered and a threat to the majority
of organizations due to poor vendor responsibility in putting forth safe,
secure default installations, well as safe as they can be within its
current state of design. Information leakage is possible even with
encryption enabled within the deployment configurations via passive
sniffing allowing attackers to freely premap targets for exploit. The
legal issues of wireless technology might not be fully up to the present
state of technology and we may well have precedent setting fallout in the
courts due to the exploit of these new toys. Security professionals and
network/systems admins in North Carolina and the rest of the US have been
slow and ineffective in keeping themselves current on the issues wireless
technology presents to their job responsibilities. Wireless technology
should well make those tasked with securing their environments feel
extremely paranoid and may well not be ready for prime time play in the
corporate world in it's present state. Those tasked with determining the
risks and security issues for their prospective employers need to get
current with the issues prior to deploying these new toys in their
environments and need to understand how to best attempt to secure these
airwave streams as vendors have left them hanging with their default
configurations. Certainly these issue will require a tighter integration
of the various security departments within organizations to identify those
passively sniffing for attack vectors. Presently war-driving and passive
sniffing goes unnoticed by grounds security staff, they need to be
educated to help identify potential proximal sniffing efforts within their
domain.
[0] Orinoco RG-1000 residential gateway is reported in past advisories to
ship with WEP enabled; From: Bill Arbaugh
Subject: RG-1000 802.11 Residential Gateway default WEP key disclosure
flaw Date: Mon, 2 Apr 2001;
Unfortunately, the default
WEP key is set to the default network name, SSID. The
SSID appears in several 802.11 management frames in
the clear-- even when WEP is enabled. Therefore, an
attacker with a sniffer capable of capturing
management frames can determine the current WEP key
which is the last five digits of the network name,
(provided the default has not been changed). Armed
with the network name, and the current WEP key the
attacker can easily gain access to the users wireless
LAN. Additionally, the default network name for the
unit studied was the last six nibbles of the MAC
address converted into ASCII [1]. As a result even if
the key were not the network name, an attacker could
determine it by sniffing the MAC address of the unit.
To Lucent/Ornioco's credit, the fact that the default
encryption key should be changed is strongly
encouraged in the manual. However, the fact that the
default key is disclosed in the clear as part of the
network name is unfortunate. The default encryption
key should be changed to a randomly generated value
set at the factory.
References:
Lucent Technologies Inc., Orinoco Residential
Gateway Getting Started, February 2001.
[1] Alan Clegg's story on this highly visible government contractor is interesting. Alan accounted how after
sniffing traffic from their parking lot on his way to work, upon arriving
at work launched a very intrusive port scan against their systems. This
was noticed and their staff sent out the regular "what are your systems
doing scanning ours" series of e-mails. Alan then responded something to
the effect how it was good their sensors had picked up his intrusive
probes, but asked them if they had noted his efforts earlier from their
parking lot that morning. There was as Alan described silence on the
issue from that point on from this company. Though if I recall it was a
heads up to them as the next day their AP's
were WEP enabled. Prior to releasing this information Alan stated he
contacted staff at the company in question, perhaps to avoid surprising
embarrassment of his release of this information at the local Infragard
meeting here, but they never responded nor did it appear attend the
meeting.
Thanks:
To Jose Nazario jose@crimelabs.net and Chris Connelly chris@connelly.net,
both of whom are affiliated with crimelab (www.crimelabs.net) for
previewing this work and offering suggestions and critiques.
References:
Briefings given by Alan Clegg and Art Ehuan at the recent NC Infragard
meeting on April 26th.
http://alan.clegg.com/802/index.html
http://alan.clegg.com/LawEnforcement/
Various postings cited by specific authors to these mailing lists:
bugtraq, firewalls, firewalls-wizards, pen-tester, vuln-dev, etc...
Wireless 802.11b Security FAQ By Christopher W. Klaus of Internet Security
Systems (ISS) Email: cklaus@iss.net Version 1.5
http://www.iss.net/wireless
http://www.extremetech.com/print_article/0,3428,a=13880,00.asp
- Print Article WEP insecurities
http://www.iss.net/wireless/WLAN_FAQ.php#[4.2] 802.11
Security Analysis Tools">Internet Security Systems, Inc. Wireless FAQ
Wireless Vulnerability Press Kit: FAQ [Cigital]
http://www.research.ibm.com/gsal/wsa/
http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
http://www.cisco.com/warp/public/784/packet/jul01/p74-cover.html
http://www.wi2600.org/mediawhore/nf0/wireless/ssid_defaults/ssid_defaults-1.0.5.txt
http://securingwireless.intranets.com
http://www.hackinthebox.org/
http://www.cigitallabs.com/resources/papers/download/arppoison.pdf
http://www.dis.org/filez/
| Hosted by: |
|