Security Blog
The latest news and insights from Google on security and safety on the Internet
Safe Browsing protection from even more deceptive attacks
November 13, 2015
Posted by Emily Schechter, Program Manager and Noé Lutz, Software Engineer
Safe Browsing
has been protecting over one billion people from
traditional phishing attacks
on the web for more than eight years. The threat landscape is constantly changing—bad actors on the web are using more and different types of deceptive behavior to trick you into performing actions that you didn’t intend or want, so we’ve expanded protection to include social engineering.
Social engineering is a much broader category than traditional phishing and encompasses more types of deceptive web content. A social engineering attack happens when either:
The content pretends to act, or looks and feels, like a trusted entity — like a bank or government.
The content tries to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.
Below are some examples of social engineering attacks that try to trick you into thinking the content is delivered by Google or Chrome. Other trusted brands are also commonly abused for social engineering attacks.
This page tries to trick you into downloading and executing malware or unwanted software. It uses Chrome’s logo and name to confuse you into believing the site is operated by Google. Content like this may include an inconspicuous legal disclaimer that states it is not affiliated with Google. This does not change the deceptive nature of this content—as always, use caution when downloading files from the web.
This is a fake tech phone support page. This page mimics a warning and may trick you into calling a third-party company that pretends to be Google or some other trusted entity, but charges a fee for support. (Chrome does not offer paid remote support).
This is a fake Google login page. It might trick you into disclosing your account login credentials. Other phishing sites like this could trick you into giving up other personal information such as credit card information. Phishing sites may look exactly like the real site—so be sure to look at the address bar to check that the URL is correct, and also check to see that the website begins with https://. See more information
here
.
If we identify that a web page contains social engineering content, Chrome will warn you by displaying the following warning:
(If you believe Safe Browsing has classified a web page in error, please report it
here
.)
We'll continue to improve Google's Safe Browsing protection to help more people stay safer online. Check out the
Safe Browsing Transparency Report
to find out more.
New Research: Encouraging trends and emerging threats in email security
November 12, 2015
Posted by Elie Bursztein, Anti-Fraud and Abuse Research and Nicolas Lidzborski, Gmail Security Engineering Lead
We’re constantly working to help make email more secure for everyone. These efforts are reflected in security protections like
default HTTPS
in Gmail as well as our
Safer Email Transparency report
, which includes information about email security beyond just Gmail.
To that end, in partnership with the University of Michigan and the University of Illinois, we’re publishing the results of a
multi-year study
that measured how email security has evolved since 2013. While Gmail was the foundation of this research, the study’s insights apply to email more broadly, not unlike our
Safer Email Transparency report
. It’s our hope that these findings not only help make Gmail more secure, but will also be used to help protect email users everywhere as well.
Email security strengthens, industry-wide
The study showed that email is more secure today than it was two years ago. Here are some specific findings:
Newer security challenges and how we can address them
Our study identified several new security challenges as well.
First, we found regions of the Internet actively preventing message encryption by tampering with requests to initiate SSL connections. To mitigate this attack, we are working closely with partners through the industry association
M3AAWG
to strengthen “opportunistic TLS” using technologies that we pioneered with Chrome to protect websites against interception.
Second, we uncovered malicious DNS servers publishing bogus routing information to email servers looking for Gmail. These nefarious servers are like telephone directories that intentionally list misleading phone numbers for a given name. While this type of attack is rare, it’s very concerning as it could allow attackers to censor or alter messages before they are relayed to the email recipient.
While these threats do not affect Gmail to Gmail communication, they may affect messaging between providers. To notify our users of potential dangers, we are developing in-product warnings for Gmail users that will display when they receive a message through a non-encrypted connection. These warnings will begin to roll-out in the coming months.
All email services—Gmail included—depend on the trust of their users. Partnering with top researchers helps us make the email ecosystem as a whole safer and more secure for everyone. Security threats won’t disappear, but studies like these enable providers across the industry to fight them with better, more powerful protections today and going forward.
[This work was made possible thanks to the contribution of many Googlers including Vijay Eranti, Kurt Thomas, John Rae-Grant, and Mark Risher.]
Sustaining Digital Certificate Security
October 28, 2015
Posted by Ryan Sleevi, Software Engineer
This post updates our
previous notification
of a misissued certificate for google.com
Following our notification, Symantec published
a report
in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.
However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.
Symantec performed another audit and, on October 12th, announced that they had found an additional
164 certificates
over 76 domains and
2,458 certificates
issued for domains that were never registered.
It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.
After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.
More immediately, we are requesting of Symantec that they further update their public incident report with:
A post-mortem analysis that details why they did not detect the additional certificates that we found.
Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.
Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL
The third-party security audit must assess:
The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.
We may take further action as additional information becomes available to us.
Behind the red warning: more info about online site safety
October 20, 2015
Posted by
Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard
Emily Schechter, Safe Browsing Program Manager and Menace to Malware
Ke Wang, Safe Browsing Engineer and Developer of Defense
You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.
To demystify these warnings, we’re launching a
Site Status section
in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.
The new Site Status section of the Transparency Report replaces our previous
Safe Browsing diagnostic page
. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host
unwanted software
. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via
Search Console
; if you use
Google Analytics
, we’ll also warn you there if your site has malware on it. (Webmasters, check the
help center
to learn how to remove malware from your websites.)
We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the
Transparency Report
to experience it yourself.
Simplifying the Page Security Icon in Chrome
October 13, 2015
Posted by Lucas Garron and Chris Palmer, Chrome security team
Sometimes, websites try to use HTTPS to be secure and get it mostly right, but they have minor errors. Until recently, Chrome marked this security state with a yellow “caution triangle” badge on the page security icon in the URL bar.
Starting with version 46, Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.
There are two reasons for this:
This change is a better visual indication of the security state of the page relative to HTTP.
Chrome users will have fewer security states to learn.
(Not) Warning About Mixed Content
This change will mainly affect HTTPS pages that contain certain
mixed content
, such as HTTP images.
Site operators face a dilemma: Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before.
Removing the yellow “caution triangle” badge means that most users will not perceive a warning on mixed content pages during such a migration. We hope that this will encourage site operators to switch to HTTPS sooner rather than later.
Fewer Security States
This change will reduce the number of page security states in Chrome from four to three.
We have to strike a balance: representing the security state of a webpage as accurately as possible, while making sure users are not overwhelmed with too many possible states and details. We’ve come to understand that our yellow “caution triangle” badge can be confusing when compared to the HTTP page icon, and we believe that it is better not to emphasize the difference in security between these two states to most users. For developers and other interested users, it will still be possible to tell the difference by checking whether the URL begins with “https://”.
In the long term, we hope that most sites on the internet will become secure, and we
plan
to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.
HTTPS support coming to Blogspot
September 30, 2015
Posted by Jo-el van Bergen, Software Engineer, Security.
Since
2008
, we've worked to encrypt the connections between our users and Google servers. Over the years we've announced that Search, Gmail, Drive, and many other products have encrypted connections by default, and most recently, we've made a similar announcement for
our ads products
.
In this same vein, today we're expanding on the
HTTPS Everywhere
mission and beginning an initial rollout of HTTPS support for Blogspot. HTTPS is a cornerstone of internet security as it provides several important benefits: it makes it harder for bad actors to steal information or track the activities of blog authors and visitors, it helps check that visitors open the correct website and aren’t being redirected to a malicious location, and it helps detect if a bad actor tries to change any data sent from Blogger to a blog visitor.
While this initial rollout won’t support all of our Blogger users, we wanted to take the first step to make HTTPS available for Blogspot; for those users who want to try it early.
We’re rolling this out gradually and Blogspot authors interested in enabling HTTPS support can begin opting-in today. Simply log into
https://www.blogger.com
, click on the blog you’d like to make HTTPS enabled, navigate to the Settings page, and select "yes" for "HTTPS Availability". Unfortunately, blogs with custom domains are not supported in this first version.
Once enabled, your blog will become accessible over both HTTP and HTTPS connections. Blogspot authors should be aware that if they choose to encrypt at this time, some of the current functionality of their blog may not work over HTTPS. This can be a result of template, gadgets, and blog post content, and is often caused by
mixed content
errors, some of which may be
fixable by the author themselves
.
We’ll also be moving some of our own blogs over to HTTPS gradually, beginning with the
Official Google Blog
and the
Google Online Security Blog
.
For the Blogspot authors who try this out - we’re interested to hear your
feedback
while we continue to improve this feature and its capabilities! For more information, visit our
Help Center
.
New research: The underground market fueling for-profit abuse
September 24, 2015
Posted by Kurt Thomas and Elie Bursztein, Google Anti-Fraud and Abuse Research
Recently, we teamed up with top researchers exploring innovative anti-abuse strategies to build a holistic understanding of for-profit abuse. The full report, which you can read
here
, was presented in June at the
Workshop on the Economics of Information Security
2015.
Over the last decade, Internet crime has matured into an underground economy where a large number of globally distributed criminals trade in data, knowledge, and services specifically geared towards defrauding users and businesses. Within this black market, criminals buy and sell compromised machines, scam hosting, exploit kits, and wholesale access to pilfered user records including usernames and passwords, credit card numbers, and other sensitive personal data. The availability of such specialized resources has transformed for-profit abuse into a cooperative effort among criminals each satisfying a cog in a supply chain.
Profiting from abuse: a bird's eye view
Here’s an example of the underground value chain required to make money from spamming knock-off luxury products:
In aggregate, the problem may appear intractable to stop. However, if we view this scenario in an economic light, then increasing the cost of fake accounts, phone numbers, or compromised websites cuts into the profitability of abuse. In the end, abuse propped up by cost-ineffective resources will crumble.
Collaborating to better understand the underground
Given the complex underbelly of abuse, we pulled together experts from industry and academia to build a systematic understanding of how criminals operate. Our previous example represents just one configuration of a value chain. In our example, revenue originates solely from victims buying counterfeit products. Criminals could adapt this strategy to scam users into paying for fake anti-virus, defraud advertisers via clickbots, or liquidate a victim’s banking assets. Regardless of the composition, we argue there is always a profit center through which victims transfer new capital into the underground. These schemes form a spectrum between selling products to unwitting victims to outright theft. A medley of alternatives such as dating scams, call-center scams, premium SMS fraud, DDoS extortion, or even stealing and re-selling gaming assets all fall within this spectrum and ultimately derive a payout from victims outside the underground.
These profit centers are in turn propped up by an ecosystem of support infrastructure that can be configured arbitrarily by criminals per their requirements. This infrastructure includes compromised hosts, human labor, networking and hosting, and accounts and engagement—all available for a fee. For example, 1,000 Google accounts cost on the order of $170, compared to CAPTCHAs which cost $1 per thousand. These costs reflect socio-economic factors as well as the impact of technical, legal, and law enforcement interventions on the availability of resources.
Redefining the abuse arms race
Client and server-side security has dominated industry’s response to digital abuse over the last decade. The spectrum of solutions—automated software updates, personal anti-virus, network packet scanners, firewalls, spam filters, password managers, and two-factor authentication to name a few—all attempt to reduce the attack surface that criminals can penetrate.
While these safeguards have significantly improved user security, they create an arms race: criminals adapt or find the subset of systems that remain vulnerable and resume operation. To overcome this reactive defense cycle, we are improving our approach to abuse fighting to also strike at the support infrastructure, financial centers, and actors that incentivize abuse. By exploring the value chain required to bulk register accounts, we were able to make Google accounts
30–40% more expensive on the black market
.
Success stories from our academic partners include
disrupting payment processing
for illegal pharmacies and counterfeit software outlets advertised by spam,
cutting off access to fake accounts
that pollute online services, and
disabling the command and control
infrastructure of botnets.
Improved Digital Certificate Security
September 18, 2015
Posted by Stephan Somogyi, Security & Privacy PM, and Adam Eijdenberg, Certificate Transparency PM
On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains
google.com
and
www.google.com
. This pre-certificate was neither requested nor authorized by Google.
We discovered this issuance via
Certificate Transparency
logs, which Chrome has required for EV certificates starting January 1st of this year. The issuance of this pre-certificate was recorded in both Google-operated and DigiCert-operated logs.
During our ongoing discussions with Symantec we determined that the issuance occurred during a Symantec-internal testing process.
We have updated Chrome’s revocation metadata to include the public key of the misissued certificate. Additionally, the issued pre-certificate was valid only for one day.
Our primary consideration in these situations is always the security and privacy of our users; we currently do not have reason to believe they were at risk.
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.
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
2025
Apr
Mar
Feb
Jan
2024
Dec
Nov
Oct
Sep
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
.
Follow