Posted by Drew Hintz, Security Engineer and Justin Kosslyn, Google Ideas

[Cross-posted on the Official Google Blog]

Would you enter your email address and password on this page?

This looks like a fairly standard login page, but it’s not. It’s what we call a “phishing” page, a site run by people looking to receive and steal your password. If you type your password here, attackers could steal it and gain access to your Google Account—and you may not even know it. This is a common and dangerous trap: the most effective phishing attacks can succeed 45 percent of the time, nearly 2 percent of messages to Gmail are designed to trick people into giving up their passwords, and various services across the web send millions upon millions of phishing emails, every day.

To help keep your account safe, today we’re launching Password Alert, a free, open-source Chrome extension that protects your Google and Google Apps for Work Accounts. Once you’ve installed it, Password Alert will show you a warning if you type your Google password into a site that isn’t a Google sign-in page. This protects you from phishing attacks and also encourages you to use different passwords for different sites, a security best practice.

Here's how it works for consumer accounts. Once you’ve installed and initialized Password Alert, Chrome will remember a “scrambled” version of your Google Account password. It only remembers this information for security purposes and doesn’t share it with anyone. If you type your password into a site that isn't a Google sign-in page, Password Alert will show you a notice like the one below. This alert will tell you that you’re at risk of being phished so you can update your password and protect yourself.

Password Alert is also available to Google for Work customers, including Google Apps and Drive for Work. Your administrator can install Password Alert for everyone in the domains they manage, and receive alerts when Password Alert detects a possible problem. This can help spot malicious attackers trying to break into employee accounts and also reduce password reuse. Administrators can find more information in the Help Center.

We work to protect users from phishing attacks in a variety of ways. We’re constantly improving our Safe Browsing technology, which protects more than 1 billion people on Chrome, Safari and Firefox from phishing and other dangerous sites via bright, red warnings. We also offer tools like 2-Step Verification and Security Key that people can use to protect their Google Accounts and stay safe online. And of course, you can also take a Security Checkup at any time to make sure the safety and security information associated with your account is current. 

To get started with Password Alert, visit the Chrome Web Store or the FAQ.

Posted by Niels Provos, Distinguished Engineer, Security Team

To protect users from malicious content, Safe Browsing’s infrastructure analyzes web pages with web browsers running in virtual machines. This allows us to determine if a page contains malicious content, such as Javascript meant to exploit user machines. While machine learning algorithms select which web pages to inspect, we analyze millions of web pages every day and achieve good coverage of the web in general.

In the middle of March, several sources reported a large Distributed Denial-of-Service attack against the censorship monitoring organization GreatFire. Researchers have extensively analyzed this DoS attack and found it novel because it was conducted by a network operator that intercepted benign web content to inject malicious Javascript. In this particular case, Javascript and HTML resources hosted on baidu.com were replaced with Javascript that would repeatedly request resources from the attacked domains.

While Safe Browsing does not observe traffic at the network level, it affords good visibility at the HTTP protocol level. As such our infrastructure picked up this attack, too. Using Safe Browsing data, we can provide a more complete timeline of the attack and shed light on what injections occurred when.

For this blog post, we analyzed data from March 1st to April 15th 2015. Safe Browsing first noticed injected content against baidu.com domains on March 3rd, 2015. The last time we observed injections during our measurement period was on April 7th, 2015. This is visible in the graph below, which plots the number of injections over time as a percentage of all injections observed:

We noticed that the attack was carried out in multiple phases. The first phase appeared to be a testing stage and was conducted from March 3rd to March 6th. The initial test target was 114.113.156.119:56789 and the number of requests was artificially limited. From March 4rd to March 6th, the request limitations were removed.

The next phase was conducted between March 10th and 13th and targeted the following IP address at first: 203.90.242.126. Passive DNS places hosts under the sinajs.cn domain at this IP address. On March 13th, the attack was extended to include d1gztyvw1gvkdq.cloudfront.net. At first, requests were made over HTTP and then upgraded to to use HTTPS. On March 14th, the attack started for real and targeted d3rkfw22xppori.cloudfront.net both via HTTP as well as HTTPS. Attacks against this specific host were carried out until March 17th.

