Public Access 'Blackspots' 89
WeakGeek writes "Unstrung has a story talking about a security issue with the combining of 802.11 and GSM/GPRS networks. Seems that 802.11b hotspots provide hackers with an easy way to grab user information from the wide-area network itself.
Back when GSM was being defined, standards were designed to only authenticate the details held on the SIM card in a user's device before starting a session on the network. The user's device doesn't in turn check the credentials of the network. Fake a network, get data.
Of course, the linked to story seems to be a 'viral' advertisement for a product that fixes this, but I still thought it interesting enough to share."
Re:WEP (Score:1)
Re:WEP (Score:1)
Re:WEP (Score:1, Interesting)
Re:WEP (Score:4, Informative)
"SSL Gateway"? SSL doesn't have anything to do with it. Do you mean IPSEC, or some other tunnel-based security? Or do you mean encapsulating GSM traffic within an SSL connection? That's not exactly a simple solution.
-- Robert
Re:WEP (Score:5, Informative)
Re:WEP (Score:1)
It most certainly does not. WEP stands for Wired Equivalent Privacy
Re:WEP (Score:1)
Re:WEP (Score:1)
As you say, the major problem with WEP's use of RC4 was in the selection of weak IV's. The other major issue was in key management. If long-lived, shared, static keys are replaced with short-lived, individual keys for unicast traffic, the security of WEP is greatly enhanced.
-- Robert
Re:WEP (Score:3, Informative)
http://www.ipsec.co.jp/products/ssh/cert/vulnerabi lity.html [ipsec.co.jp]
Here is an even cuter, step-by-step explanation of how to BRUTE-FORCE CRACK the IV and RC4 encryption in less than 1 MINUTE!
http://www.dachb0den.com/projects/bsd-airtools/wep exp.txt [dachb0den.com]
and the author even provides you with some auditing tools... for your network of course!
http://www.dachb0den.com/projects/bsd-airtools.htm l [dachb0den.com]
Padding your keys with any number, especially zero, is not a good encryption scheme. Did I mention that RC4 calls for this? It did wonders for the Windows password file. LOL!
http://etudiant.univ-mlv.fr/~ecorreia/toto.html [univ-mlv.fr]
Want more examples? Email me. It's just not a good algorithm. Unless under some kind of special condition, AES, Blowfish, or something else should be used instead.
Thank you for your time,
Quadgoatboy
Re:WEP (Score:1)
Not quite. RC4 has several pretty serious flaws, both in design and popular implementation.
What are the design flaws? I've never heard of any. It's a neat, simple stream cipher with a ridiculuously long cycle. I can't remember if you can prove there's only a single cycle or not.
Implemenation - there's no reason to bash RC4 because it's been used in a bad protocol. Skimming your links it looks like any stream cipher would have had the same problem. Or any block cipher, including AES, if they'd used dropped it in in CFB mode using the same IV, etc.
Padding your keys with any number, especially zero, is not a good encryption scheme. Did I mention that RC4 calls for this?
No, you repeat the key to get 256 bytes, i.e. from "ABCD" you'd use "ABCD" 64 times rather than "ABCD" then 252 zeros.
Re:WEP (Score:1)
However, RC4 has had some setbacks recently.
A paper on attacking RC4 [ee.ubc.ca]
A more theoretical attack paper [colorado.edu]
A paper describing an attack that requires some guessing and probability theory [nec.com]
I have a few problems with the RC4 algorithm, only one of which I'll talk about. It's not implemented poorly in one or two protocols, but several. If it's that hard for engineers to implement properly, then my brain simply thinks "Don't use that protocol! It's not worth it!" Perhaps, it's an okay protocol. Perhaps, there are just too many engineers that don't know how to implement it properly.
Thank you for your time,
Quadgoatboy
P.S. As a side note, I don't know about you, but I just don't trust a protocol that padds itself 64 times on a 32 bit key. That just kind of... creeps me out :D. Yeah, yeah, I'm paranoid, but isn't anyone who uses encryption.
BTW (Score:1)
In other words, both of you are right, and I am wrong. Enjoy ;).
Thank you for your time,
Quadgoatboy
Re:WEP (Score:2, Informative)
oh? (Score:4, Funny)
What an amazing conclusion. Networks are vulnerable. Thank you once again, Captain Obvious.
Re:oh? (Score:2, Informative)
Actually it's even more obvious than that: WLAN networks are vulnerable "because it's cheap to get a base station and masquerade as a network".
True, but frankly missing the point by a mile... Commercial WLANs need rock solid authentication for both ends for billing, trust, access control etc. etc.
Vulnerable networks (Score:4, Funny)
This all adds up to networks that could be vulnerable to hacker attacks
All networks are vulnerable, no matter how many precautions you take. Heck, just watch mission impossible [amazon.com] again (if non-networked computers are vulnerable,...).
Great (Score:2, Insightful)
More good reading (Score:5, Informative)
What blackspots ? (Score:4, Interesting)
And why would 802.11b fix this ? If you can put 802.11b there why not just put up a cell to fix the problem ?
Right now where are the 802.11b networks... for the most part they are in the cities. Where do you not have a problem with reception... in the cities.
Why would someone put an 802.11b network out on Route 100N in Vermont rather than just a cell on the top of the mountain ? I'm obviously Mr Thicky here as it does seem that if you are going to put up a wireless network you might as well put up one that is already supported by phones rather than adding more bulk to the phones with a seperate set of chips to drain the battery.
I've got bluetooth on my mobile, and GPRS. Someone please tell me why I'd want 802.11b as well ?
Re:What blackspots ? (Score:5, Interesting)
Bluetooth... (Score:2)
Could do that inside an office, very cheap and already on lots of phones. Blue tooth hardware can be tiny in comparison to 802.11b. And covers small blackspots like in offices.
802.11b would be for bigger blackspots which begs the same question.
Re:What blackspots ? (Score:1)
I've got bluetooth on my mobile, and GPRS. Someone please tell me why I'd want 802.11b as well ?
Two reasons:
It's okay ... (Score:1)
What's this to do with GSM? (Score:3, Interesting)
Maybe I'm missing the point :) but isn't this just a function of the fact that there is no user-level authentication in 802.11b at all... The fact that this makes it difficult to hook up WLANs to GSM networks is only just a side-effect.
Doesn't 802.11x begin to address this?
Re:What's this to do with GSM? (Score:3, Informative)
"The heart of the problem is that when the GSM standard was being defined back in the late 80s, no one imagined that a hacker could set up his own wireless network to gain access to an operator's network and the user data therein. Therefore, GSM networks only authenticate the details held on the SIM card in a user's device before starting a session on the network. The user's device doesn't check the credentials of the network it is attempting to access.
This was fine before the advent of wireless LAN. But now for a minimal outlay anyone can own a wireless network.
Hackers can set up "rogue" hotspots that users will access in the belief they are on the genuine public wireless LAN network. Once users are on the fake network, it is easy for the hacker to access data held on the device via the 802.11 connection (see WLAN: The Four S's and this paper for more on the insecurity of wireless LAN). Hackers can then break into the SIM software on the user's device and get the codes held there. They can then use that information to fool the GSM authentication system and thus gain access to the network."
Re:What's this to do with GSM? (Score:1)
My point exactly - 802.11 doesn't have any user authentication meaning that neither party can trust the other. Stealing information to allow you to then access a GSM network is no different to a rogue access point stealing my credit card info off my laptop.
I did read the article - did you understand it?
Re:What's this to do with GSM? (Score:1)
My understanding of the problem is that when you access a hotspot that you think belongs to AT&T (or whoever your GSM service provider is) but it actually is a counterfeit, the rogue hotspot can glean information from your SIM card that would enable them to hack into the AT&T GSM network.
The complete story (Score:5, Informative)
02.21.03
CANNES, France -- 3GSM Congress -- There's a big problem with connecting public wireless LAN access points to GSM/GPRS cellular networks, according to SIM card vendor SchulmbergerSema [smartcards.net]. 802.11b hotspots provide hackers with an easy way to grab user information from the wide-area network itself, the company tells Unstrung.
The heart of the problem is that when the GSM standard was being defined back in the late 80s, no one imagined that a hacker could set up his own wireless network to gain access to an operator's network and the user data therein. Therefore, GSM networks only authenticate the details held on the SIM card in a user's device before starting a session on the network. The user's device doesn't check the credentials of the network it is attempting to access.
This was fine before the advent of wireless LAN. But now for a minimal outlay anyone can own a wireless network.
At the same time, vendors and operators are starting to use SIM card-based authentication front-end systems for public wireless LAN networks, which allow them to link the user back to the home location register (HLR) database on the GSM network and thus manage and bill a subscriber on the WLAN network in the same way as they would on the wide-area network.
This all adds up to networks that could be vulnerable to hacker attacks, according to Schlumberger.
Hackers can set up "rogue" hotspots that users will access in the belief they are on the genuine public wireless LAN network. Once users are on the fake network, it is easy for the hacker to access data held on the device via the 802.11 connection (see WLAN: The Four S's [unstrung.com] and this paper [berkeley.edu] for more on the insecurity of wireless LAN). Hackers can then break into the SIM software on the user's device and get the codes held there. They can then use that information to fool the GSM authentication system and thus gain access to the network.
Schlumberger say that this won't be a problem once UMTS networks are available, because the 3G standard ensures what's known as "mutual authentication" -- the network authenticates a user device, and the device confirms that it is actually on a valid network before the session can proceed.
However, for public wireless LAN implementations that will connect to backend systems on GSM and GPRS networks, Schlumberger has developed a SIM card-based system (surprise!) that enables mutual authentication between the device and networks that are accessed via the gateway of public wireless LAN hotspots. The mutual authentication takes place via algorithms on the card itself rather than in SIM card software on the device.
Schlumberger is showing a system at the 3GSM congress that uses a separate smartcard and reader plugged into a WLAN-enabled laptop. However, the firm says that the smartcard and radio could be integrated into one PCMCIA card, much in the way that Nokia Corp. [nokia.com] (NYSE: NOK [stockpoint.com] - message board [slashdot.org]) has done.
Orange France [orange.fr] is currently testing Schlumberger's security system. Schlumberger expects that operators will start to roll it out before the end of this year.
-- Dan Jones, Senior Editor, Unstrung
http://www.unstrung.com [unstrung.com]
802.11b WAN will be shortlived (Score:4, Interesting)
Why don't we just install it under our skins and we can all be 802.11 hotspots ourselves.
Re:802.11b WAN will be shortlived (Score:2, Informative)
A viral advertisement (Score:4, Funny)
You guys need to fact check a bit. I didn't see anywhere that mentioned that the story was under the GPL.
Tired of the wirless security fud (Score:1, Flamebait)
Customer: Is this wireless networking secure?
Me: What Operating System are you running?
Customer: Windows Xpeee
Me: It doesn't matter you will never be secure.!
It is a matter of choice it can be as secure as you wish it to be. If you really think you need security tunnel through ssl..
Re:Tired of the wirless security fud (Score:1)
Customer: Is this wireless network secure?
Me: What OS are you using?
Customer: WinXP
Me: It doesn't matter, you will never be secure!
Customer: *YOUR* job is to make me secure!
Me: Unless you agree to let me change your OS that's not going to be possible. I can't perform miracles.
Customer: I want to talk to your supervisor!
time passes
Supervisor: I had a complaint today. Please clean up your desk.
Sucks to be me... at least I'm not in customer service anymore.
Re:Tired of the wirless security fud (Score:1)
"La. La. La. My machine is secure. La. La. La."
just hire a HACKER! (Score:2)
It is amazing how much of this stuff goes on in design - if the executives of the firms involved in the standardization process can't understand the problem, it must not exist!
Every protocol out there is going to get picked apart
Tunneling GSM authentication not mentioned (Score:4, Interesting)
Protocols like EAP (Extensible Authentication Protocol) are intended to provide a generic mechanism over any transport system to handle legacy and modern handshaking and exchange to authenticate a user in a system.
In 802.1x/EAP, included as of the 802.11i wireless security update, 802.1x defines the roles of a client, access point authentication passthrough, and an authenticator. 802.1x restricts access to the network until the access point using EAP has been told by the authentication system that the client is okay to be on the network. It hands off a key, which eliminates spoofing, as even if you spoof the MAC address, you don't have the key. The key can be swapped frequently, like every 10,000 packets.
The problem with 802.1x/EAP is the same as with the SIM/GSM authentication system as described here. The authentication is sent in the clear! So you have three flavors of tunneled, SSL-like EAP: EAP-TLS (requires a pre-installed certificate on the client), EAP-TTLS (Meetinghouse, Funk support, tunnels EAP inside a tunnel), and PEAP (Microsoft, Cisco, same tunneling but ignores legacy protocols supported within EAP-TTLS).
Hard to use this to clone mobiles. (Score:5, Informative)
The scenario is one where GSM operators use 802.11 to provide data-infill on their GSM networks, and reuse the GSM authentication mechanism over 802.11 to control access. The article is correct to point out that it would be relatively easy for someone to setup an 802.11 access point which pretends to belong to a GSM operator and requests GSM authentication information from connecting devices.
However, this shouldn't be too big a problem. The GSM authentication mechanism is based on a shared secret key which is written in to the SIM card in a way that SHOULD be read-only. Once its written the key is used by the SIM to calculate a response to a challenge sent from the network. This authentication algorithm is chosen by the network operator, and should be a one way function (ie you can't analyse the challenge/responses to get the secret key). Therefore, the hacker with a false network could get a set of valid responses to a set of challenges, but if the authentication algorithm is correct he can't use this data to get the secret key and clone the SIM.
The only comment I would make is that flaws have been discovered in the authentication algorithms used by some networks which potentially makes it possible to find the secret key if you have enough challenge/response data. However these algorithms are being replaced, and the computation is still quite heavy.
To summarise: fake networks attacks aren't new. Using 802.11 just makes it easier. Its best to suppress fake networks by mutual autentication, but even if you don't do this it should still be impossible for the fake network to get enough data to clone a mobile. The main problem with fake networks is that they can intercept the content of communications very easily.
a technology from the late 80s (Score:1)
There will always be people that will try to break into something, so just work on ways to make it more secure.
Step 1.) Remove all Microsoft products
EAP-SIM (Score:2, Informative)
Someone mentioned that the authentication information for EAP is passed in the clear. EAP-SIM is not vulnerable to replay attacks because it's a challenge and response method. In normal GSM authentication, the network decides on a random challenge RAND. The network and the SIM calculate a signed response SRES and a session key Kc. The user equipment sends back SRES and the network uses it to authenticate the SIM. This leaves Kc as a shared secret at each end. EAP-SIM uses the same triplet, and uses the multiple passes for mutual authentication (theres an Internet Draft for it at http://www.ietf.org). EAP-SIM can also supply the accumulated Kc's to be used as a session key for WEP. Ok, WEP has known problems, but because you can force re-authentication periodically you can avoid a black-hat accumulating enough packets to crack your session.
BTW, Schlumberger aren't the only company offering "WLAN" SIMs - another company has been unsuccessfully lobbying 3GPP (the 3G industry standardisation body, who deal with WLAN/3G interoperation) with the same idea.
Re:EAP-SIM (Score:1)
Yes, but RAND is 128 bits! Even if the SIM didn't have defences against multiple requests (which many do), that's 3.4e28 triplets to record. It isn't going to happen.
More realistically, if an operator is using the COMP128 encryption algorithm, given physical access to the SIM, the secret key Ki could be cracked in which case you could make up the triplets. That's a real problem, but it's not peculiar to WLAN - it would allow cloning of generic SIMs for GSM use. The problem is that COMP128 was intended as an illustrative algorithm, not intended for production use. Wise operators either don't use it, or are replacing SIMs using it.
I've done this before myself. (Score:4, Interesting)
It was just an exparement at the time because I was bored.
I setup an oBSD box with wireless card in it not connected to any real network, but acting as an access point.
It handed out seemingly public IPs (It was slightly off from the real IPs my network used)
I did not use WEP on purpose, but set the network name to 'Private_GO_AWAY' (or some such message)
It then ran honeyd and pretended to be a network of a few hosts.
People looking for net access failed to get it, and most left it at that.
Once someone attempted to open a connection to any of these fake IPs, my machine portscanned them back, fingerprinted the OS, grabbed banners from any service it found running, and logged this all with date/time/MAC/hardware brand/etc info.
It also at that point started logging every packet that IP sent up until it left the wireless network.
It was fun to watch people who actually tried to 'break in' over wireless.
As i recal it was only about 5 people in a 6 month period, out of hundreds of people 'passing by' looking for net access.
Only those 5 or so people do I have detailed logs on. (I didnt bother logging anything about the ones just wanting net access, other than the fact they requested an IP and when)
If my signal is being broadcast out and they have full rights to do what they want with it, I feel the same is true for the replys from their wireless hardware to me
Simple solution... (Score:2)
Encryption makes it practical to separate the service of connectivity from the service of trust, so an untrusted hotspot can be safely used for connectivity while still maintaining a trusted connection.
The Fallacy of Network Security (Score:2, Interesting)
As was mentioned above, any network can be penetrated once physical access is obtained. Most network security is designed around the concept of trusted portions of the network; an attacker must either break through a firewall, gain control of a machine within the trusted portion of the network, or add a machine under his control to the network. Under 802.2 and related networking protocols, physical access is limited to a wire; to add a machine to the network, an attacker must at least be in the building. Under 802.11, physical access is anywhere within a certain range of a node. With the right equipment, this range can be extended considerably. Suddenly, that firewall isn't quite so effective.
My opinion hasn't changed since the first time I read about 802.11: great, useful, whatever, but NOT TO BE TRUSTED. I have an 802.11 hub on my network, but it sits in the DMZ. Wireless users around the house can still get access to the Internet and some network services, but unauthenticated machines can't get into my happy safe zone. If I needed something like that, I could set up VPN to let my wireless machines become part of the safe zone. VPN uses much better authentication and encryption than 802.11, and VPN implementations can be easily patched as the protocol improves. AFAIK, VPN authentication would defeat the attack described above.
Not entirely true (Score:2)
When the radio-connection has been established, the network sends a unique 128-bit key (RAND) to the MS (phone). The phone then uses the A3/A8 algorithm implementation, together with the RAND and an internal key stored only in the SIM (and the network's AuC) known as the Ki. This algorithm produces a 32-bit SRES (authentication check) and a 64-bit Kc (data encryption key).
RAND is sent in an AUTHENTICATION REQUEST message, and the computed SRES is sent back in an AUTHENTICATION RESPONSE. The Kc is not returned (as the network already knows it, the SRES is sent to confirm that the MS is who it says it is).
In theory, the attacker could ignore the response and begin an unciphered radio connection. However, ciphering forms an implicit form of two-way authentication. Since the Kc is used to encrypt calls, and the real Kc is not known by the network, the phone would start encrypting bursts (packets) and the network would not be able to decrypt them, hence communication would fail.
Of course, the network could simply avoid encryption by specifying no algorithm in CIPERING MODE COMMAND message, however most phones would display a warning to the user that the session is not encrypted, and hence the attack is known.