Security Blog
The latest news and insights from Google on security and safety on the Internet
Disabling SSLv3 and RC4
September 17, 2015
Posted by Adam Langley, Security Engineer
As the
previously
announced
transition to SHA-256 certificates is nearing completion, we are planning the next changes to Google’s TLS configuration. As part of those changes, we expect to disable support for SSLv3 and RC4 in the medium term.
SSLv3 has been
obsolete
for over 16 years and is so full of known problems that the IETF has decided that it
must no longer be used
. RC4 is a 28 year old cipher that has done remarkably well, but is now the subject of
multiple
attacks
at security conferences. The IETF has decided that RC4 also warrants a statement that it too
must no longer be used
.
Because of these issues we expect to disable both SSLv3 and RC4 support at Google’s frontend servers and, over time, across our products in general, including Chrome, Android, our webcrawlers and our SMTP servers. (Indeed, SSLv3 support has already been removed from Chrome.) The
SSL Pulse
survey of the top 200,000 HTTPS sites finds that, already, 42% of sites have disabled RC4 and 65% of sites have disabled SSLv3.
If your TLS client, webserver or email server requires the use of SSLv3 or RC4 then the time to update was some years ago, but better late than never. However, note that just because you might be using RC4 today doesn’t mean that your client or website will stop working: TLS can negotiate cipher suites and problems will only occur if you don’t support anything but RC4. (Although if you’re using SSLv3 today then things will stop working when we disable it because SSLv3 is already a last resort.)
Minimum standards for TLS clients
Google's frontend servers do a lot more than terminate connections for browsers these days; there are also lots of embedded systems talking to Google using TLS. In order to reduce the amount of work that the deprecation of outdated cryptography causes, we are also announcing suggested minimum standards for TLS clients today. This applies to TLS clients in general: certainly those that are using TLS as part of HTTPS, but also, for example, SMTP servers using STARTTLS.
We can't predict the future, but devices that meet these requirements are likely to be able to continue functioning without changes to their TLS configuration up to 2020. You should expect these standards to be required in cases where Google runs certification programs, but it’s a very good idea to meet them anyway.
Devices that don’t meet these standards aren’t going to stop working anytime soon (unless they depend on RC4 or SSLv3—see above), but they might be affected by further TLS changes in the coming years.
Specifically, we are requiring:
TLS 1.2 must be supported.
A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that's being connected to.
The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
At least the certificates in
https://pki.google.com/roots.pem
must be trusted.
Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.
In order to make testing as easy as possible we have set up
https://cert-test.sandbox.google.com
, which requires points 1–3 to be met in order to make a successful connection. Thus, if your TLS client can’t connect to that host then you need to update your libraries or configuration.
No longer serving a cross-sign to Equifax
At the moment the certificate chains that Google properties serve most often include a cross-sign from our CA, GeoTrust, to our previous CA, Equifax. This allows clients that only trust our previous CA to continue to function. However, this cross-sign is only a transitional workaround for such clients and we will be removing it in the future. Clients that include our required set of root CAs (at
https://pki.google.com/roots.pem
) will not be affected, but any that don’t include the needed GeoTrust root may stop working.
Cutting unwanted ad injectors out of advertising
September 10, 2015
Posted by Vegard Johnsen, Product Manager, Google Ads Traffic Quality
For the last few months, we’ve been raising awareness of the ad injection economy, showing how unwanted ad injectors can
hurt user experience
,
jeopardize user security
, and
generate significant volumes of unwanted ads
. We’ve used learnings from
our research
to prevent and remove unwanted ad injectors from Google services and improve our policies and technologies to make it more difficult to spread this unwanted software.
Today, we’re announcing a new measure to remove injected ads from the advertising ecosystem, including an automated filter in DoubleClick Bid Manager that removes impressions generated by ad injectors before any bid is made.
Unwanted ad injectors: disliked by users, advertisers, and publishers
Unwanted ad injectors are programs that insert new ads, or replace existing ones, in the pages users visit while browsing the web. 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.
We’ve received almost 300,000 user complaints about them in Chrome since the beginning of 2015—more than any other issue, and it’s no wonder. Ad injectors affect all sites equally. You wouldn’t be happy if you tried to get the morning news and saw this:
Not only are they intrusive, but people are often tricked into installing them in the first place, via deceptive advertising, or software “bundles.” Ad injection can also be a security risk, as the
recent “Superfish” incident
showed.
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.
Removing injected inventory from advertising
Earlier this quarter, we launched an automated filter on DoubleClick Bid Manager to prevent advertisers from buying injected ads across the web. This new system detects ad injection and proactively creates a blacklist that prevents our systems from bidding on injected inventory. Advertisers and agencies using our platforms are already protected. No adjustments are needed. No settings to change.
We currently blacklist 1.4% of the inventory accessed by DoubleClick Bid Manager across exchanges. However, we’ve found this percentage varies widely by provider. Below is a breakdown showing the filtered percentages across some of the largest exchanges:
We’ve always enforced
policies
against
the sale of injected inventory on our ads platforms, including the DoubleClick Ad Exchange. Now advertisers using DoubleClick Bid Manager can avoid injected inventory across the web.
No more injected ads?
We don’t expect the steps we’ve outlined above to solve the problem overnight, but we hope others across the industry take action to cut ad injectors out of advertising. With the tangle of different businesses involved—knowingly, or unknowingly—in the ad injector ecosystem, progress will only be made if we all work together. We strongly encourage all members of the ads ecosystem to review their policies and practices and take actions to tackle this issue.
Say hello to the Enigma conference
August 18, 2015
Posted by Elie Bursztein - Anti-abuse team, Parisa Tabriz - Chrome Security and Niels Provos - Security team
USENIX Enigma
is a new conference focused on security, privacy and electronic crime through the lens of emerging threats and novel attacks. The goal of this conference is to help industry, academic, and public-sector practitioners better understand the threat landscape. Enigma will have a single track of 30-minute talks that are curated by a panel of experts, featuring strong technical content with practical applications to current and emerging threats.
Google is excited to both sponsor and help USENIX build Enigma, since we share many of its core principles: transparency, openness, and cutting-edge security research. Furthermore, we are proud to provide Enigma with with engineering and design support, as well as volunteer participation in program and steering committees.
The first instantiation of Enigma will be held January 25-27 in San Francisco. You can sign up for more information about the conference or propose a talk through the official conference site at
http://enigma.usenix.org
New research: Comparing how security experts and non-experts stay safe online
July 23, 2015
Posted by
Iulia Ion, Software Engineer - Rob Reeder, Research Scientist - Sunny Consolvo, User Experience Researcher
Today, you can find more online security tips in a few seconds than you could use in a lifetime. While this collection of best practices is rich, it’s not always useful; it can be difficult to know which ones to prioritize, and why.
Questions like ‘Why do people make some security choices (and not others)?’ and ‘How effectively does the security community communicate its best practices?’ are at the heart of a new paper called, “...no one can hack my mind”: Comparing Expert and Non-Expert Security Practices” that we’ll present this week at the
Symposium on Usable Privacy and Security
.
This paper outlines the results of two surveys—one with 231 security experts, and another with 294 web-users who aren’t security experts—in which we asked both groups what they do to stay safe online. We wanted to compare and contrast responses from the two groups, and better understand differences and why they may exist.
Experts’ and non-experts’ top 5 security practices
Here are experts’ and non-experts’ top security practices, according to our study. We asked each participant to list 3 practices:
Common ground: careful password management
Clearly, careful password management is a priority for both groups. But, they differ on their approaches.
Security experts rely heavily on password managers, services that store and protect all of a user’s passwords in one place. Experts reported using password managers, for at least some of their accounts, three-times more frequently than non-experts.
As one expert said, “Password managers change the whole calculus because they make it possible to have both strong and unique passwords.”
On the other hand, only 24% of non-experts reported using password managers for at least some of their accounts, compared to 73% of experts. Our findings suggested this was due to lack of education about the benefits of password managers and/or a perceived lack of trust in these programs. “I try to remember my passwords because no one can hack my mind,” one non-expert told us.
Key differences: software updates and antivirus software
Despite some overlap, experts’ and non-experts’ top answers were remarkably different.
35% of experts and only 2% of non-experts said that installing software updates was one of their top security practices. Experts recognize the benefits of updates—“Patch, patch, patch,” said one expert—while non-experts not only aren’t clear on them, but are concerned about the potential risks of software updates. A non-expert told us: “I don’t know if updating software is always safe. What [if] you download malicious software?” and “Automatic software updates are not safe in my opinion, since it can be abused to update malicious content.”
Meanwhile, 42% of non-experts vs. only 7% of experts said that running antivirus software was one of the top three three things they do to stay safe online. Experts acknowledged the benefits of antivirus software, but expressed concern that it might give users a false sense of security since it’s not a bulletproof solution.
Next Steps
In the immediate term, we encourage everyone to read the
full research paper
, borrow experts’ top practices, and also check out our tips for
keeping your information safe on Google
.
More broadly, our findings highlight fundamental misunderstandings about basic online security practices. Software updates, for example, are the seatbelts of online security; they make you safer, period. And yet, many non-experts not only overlook these as a best practice, but also mistakenly worry that software updates are a security risk.
No practice on either list—expert or non-expert—makes users less secure. But, there is clearly room to improve how security best practices are prioritized and communicated to the vast majority of (non expert) users. We’re looking forward to tackling that challenge.
Working Together to Filter Automated Data-Center Traffic
July 21, 2015
Posted by Vegard Johnsen, Product Manager Google Ad Traffic Quality
Today the
Trustworthy Accountability Group
(TAG)
announced
a new pilot blacklist to protect advertisers across the industry. This blacklist comprises data-center IP addresses associated with non-human ad requests. We're happy to support this effort along with other industry leaders—Dstillery, Facebook, MediaMath, Quantcast, Rubicon Project, TubeMogul and Yahoo—and contribute our own data-center blacklist. As mentioned to
Ad Age
and in our recent
call to action
, we believe that if we work together we can raise the fraud-fighting bar for the whole industry.
Data-center traffic is one of
many types
of non-human or illegitimate ad traffic. The newly shared blacklist identifies web robots or “bots” that are being run in data centers but that avoid detection by the
IAB/ABC International Spiders & Bots List
. Well-behaved bots announce that they're bots as they surf the web by including a bot identifier in their declared User-Agent strings. The bots filtered by this new blacklist are different. They masquerade as human visitors by using User-Agent strings that are indistinguishable from those of typical web browsers.
In this post, we take a closer look at a few examples of data-center traffic to show why it’s so important to filter this traffic across the industry.
Impact of the data-center blacklist
When observing the traffic generated by the IP addresses in the newly shared blacklist, we found significantly distorted click metrics. In May of 2015 on DoubleClick Campaign Manager alone, we found the blacklist filtered 8.9% of all clicks. Without filtering these clicks from campaign metrics, advertiser click-through rates would have been incorrect and for some advertisers this error would have been very large.
Below is a plot that shows how much click-through rates in May would have been inflated across the most impacted of DoubleClick Campaign Manager’s larger advertisers.
Two examples of bad data-center traffic
There are two distinct types of invalid data-center traffic: where the intent is malicious and where the impact on advertisers is accidental. In this section we consider two interesting examples where we’ve observed traffic that was likely generated with malicious intent.
Publishers use many different strategies to increase the traffic to their sites. Unfortunately, some are willing to use any means necessary to do so. In our investigations we’ve seen instances where publishers have been running software tools in data centers to intentionally mislead advertisers with fake impressions and fake clicks.
First example
UrlSpirit is just one example of software that some unscrupulous publishers have been using to collaboratively drive automated traffic to their websites. Participating publishers install the UrlSpirit application on Windows machines and they each submit up to three URLs through the application’s interface. Submitted URLs are then distributed to other installed instances of the application, where Internet Explorer is used to automatically visit the list of target URLs. Publishers who have not installed the application can also leverage the network of installations by paying a fee.
At the end of May more than 82% of the UrlSpirit installations were being run on machines in data centers. There were more than 6,500 data-center installations of UrlSpirit, with each data-center installation running in a separate virtual machine. In aggregate, the data-center installations of UrlSpirit were generating a monthly rate of at least half a billion ad requests— an average of 2,500 fraudulent ad requests per installation per day.
Second example
HitLeap is another example of software that some publishers are using to collaboratively drive automated traffic to their websites. The software also runs on Windows machines, and each instance uses the Chromium Embedded Framework to automatically browse the websites of participating publishers—rather than using Internet Explorer.
Before publishers can use the network of installations to drive traffic to their websites, they need browsing minutes. Participating publishers earn browsing minutes by running the application on their computers. Alternatively, they can simply buy browsing minutes—with bundles starting at $9 for 10,000 minutes or up to 1,000,000 minutes for $625.
Publishers can specify as many target URLs as they like. The number of visits they receive from the network of installations is a function of how long they want the network of bots to spend on their sites. For example, ten browsing minutes will get a publisher five visits if the publisher requests two-minute visit durations.
In mid-June, at least 4,800 HitLeap installations were being run in virtual machines in data centers, with a unique IP associated with each HitLeap installation. The data-center installations of HitLeap made up 16% of the total HitLeap network, which was substantially larger than the UrlSpirit network.
In aggregate, the data-center installations of HitLeap were generating a monthly rate of at least a billion fraudulent ad requests—or an average of 1,600 ad requests per installation per day.
Not only were these publishers collectively responsible for billions of automated ad requests, but their websites were also often extremely deceptive. For example, of the top ten webpages visited by HitLeap bots in June, nine of these included
hidden ad slots
-- meaning that not only was the traffic fake, but the ads couldn’t have been seen even if they had been legitimate human visitors.
http://vedgre.com/7/gg.html
is illustrative of these nine webpages with hidden ad slots. The webpage has no visible content other than a single 300×250px ad. This visible ad is actually in a 300×250px iframe that includes two ads, the second of which is hidden. Additionally, there are also twenty-seven 0×0px hidden iframes on this page with each hidden iframe including two ad slots. In total there are fifty-five hidden ads on this page and one visible ad. Finally, the ads served on
http://vedgre.com/7/gg.html
appear to advertisers as though they have been served on legitimate websites like indiatimes.com, scotsman.com, autotrader.co.uk, allrecipes.com, dictionary.com and nypost.com, because the tags used on
http://vedgre.com/7/gg.html
to request the ad creatives have been deliberately spoofed.
An example of collateral damage
Unlike the traffic described above, there is also automated data-center traffic that impacts advertising campaigns but that hasn’t been generated for malicious purposes. An interesting example of this is an advertising competitive intelligence company that is generating a large volume of undeclared non-human traffic.
This company uses bots to scrape the web to find out which ad creatives are being served on which websites and at what scale. The company’s scrapers also click ad creatives to analyse the landing page destinations. To provide its clients with the most accurate possible intelligence, this company’s scrapers operate at extraordinary scale and they also do so without including bot identifiers in their User-Agent strings.
While the aim of this company is not to cause advertisers to pay for fake traffic, the company’s scrapers do waste advertiser spend. They not only generate non-human impressions; they also distort the metrics that advertisers use to evaluate campaign performance—in particular, click metrics. Looking at the data across DoubleClick Campaign Manager this company’s scrapers were responsible for 65% of the automated data-center clicks recorded in the month of May.
Going forward
Google has always invested to prevent this and other types of invalid traffic from entering our ad platforms. By contributing our data-center blacklist to TAG, we hope to help others in the industry protect themselves.
We’re excited by the collaborative spirit we’ve seen working with other industry leaders on this initiative. This is an important, early step toward tackling fraudulent and illegitimate inventory across the industry and we look forward to sharing more in the future. By pooling our collective efforts and working with industry bodies, we can create strong defenses against those looking to take advantage of our ecosystem. We look forward to working with the TAG Anti-fraud working group to turn this pilot program into an industry-wide tool.
Google, the Wassenaar Arrangement, and vulnerability research
July 20, 2015
Posted by
Neil Martin, Export Compliance Counsel,
Google Legal
Tim Willis, Hacker Philanthropist, Chrome Security Team
Cross-posted on the
Google Public Policy Blog
As the usage and complexity of software grows, the importance of security research has grown with it. It’s through diligent research that we uncover and fix bugs — like
Heartbleed
and
POODLE
— that can cause serious security issues for web users around the world.
The time and effort it takes to uncover bugs is significant, and the marketplace for these vulnerabilities is competitive. That’s why we provide cash rewards for quality security research that identifies problems in our own products or proactive improvements to open-source products. We’ve
paid
more than $4 million to researchers from all around the world - our current Hall of Fame includes researchers from Germany, the U.S., Japan, Brazil, and more than 30 other countries.
Problematic new export controls
With the benefits of security research in mind, there has been some public
head scratching
and
analysis
around
proposed export control rules
put forth by the U.S. Department of Commerce that would negatively affect vulnerability research.
The Commerce Department's proposed rules stem from U.S. membership in the
Wassenaar Arrangement
, a multilateral export control association. Members of the Wassenaar Arrangement have agreed to control a wide range of goods, software, and information, including technologies relating to "intrusion software" (as they've defined that term).
We believe that these proposed rules, as currently written, would have a significant negative impact on the open security research community. They would also hamper our ability to defend ourselves, our users, and make the web safer. It would be a disastrous outcome if an export regulation intended to make people more secure resulted in billions of users across the globe becoming persistently less secure.
Google comments on proposed rules
Earlier today, we formally submitted comments on the proposed rules to the United States Commerce Department’s Bureau of Industry and Security (BIS). Our comments are lengthy, but we wanted to share some of the main concerns and questions that we have officially expressed to the U.S. government today:
Rules are dangerously broad and vague.
The proposed rules are not feasible and would require Google to request thousands - maybe even tens of thousands - of export licenses. Since Google operates in many different countries, the controls could cover our communications about software vulnerabilities, including: emails, code review systems, bug tracking systems, instant messages - even some in-person conversations!
BIS’ own FAQ
states that information about a vulnerability, including its causes, wouldn’t be controlled, but we believe that it sometimes actually could be controlled information.
You should never need a license when you report a bug to get it fixed.
There should be standing license exceptions for everyone when controlled information is reported back to manufacturers for the purposes of fixing a vulnerability. This would provide protection for security researchers that report vulnerabilities, exploits, or other controlled information to any manufacturer or their agent.
Global companies should be able to share information globally.
If we have information about intrusion software, we should be able to share that with our engineers, no matter where they physically sit.
Clarity is crucial.
We acknowledge that we have a team of lawyers here to help us out, but navigating these controls shouldn’t be that complex and confusing. If BIS is going to implement the proposed controls, we recommend providing a simple, visual flowchart for everyone to easily understand when they need a license.
These controls should be changed ASAP.
The only way to fix the scope of the intrusion software controls is to do it at the annual meeting of Wassenaar Arrangement members in December 2015.
We’re committed to working with BIS to make sure that both white hat security researchers’ interests and Google users’ interests are front of mind. The proposed BIS rule for public comment is available
here
, and comments can also be sent directly to
publiccomments@bis.doc.gov
. If BIS publishes another proposed rule on intrusion software, we’ll make sure to come back and update this blog post with details.
More Visible Protection Against Unwanted Software
July 16, 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
June 16, 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’
May 21, 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
May 6, 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.
Labels
#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
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.