Technology for Mortals

Last week I asked the browser companies of the world Microsoft, Mozilla, Apple, and Google to add an HTTPS-only web browsing mode which I called “mandatory SSL” (also posted here on CircleID).  This week, Google added HTTPS-only web browsing to the alpha version of Chrome 2.0.  I have no idea if I had any influence on this, but I want to congratulate Google Chrome developers on taking security seriously.

Now if they’ll implement my DNS recommendations which automates this on the server end, I’ll be even happier.  Right now, the HTTPS-only whitelist that Google supports in Chrome 2.0 alpha is still a manual procedure which requires too much user intervention which only benefits a very small percentage of the population.  If a site like Google would publish a custom record in DNS telling clients to automatically switch to HTTPS-only mode for services like GMail and keep that secure setting persistent even if a future rogue DNS server said otherwise, that would benefit 100% of the population.

The recent research highlighting the alarming practice of Secure Socket Layer (SSL) Certificate Authority (CA) vendors using the MD5 hashing algorithm (which was known to be broken since 2005) has shown a major crack in the foundation of the Web.  While the latest research has shown that fake SSL certificates with MD5 hashes can be forged to perfection when the CA (such as VeriSign’s RapidSSL) uses predictable certificate fields, the bigger problem is that the web has fundamentally botched secure authentication.

The problem is that web browsers make SSL entirely optional and it relies on user vigilance and expertise to ensure that the secure authentication mechanism is working correctly.  But this is fundamentally unsound because we know that users will almost always make the wrong decision.  One study from Harvard showed that most users will ignore an explicit warning of an invalid SSL certificates and more alarmingly, it showed that 100% of test subjects will log in to a webpage with SSL completely turned off.  This isn’t difficult to believe given that half of all Banks in the U.S. ran online banking sites with no SSL login page and the customers didn’t care.  It took more than a year of public shaming for the majority of those banks to strengthen their security but even today, we can go to online banking sites like wachovia.com and they’ll still ask you to login on a non-SSL webpage.  See image below.

This is proof that the Web standard is fundamentally insecure no matter how secure the underlying cryptography is because web browsers defer to the user for security decisions.  Anyone wanting to steal a password doesn’t need to go to the trouble of generating a fake SSL certificate at a cost of several hundred dollars per certificate, they merely needs to set up a fake http://bankofamerica.com, a fake http://GMail.com, a fake http://Salesforce.com, or any other website and the user will gladly hand their password over.  DNS hijacking wouldn’t even be necessary if the Internet connection is a wireless hotspot because it’s trivial to create a fake hotspot.

But there is a 100% reliable way to implement SSL or or Transport Layer Security (TLS) authentication securely.  For example, most VPN clients and Microsoft Outlook are good examples of how to reliably implement SSL/TLS authentication.  All of these secure authentication solutions have one thing in common: they all take the decision of enabling SSL and which certificates to accept out of the user’s hands.  If SSL is turned off, the application simply doesn’t work.  If the certificate is invalid, the application simply doesn’t work.  The responsibility to keep things working correctly now falls on the shoulders of the Information Technology (IT) department where it belongs and users aren’t burdened with confusing security decisions which they aren’t qualified handle in the first place.  The application simply works without hassling the user and it works securely 100% of the time.

What is needed is an overhaul of the way web browsers handle secure authentication but the challenge is transition to a more secure mechanism while maintaining backwards compatibility.  This could be achieved by implementing a mandatory SSL/TLS HTTPS mechanism that could be bolted on to the existing DNS infrastructure and web browsers with the following mechanisms.

• Web browsers surfing on mandatory SSL/TLS websites or domains should always require valid SSL/TLS certificates with no exceptions and no opt-out interface accessible to the user.
• Custom DNS records on a domain could explicitly announce to the world which host and/or domain names should operate in mandatory SSL/TLS mode.
• Web browsers could have a list of default mandatory SSL/TLS host names e.g., “secure” or “wwws”.
• Web browsers should maintain a list of any mandatory SSL/TLS HTTPS websites that the user has visited.  So even if DNS is untrustworthy in the case of public wireless hotspots, the web browser will insist on mandatory SSL/TLS even if the DNS infrastructure says otherwise.

