Security Blog
The latest news and insights from Google on security and safety on the Internet
Out with unwanted ad injectors
2015年3月31日
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.
Even more unwanted software protection via the Safe Browsing API
2015年3月24日
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
.
Maintaining digital certificate security
2015年3月23日
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.
標籤
#sharethemicincyber
#supplychain #security #opensource
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
2024
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2023
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2022
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2021
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2020
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
7月
6月
4月
3月
2月
1月
2013
12月
11月
10月
8月
6月
5月
4月
3月
2月
1月
2012
12月
9月
8月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
2010
11月
10月
9月
8月
7月
5月
4月
3月
2009
11月
10月
8月
7月
6月
3月
2008
12月
11月
10月
8月
7月
5月
2月
2007
11月
10月
9月
7月
6月
5月
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.