Protecting users from malicious downloads

Posted by Moheeb Abu Rajab, Google Security Team

For the past five years Google has been offering protection to users against websites that attempt to distribute malware via drive-by downloads — that is, infections that harm users’ computers when they simply visit a vulnerable site. The data produced by our systems and published via the Safe Browsing API is used by Google search and browsers such as Google Chrome, Firefox, and Safari to warn users who may attempt to visit these dangerous webpages.

Safe Browsing has done a lot of good for the web, yet the Internet remains rife with deceptive and harmful content. It’s easy to find sites hosting free downloads that promise one thing but actually behave quite differently. These downloads may even perform actions without the user’s consent, such as displaying spam ads, performing click fraud, or stealing other users’ passwords. Such sites usually don’t attempt to exploit vulnerabilities on the user’s computer system. Instead, they use social engineering to entice users to download and run the malicious content.

Today we’re pleased to announce a new feature that aims to protect users against these kinds of downloads, starting with malicious Windows executables. The new feature will be integrated with Google Chrome and will display a warning if a user attempts to download a suspected malicious executable file:

Download warning

This warning will be displayed for any download URL that matches the latest list of malicious websites published by the Safe Browsing API. The new feature follows the same privacy policy currently in use by the Safe Browsing feature. For example, this feature does not enable Google to determine the URLs you are visiting.

We’re starting with a small-scale experimental phase for a subset of our users who subscribe to the Chrome development release channel, and we hope to make this feature available to all users in the next stable release of Google Chrome. We hope that the feature will improve our users’ online experience and help make the Internet a safer place.

For webmasters, you can continue to use the same interface provided by Google Webmaster Tools to learn about malware issues with your sites. These tools include binaries that have been identified by this new feature, and the same review process will apply.

Improving SSL certificate security

Posted by Ben Laurie, Google Security Team

In the wake of the recent Comodo fraud incident, there has been a great deal of speculation about how to improve the public key infrastructure, on which the security of the Internet rests. Unfortunately, this isn’t a problem that will be fixed overnight. Luckily, however, experts have long known about these issues and have been devising solutions for some time.

Given the current interest it seems like a good time to talk about two projects in which Google is engaged.

The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this:

$ openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -outform DER | openssl sha1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
405062e5befde4af97e9382af16cc87c8fb7c4e2
$ dig +short 405062e5befde4af97e9382af16cc87c8fb7c4e2.certs.googlednstest.com TXT
"14867 15062 74"

In other words: take the SHA-1 hash of the certificate, represent it as a hexadecimal number, then look up a TXT record with that name in the certs.googlednstest.com domain. What you get back is a set of three numbers. The first number is the day that Google’s crawlers first saw that certificate, the second is the most recent day, and the third is the number of days we saw it in between.

In order for the hash of a certificate to appear in our database, it must satisfy some criteria:

• It must be correctly signed (either by a CA or self-signed).
• It must have the correct domain name — that is, one that matches the one we used to retrieve the certificate.

The basic idea is that if a certificate doesn’t appear in our database, despite being correctly signed by a well-known CA and having a matching domain name, then there may be something suspicious about that certificate. This endeavor owes much to the excellent Perspectives project, but it is a somewhat different approach.

Accessing the data manually is rather difficult and painful, so we’re thinking about how to add opt-in support to the Chrome browser. We hope other browsers will in time consider acting similarly.

The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality.

One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification.

It will be some time before DNSSEC is deployed widely enough for DANE to be broadly useful, since DANE requires every domain to be able to use DNSSEC. However, work is on the way to use DNSSEC for the Certificate Catalog well before the entire DNSSEC infrastructure is ready. If we publish a key for the domain in which we publish the catalog, clients can simply incorporate this key as an interim measure until DNSSEC is properly deployed.

Improving the public key infrastructure of the web is a big task and one that’s going to require the cooperation of many parties to be widely effective. We hope these projects will help point us in the right direction.