The mandatory SSL/TLS HTTPS mechanism would require changes to all modern web browsers but it would work with existing DNS infrastructure.  The system would be backward compatible and the mechanism would remain entirely optional.  But once a company, a bank, or a cloud application vendor opts in to mandatory SSL/TLS, they will be able to enforce strong authentication policies throughout the entire globe.

Unfortunately, many companies perceive brand names and the perception of security more than actual security itself and they balk at the notion of good mandatory SSL/TLS security.  I’ve known companies that would rather run an invalid out-of-date VeriSign certificate which cost them several hundred dollars than do it properly with a $20 GoDaddy certificate.  These attitudes will eventually change once stronger authentication mechanisms are available and standardized and hopefully they’ll implement good SSL security.  In the long run DNSSEC could facilitate even easier and simpler Public Key Infrastructure (PKI).

To move forward, we first need to acknowledge that the current HTTPS SSL mechanism is completely broken.  It’s hard for a security professionals like myself to say that because I risk reinforcing the attitude that we might as well not bother with SSL security to begin with since it’s worthless to the majority of users.  But when the mechanism is so fundamentally broken, it’s time that we all stand up and say enough is enough and we need to fix it.

The Internet standards bodies needs to quickly adopt and standardize a custom DNS record for mandatory SSL/TLS.  Then Microsoft, Mozilla, Apple, or Google need to implement the changes on their web browser products to enforce the strong SSL policies.

As Robert Graham, co-founder and CEO of Erratasec pointed out, I have the implementation process backwards because implementation has always come before standardization on the Internet.  I must have been asleep writing that last paragraph because I should already know better.

Robert Graham: What made the Internet different from all the other competing internetworks of the 1980s was that people would implement something first, then standardize it.  OSI failed because standards led implementations.

Either Microsoft or Mozilla should just implement something, and document the DNS format that they will accept. Standards bodies can catch up later.

Microsoft or Mozilla, the two dominant web browser companies, should simply implement something immediately in their respective browsers and document the required custom DNS records.  This would be similar to Microsoft’s SenderID standard used for mail authentication which was eventually standardized.  Then if the mandatory SSL/TLS mechanism gains acceptance, the standards bodies will follow.

Some might ask “what about Extended Validation (EV) certificates”?  They suffer from the same problem in that they rely on the user to decide if the security mechanism should be enforced or not which we know this is virtually 100% unreliable.  Furthermore, the cost of EV SSL certificates is insane and it addresses a problem that is the least of our worries today.  There’s nothing wrong with a cheap $20 SSL certificate if the system is systematically enforced correctly.  $20 per year is more than reasonable price given the fact that the Certificate Authority (CA) is merely performaing an automated email round trip verification and a few math calculations to sign your digital certificate.

Andrew Storms – nCircle, George Ou, DHS secretaries, Secretary Michael Chertoff
Photo credits: Martin McKeay, photo 1 and photo 2, Attribution-ShareAlike License

I had the pleasure this Tuesday of meeting Secretary of Homeland Security Michael Chertoff along with a small roundtable of bloggers in Silicon Valley and the San Francisco Bay Area.  The event was hosted by the Hoover Institution at Stanford University in a really high-end conference room with a round table, seats for an audience, and video conferencing gear mounted high up.

UPDATE 11/13/2008 – Martin posted more comments and photos and Andrew posted his wrap-up here.

Martin McKeay got the call and invited me and Andrew Storms to the event and it was fortunate that he did because there was only the three of us and one reporter from the San Francisco Chronicle Deborah Gage besides the Department of Homeland Security (DHS) staffers and Mr. Chertoff.  Martin already posted a good wrap-up here and he put up the whole audio session on his regular podcast.  I just wish I had grabbed Martin’s camera and got a shot of him and Mr. Chertoff at the other end of the table.  Deborah Gage has a summary posted here at the SF Chronicle.  Andrew posted a series of nice photos here.

I personally thought the event was fruitful and I very much appreciated Mr. Chertoff’s time as well as his candid and straight forth answers.  I wish him well in whatever endeavor he moves on to after President-elect Obama’s transition.

