tag:blogger.com,1999:blog-1988432060681510848.post104327721943908755..comments2024-03-25T23:51:47.067-05:00Comments on Revolution Wi-Fi: Is WPA2 Security Broken Due to Defcon MS-CHAPv2 Cracking?Andrew von Nagyhttp://www.blogger.com/profile/12658799453646609565noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-1988432060681510848.post-31781154467819070982012-10-31T15:53:39.367-05:002012-10-31T15:53:39.367-05:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-61024208110379523912012-08-25T09:41:09.856-05:002012-08-25T09:41:09.856-05:00Agreed! VPN over WiFi is an old approach that resu...Agreed! VPN over WiFi is an old approach that results in poor user experience and mobility. And unless it's auto-launched it can leave users open to direct attacks on open WiFi networks. Andrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-76298006514636426902012-08-25T08:35:40.745-05:002012-08-25T08:35:40.745-05:00vpn on wifi is sillyvpn on wifi is sillyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-7784835201162738272012-08-08T07:44:41.998-05:002012-08-08T07:44:41.998-05:00In terms of pki supporting WiFi,could just add the...In terms of pki supporting WiFi,could just add the SSID as alternate name, like rfc822name, dnsname and UPN. Technically, SPN would seem appropriate for Ssid. Personally for business would consider using open WiFi and putting all devices on a vpn, because that approach is likely safer. Most WiFi routers seem to run antique Linux without security patches, plus vpn allows remote access.Dave Bacherhttps://www.blogger.com/profile/02441603261537923363noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-87995703322540680542012-08-07T08:40:26.596-05:002012-08-07T08:40:26.596-05:00Awesome article !Awesome article !Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-61131774274847247592012-08-03T12:20:02.428-05:002012-08-03T12:20:02.428-05:00Doing a bit more research on the client server val...Doing a bit more research on the client server validation for Windows devices, I found this:<br /><br />Clients validate various settings in the certificate based on the CryptoAPI checks enabled in the remote access policy or network policy:<br /><a href="http://technet.microsoft.com/en-us/library/cc731363(v=ws.10).aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/cc731363(v=ws.10).aspx</a><br /><br />And, the CryptoAPI has a function called "CertVerifyCertificateChainPolicy":<br /><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa380252(v=vs.85).aspx#certificate_chain_verification_functions" rel="nofollow">http://msdn.microsoft.com/en-us/library/windows/desktop/aa380252(v=vs.85).aspx#certificate_chain_verification_functions</a><br /><br />Which includes checking basicConstraints in the certificate with the "CERT_CHAIN_POLICY_BASIC_CONSTRAINTS" parameter:<br /><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).aspx</a><br /><br />In that last link, the basicConstraints parameter is listed with others as "predefined" in the function call, so I'm hoping that means that it is always checked by default. I'd need to perform testing to be positive.<br /><br />It should also be noted, that clients should verify that the EAP server presents a Cryptobinding TLV to ensure that both outer and inner EAP methods are performed by the same entity.<br /><a href="http://msdn.microsoft.com/en-us/library/cc238447(v=prot.10).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/cc238447(v=prot.10).aspx</a><br /><br />Cheers,<br />AndrewAndrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-86818466873676055852012-08-03T11:56:32.292-05:002012-08-03T11:56:32.292-05:00Hi Paul,
I agree with your statements and the rese...Hi Paul,<br />I agree with your statements and the research that you linked to.<br /><br />However, corporate environments typically DO deploy private PKI infrastructures, and most MDM solutions on the market today can either integrate with a private PKI infrastructure or use their own private PKI (typically for simplicity for smaller customers). Part of deploying configuration profiles to devices includes the Root and Intermediate CAs along with the WLAN profile settings. So I think a good solution for any organization is to deploy a private PKI of some form for WLANs, at least for corporate issued devices and BYOD type personal devices.<br /><br />Public PKI systems and certificates are another matter. Guest networks may use PEAP and rely on public certificates, but often are simply open with captive web portals of some form. So, I don't think it's a big issue today. But it could become more of an issue with HS2.0 deployments. I'll also have to do some research on how this interacts with the 802.11u features being brought to market with HS2.0.<br /><br />Also, I'm not positive if various operating system supplicants check the "basicConstraints" field in the certificate or not. That's something that I will have to do more research on. But thanks for pointing this out. <br /><br />Cheers,<br />AndrewAndrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-67070447648061730872012-08-03T10:15:55.684-05:002012-08-03T10:15:55.684-05:00Hi Paul,
Nice links. Your statements imply great...Hi Paul,<br /><br />Nice links. Your statements imply greater importance on validating server certificates to reduce the chance of being victim to Evil Twin Attacks.In Win7 you can also specify the CA server IP/hostname.<br /><br />Anyone considering allowing Macbooks on the network?<br /><br />ManY thanks,<br />AdrianAnonymoushttps://www.blogger.com/profile/06308646290993767445noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-74306775182139591442012-08-02T08:27:04.538-05:002012-08-02T08:27:04.538-05:00Hi,
Moxie Marlinspike published the SSLstrip appl...Hi,<br /><br />Moxie Marlinspike published the SSLstrip application back in 2009.<br /><br />http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br /><br />When reviewing how this application is working you'll understand that it exploits the Certificate Trust Chain mechanism. This means that any Wireless LAN client that is unable to validate the Trust Chain can be lured and could connect to an Evil Twin infrastructure.<br /><br />http://www.suse.de/~lnussel/The_Evil_Twin_problem_with_WPA2-Enterprise_v1.1.pdf<br /><br />Windows 7 is the only Wireless LAN client I know that is capable of validating intermediate certificates. But, this implies deploying all intermediate certificates on the workstation.<br /><br />Consequently, the only real alternative to somehow guarantee that a client workstation will not be lured by an evil twin is to create a private root CA and control how certificates are being distributed. But, this implies deploying the root CA on all client workstation for them to be able to validate the RADIUS server authenticity.<br /><br />This means, that when the TLS tunnel is established with an evil twin infrastructure, it is possible to capture the MsCHAPv2 handshake. And that's where this new ChapCrack tool comes into place.<br /><br />My current line of thoughts regarding overall security is now the following: The only thing that can really be trusted is what's in the Data Center. The use Virtual Desktop becomes a priority. Each branch office should be considered as a big home office connected to an Internet Only Access (IOA). Consequently, securing end point accesses with 802.1X becomes less important and depending on the enterprise type of business, it is sometimes not relevant anymore.<br /><br />Best regards,<br /><br />Paul Gallant, Eng.<br />CWNA, CWSPPaulhttps://www.blogger.com/profile/18287749604287529008noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-68960989850176190012012-08-02T07:24:37.299-05:002012-08-02T07:24:37.299-05:00Yes, agreevwith both u and Marcus. This week I ha...Yes, agreevwith both u and Marcus. This week I have received a fewvconcerns with subject "MSCHAPv2 insecure". The idea of tunneled protocols is to send inner-eap credentials within a securevTLS tunnel... The integrity of that tunnel lies on the wireless supplicant and radius server.. The following may help:<br />- validate server certificate<br />- enable the Enable Identity Privacy with string Anonymous to,obscure the TLS tunnnel Id (visible in packet captures)..<br />- use digital client certificates.. <br /><br />To be honest, it is easier to attack clients rather than infrastructure.... I.e deauth clients, identify open preconfigured WLAN profiles and invite clients to your sttractive WLAN network....<br /><br /><br />My 2 cents...Anonymoushttps://www.blogger.com/profile/06308646290993767445noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-48045377057139722582012-08-01T19:42:52.873-05:002012-08-01T19:42:52.873-05:00Andrew,
Thanks much for this. The tech press lik...Andrew,<br /><br />Thanks much for this. The tech press likes to sensationalize these things regardless of the actual real world impact. I also appreciate that you spent some time detailing the need for strong server-side cert validation and a robust PKI.<br /><br />This is very important for Hotspot 2.0 / Passpoint, as EAP-TTLS w/MS-CHAPv2 is the only real alternative to SIM or USIM authentication mechanisms in the short term. (I'm dubious that client-side certs with EAP-TLS will prove scalable). And as EAP-TTLS support is mandatory for all handsets in the HS2.0 Tech Spec, I expect to see some creative implementations to exploit it.<br /><br />Very intrigued by Chris' thoughts on using ANQP exchanges to do the OSCP checking prior to setting up the TLS tunnel. That's a great example of how GAS/ANQP will prove useful to enable enhanced services.<br /><br />Best,<br />DaveDave Wrightnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-81359246574970544802012-08-01T17:11:00.856-05:002012-08-01T17:11:00.856-05:00Actually, thinking about this more... The Wi-Fi Al...Actually, thinking about this more... The Wi-Fi Alliance WPA2 certification program does not include interoperability testing or certification for LEAP as an authentication protocol. So when the articles state WPA2 Enterprise Wi-Fi networks, they implicitly are excluding LEAP from their analysis impact and giving a clear impression that other protocols such as PEAP are vulnerable. They likely didn't know they were doing this, but it is still confusing and misleading.<br /><br />AndrewAndrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-72493315478468584772012-08-01T10:52:42.038-05:002012-08-01T10:52:42.038-05:00Thanks Marcus! Good point.Thanks Marcus! Good point.Andrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-13225729051691252532012-08-01T10:47:44.676-05:002012-08-01T10:47:44.676-05:00Andrew,
Well written and explained as usual. I agr...Andrew,<br />Well written and explained as usual. I agree with your conclusion. One point I want to add is that mis-informed articles and news headlines (as you linked to) are incorrectly associating Marlinspike's "WPA2-Enterprise" and "MS-CHAPv2" references with PEAP and EAP-TTLS. Marlinspike is being intentionally ambiguous because his attack/tool will receive more press that way--unfortunately, by being ambiguous, he's bred confusion and incorrect conclusions. But, I don't think he's talking about PEAP or TTLS at all. He's talking about LEAP. He makes the point that previous MS-CHAPv2 attacks have been focused on dictionary attacks, pointing to ASLEAP as an example. But his point is that people have trusted PPTP and LEAP for a long time because they can still use long, complex passwords and avoid normal offline dictionary attacks. His Defcon chat was all about demonstrating that the protocol itself is fundamentally broken and the original password can be recovered regardless of its length/complexity.<br /><br />thanks,<br />MarcusMarcus Burtonhttp://www.ruckuswireless.comnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-49694837709944568002012-08-01T10:39:58.037-05:002012-08-01T10:39:58.037-05:00Excellent article Andrew, thank you!Excellent article Andrew, thank you!Anonymousnoreply@blogger.com