trust on the internet takes (another) hit

SSL certificates are supposed to provide users with assurance that the sites they are browsing are legitimate. When you go to your online banking web site via https and see the reassuring lock in the address bar which tells you that the site is really your bank, it is the SSL certificate system which provides this indication. Each certificate is signed by a series of trusted authorities which vouch for its authenticity.

When you buy an SSL certificate, the registrar from which you make the purchase is supposed to make sure that you are, in fact, who you say you are. For example, if I were to order a cert for http://www.consolidatedamalgamated.com, the registrar would require me to provide some evidence that I was in fact representing Consolidated Amalgamated and that CA was a legitimate company. Only after doing this due diligence would the signed certificate be issued, thus providing users with assurance that the sites they are visiting are, in fact legitimate.

The fragility of this system for supporting trust on the Internet was spotlighted on March 15th, when an attack on the SSL certificate system resulted in a number of fraudulent certificates being issued for sites which millions of people worldwide use every day.

The attack was detected by Jacob Applebaum, a third party security researcher who noticed that Mozilla and Google had pushed out patches to the Firefox and Chrome browsers revoking the validity of a number of SSL certificates issued by an affiliate of Comodo, one of the Certificate Authorities empowered to issue certs. Comodo (and other CAs) typically subcontract the sales and verification of SSL certs to other companies called Registration Authorities or RAs. The attackers appear to have gotten access to credentials used by one of Comodo’s RAs to request new certificates once the checks were complete. They used this information to request 9 different certificates for well known communications related domains such as yahoo.com, google.com, skype.com and live.com.

So why would an attacker do this? Primarily to be able to intercept credentials and communications between users and the web sites for which they spoofed certificates by enticing users to visit the fraudulent web sites instead of the legitimate ones. Once a user has logged on to their Yahoo Mail account via a site with one of these spoofed certs, they would see the familiar lock icon telling them that they were really talking to Yahoo and that their communications were secure, when in fact, the attackers were routing all of their traffic through systems under their control. The attackers would be able to harvest credentials and read the victims’ emails without tipping them off to the attack. The attackers also registered a certificate for “addons.mozilla.com” which would have allowed them to trick users into installing malicious browser extensions for Firefox. To top off the attack, they also registered a certificate for a new certificate authority called “Global Trustee” which would have allowed them to issue legitimate looking certificates on their own.

The Comodo attack appears to have originated from an IP address located in Iran, which raises an interesting question. Were the attackers simply run of the mill cyber criminals who wanted to use the information gathered for profit, or was this a state sponsored attack aimed at compromising the communications of opponents of the Iranian regime? Given the recent unrest in the Middle East and the key role played by social media, the Iranian government would probably be really interested in reading the mail or listening to the Skype calls of opposition figures. Of course, the attackers might have been located somewhere else and used Iranian proxy systems to make the attacks look like they were coming from Iran.

The attack points out a number of issues with the current SSL web of trust. First, the delegated nature of the system means that it is only as strong as the weakest link – in this case the security of the registration authorities. Second, the mechanism for revoking certificates has some serious drawbacks. There are basically two ways for registrars to let users’ browsers know that certificates are invalid – one method is called Certificate Revocation Lists and the other is called Online Certificate Status Protocol. In theory, browsers use these protocols to check the validity of each certificate they receive. In theory. In reality, in their default configurations, browsers will allow certificates to be used even if they are unable to get certificate status for them – this is a “fail open” situation. Should an attacker combine the creation of fraudulent certificates with a denial of service attack against a CA’s CRL or OCSP infrastructures, millions of users browsers would happily accept the fake certs without a peep.

In order to provide users with protection against this attack, the browser vendors had to issue updates to their software which included the bad certificate numbers in the local Certificate Revocation Lists. This puts the onus on the user, and I have seen enough users who don’t bother to update browser software to wonder just how many people are still vulnerable to this attack.

Requiring CAs to maintain robust infrastructures for OCSP and CRL checking by browsers and configuring browsers to require positive CA validation of certificates would go a long way towards fixing this issue in the short term, but such a solution has its own price in terms of privacy. As a result of their certificate checking functions, CAs would become able to track the web browsing habits of millions of internet users. Such a fix would also require a significant investment in infrastructure by the CAs, which could lead to higher prices for certificates.

The Internet was a very different animal when SSL was invented. Today’s internet is at the core of economic and social life and it needs to be protected in a way which is in line with that role. Hopefully, this incident will spur development of a new, more robust trust infrastructure for the internet.

trust on the internet takes (another) hit

app stores and security

As personal handheld devices like smartphones and tablets become part of employees’ technical arsenals, the security of those devices begins to impact the corporate environment.  No matter how many times we tell people not to store sensitive corporate information on these devices, there will always be a subset of people who do so.  They are not being malicious; rather they see these new technologies as a way to improve their productivity and are frustrated with corporate IT departments’ unwillingness or inability to support them.

Once corporate information is on these devices, security professionals need to be concerned about not only the inherent security of the device, but the trustworthiness of totally unrelated applications which the employee installs on their device. 

In the past week, Google removed more than 50 applications from the Android Market after a user discovered that they were actually pirated versions of popular Android applications which had been modified to contain a piece of malware dubbed “DroidDream,” which sends the attacker a variety of information about the device it is installed on and more importantly, provides a mechanism allowing the attacker to load and execute additional code onto the phone or tablet.

To Google’s credit, they reacted to this news quite quickly – within minutes of being notified of the problem, they removed the malware laden applications from the Android Market and later sent commands to all Android devices to remove the applications from users devices.  However, over 50,000 downloads of the rogue applications were made prior to the discovery of the malware and it is unknown how many of the affected users’ devices may have downloaded additional nefarious applications which were not removed by Google’s actions.

The basic problem here is that the structure of Android Market does not include any review of applications prior to their being put on sale.  Say what you like about Apple’s draconian control of its iOS platforms and App Store, but the App Store is much more likely to catch and prevent the distribution of malware than Android Market.

Of course, iOS users who decide to “jailbreak” their devices, thus allowing them to install applications from third parties outside of the App Store are just as much at risk as Android Market users.  Jailbreaking an iOS device is very easy and users may be tempted to jailbreak in order to obtain software which is not available from the App Store. 

All of this complicates life for the corporate IT manager who wants to make these amazing new devices part of their IT ecosystem.  If users are allowed to use their personal devices for corporate business, we need to worry about what applications they are installing on these devices.  As they are not corporate owned or controlled, we can’t really tell people what apps they should or should not install or prohibit them from jailbreaking their device.  If we decide to roll out corporate owned iOS and Android devices, we end up with new platforms to support without the security and configuration tools which allow us to protect our desktop and laptop computing devices.

So what do we do?  For now, I think that educating our users about the risks they face while using their personal devices is job one.  We need to make users understand that jailbreaking an iOS device significantly reduces the level of security on the device.  We need to explain to users that Android applications are not pre reviewed in any meaningful way by Google.

As far as enterprise use of these new devices, I think that Google and Apple need to get working on some enterprise management software that allows corporations to securely configure and manage these devices.  Ideally, it should be possible to create a separate encrypted corporate partition where work information is stored.  This partition should need to periodically phone home to check to make sure that the device is still authorized to access corporate information and to pick up policy updates.

Consumer devices are clearly the wave of the future in enterprises – but we need help from the vendors to make these devices safe for corporate use.

app stores and security