Mr. Chertoff talked about the challenges of their relatively new organization and the understandable growing pains they’ve had trying to get their own house in order.  The DHS struggled with failing grades in the federal information security standards in its first 3 years of operation but managed to raise its grade to a “D” in 2006 and a “B” in 2007.  I know the media and the blogosphere usually have a field day blasting the feds for this but from my personal experience in information security, private businesses are not much better than the federal agencies.  The press recently had their own black eye at the 2008 Blackhat event this summer.  I’m certainly not trying to make an “everyone does it” excuse and the point I’m trying to make is that security is everyone’s problem and we can all use improvement.

One of the things I complained about to Mr. Chertoff about was the lack of encryption security on all the laptops that are frequently lost or stolen by the various federal departments.  I’m all too familiar with the letters from the Veteran’s administration that my private information was compromised.  The two questions that need to be answered is what were those laptops doing with all that data in the first place and why weren’t those hard drives encrypted.

Mr. Chertoff answered by examining the root cause of the problem which is the question of why we even care about all this personal information such as social security number, mother’s maiden name, and other unique tidbits of our identities to begin with.  The bigger question is why are we relying on these easily obtainable static secrets to begin with.  I agree with Mr. Chertoff and I’ve been a long time proponent of strong authentication technologies.  Unfortunately, the United States is far behind Europe and Asian countries when it comes to adopting smartcard strong cryptographic technologies which not only make life more secure but also more convenient.  With strong token based authentication technologies and other digitally signed identification cards, we would no longer need to bother with such easily breakable security measures.  The think tank which I work for Information Technology Innovation Foundation (ITIF) issued a report about Digital Quality of Life which shows all the social benefits of the IT revolution.

The problem for the time being is that while we wait for the day banks and institutions no longer rely on our social security numbers, our mother’s maiden name, and other “secrets”, we’re all vulnerable.  Governments and businesses must handle our data with the utmost security and care.  The challenge is that our data is so dispersed and handled by so many different entities that all it takes is a single leak to compromise our sensitive personal data.  This is where federal security guidelines as well as mandatory public disclosure rules for companies that lose customer data can make a significant difference.  If companies don’t need to disclose a breach in security, they often view data theft as an acceptable cost of doing business compared to the cost of implementing stronger security measures.  When a company’s public reputation is on the line because they have to notify the public of any security breaches, the cost of failure often becomes high enough that it justifies security measures that were once deemed too high.

Lastly, we closed the session with a discussion on the “no-fly list” becoming too diluted with the alleged million names.  The million name no-fly list figure has been repeated so often in the press and blogosphere that most of us have come to accept it as “fact” and I’m ashamed to admit that I’m guilty of believing this urban legend since I asked Mr. Chertoff the question.  The problem is that there aren’t a million names on the no-fly list or anything remotely close to it.  The DHS recently disclosed the actual number to be 2,500 people on the actual no-fly list and 20,000 people on the total selectee list.

However, that 20,000 list has many permutations in the way names are potentially spelled and arranged that the effective list is many times more than 20,000 names.  Sometimes there might be a common name on the list that may be shared by many people.  Mr. Chertoff explained that people can actually get themselves off the list if they were to give a little more detail about themselves to the airline such as a birthday so that the airline can filter them out of the list, but the airlines will need maintain a more detailed database and go through with the filtering.  Next year this may become easier when the DHS will send the list to the airlines so that they can compare the list to their manifests rather than the current system where the airlines have to send lists to the DHS.

What I’m wondering is why the airline can’t simply check the passport on the spot and look at the birthday to see if it matches the no-fly or total selectee list rather than refuse to let the individual fly because of a false positive.  We can also leverage technology where the newest digitally signed E-Passports could be prescreened so that a simple check of an E-Passport should allow any passenger to quickly and positively prove their innocence and avoid the nightmare of a no-fly false positive.

