Stacking Fault

Google Using SSLv2 and an Expired Cert?

Popular web search engine Google appears to be the latest in a string of companies who are not paying attention to certificate expiration dates. Connecting to Google's web site using HTTPS (HTTP over SSL) results in a SSL v2 connection using an expired certificate. (You can try it yourself by clicking over to https://www.google.com/.) Using an expired certificate is considered "bad form" in the secure web server world, though many hundreds (if not hundreds of thousands) of sites do it every day. But requiring a SSL Version 2 connection is downright dangerous.

Certificates are digital documents that carry a nebulous concept of "trust." The idea is that if everyone trusts a certificate's issuer, the cryptographic dead chickens waved over the certificate can transfer that trust to a third party. How this works in the web serving world is a "secure" server operator generates a public / private key pair and asks a well-known, trusted third party to digitally sign his public key. The well-known, trusted third party distributes their well-known, trusted public key far and wide (it's usually embedded in your web browser.)

When you attempt to connect to the "secure" server in our thought experiment, the server authenticates itself to you using it's public / private key pair. Your browser then authenticates the "secure" server's public key with the public key from the well-known, trusted third part (which was compiled into the browser when it was forged from molten bits at the browser-forge.)

X.509 Certificates are the standard mechanism for carrying the public keys that make this trust network work. They are a number of problems with X.509 certificates, but for the most part, web operators have figured out how to work around most of the problems. (For the curious, Peter Gutmann has a good overview of issues in implementing X.509 at his page: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.)

There are a pair of fields inside certificates that describe the validity period for a certificate. Before the "valid from" date the certificate is premature. After the "valid to" date and there's concern the certificate's public key has been too exposed to attack attempts. The theory behind using X.509 certificates tells us that it's good practice to change your public / private key pairs every so often to help mitigate the risk that an attacker has successfully broken, borrowed, or stolen the private key. Is it likely an attacker is going to reverse engineer a private key from a public key? Probably not, but the math keeps getting better every year. At the time this post is being composed, there are no known attacks that can derive a 2048 bit private key from it's associated public key in anything close to a tractable amount of time.

But information security specialists and cryptographers are notoriously paranoid. That's why we choose really big keys and like to change our keys frequently. There's always the possibility that the RSA cryptosystem will be effectively broken tomorrow. It may be an advance in our fundamental understanding of mathematics, or it might be a quantum computer that can factor large numbers faster than we ever imagined. Or, more likely, an adversary might "shoulder surf" the password for a server's private key, giving them the ability to impersonate that secure server.

How do we protect ourselves against these possibilities (some might say eventualities?) We expire our certificates and generate new keys.

But there's a down side to this process. It requires server operators to seriously consider operational issues surrounding the generation and installation of new certificates. In short, if you want to have a secure server, you should plan on renewing your certificates every now and again. Put a reminder in your day timer, or use a PDA to help you remember that a couple weeks before your certificates expire, you should get new ones.

Perhaps more concerning is Google's use of Version 2 of SSL. SSL Version 2 is inherently dangerous. It is vulnerable to a series of attacks, all of them bad. In modern times, there are few who use SSLv2; most have already migrated to SSLv3 or TLS (Transport Layer Security.) Requiring clients use SSL version 2 is an extremely bad move. It offers no benefit and dramatically increases the attack surface offered to malicious attackers.

So what should we learn from this?

The first thing we should learn is even the big guys get it wrong every now and again. Should anyone tell you it's okay to use an expired certificate or use SSLv2 because that's what Google did, ignore them. They're wrong. Very, very, very wrong.

The second thing we should learn is never forget to renew your certificates. Certificates are the basic "vehicles of cryptographic trust" on the internet. If you have problems remembering things, buy a day-timer and write yourself a "to do" a couple weeks before your certificate expires.

And the last thing? Never use SSLv2. A lot of really smart people sat down and thought about problems with SSLv2. In the end they decided it was broken enough to warrant a follow-on protocol. You may not be smart enough to break SSLv2, and the guy maintaining your web server may not be smart enough to break SSLv2, but there are people out there who are, and some of them aren't nice people.

Did I mention Never use SSLv2? Good, because it's really important.

posted by Matthew S. Hamrick @ 12:00 PM 0 comments  

A Few Quick Notes about Unix Security in Large Installations

NewsForge recently posted a story on their site entitled Tackling Unix security in large organizations, part 1. While it's great to see people taking the time to write about Unix security, we believe that most of the conclusions in the article are inaccurate. We're adding a few notes about our thoughts of Unix security in an effort to reverse any damage done to the Unix community by NewsForge's article.

In the article, the author writes "In large heterogeneous Unix/Linux environments with several hundred servers, keeping up to date with security patches, which are the number one requirement for strong security, is next to impossible." While we agree with the sentiment, there are a number of products that maintain a database of which computers are running which operating systems or applications, and in conjunction with agents on the systems help administrators manage the complexity of distributing the right patches to the right machines. Shavlik Technologies sells a cross-platform patch management solution that's been getting quite a bit of buzz lately. And yes, it even supports Unix.

At most large installations, there will likely be one or two legacy applications that have to run on a particular revision of the host operating system. If the host operating system on such machines is no longer supported by the OS vendor, administrators have a true problem. Patch management solutions will offer little help for vulnerabilities on such systems; administrators are likely to know exactly what the vulnerabilities are. The solution for such systems is to isolate them as much as possible, reducing the likelihood an outside attacker can access the network on which these systems operate.

Later in the article, the author writes "real challenge is to prevent attackers from getting a local command line login." There's a maxim in computer security that if an attacker can run code on your machine, it's as good as 0wn3d. We're starting to see work on systems like TrustedBSD, SE/Linux, and STOSDarwin which should reduce the likelihood of a local user successfully attacking the OS from the inside, but the sad truth is, you've got to be able to trust your users.

One aspect of attack dynamics the author did not touch on was the use of a compromised machine on a "secure" network to attack other machines on the same network. Packet sniffers like Ethereal are easy to setup and actually quite useful for debugging applications in development and deployment. So making a blanket proclamation that "no sniffers will be used on the production machines" is going to limit your operations staff. Maybe a better way to express your policy is, "only Bob, our trusted application developer, gets to use the sniffer."

There are a number of techniques for limiting a user's access to device files that would allow them to pop a machine's ethernet adapter over into promiscuous mode, but one can imagine an unforeseen vulnerability that would allow a malicious user to sidestep these permissions. There's also the problem that if you're working on a multi-user machine, an attacker may not have to set the network adapter into promiscuous mode to sniff passwords bound for the compromised machine.

This is why SSH is so popular. SSH is like telnet, only it encrypts the session. Cryptographic server authentication is available with most implementations of SSH, as are multiple user authentication techniques. OpenSSH is a great tool, but it suffers from key management problems when used in a large environment. SSH.Com has re-branded their version of SSH as Tectia, and for good reason. The Tectia implementation offers a number of key management solutions not found in OpenSSH, including the use of X.509 certificates and hardware tokens.

Another step your IT staff can take to reduce the risk of successful attack is to use a One Time Password solution. Not to be confused with the "One Time Pad," One Time Password solutions like those offered by RSA SecurID, CryptoCard, or Priva-Tech use a secure user-specific token to hold a shared secret that is used to generate a session-specific password. Each time someone logs into a machine, a different password is used to authenticate them. The important bit, the shared secret, is locked inside a hardware token so it will never fly across the network, possibly to be intercepted by a malicious attacker.

posted by Matthew S. Hamrick @ 5:00 PM 0 comments