Technology for Mortals

Security researcher Moxie Marlinspike gave one of the more interesting and terrifying presentations at BlackHat 2009 in Las Vegas yesterday. Marlinspike demonstrated how the X.509 digital certificates used by Secure Socket Layer (SSL) to secure online communications such as eCommerce and online banking were was completely broken.  This allowed Marlinspike to pose as the Mozilla update server for users on the same local area network such as a hotspot which allows him to distribute malware in the guise of of a Mozilla Firefox update.

Read the rest at DigitaSociety.org.

Mass media and blogosphere hysteria ensued after several ISPs (including AT&T) responded to customer complaints and blocked an IP address that was transmitting massive amounts of Denial of Service (DoS) traffic. For something as routine as and essential as blocking a malicious attack from a computer on the Internet, all hell broke loose late Sunday evening and early Monday morning because the IP address belonged to a popular image sharing site called 4chan whose members are infamous for perpetrating porn flooding pranks on YouTube as well as organizing DoS attacks against other websites.

Read the rest at DigitalSociety.org

F-Secure is getting some news coverage because one of their bloggers claim that they have identified a security failure in Windows 7 Release Candidate.  Their blogger Mikko writes that Windows 7 still hides file extensions which allows virus writers to easily trick users in to launching executable files that were disguised as ordinary document files.  Mikko showed some screenshots of how this supposed vulnerability would be exploited but there is a mistake in Mikko’s analysis.

The mistake is that when you create an executable file on your own computer, it will just launch silently without any warning.  But if you actually tried to download such a file from a website or save/open it from an email attachment, Windows Attachment Execution Service (introduced with Windows XP SP2) will warn you that it is an executable which is actually more explicit and obvious than hoping the user understands what three letter file extensions qualify as an executable.

To prove the point, I downloaded a file called test.txt.cmd from my own website.  You can download the zipped version here and verify for yourself.  I decompressed the file and launched the file and I got the following warning.  Had someone emailed me this file, I would have gotten the exact same warning.  In light of this warning, there is no chance I would mistaken this file as a plain old .TXT text file.

Furthermore, if the executable had required system-level privileges, I would have gotten an additional UAC warning message in either Windows Vista or Windows 7.

Now I am not suggesting that hiding file extensions is a good thing.  In fact, I hate it and I always disable that feature on any Windows computer I use.  But I do not think it’s accurate to portray this as a security failure in Windows 7 or anything after Windows XP SP2.

One of the things I keep noticing, is that Microsoft “enterprise stack” of applications almost all seem to need a hole straight into the LAN from the outside to work right. This is rediculous. Why did I bother setting up a DMZ and a firewall, when every application needs direct access to the inner circle? I know why this is… all of these applications rely upon Kerberos, domain membership, Active Directory, and other things that don’t play nicely through a firewall. But still, this is a dumb situation. Microsoft needs to respect my network topology. The last thing I want is for a problem with Exchange, OCS, etc. to become a security exploit in the middle of my LAN.

J.Ja

I’ve been privately talking about the theoretical dangers of HTTPS hacking with the developers of a major web browser since 2006 and earlier last month, I published my warnings about HTTPS web hacking along with a proposed solution.  A week later, Google partially implemented some of my recommendations in an early Alpha version of their Chrome 2.0 browser by implementing a client-side list of websites that should only operate in secure HTTPS mode regardless of any redirection trickery.  This week at the Black Hat security conference in Washington DC, Moxie Marlinspike released a tool called SSL Strip which exploits the weak manner in which SSL is implemented in HTTPS (PDF presentation from Black Hat) which means the vulnerability is no longer just theoretical.  Since this issue is fairly complex, I’ll try to summarize it in a nutshell in this article.

The problems with HTTPS

Web browsers always start off using HTTP which has zero security.  No one actually manually types in “HTTPS” or “HTTP” and they generally just type “gmail.com” for example and expect the web browser to magically re-route them to a secure sign-in.  Unfortunately, that relies on a mechanism that redirects the user from an insecure HTTP page to a secure HTTPS page.  Yet this redirect can easily be blocked by a hostile man-in-the-middle which is exactly what SSL Strip does.  This means the user never gets taken to the secure authentication page leaving their username and password in the clear for the hijacker to see and take.

The user could in theory recognize that they were not redirected to a secure website and the web browser could even try to give the user positive feedback about a secure website with icons like a padlock or light up the address bar green or some other color, but nearly all end users ignore these signs.  That means in practice, relying on people to ensure their own security and safety will almost always result in failure.