Many of the challenges in security we face today are not technical but social.  These social issues must be overcome to make people secure as possible while making life easier.  But too many technically uninformed people are scaring the public with claims that E-Passports or strong authentication mechanisms are somehow all about tracking and controlling the movements of citizens when none of these fears are grounded in reality.  Tracking exists today every time someone uses a credit card or ATM card and all it takes is a court order to access that information yet people are generally willing to use those technologies for the convenience, discounts, and safety they offer.  But because of the many unfounded fears of new technology, we are left in the worst state of technology where people want just enough to be dangerous but not enough to be secure.  I only hope that through education, we can eventually get people accept strong authentication technology which will improve the lives of everyone.

For most of this decade, I have worked tirelessly to educate the public and IT on the issue of wireless network security.  I’ve debunked all the wireless LAN security myths, published a comprehensive guide to wireless LAN security, clarified the difference between link-layer and VPN wireless security, and alerted IT managers to the real threats against enterprise wireless LANs.  Today I’m going to wear my myth busters hat again and alert you to the latest bunk news on the latest WPA cracking method and the irrelevant fear mongering “experts” that are pitching new VPN deployments to replace existing wireless LAN security solutions.

So what really happened?
Russian software company ElcomSoft has created a new bruteforce password cracking solution that leverages General Purpose Graphical Processing Unit (GPGPU) technology to speed up hash computations by a factor of 100.  More specifically, they’re using NVIDIA’s Compute Unified Device Architecture (CUDA) compiler to generate software that leverages NVIDIA GPUs.  In simpler terms, ElcomSoft is using cheap off the shelf gaming graphics cards to reduce the time it takes to crack passwords.

Note: NVIDIA CUDA is also useful to the scientific community for high performance computing and it can be used to improve video encoding and Photoshop performance dramatically.

What does this mean?
It means any authentication system that relies on password complexity are now 100 times weaker.  So if a user’s password normally takes 100 million years to crack, now it “only” takes 1 million year to crack.  If your password only took 100 hours to crack, now it takes 1 hour to crack using this new software coupled with some high performance NVIDIA gaming graphics cards.

Who does this affect?
This is NOT a Wi-Fi Protected Access (WPA) specific attack; it’s for any authentication scheme that relies on PSK or Password complexity which affects many VPN solutions as well.  If anything, WPA probably has one of the more resilient PSK schemes in use because it was deliberately designed with 100 rounds of SHA-1 hashing to make brute force attacks much more expensive.  This affects some VPN and some WPA wireless security implementations.

It generally affects home users who use the home implementation of WPA which uses pre-shared keys (PSK) which are just longer passwords.  Some businesses also use WPA in PSK mode so they’re affected to.  Some VPN authentication mechanisms like PPTP VPN and some IPSEC VPN implementations that rely on passwords or PSKs are also at higher risk.

It has zero affect enterprise mode WPA deployments which use TLS protected authentication such as PEAP or EAP-TLS.  Internal LAN authentication schemes such as NTLM and LDAP are also significantly weakened.  SSL authentication schemes are not vulnerable to this particular attack.

What should the affected do?
If you haven’t already done so, make sure you’re using a long enough and random enough password for your PSK.  That means you don’t use something out of the dictionary or some variation of a dictionary word or anything else that might be guessed by brute force.  My previous minimum recommendation was 10 random alpha-numeric characters which would have taken about 579 thousand years for a single computer to crack.  With the new cracking software, it takes a single computer with a high performance gaming graphics card about 5793 years to crack.  With 1000 GPU-armed computers, we can cut that time down to 5.79 years but no rational attacker is going to use this method to go after a residential target or even business targets.  There are much easier, cheaper, and faster ways of breaking in to a network.  If you want to neutralize the new GPGPU threat to passwords, simply add 2 random alpha-numeric characters to your PSK.

Should you switch to VPN wireless security?
First of all, this new crack does not affect most businesses since they should generally be avoiding any authentication scheme that relies on password complexity.  Second, read my article on the difference between link-layer and VPN and you’ll understand that VPN has never been the right solution for wireless LAN security. Ignore the “experts” and companies that are trying to sell you a new solution that were never relevant to begin with and use some common sense.  Enterprises should be more concerned with the real threats against enterprise wireless LANs.