On March 18th, the number of hosts under attack was increased to include the following: d117ucqx7my6vj.cloudfront.net, d14qqseh1jha6e.cloudfront.net, d18yee9du95yb4.cloudfront.net, d19r410x06nzy6.cloudfront.net, d1blw6ybvy6vm2.cloudfront.net. This is also the first time we find truncated injections in which the Javascript is cut-off and non functional. At some point during this phase of the attack, the cloudfront hosts started serving 302 redirects to greatfire.org as well as other domains. Substitution of Javascript ceased completely on March 20th but injections into HTML pages continued. Whereas Javascript replacement breaks the functionality of the original content, injection into HTML does not. Here HTML is modified to include both a reference to the original content as well as the attack Javascript as shown below:

<html>
<head>
<meta name="referrer" content="never"/>
<title> </title>
</head>
<body>
      <iframe src="http://pan.baidu.com/s/1i3[...]?t=Zmh4cXpXJApHIDFMcjZa" style="position:absolute; left:0; top:0; height:100%; width:100%; border:0px;" scrolling="yes"></iframe>
</body>
<script type="text/javascript">
[... regular attack Javascript ...]

In this technique, the web browser fetches the same HTML page twice but due to the presence of the query parameter t, no injection happens on the second request. The attacked domains also changed and now consisted of: dyzem5oho3umy.cloudfront.net, d25wg9b8djob8m.cloudfront.net and d28d0hakfq6b4n.cloudfront.net. About 10 hours after this new phase started, we see 302 redirects to a different domain served from the targeted servers.

The attack against the cloudfront hosts stops on March 25th. Instead, resources hosted on github.com were now under attack. The first new target was github.com/greatfire/wiki/wiki/nyt/ and was quickly followed by github.com/greatfire/ as well as github.com/greatfire/wiki/wiki/dw/.

On March 26th, a packed and obfuscated attack Javascript replaced the plain version and started targeting the following resources: github.com/greatfire/ and github.com/cn-nytimes/. Here we also observed some truncated injections. The attack against github seems to have stopped on April 7th, 2015 and marks the last time we saw injections during our measurement period.

From the beginning of March until the attacks stopped in April, we saw 19 unique Javascript replacement payloads as represented by their MD5 sum in the pie chart below.

For the HTML injections, the payloads were unique due to the injected URL so we are not showing their respective MD5 sums. However, the injected Javascript was very similar to the payloads referenced above.

Our systems saw injected content on the following eight baidu.com domains and corresponding IP addresses:

• cbjs.baidu.com (123.125.65.120)
• eclick.baidu.com (123.125.115.164)
• hm.baidu.com (61.135.185.140)
• pos.baidu.com (115.239.210.141)
• cpro.baidu.com (115.239.211.17)
• bdimg.share.baidu.com (211.90.25.48)
• pan.baidu.com (180.149.132.99)
• wapbaike.baidu.com (123.125.114.15)

The sizes of the injected Javascript payloads ranged from 995 to 1325 bytes.

We hope this report helps to round out the overall facts known about this attack. It also demonstrates that collectively there is a lot of visibility into what happens on the web. At the HTTP level seen by Safe Browsing, we cannot confidently attribute this attack to anyone. However, it makes it clear that hiding such attacks from detailed analysis after the fact is difficult.

Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible. This provides further motivation for transitioning the web to encrypted and integrity-protected communication. Unfortunately, defending against such an attack is not easy for website operators. In this case, the attack Javascript requests web resources sequentially and slowing down responses might have helped with reducing the overall attack traffic. Another hope is that the external visibility of this attack will serve as a deterrent in the future.

Posted by 
Neal Mohan, VP Product Management, Display and Video Ads
Jerry Dischler, VP Product Management, AdWords

Since 2008 we’ve been working to make sure all of our services use strong HTTPS encryption by default. That means people using products like Search, Gmail, YouTube, and Drive will automatically have an encrypted connection to Google. In addition to providing a secure connection on our own products, we’ve been big proponents of the idea of “HTTPS Everywhere,” encouraging webmasters to prevent and fix security breaches on their sites, and using HTTPS as a signal in our search ranking algorithm.

This year, we’re working to bring this “HTTPS Everywhere” mission to our ads products as well, to support all of our advertiser and publisher partners. Here are some of the specific initiatives we’re working on:

• We’ve moved all YouTube ads to HTTPS as of the end of 2014.
• Search on Google.com is already encrypted for a vast majority of users and we are working towards encrypting search ads across our systems.
• By June 30, 2015, the vast majority of mobile, video, and desktop display ads served to the Google Display Network, AdMob, and DoubleClick publishers will be encrypted.
• Also by June 30, 2015, advertisers using any of our buying platforms, including AdWords and DoubleClick, will be able to serve HTTPS-encrypted display ads to all HTTPS-enabled inventory.

Of course we’re not alone in this goal. By encrypting ads, the advertising industry can help make the internet a little safer for all users. Recently, the Interactive Advertising Bureau (IAB) published a call to action to adopt HTTPS ads, and many industry players are also working to meet HTTPS requirements. We’re big supporters of these industry-wide efforts to make HTTPS everywhere a reality.

Our HTTPS Everywhere ads initiatives will join some of our other efforts to provide a great ads experience online for our users, like “Why this Ad?”, “Mute This Ad” and TrueView skippable ads. With these security changes to our ads systems, we’re one step closer to ensuring users everywhere are safe and secure every time they choose to watch a video, map out a trip in a new city, or open their favorite app.

Posted by Eric Severance, Software Engineer, Safe Browsing 

Last month, we posted about unwanted ad injectors, a common side-effect of installing unwanted software. Ad injectors are often annoying, but in some cases, they can jeopardize users’ security as well. Today, we want to shed more light on how ad injector software can hijack even encrypted SSL browser communications.

How ad injectors jeopardize security

In the example below, the ad injector software tampers with the security trust store that your browser uses to establish a secure connection with your Gmail. This can give the injector access to your personal data and make your computer vulnerable to a 'man in the middle' attack.

SSL hijacking is completely invisible to users because hijacked browser sessions appear like any other secure browser session. The screenshot on the left shows a normal connection to Gmail, the one on the right shows the difference when a SSL hijacker is installed.

You may recall the recent SuperFish/Komodia incident. As has been reported, the Komodia SSL hijacker did not properly verify secure connections and it was not using keys in a secure way. This type of software puts users at additional risk by making it possible for remote attackers to impersonate web sites and expose users’ private data.

How to stay safe

Safe Browsing protects users from several classes of unwanted software that expose users to such risk. However, it never hurts to remain cautious when downloading software or browsing the web. When you are visiting a secure site, like your email or online banking site, pay extra attention to any unusual changes to the site’s content. If you notice unusual changes, like extra ads, coupons, or surveys, this may be an indication that your computer is infected with this type of unwanted software. Please, also check out these tips to learn how you can stay safe on the web.

For software developers, if your software makes changes to the content of web sites, the safest way to make those changes is through a browser extension. This keeps users’ communications secure by relying on the browser’s security guarantees. Software that attempts to change browser behavior or content by any other means may be flagged as unwanted software.

Posted by Adrian Ludwig, Lead Engineer for Android Security

We’re committed to making Android a safe ecosystem for users and developers. That’s why we built Android the way we did—with multiple layers of security in the platform itself and in the services Google provides. In addition to traditional protections like encryption and application sandboxes, these layers use both automated and manual review systems to keep the ecosystem safe from malware, phishing scams, fraud, and spam every day.

Android offers an application-focused platform security model rooted in a strong application sandbox. We also use data to improve security in near real time through a combination of reliable products and trusted services, like Google Play, and Verify Apps. And, because we are an open platform, third-party research and reports help make us stronger and users safer.

But, every now and then we like to check in to see how we’re doing. So, we’ve been working hard on a report that analyzes billions (!) of data points gathered every day during 2014 and provides comprehensive and in-depth insight into security of the Android ecosystem. We hope this will help us share our approaches and data-driven decisions with the security community in order to keep users safer and avoid risk.

It’s lengthy, so if you’ve only got a minute, we pulled out a few of the key findings here:

• Over 1 billion devices are protected with Google Play which conducts 200 million security scans of devices per day.
• Fewer than 1% of Android devices had a Potentially Harmful App (PHA) installed in 2014. Fewer than 0.15% of devices that only install from Google Play had a PHA installed.
• The overall worldwide rate of Potentially Harmful Application (PHA) installs decreased by nearly 50% between Q1 and Q4 2014.
• SafetyNet checks over 400 million connections per day for potential SSL issues.
• Android and Android partners responded to 79 externally reported security issues, and over 25,000 applications in Google Play were updated following security notifications from Google Play.

