Google Online Security Blog

Safe Browsing Alerts for Network Administrators

28 septembre 2010

Posted by Nav Jagpal and Ke Wang, Security Teamattempt to notifyWebmaster Tools featureGoogle Safe Browsing Alerts for Network AdministratorsAutonomous Systemsafebrowsingalerts.googlelabs.com

Moving security beyond passwords

20 septembre 2010

Posted by Travis McCoy, Product Manager, Google Security Team

Entering your username and password on a standard website gives you access to everything from your email and bank accounts to your favorite social networking site. Your passwords possess a lot of power, so it's critical to keep them from falling into the wrong hands. Unfortunately, we often find that passwords are the weakest link in the security chain. Keeping track of many passwords is a pain, and unfortunately accounts are regularly compromised when passwords are too weak, are reused across websites, or when people are tricked into sharing their password with someone untrustworthy. These are difficult industry problems to solve, and when re-thinking the traditional username/password design, we wanted to do more.

As we explained today on our Google Enterprise Blog, we've developed an option to add two-step verification to Google Apps accounts. When signing in, Google will send a verification code to your phone, or let you generate one yourself using an application on your Android, BlackBerry or iPhone device. Entering this code, in addition to a normal password, gives us a strong indication that the person signing in is actually you. This new feature significantly improves the security of your Google Account, as it requires not only something you know: your username and password, but also something that only you should have: your phone. Even if someone has stolen your password, they'll need more than that to access your account.

blog serieshttp://www.staysafeonline.org/

Stay safe while browsing

16 septembre 2010

Posted by Panayiotis Mavrommatis and Niels Provos, Security Team
We are constantly working on detecting sites that are compromised or are deliberately set up to infect your machine while browsing the web. We provide warnings on our search results and to browsers such as Firefox and Chrome. A lot of the warnings take people by surprise — they can trigger on your favorite news site, a blog you read daily, or another site you would never consider to be involved in malicious activities.

In fact, it’s very important to heed these warnings because they show up for sites that are under attack. We are very confident with the results of our scanners that create these warnings, and we work with webmasters to show where attack code was injected. As soon as we think the site has been cleaned up, we lift the warning.

This week in particular, a lot of web users have become vulnerable. A number of live public exploits were attacking the latest versions of some very popular browser plug-ins. Our automated detection systems encounter these attacks every day, e.g. exploits against PDF (CVE-2010-2883), Quicktime (CVE-2010-1818) and Flash (CVE-2010-2884).

We found it interesting that we discovered the PDF exploit on the same page as a more “traditional” fake anti-virus page, in which users are prompted to install an executable file. So, even if you run into a fake anti-virus page and ignore it, we suggest you run a thorough anti-virus scan on your machine.

We and others have observed that once a vulnerability has been exploited and announced, it does not take long for it to be abused widely on the web. For example, the stack overflow vulnerability in PDF was announced on September 7th, 2010, and the Metasploit project made an exploit module available only one day later. Our systems found the vulnerability abused across multiple exploit sites on September 13th.

Here’s a few suggestions for protecting yourself against web attacks:

Keep your OS, browser, and browser plugins up-to-date.
Run anti-virus software, and keep this up-to-date, too.
Disable or uninstall any software or browser plug-ins you don’t use — this reduces your vulnerability surface.
If you receive a PDF attachment in Gmail, select “View” to view it in Gmail instead of downloading it.

Vulnerability trends: how are companies really doing?

30 août 2010

Posted by Adam Mein, Google Security Teamissued a correctionterminology mix-up

Vendors disclose their vulnerabilities in inconsistent formats, using different severity classifications. This makes the process of measuring the number of total vulnerabilities assigned to a given vendor much more difficult.

Assessing the severity, scope, and nature of a bug sometimes requires intimate knowledge of a product or technology, and this can lead to errors and misinterpretation.

Keeping the fix status updated for thousands of entries is no small task, and we’ve consistently seen long-fixed errors marked as unfixed in a number of databases.

Not all compilers of vulnerability databases perform their own independent verification of bugs they find reported from other sources. As a result, errors in one source can be replicated to others.

Rebooting Responsible Disclosure: a focus on protecting end users

20 juillet 2010

Posted by Chris Evans, Eric Grosse, Neel Mehta, Matt Moore, Tavis Ormandy, Julien Tinnes, Michal Zalewski; Google Security Team 2001 post by Bruce Schneier

0-day attacks that rely on vulnerabilities known to the vendor for a long while.

Situations where it became clear that a vulnerability was being actively exploited in the wild, subsequent to the bug being fixed or disclosed.

Chromium severity guidelinesMozilla severity ratings

Placing a disclosure deadline on any serious vulnerability they report, consistent with complexity of the fix. (For example, a design error needs more time to address than a simple memory corruption bug).