It is time we think outside the box beyond ineffective positive or negative feedback systems and do this seamlessly and automatically for the end user.  When we think about all other implementations of SSL such as SSLVPN or Outlook email over SSL, we don’t expect end users to make security decisions on what a digital certificate should look like or whether there should be one at all.  To do this for the HTTPS web browser implementation of SSL is simply a way of shifting the IT responsibility to the end user which not only poses undue burden on the end user, but almost certainly ensures that the wrong security decision will be made.

How to make HTTPS secure

There needs to be an automated mechanism that ensures the end user’s security which requires zero knowledge or participation from the end user to work.  We can create such a secure mechanism with minor changes to DNS and web browsers.  First, we use DNS to publish a list of websites that must operate in HTTPS through custom DNS records.  Second, the web browser will automatically force a connection to an HTTPS page if instructed to do so by DNS and it will maintain a list of websites that are only to operate in secure HTTPS mode.  We do this second part because we cannot always assume that DNS is trustworthy especially in the case of wireless hotspots.  The DNS mechanism would only work as a toggle on to force HTTPS for all future web browsing sessions but it would not be permitted to toggle off HTTPS unless it was a trustworthy DNSSEC server.  This means that once a user successfully visits a secure website for the first time, they will always remain secure for that website even if they cannot trust the DNS server they’re using on public wireless hotspots.

However, this leaves open the possibility that a user in an untrusted network with a hostile DNS server might connect to a new website they’ve never connected to before in an insecure manner.  This is a relatively small vector of attack with a very small window of opportunity for success, but this too could be mitigated to a certain extent.  Web browsers could come with a pre-populated list of HTTPS-only websites, but maintaining a list of every website in the world would be difficult.  However, we could at least cover all the major sites like Gmail, Hotmail, and every online banking and shopping establishment.  We could also mitigate this problem with DNSSEC if the end user was hard coded to a trusted DNSSEC server, but this would be difficult to manage and the mechanism wouldn’t work if the malicious wireless hotspot blocked off all access to external DNS or DNSSEC servers.

The bottom line is that if we can lock down 99% of the secure websites that people are likely to visit, we can minimize the danger of stolen user credentials and security breaches.  Now that there is a real and tangible threat to HTTPS in the form of a tool like SSL Strip that hijacks any HTTPS website, the time to act on these recommendations for securing HTTPS is now.  We need leadership from Microsoft, Mozilla, Apple, and Google today to secure the most important application on the Internet today.  Google has already made some strides with a partial implementation, but we need a full implementation of these recommendations and we need everyone to jump on board.

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.

I just spent an hour trouble shooting my mother’s computer over the phone.  Apparently, all the certificates were throwing up errors and giving the scary message that someone might be hijacking your computer session.  One thing I forgot to check was the date on the computer which got reset and the date mismatch was forcing every secure website to report scary messages.

This is one of those things I just want to scream at Microsoft developers for in the way they changed Internet Explorer 7.  IE6 use to tell you if the certificate was legitimate but it had a bad date which easily tipped you off.  Now Microsoft gives you an inline web message that doesn’t let you inspect the certificate unless you hit continue anyways accept the certificate.  Like many things in Windows Vista, Microsoft has crippled and dumb down the new interface making it far less useful.

Windows XP use to have a simple status on the network connection icon which lets you see the IP address and now I have to bark out start-run-cmd-ipconfig orders letter by letter whenever I’m doing troubleshooting.  Just wait till we get IPv6 when we get to bark out those long 128-bit addresses instead of the simple 32-bit address and I’m glad I’m not doing helpdesk support.

The fundamental problem with the web browser and SSL is that the browser allows the user to ignore the certificates at all an no amount of green-lit extended trust nonsense is going to fix that.  The whole certificate expiration thing was a horrible tradeoff that makes the system unfriendly and expensive because you’re forced to spend hundreds of dollars a year on certificates.  The system is prioritized on making certificate authorities rich and consumer security comes second.  It’s not that I have a problem with companies making a profit, but the whole certificate business model of forcing you to buy every single certificate rather than delegate a signing authority to your domain like DNSSEC is just too draconian.

Anyhow, that’s my fuming for the day.

I know it is short notice, but I will be participating in a 1 hour Webcast today on the topic of email security. You can sign up for it at TechRepublic. Hope this isn’t too short of a notice for you to listen in!

J.Ja