#SecChat $1 million guarantee 12 Scams of Christmas access to live fraud resolution agents Acquisition Alex Thurber Android antivirus Apple botnet Channel Partners cloud security Compliance Consumer counter identity theft credit card fraud and protection credit fraud alerts credit monitoring credit monitoring and resolution critical infrastructure Cyber Security Mom cyberbullying Cybercrime cybermom data breach data center data center security Data Protection Dave DeWalt DLP Email & Web Security embedded encryption Endpoint Protection enterprise facebook fake anti-virus software Family Safety Friday Security Highlights global threat intelligence google government Hacktivism how to talk to kids how to talk to teens identity fraud identity fraud scams identity protection identity protection $1 million guarantee identity protection fraud identity protection surveillance identity surveillance identity theft identity theft expert identity theft fraud identity theft protection identity theft protection product Identity thieves and cybercriminals intel iphone kids online behavior lost wallet protection malware McAfee McAfee Channel McAfee Family Protection McAfee Identity Protection McAfee Initiative to Fight Cybercrime McAfee Labs McAfee security products Mid-Market Mobile mobile malware mobile security monitor credit and personal information Network Security online personal data protection online safety Operation Aurora PCI personal identity theft fraud personal information loss personal information protection phishing privacy proactive identity protection proactive identity surveillance Public Sector restore credit and personal identity Risk and Compliance scam scams scareware security smartphones social media social networking social networks spam Stuxnet twitter vulnerability Web 2.0 work with victim restore identity
|
|
If you are running WPA Enterprise with PEAP, or EAP/TTLS its about time you take a serious look at your client configuration! This weekend at Shmoocon in Washington D.C, Josh Wright and I gave a presentation that demonstrated how a very common, but incorrect client supplicant configuration can lead to the compromise of certain wireless networks and in some cases, provide Windows domain access.
Our AP impersonation attack on PEAP and EAP/TTLS relies on the client failing to properly validate the authentication server’s (RADIUS) TLS certificate. By default, the Windows Zero Configuration (WZC) wireless supplicant performs this validation by putting the trust of the network in the client’s hands. WZC will prompt the client to either continue or cancel upon connecting to the wireless network (similar to the way your web browser prompts you when accessing certain websites over HTTPS). Furthermore, the client may be mislead by this message as it only contains the signing authorities’ name (i.e Verisign) rather then the actual certificate name.
The severity of this issue is further escalated when the client is configured not to validate the server certificate at all. Unfortunately, this is the most common configuration I’ve seen used within organizations. It should be noted that because this is a configuration related attack, WZC is not the only vulnerable client supplicant. OSX’s client, Juniper’s Odyssey Client, and virtually every other wireless supplicant is vulnerable as well.
In either of these scenarios, FreeRADIUS-WPE (our modified version of the open source RADIUS server) can be used to gain access to the inner authentication credentials passed in the TLS tunnel that is established between client and the authentication server. These weak inner authentication protocols (i.e. PAP, MSCHAPv1, MSCHAPv2, etc..) rely on the outer TLS tunnel for protection, so without this protection they are greatly exposed to attack. In some cases these protocols reveal the client’s username and password in clear text, while other cases require a brute force attack. Due to active directory integration, these credentials may also be those used for domain authentication.
Finally, because this is the result of a client related issue, clients may be vulnerable in areas such as coffee shops, airports and other locations outside of the vicinity of the corporate wireless network.
When using WZC and other supplicants, you’ll want to make sure that the client clearly validates the server certificate by only trusting certificates that match the signing authority, and hostname of the RADIUS server. An example of the WZC configuration is below. This is also covered in Microsoft knowledge base article KB941123. For additional information on protecting yourself from this and other attacks, please see my 802.11 attacks whitepaper on Foundstone.com!
|
|
Self-signed certs not installed on the supplicant machine would necessitate not validating the cert. Bad mojo.
I’ve found that some admins uncheck “validate server certificate” because sometimes it prevents users from authenticating. If everything is properly configured, then of course validating the server certificate should not be a problem. But in the real world mistakes happen sometimes and unchecking that box can get users authenticated in a pinch.
The common response is “well…we couldn’t get the wireless working, so we were playing around with the configuration and we noticed that if we unchecked that box, everything worked!”
unfortunately i’ve heard that more then you can imagine. Nonetheless the validate server certificate box is somewhat misleading in itself. With that checkbox checked, WZC will prompt the user to either “continue” or “cancel”. When it prompts the user, WZC only displays the signing authority of the certificate, and not the certificate name (i.e verisign). An attacker with a couple dollars can buy any verisign certificate to mislead users.
Think about it, if you’re prompted in a similar situation and the first thing you see is “verisign” would you be more inclined to accept it?
Also, in general its never a good idea to put the security of the network in the client’s hands, which by prompting the user, WZC is doing.
On the WZC supplicant, “validate server certificate” is enabled by default, I am not sure why an organization would remove this configuration.
Good job. I’m glad to see a topic that is *not WEP related. What you’re doing here is actually valuable to real enterprise wireless configurations. This technique will certainly be useful on wireless pentests.
Submit your own comments / message for this post