Oct
NOV
Dec
29
2020
2021
2022
success
fail
About this capture
COLLECTED BY
Collection:
Common Crawl
Web crawl data from Common Crawl.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20211129114539/https://security.googleblog.com/2016/03/
Security Blog
The latest news and insights from Google on security and safety on the Internet
More Encryption, More Notifications, More Email Security
March 24, 2016
Posted by Nicolas Lidzborski, Gmail Security Engineering Lead and Jonathan Pevarnek,
Jigsaw
Engineer
Today, we’re announcing a variety of new protections that will help keep Gmail users even safer and promote email security best practices across the Internet as a whole.
New tools and industry standards make email even safer
On
Safer Internet Day
this year, we introduced a new visual element to Gmail that lets users know when they’ve received a message that wasn’t delivered using encryption or if they’re composing a message to a recipient whose email service doesn’t support TLS encryption. It’s the red lock icon featured below:
This has had an immediate, positive effect on Gmail security. In the 44 days since we introduced it, the amount of inbound mail sent over an encrypted connection
increased by 25%
. We’re very encouraged by this progress! Given the relative ease of implementing encryption and its significant benefits for users, we expect to see this progress continue.
However, as our recent
research
with the University of Michigan and University of Illinois shows, misconfigured or malicious parts of the Internet can still tamper with email encryption. To help ensure TLS encryption works as intended, we’ve teamed-up with a variety of industry partners — including Comcast, Microsoft, and Yahoo!— to submit a
draft IETF specification
for “SMTP Strict Transport Security.” With this new proposed standard, companies can ensure that mail will only be delivered through encrypted channels, and that any encryption failures should be reported for further analysis, helping shine the spotlight on any malfeasance occurring around the Internet.
Safe Browsing makes Gmail more secure
Since 2007,
Safe Browsing
has protected users across the web by warning them before they visit dangerous sites known for phishing, malware, and
Unwanted Software
. Over the years, we’ve brought the protections afforded by Safe Browsing to other Google products as well, including: Chrome,
Android
, Ads, Google Analytics, and more.
Safe Browsing already protects Gmail users by identifying potentially dangerous links in messages. Starting this week, Gmail users will begin to see warnings if they click these links, further extending this protection to different web browsers and email apps. The full-page warning will look like this:
Enhancing state-sponsored attack warnings
Since 2012
, we’ve warned Gmail users when we suspect they’ve been targeted by state-sponsored attackers:
These warnings are rare—fewer than 0.1% of users ever receive them—but they are critically important. The users that receive these warnings are often activists, journalists, and policy-makers taking bold stands around the world.
Today, we’re launching a new, full-page warning with instructions about how these users can stay safe. They may see these new warnings instead of, or in addition to, the existing ones.
The security of our users and their data is paramount. We’ll continue to build new protections, and work closely with the broader email ecosystem to support and improve standards such as TLS, that keep users safe.
Certificate Transparency for Untrusted CAs
March 21, 2016
Posted by Martin Smith, Software Engineer, Certificate Transparency
Today we are announcing a new Certificate Transparency log for a new set of root certificates: those that were once or are not yet trusted by browsers.
Certificate Transparency
(CT) data has a number of different uses, including protecting users from mis-issued certificates and providing webmasters and other interested parties with a public record of what certificates have been issued for domains.
Initially
, our logs included browser-trusted Certificate Authorities (CAs). However, there are two main classes of CA that can’t easily be included in the existing logs:
Those that were once trusted and have since been withdrawn from the root programs.
New CAs that are on the path to inclusion in browser trusted roots.
Including these in trusted logs is problematic for several reasons, including uncertainties around revocation policies and the possibility of cross-signing attacks being attempted by malicious third-parties.
However, visibility of these CAs’ activities is still useful, so we have created a new CT log for these certificates. This log will not be trusted by Chrome, and will provide a public record of certificates that are not accepted by the existing Google-operated logs.
The new log is accessible at
ct.googleapis.com/submariner
and is listed on our
Known Logs
page. It has the same API as the existing logs.
Initially, Submariner includes certificates chaining up to the set of root certificates that
Symantec
recently announced it had discontinued, as well as a
collection of additional roots
suggested to us that are pending inclusion in Mozilla.
Once Symantec’s affected certificates are no longer trusted by browsers, we will be withdrawing them from the trusted roots accepted by our existing logs (Aviator, Pilot, and Rocketeer).
Third parties are invited to suggest additional roots for potential inclusion in the new log by email to
google-ct-logs@googlegroups.com
.
Everyone is welcome to make use of the log to submit certificates and query data. We hope it will prove useful and help to improve web security.
BinDiff now available for free
March 18, 2016
Posted by Christian Blichmann, Software Engineer
BinDiff is a comparison tool for binary files that helps to quickly find differences and similarities in disassembled code. It is used by security researchers and engineers across the globe to identify and isolate fixes for vulnerabilities in vendor-supplied patches and to analyze multiple versions of the same binary. Another common use case is to transfer analysis results from one binary to another, helping to prevent duplicate analyses of, for example, malware binaries. This also helps to retain knowledge across teams of binary analysts where the individual workflows might vary from analyst to analyst.
More specifically, BinDiff can be used to:
Compare binary files for x86, MIPS, ARM/AArch64, PowerPC, and other architectures.
Identify identical and similar functions in different binaries.
Port function names, comments and local variable names from one disassembly to another.
Detect and highlight changes between two variants of the same function.
Here is a screenshot demonstrating what using BinDiff to display per-function differences looks like:
At Google, the BinDiff core engine powers a large-scale malware processing pipeline helping to protect both internal and external users. BinDiff provides the underlying comparison results needed to cluster the world's malware into related families with billions of comparisons performed so far.
Ever since zynamics
joined Google
in 2011, we have been committed to keeping our most valuable tools available to the security research community. We first lowered the price, and today we are taking the next logical step by making it available free of charge.
You can download BinDiff from the
zynamics web site
. It’s the current version, BinDiff 4.2 for both Linux and Windows. To use it, you also need the commercial Hex-Rays IDA Pro disassembler, 6.8 or later.
Happy BinDiff-ing!
Securing the web, together
March 15, 2016
Posted by Rutledge Chin Feman and Tim Willis, HTTPS Evangelists
Encryption keeps people’s information safe as it moves between their devices and Google, protecting it from interception and unauthorized access by attackers. With a modern encrypted connection, you can be confident that your data will be private and secure.
Today we are launching a new section of our
Transparency Report
to track the progress of encryption efforts—both at Google and on some of the web's most trafficked sites. Our aim with this project is to hold ourselves accountable and encourage others to encrypt so we can make the web even safer for everyone.
Here's an overview of what is included in the new report:
Google sites
Every week, we’ll update this report with progress we've made towards implementing HTTPS by default across Google’s services. We’ve long offered Gmail, Drive, and Search over HTTPS, and in the last year, we’ve begun to add traffic from more products, like
ads
and
Blogger
as well.
We're making positive strides, but we still have a ways to go.
This chart represents the percentage of requests to Google's servers that used encrypted connections. YouTube traffic is currently not included in this data.
We plan on adding additional Google products over time to increase the scope of this report.
Popular third-party sites
Our report also includes data about the
HTTPS connections on many popular sites across the web
, beyond Google. We've chosen these sites based on a combination of publicly-available
Alexa data
and our own Google internal data; we estimate they account for approximately 25% of all web traffic on the Internet.
Certificate Transparency
Websites use certificates to assert to users that they are legitimate, so browsers need to be able to check whether the certificate that you’re being presented is valid and appropriately issued. That is why this report also offers a
Certificate Transparency log viewer
, providing a web interface for users and site administrators to easily check and see who has issued a certificate for a website. For example, if you use this log viewer and search for google.com with ‘include expired' checked, you'll see the
mis-issued google.com certificate from September 2015
.
Encryption for everyone
Implementing HTTPS can be difficult—we know from experience! Some common obstacles include:
Older hardware and/or software that doesn’t support modern encryption technologies.
Governments and organizations that may block or otherwise degrade HTTPS traffic.
Organizations that may not have the desire or technical resources to implement HTTPS.
While there’s no one-size-fits-all solution to these challenges,
we’ve put together a resource for webmasters to use
as they work through this process. We also support industry-wide efforts, like EFF's ‘
Encrypt the Web
’ report, that aim to bring more of the web to HTTPS.
Implementing encryption is not easy work. But, as more people spend more of their time on the web, it’s an increasingly essential element of online security. We hope this report will provide a snapshot of our own encryption efforts and will encourage everyone to make HTTPS the default on the web, even faster.
Get Rich or Hack Tryin’
March 14, 2016
Posted by Nathan Parker, Chrome Defender and Tim Willis, Hacker Philanthropist
Since 2010, we've happily rewarded researchers who find and report security issues to us through Google’s Security Reward Program. Last year,
Google paid researchers more than $2,000,000 for their work
to make Google users safer.
It's no secret that Chrome takes security seriously. Today, we’re introducing two new changes to expand the Chrome Reward Program even further:
Increasing our top reward from $50,000 to $100,000.
Last year we introduced a $50,000 reward for the persistent compromise of a Chromebook in guest mode. Since we introduced the $50,000 reward, we haven’t had a successful submission. That said, great research deserves great awards, so we’re putting up a standing six-figure sum, available all year round with no quotas and no maximum reward pool.
Adding a Download Protection Bypass bounty.
We’re extending our reward program scope to include rewards for methods that bypass Chrome’s
Safe Browsing
download protection features
. There’s much more detail on this new category on
our rewards page
- be sure to take a look if you’re interested.
We look forward to seeing some amazing bugs and continuing to work with the security research community.
Happy hacking!
Scalable vendor security reviews
March 7, 2016
Posted by Lukas Weichselbaum and Daniel Fabian, Google Security
[Cross-posted on the
Google Open Source Blog
]
At Google, we assess the security of hundreds of vendors every year. We scale our efforts through automating much of the initial information gathering and triage portions of the vendor review process. To do this we've developed the Vendor Security Assessment Questionnaire (VSAQ), a collection of self-adapting questionnaires for evaluating multiple aspects of a vendor's security and privacy posture.
We've received feedback from many vendors who completed the questionnaires. Most vendors found them intuitive and flexible — and, even better, they've been able to use the embedded tips and recommendations to improve their security posture. Some also expressed interest in using the questionnaires to assess their own suppliers.
Based on this positive response, we've decided to open source the VSAQ Framework (Apache License Version 2) and the generally applicable parts of our questionnaires on GitHub:
https://github.com/google/vsaq
. We hope it will help companies spin up, or further improve their own vendor security programs. We also hope the base questionnaires can serve as a self-assessment tool for security-conscious companies and developers looking to improve their security posture.
The VSAQ Framework comes with four security questionnaire templates that can be used with the VSAQ rendering engine:
Web Application Security Questionnaire
Security & Privacy Program Questionnaire
Infrastructure Security Questionnaire
Physical & Data Center Security Questionnaire
All four base questionnaire templates can be readily extended with company-specific questions. Using the same questionnaire templates across companies may help to scale assessment efforts. Common templates can also minimize the burden on vendor companies, by facilitating the reuse of responses.
The
VSAQ Framework
comes with a simple client-side-only reference implementation that's suitable for self-assessments, for vendor security programs with a moderate throughput, and for just trying out the framework. For a high-throughput vendor security program, we recommend using the VSAQ Framework with a custom server-side component that fits your needs (the interface is quite simple).
Give VSAQ a try! A demo version of the VSAQ Framework is available here:
https://vsaq-demo.withgoogle.com
Excerpt from Security and Privacy Programs Questionnaire
Let us know how VSAQ works for you:
contact us
. We look forward to getting your feedback and continuing to make vendor reviews scalable — and maybe even fun!
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome security
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
interoperability
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
vulnerabilities
Archive
2021
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