Security Blog
The latest news and insights from Google on security and safety on the Internet
More Visible Protection Against Unwanted Software
16. Juli 2015
Posted by Moheeb Abu Rajab and Stephan Somogyi, Google Safe Browsing Team
Last year, we announced our
increased focus on unwanted software (UwS)
, and
published our unwanted software policy
. This work is the direct result of our users falling prey to UwS, and how badly it was affecting their browsing experience. Since then, Google Safe Browsing’s ability to detect deceptive software has steadily improved.
In the coming weeks, these detection improvements will become more noticeable in Chrome: users will see more
warnings
(like the one below) about unwanted software than ever before.
We want to be really clear that Google Safe Browsing’s mandate remains unchanged: we’re exclusively focused on protecting users from malware, phishing, unwanted software, and similar harm. You won’t see Safe Browsing warnings for any other reasons.
Unwanted software is being distributed on web sites via a variety of sources,
including
ad
injectors
as well as ad networks lacking strict quality guidelines. In many cases, Safe Browsing within your browser is your last line of defense.
Google Safe Browsing has protected users from phishing and malware since 2006, and from unwanted software since 2014. We provide this protection across browsers (Chrome, Firefox, and Safari) and across platforms (Windows, Mac OS X, Linux, and Android). If you want to help us improve the defenses for everyone using a browser that integrates Safe Browsing, please consider checking the box that appears on all of our warning pages:
Safe Browsing’s focus is solely on protecting people and their data from badness. And nothing else.
Announcing Security Rewards for Android
16. Juni 2015
Posted by Jon Larimer, Android Security Engineer
Since 2010, our security reward programs have helped make Google products safer for everyone. Last year, we paid
more than 1.5 million dollars
to security researchers that found vulnerabilities in Chrome and other Google Products.
Today, we're expanding our program to include researchers that will find, fix, and prevent vulnerabilities on Android, specifically. Here are some details about the new
Android Security Rewards
program:
For vulnerabilities affecting Nexus phones and tablets available for sale on Google Play (currently Nexus 6 and Nexus 9), we will pay for each step required to fix a security bug, including patches and tests. This makes Nexus the first major line of mobile devices to offer an ongoing vulnerability rewards program.
In addition to rewards for vulnerabilities, our program offers even larger rewards to security researchers that invest in tests and patches that will make the entire ecosystem stronger.
The largest rewards are available to researchers that demonstrate how to work around Android’s platform security features, like ASLR, NX, and the sandboxing that is designed to prevent exploitation and protect users.
Android will continue to participate in Google’s
Patch Rewards Program
which pays for contributions that improve the security of Android (and other open source projects). We’ve also sponsored
mobile pwn2own
for the last 2 years, and we plan to continue to support this and other competitions to find vulnerabilities in Android.
As we have often said, open security research is a key strength of the Android platform. The more security research that's focused on Android, the stronger it will become.
Happy hunting.
New Research: Some Tough Questions for ‘Security Questions’
21. Mai 2015
Posted by Elie Bursztein, Anti-Abuse Research Lead and Ilan Caron, Software Engineer
What was your first pet’s name?
What is your favorite food?
What is your mother’s maiden name?
What do these seemingly random questions have in common? They’re all familiar examples of ‘security questions’. Chances are you’ve had to answer one these before; many online services use them to help users recover access to accounts if they forget their passwords, or as an additional layer of security to
protect against suspicious logins
.
But, despite the prevalence of security questions, their safety and effectiveness have rarely been studied in depth. As part of our constant efforts to improve account security, we analyzed hundreds of millions of secret questions and answers that had been used for millions of account recovery claims at Google. We then worked to measure the likelihood that hackers could guess the answers.
Our findings, summarized in a
paper
that we recently presented at
WWW 2015
, led us to conclude that secret questions are neither secure nor reliable enough to be used as a standalone account recovery mechanism. That’s because they suffer from a fundamental flaw: their answers are either somewhat secure or easy to remember—but rarely both.
Click infographic for larger version
Easy Answers Aren’t Secure
Not surprisingly, easy-to-remember answers are less secure. Easy answers often contain commonly known or publicly available information, or are in a small set of possible answers for cultural reasons (ie, a common family name in certain countries).
Here are some specific insights:
With a single guess, an attacker would have a 19.7% chance of guessing English-speaking users’ answers to the question
"What is your favorite food?"
(it was ‘pizza’, by the way)
With ten guesses, an attacker would have a nearly 24% chance of guessing Arabic-speaking users’ answer to the question
"What’s your first teacher’s name?"
With ten guesses, an attacker would have a 21% chance of guessing Spanish-speaking users’ answers to the question,
"What is your father’s middle name?"
With ten guesses, an attacker would have a 39% chance of guessing Korean-speaking users’ answers to the question
"What is your city of birth?"
and a 43% chance of guessing their favorite food.
Many different users also had identical answers to secret questions that we’d normally expect to be highly secure, such as
"What’s your phone number?"
or
"What’s your frequent flyer number?"
. We dug into this further and found that 37% of people intentionally provide false answers to their questions thinking this will make them harder to guess. However, this ends up backfiring because people choose the same (false) answers, and actually increase the likelihood that an attacker can break in.
Difficult Answers Aren’t Usable
Surprise, surprise: it’s not easy to remember where your mother went to elementary school, or what your library card number is! Difficult secret questions and answers are often hard to use. Here are some specific findings:
40% of our English-speaking US users couldn’t recall their secret question answers when they needed to. These same users, meanwhile, could recall reset codes sent to them via SMS text message more than 80% of the time and via email nearly 75% of the time.
Some of the potentially safest questions—
"What is your library card number?"
and
"What is your frequent flyer number?"
—have only 22% and 9% recall rates, respectively.
For English-speaking users in the US the easier question,
"What is your father’s middle name?"
had a success rate of 76% while the potentially safer question
"What is your first phone number?"
had only a 55% success rate.
Why not just add more secret questions?
Of course, it’s harder to guess the right answer to two (or more) questions, as opposed to just one. However, adding questions comes at a price too: the chances that people recover their accounts drops significantly. We did a subsequent analysis to illustrate this idea (Google never actually asks multiple security questions).
According to our data, the ‘easiest’ question and answer is
"What city were you born in?"
—users recall this answer more than 79% of the time. The second easiest example is
"What is your father’s middle name?"
, remembered by users 74% of the time. If an attacker had ten guesses, they’d have a 6.9% and 14.6% chance of guessing correct answers for these questions, respectively.
But, when users had to answer both together, the spread between the security and usability of secret questions becomes increasingly stark. The probability that an attacker could get both answers in ten guesses is 1%, but users will recall both answers only 59% of the time. Piling on more secret questions makes it more difficult for users to recover their accounts and is not a good solution, as a result.
The Next Question: What To Do?
Secret questions have long been a staple of authentication and account recovery online. But, given these findings its important for users and site owners to think twice about these.
We strongly encourage Google users to make sure their Google account recovery information is current. You can do this quickly and easily with our
Security Checkup
. For years, we’ve only used security questions for account recovery as a last resort when SMS text or back-up email addresses don’t work and we will never use these as stand-alone proof of account ownership.
In parallel, site owners should use other methods of authentication, such as backup codes sent via SMS text or secondary email addresses, to authenticate their users and help them regain access to their accounts. These are both safer, and offer a better user experience.
New Research: The Ad Injection Economy
6. Mai 2015
Posted by Kurt Thomas, Spam & Abuse Research
In March, we
outlined
the problems with unwanted ad injectors, a common symptom of
unwanted software
. 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 user complaints about them in Chrome since the beginning of 2015—more than any other issue. Unwanted ad injectors are not only annoying, they can pose
serious security risks
to users as well.
Today, we’re releasing the results of a study performed with the University of California, Berkeley and Santa Barbara that examines the ad injector ecosystem, in-depth, for the first time. We’ve summarized our key findings below, as well as Google’s broader efforts to protect users from unwanted software. The full report, which you can read
here
, will be presented later this month at the
IEEE Symposium on Security & Privacy
.
Ad injectors’ businesses are built on a tangled web of different players in the online advertising economy. This complexity has made it difficult for the industry to understand this issue and help fix it. We hope our findings raise broad awareness of this problem and enable the online advertising industry to work together and tackle it.
How big is the problem?
This is what users might see if their browsers were infected with ad injectors. None of the ads displayed appear without an ad injector installed.
To pursue this research, we custom-built an ad injection “detector” for Google sites. This tool helped us identify tens of millions of instances of ad injection “in the wild” over the course of several months in 2014, the duration of our study.
More detail is below, but the main point is clear: deceptive ad injection is a significant problem on the web today. We found 5.5% of unique IPs—millions of users—accessing Google sites that included some form of injected ads.
How ad injectors work
The ad injection ecosystem comprises a tangled web of different players. Here is a quick snapshot.
Software
: It all starts with software that infects your browser. We discovered more than 50,000 browser extensions and more than 34,000 software applications that took control of users’ browsers and injected ads. Upwards of 30% of these packages were outright malicious and simultaneously stole account credentials, hijacked search queries, and reported a user’s activity to third parties for tracking. In total, we found 5.1% of page views on Windows and 3.4% of page views on Mac that showed tell-tale signs of ad injection software.
Distribution
: Next, this software is distributed by a network of affiliates that work to drive as many installs as possible via tactics like: marketing, bundling applications with popular downloads, outright malware distribution, and large social advertising campaigns. Affiliates are paid a commision whenever a user clicks on an injected ad. We found about 1,000 of these businesses, including Crossrider, Shopper Pro, and Netcrawl, that use at least one of these tactics.
Injection Libraries:
Ad injectors source their ads from about 25 businesses that provide ‘injection libraries’. Superfish and Jollywallet are by far the most popular of these, appearing in 3.9% and 2.4% of Google views, respectively. These companies manage advertising relationships with a handful of ad networks and shopping programs and decide which ads to display to users. Whenever a user clicks on an ad or purchases a product, these companies make a profit, a fraction of which they share with affiliates.
Ads
: The ad injection ecosystem profits from more than 3,000 victimized advertisers—including major retailers like Sears, Walmart, Target, Ebay—who unwittingly pay for traffic to their sites. Because advertisers are generally only able to measure the final click that drives traffic to their sites, they’re often unaware of many preceding twists and turns, and don’t know they are receiving traffic via unwanted software and malware. Ads originate from ad networks that translate unwanted software installations into profit: 77% of all injected ads go through one of three ad networks—dealtime.com, pricegrabber.com, and bizrate.com. Publishers, meanwhile, aren’t being compensated for these ads.
Examples of injected ads ‘in the wild’
How Google fights deceptive ad injectors
We pursued this research to raise awareness about the ad injection economy so that the broader ads ecosystem can better understand this complex issue and work together to tackle it.
Based on our findings, we took the following actions:
Keeping the Chrome Web Store clean:
We removed 192 deceptive Chrome extensions that affected 14 million users with ad injection from the Chrome Web Store. These extensions violated Web Store policies that extensions have a
narrow and easy-to-understand purpose
. We’ve also deployed new safeguards in the Chrome Web Store to help protect users from deceptive ad injection extensions.
Protecting Chrome users:
We improved protections in Chrome to
flag unwanted software
and display familiar red warnings when users are about to download deceptive software. These same protections are broadly available via the
Safe Browsing API
. We also
provide a tool
for users already affected by ad injectors and other unwanted software to clean up their Chrome browser.
Informing advertisers:
We reached out to the advertisers affected by ad injection to alert each of the deceptive practices and ad networks involved. This reflects a broader set of
Google Platforms program policies
and the
DoubleClick Ad Exchange (AdX) Seller Program Guidelines
that prohibit programs overlaying ad space on a given site without permission of the site owner.
Most recently, we
updated
our AdWords policies to make it more difficult for advertisers to promote unwanted software on AdWords. It's still early, but we've already seen encouraging results since making the change: the number of 'Safe Browsing' warnings that users receive in Chrome after clicking AdWords ads has dropped by more than 95%. This suggests it's become much more difficult for users to download unwanted software, and for bad advertisers to promote it. Our
blog post
from March outlines various policies—for the Chrome Web Store, AdWords, Google Platforms program, and the DoubleClick Ad Exchange (AdX)—that combat unwanted ad injectors, across products.
We’re also constantly improving our
Safe Browsing
technology, which protects more than one billion Chrome, Safari, and Firefox users across the web from phishing, malware, and unwanted software. Today, Safe Browsing shows people
more than 5 million warnings per day
for all sorts of malicious sites and unwanted software, and discovers more than 50,000 malware sites and more than 90,000 phishing sites every month.
Considering the tangle of different businesses involved—knowingly, or unknowingly—in the ad injector ecosystem, progress will only be made if we raise our standards, together. We strongly encourage all members of the ads ecosystem to review their policies and practices so we can make real improvement on this issue.
Protect your Google Account with Password Alert
29. April 2015
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
.
A Javascript-based DDoS Attack as seen by Safe Browsing
24. April 2015
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.
Ads Take a Step Towards “HTTPS Everywhere”
17. April 2015
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.
Beyond annoyance: security risks of unwanted ad injectors
16. April 2015
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
.
Android Security State of the Union 2014
2. April 2015
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
.
Out with unwanted ad injectors
31. März 2015
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.
Labels
#sharethemicincyber
#supplychain #security #opensource
AI Security
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2026
Apr.
März
Feb.
Jan.
2025
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2024
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2023
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2022
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2021
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2020
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2019
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2018
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2017
Dez.
Nov.
Okt.
Sept.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2016
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2015
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2014
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Apr.
März
Feb.
Jan.
2013
Dez.
Nov.
Okt.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2012
Dez.
Sept.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2011
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
2010
Nov.
Okt.
Sept.
Aug.
Juli
Mai
Apr.
März
2009
Nov.
Okt.
Aug.
Juli
Juni
März
2008
Dez.
Nov.
Okt.
Aug.
Juli
Mai
Feb.
2007
Nov.
Okt.
Sept.
Juli
Juni
Mai
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
.png)
Follow