Update: Looks like Robert Graham independently came to the same conclusions in his blog that this is bunk.  He also points out that this only goes 100 times faster with $1000 worth of graphics cards and that FPGA solutions are more feasible.  I do doubt the feasibility of using large-scale distributed computing because it can only be targeted on a single wireless LAN at any given time because pre-computed tables only work for a unique SSID because it is used as a SALT in WPA PSK.  There are always far cheaper and faster methods than a brute force method for breaking in to any system.

In May, Erratasec founder and researcher David Maynor sent out these pictures to a small security list beaming with joy as if to show off his new baby.  He asked us to guess what it’s for and a number of us made some educated guesses.  He then tipped us off that the battery on the bottom of the box would run for 5 days and that it was intended to be shipped to a nonexistent person.  Well that was all the clues I needed to solve the riddle of the iPhone in a shipping box.

Basically, the iPhone is a mini Apple computer running a stripped down specialized version of Mac OS X which is based on UNIX.  This allows David to install a set of passive or active wireless reconnaissance or penetration tools on the unlocked iPhone and run it for 5 days on an extended battery.  When the box is shipped to a nonexistent person at a company, organization, or government institution, the box will sit in the shipping and receiving area without an owner to claim it until it gets returned to the original shipper which might be some anonymous PO box.  Because the iPhone is well within range of the wireless network, it can be remotely controlled via the iPhone AT&T wireless 3G data service.

Traditionally, the wireless hacker must physically sit near a site in a car or building with a high powered directional antenna aimed at the target site.  Having the iPhone in a box inside the building means this would be completely unnecessary which saves on travel and reduces the risk of being caught on site.  Discovering the device in passive mode is practically impossible because wireless intrusion detection systems are incapable of analyzing wireless mobile data services.  This is the ultimate remote wireless hacking tool which could be used for ethical penetration testing or for criminal purposes and this is the subject of David Maynor’s presentation at DEFCON 16 tomorrow in Las Vegas.

It’s going to be interesting what the state of development is and I’m eager to get an update on whether FreeRADIUS-WPE, the ultimate enterprise wireless penetration tool (MUST READ for security professionals), has been implemented yet.  I’m hoping this will raise awareness that many enterprise wireless LANs have not been properly secured and Microsoft needs to fix their wireless client so that it is less suceptible to these attacks.

Developing …

This link to Google Video (WARNING – NSFW Not Safe For Work images) seems like it’s been hijacked in some way by a foreign language site.  I accidentally came across it when I was looking at some LCD monitor review videos on Google Video.  I someone doubt that Google approves of the content and the avatar image and I sent in a complaint to Google but the page and profile hasn’t been removed yet.  I’m not sure what to make of it or what, if any, exploits are involved.

One day after the Debian Linux project announced a massive flaw where its implementation of OpenSSL key generators only used 15 bits of entropy (32,768 combinations), HD Moore (creator of Metasploit) has released a tool to exploit it.  Nate McFeters has a good write up here on this matter.

Because this bug is involves very obscure cryptographic concepts and the severity and scope of the flaw wasn’t easily understood, it didn’t really get a whole lot of media coverage.  Now that the flaw can be exploited in Metasploit, the issue should get some attention.

The flaw stems from the fact that the PRNG (Pseudo Random Number Generator) was crippled leaving it with only 32768 combinations to test.  That means all RSA and DSA cryptographic keys generated by Debian and Ubuntu Linux distributions are effectively worthless.

The impact of this exploit is massive and it can easily affect non-Linux systems like Windows or Mac if those computers have a Root Certificate generated from a Debian/Ubuntu computer.  Any asymmetric crypto keys generated between September 2006 and 5/13/2008 on Debian or Ubuntu Linux distributions are affected.  Every affected key needs to be revoked and regenerated. System administrator and security professionals everywhere should start auditing their computer for this very serious weakness as soon as possible.

Update 4:32:PM

c0uchw4rrior in comments below asked: “You mention Root Certs in the last paragraph. Does that include SSL web certs from Verisign/GoDaddy, etc?”

Nathan McFeters has written one of the best explanations I’ve seen about the latest rash of SQL injection attacks at my old security blog Zero Day.  Nathan took the opertunity to point out another serious hole in the PCI (Payment Card Industry) standards which allow vendors to skip web application security audits if they simply buy a Web Application Firewall.