We want to ensure that Android is a safe place, and this report has helped us take a look at how we did in the past year, and what we can still improve on. In 2015, we have already announced that we are being even more proactive in reviewing applications for all types of policy violations within Google Play. Outside of Google Play, we have also increased our efforts to enhance protections for specific higher-risk devices and regions.

As always, we are appreciate feedback on our report and suggestions for how we can improve Android. Contact us at security@android.com.

Posted by Nav Jagpal, Software Engineer, Safe Browsing

It’s tough to read the New York Times under these circumstances:

And it’s pretty unpleasant to shop for a Nexus 6 on a search results page that looks like this:

The browsers in the screenshots above have been infected with ‘ad injectors’. Ad injectors are programs that insert new ads, or replace existing ones, into the pages you visit while browsing the web. We’ve received more than 100,000 complaints from Chrome users about ad injection since the beginning of 2015—more than network errors, performance problems, or any other issue. 

Injectors are yet another symptom of “unwanted software”—programs that are deceptive, difficult to remove, secretly bundled with other downloads, and have other bad qualities. We’ve made several recent announcements about our work to fight unwanted software via Safe Browsing, and now we’re sharing some updates on our efforts to protect you from injectors as well. 

Unwanted ad injectors: disliked by users, advertisers, and publishers

Unwanted ad injectors aren’t part of a healthy ads ecosystem. They’re part of an environment where bad practices hurt users, advertisers, and publishers alike. 

People don’t like ad injectors for several reasons: not only are they intrusive, but people are often tricked into installing ad injectors in the first place, via deceptive advertising, or software “bundles.” Ad injection can also be a security risk, as the recent “Superfish” incident showed. 

But, ad injectors are problematic for advertisers and publishers as well. Advertisers often don’t know their ads are being injected, which means they don’t have any idea where their ads are running. Publishers, meanwhile, aren’t being compensated for these ads, and more importantly, they unknowingly may be putting their visitors in harm’s way, via spam or malware in the injected ads. 

How Google fights unwanted ad injectors

We have a variety of policies that either limit, or entirely prohibit, ad injectors. 

In Chrome, any extension hosted in the Chrome Web Store must comply with the Developer Program Policies. These require that extensions have a narrow and easy-to-understand purpose. We don’t ban injectors altogether—if they want to, people can still choose to install injectors that clearly disclose what they do—but injectors that sneak ads into a user’s browser would certainly violate our policies. We show people familiar red warnings when they are about to download software that is deceptive, or doesn’t use the right APIs to interact with browsers.

On the ads side, AdWords advertisers with software downloads hosted on their site, or linked to from their site, must comply with our Unwanted Software Policy. Additionally, both Google Platforms program policies and the DoubleClick Ad Exchange (AdX) Seller Program Guidelines, don’t allow programs that overlay ad space on a given site without permission of the site owner.

To increase awareness about ad injectors and the scale of this issue, we’ll be releasing new research on May 1 that examines the ad injector ecosystem in depth. The study, conducted with researchers at University of California Berkeley, drew conclusions from more than 100 million pageviews of Google sites across Chrome, Firefox, and Internet Explorer on various operating systems, globally. It’s not a pretty picture. Here’s a sample of the findings:

• Ad injectors were detected on all operating systems (Mac and Windows), and web browsers (Chrome, Firefox, IE) that were included in our test.
• More than 5% of people visiting Google sites have at least one ad injector installed. Within that group, half have at least two injectors installed and nearly one-third have at least four installed.
• Thirty-four percent of Chrome extensions injecting ads were classified as outright malware.
• Researchers found 192 deceptive Chrome extensions that affected 14 million users; these have since been disabled. Google now incorporates the techniques researchers used to catch these extensions to scan all new and updated extensions.

We’re constantly working to improve our product policies to protect people online. We encourage others to do the same. We’re committed to continuing to improve this experience for Google and the web as a whole.

Posted by Emily Schechter, Safe Browsing Program Manager

Deceptive software disguised as a useful download harms your web experience by making undesired changes to your computer. Safe Browsing offers protection from such unwanted software by showing a warning in Chrome before you download these programs. In February we started showing additional warnings in Chrome before you visit a site that encourages downloads of unwanted software.