Responding to a missed disclosure deadline or refusal to address the problem by publishing an analysis of the vulnerability, along with any suggested workarounds.

Setting an aggressive disclosure deadline where there exists evidence that blackhats already have knowledge of a given bug.

Update September 10, 2010: We'd like to clarify a few of the points above about how we approach the issue of vulnerability disclosure. While we believe vendors have an obligation to be responsive, the 60 day period before public notification about critical bugs is not intended to be a punishment for unresponsive vendors. We understand that not all bugs can be fixed in 60 days, although many can and should be. Rather, we thought of 60 days when considering how large the window of exposure for a critical vulnerability should be permitted to grow before users are best served by hearing enough details to make a decision about implementing possible mitigations, such as disabling a service, restricting access, setting a killbit, or contacting the vendor for more information. In most cases, we don't feel it's in people's best interest to be kept in the dark about critical vulnerabilities affecting their software for any longer period.
Update May 12, 2021: February 2015, Google's responsible discloure policy was adjusted to 90 days. View our current policy here.

Extending SSL to Google search

21 mai 2010

Posted by Murali Viswanathan, Product Managerdefault settinghttps://www.google.comOfficial Google Blog

Do Know Evil: web application vulnerabilities

4 mai 2010

Posted by Bruce Leban, Software EngineerUPDATE July 13: We have changed the name of the codelab application to Gruyere. The codelab is now located at http://google-gruyere.appspot.com.Google Code UniversityGoogle Labshttp://google-gruyere.appspot.comGoogle Code University

The Rise of Fake Anti-Virus

14 avril 2010

Posted by Niels Provos, Security Team

The Nocebo Effect on the Web: An Analysis of Fake AV distributionWorkshop on Large-Scale Exploits and Emergent Threats

trusted companies

The chilling effects of malware

30 mars 2010

Posted by Neel Mehta, Security Teamdiscussedsuspicious account activity alerts

Phishing phree

30 mars 2010

Posted by Colin Whittaker, Anti-Phishing Team phishingSafeBrowsing APIpaper17th Annual Network and Distributed System Security SymposiumWhat we look for

Our system analyzes a number of webpage features to help make a verdict about whether a site is a phishing site. Starting with a page’s URL, we look to see if there is anything unusual about the host, such as whether the hostname is unusually long or whether the URL uses an IP address to specify the host. We also look to see if the URL contains any phrases like “banking” or “login” that might indicate that the page is trying to steal information.

We don’t just look at the URL, though. After all, a perfectly legitimate site could certainly use words like “banking” or “login.” We collect a snapshot of the page’s content to examine it closely for phishing behavior. For example, we check to see if the page has a password field or whether most of the links point to a common phishing target, as both of these characteristics can be a sign of phishing. Additionally, we pick out some of the most characteristic terms that show up on a page (as defined by their TF-IDF scores), and look for terms like “password” or “PIN number,” which also may indicate that the page is intended for phishing.

We also check the page’s hosting information to find out which networks host the page and where the page’s servers are located geographically. If a site purporting to be an American bank runs its servers in a different country and is hosted on a local residential ISP’s network, we have a strong signal that the site is bad.

Finally, we check the page’s PageRank to see if the page is popular or not, and we check the spam reputation of the page’s domain. We discovered in our research findings that almost all phishing pages are found on domains that almost exclusively send spam. You can observe this trend in the CCDF graph of the spam reputation scores for phishing pages as compared to the graph of other, non-phishing pages.

How we learn to recognize phishing pages
We use a sample of the data that our system generates to train the classifier that lies at the core of our automatic system using a machine learning algorithm. Coming up with good labels (phishing/not phishing) for this data is tricky because we can’t label each of the millions of pages ourselves. Instead, we use our published phishing page list, largely generated by our classifier, to assign labels for the training data.

You might be wondering if this system is going to lead to situations where the classifier makes a mistake, puts that mistake on our list, and then uses the list to learn to make more mistakes. Fortunately, the chain doesn’t make it that far. Our classifier only makes a relatively small number of mistakes, which we can correct manually when you report them to us. Our learning algorithms can handle a few temporary errors in the training labels, and the overall learning process remains stable.

How well does this work?

Of the millions of webpages that our scanners analyze for phishing, we successfully identify 9 out of 10 phishing pages. Our classification system only incorrectly flags a non-phishing site as a phishing site about 1 in 10,000 times, which is significantly better than similar systems. In our experience, these “false positive” sites are usually built to distribute spam or may be involved with other suspicious activity. While phishers are constantly changing their strategies, we find that they do not change them enough to reliably escape our system. Our experiments showed that our classification system remained effective for over a month without retraining.

If you are a webmaster and would like more information about how to keep your site from looking like a phishing site, please check out our post on the Webmaster Central Blog. If you find that your site has been added to our phishing page list ("Reported Web Forgery!") by mistake, please report the error to us.

Security Blog