Today, we’re adding information about unwanted software to our Safe Browsing API.

In addition to our constantly-updated malware and phishing data, our unwanted software data is now publicly available for developers to integrate into their own security measures. For example, any app that wants to save its users from winding up on sites that lead to deceptive software could use our API to do precisely that.

We continue to integrate Safe Browsing technology across Google—in Chrome, Google Analytics, and more—to protect users. Our Safe Browsing API helps extend our malware, phishing, and unwanted software protection to keep more than 1.1 billion users safe online.

Check out our updated API documentation here.

Posted by Adam Langley, Security Engineer 

On Friday, March 20th, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by an intermediate certificate authority apparently held by a company called MCS Holdings. This intermediate certificate was issued by CNNIC. 

CNNIC is included in all major root stores and so the misissued certificates would be trusted by almost all browsers and operating systems. Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 and greater would have rejected these certificates because of public-key pinning, although misissued certificates for other sites likely exist.

We promptly alerted CNNIC and other major browsers about the incident, and we blocked the MCS Holdings certificate in Chrome with a CRLSet push. CNNIC responded on the 22nd to explain that they had contracted with MCS Holdings on the basis that MCS would only issue certificates for domains that they had registered. However, rather than keep the private key in a suitable HSM, MCS installed it in a man-in-the-middle proxy. These devices intercept secure connections by masquerading as the intended destination and are sometimes used by companies to intercept their employees’ secure traffic for monitoring or legal reasons. The employees’ computers normally have to be configured to trust a proxy for it to be able to do this. However, in this case, the presumed proxy was given the full authority of a public CA, which is a serious breach of the CA system. This situation is similar to a failure by ANSSI in 2013.

This explanation is congruent with the facts. However, CNNIC still delegated their substantial authority to an organization that was not fit to hold it. 

Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of abuse and we are not suggesting that people change passwords or take other action. At this time we are considering what further actions are appropriate.

This event also highlights, again, that the Certificate Transparency effort is critical for protecting the security of certificates in the future.

(Details of the certificate chain for software vendors can be found here.)

Update - April 1: As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products. This will take effect in a future Chrome update. To assist customers affected by this decision, for a limited time we will allow CNNIC’s existing certificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist. While neither we nor CNNIC believe any further unauthorized digital certificates have been issued, nor do we believe the misissued certificates were used outside the limited scope of MCS Holdings’ test network, CNNIC will be working to prevent any future incidents. CNNIC will implement Certificate Transparency for all of their certificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.

Posted by Stephan Somogyi, Product Manager, Security and Privacy

[Cross-posted on the Google Analytics Blog]

If you run a web site, you may already be familiar with Google Webmaster Tools and how it lets you know if Safe Browsing finds something problematic on your site. For example, we’ll notify you if your site is delivering malware, which is usually a sign that it’s been hacked. We’re extending our Safe Browsing protections to automatically display notifications to all Google Analytics users via familiar Google Analytics Notifications.

Google Safe Browsing has been protecting people across the Internet for over eight years and we're always looking for ways to extend that protection even further. Notifications like these help webmasters like you act quickly to respond to any issues. Fast response helps keep your site—and your visitors—safe.

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

[Cross-posted from the Chromium Blog]

Around this time each year we announce the rules, details and maximum cash amounts we’re putting up for our Pwnium competition. For the last few years we put a huge pile of cash on the table (last year it was e million) and gave researchers one day during CanSecWest to present their exploits. We’ve received some great entries over the years, but it’s time for something bigger.

Starting today, Pwnium will change its scope significantly, from a single-day competition held once a year at a security conference to a year round, worldwide opportunity for security researchers.

For those who are interested in what this means for the Pwnium rewards pool, we crunched the numbers and the results are in: it now goes all the way up to $∞ million*.

We’re making this change for a few reasons:

• Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them. 
• Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.
• Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Logistically, we’ll be adding Pwnium-style bug chains on Chrome OS to the Chrome VRP. This will increase our top reward to $50,000, which will be on offer all year-round. Check out our FAQ for more information.

Happy hunting!

*Our lawyercats wouldn’t let me say “never-ending” or “infinity million” without adding that “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Check out the reward eligibility requirements on the Chrome VRP page.