Security Blog
The latest news and insights from Google on security and safety on the Internet
Cleaning up after password dumps
September 10, 2014
One of the unfortunate realities of the Internet today is a phenomenon known in security circles as “credential dumps”—the posting of lists of usernames and passwords on the web. We’re always monitoring for these dumps so we can respond quickly to protect our users. This week, we identified several lists claiming to contain Google and other Internet providers’ credentials.
We found that less than 2% of the username and password combinations might have worked, and our
automated anti-hijacking systems
would have blocked many of those login attempts. We’ve protected the affected accounts and have required those users to reset their passwords.
It’s important to note that in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems. Often, these credentials are obtained through a combination of other sources.
For instance, if you reuse the same username and password across websites, and one of those websites gets hacked, your credentials could be used to log into the others. Or attackers can use
malware
or
phishing
schemes to capture login credentials.
We’re constantly working to keep your accounts secure from phishing, malware and spam. For instance, if we see unusual account activity, we’ll stop sign-in attempts from unfamiliar locations and devices. You can
review this activity
and confirm whether or not you actually took the action.
A few final tips: Make sure you’re using a
strong password
unique to Google. Update your
recovery options
so we can reach you by phone or email if you get locked out of your account. And consider
2-step verification
, which adds an extra layer of security to your account. You can visit
g.co/accountcheckup
where you’ll see a list of many of the security controls at your disposal.
Posted by Borbala Benko, Elie Bursztein, Tadek Pietraszek and Mark Risher, Google Spam & Abuse Team
Gradually sunsetting SHA-1
September 5, 2014
Cross-posted on the
Chromium Blog
The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be
since at least 2005
— 9 years ago.
Collision attacks against SHA-1 are too affordable
for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.
That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
SHA-1's use on the Internet has been deprecated since 2011, when the CA/Browser Forum, an industry group of leading web browsers and certificate authorities (CAs) working together to establish basic security requirements for SSL certificates, published their
Baseline Requirements for SSL
. These Requirements recommended that all CAs transition away from SHA-1 as soon as possible, and followed similar events in other industries and sectors, such as
NIST
deprecating SHA-1 for government use in 2010.
We have seen this type of weakness turn into a practical attack before, with
the MD5 hash algorithm
. We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it. Unfortunately, this can be quite challenging. For example, when Chrome disabled MD5, a number of enterprises, schools, and small businesses were affected when their proxy software —
from leading vendors
— continued to use the insecure algorithms, and were left
scrambling for updates
. Users who used personal firewall software were also affected.
We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up (keep in mind that we release stable versions of Chrome about 6-8 weeks after their branch point):
Chrome 39 (Branch point 26 September 2014)
Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is
used to highlight other deprecated and insecure practices
, such as passive mixed content.
Chrome 40 (Branch point 7 November 2014; Stable after holiday season)
Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.
The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.
Chrome 41 (Branch point in Q1 2015)
Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.
The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.
Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.
Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer
That’s not the download you’re looking for...
August 14, 2014
Cross-posted on the
Chrome Blog
You should be able to use the web safely, without fear that malware could take control of your computer, or that you could be tricked into giving up personal information in a phishing scam.
That’s why we’ve invested so much in tools that protect you online. Our
Safe Browsing
service protects you from malicious websites and warns you about malicious downloads in Chrome. We’re currently showing more than three million download warnings per week—and because we make this technology available for other browsers to use, we can help keep 1.1 billion people safe.
Starting next week, we’ll be expanding Safe Browsing protection against additional kinds of deceptive software: programs disguised as a helpful download that actually make unexpected changes to your computer—for instance, switching your homepage or other browser settings to ones you don’t want.
We’ll show a warning in Chrome whenever an attempt is made to trick you into downloading and installing such software. (If you still wish to proceed despite the warning, you can access it from your Downloads list.)
As always, be careful and make sure you trust the source when downloading software. Check out
these tips
to learn how you can stay safe on the web.
Posted by Moheeb Abu Rajab, Staff Engineer, Google Security
Protecting Gmail in a global world
August 12, 2014
Last week
we announced support
for non-Latin characters in Gmail—think δοκιμή and 测试 and みんな—as a first step towards more global email. We’re really excited about these new capabilities. We also want to ensure they aren’t abused by spammers or scammers trying to send misleading or harmful messages.
Scammers can exploit the fact that
ဝ
,
૦
, and
ο
look nearly identical to the letter
o
, and by mixing and matching them, they can hoodwink unsuspecting victims.* Can you imagine the risk of clicking “Sh
ဝ
ppingSite” vs. “ShoppingSite” or “MyBank” vs. “MyB
ɑ
nk”?
To stay one step ahead of spammers, the Unicode community has identified suspicious combinations of letters that could be misleading, and Gmail will now begin rejecting email with such combinations. We’re using an open standard—the
Unicode Consortium
’
s “Highly Restricted” specification
—which we believe strikes a healthy balance between legitimate uses of these new domains and those likely to be abused.
We’re rolling out the
changes
today, and hope that others across the industry will follow suit. Together, we can help ensure that international domains continue to flourish, allowing both users and businesses to have a
tête-à-tête
in the language of their choosing.
Posted by Mark Risher, Spam & Abuse Team
*For those playing at home, that's a Myanmar letter Wa (U+101D), a Gujarati digit zero (U+AE6) and a Greek small letter omicron (U+03BF), followed by the ASCII letter 'o'.
HTTPS as a ranking signal
August 7, 2014
Cross-posted from the
Webmaster Central Blog
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like
strong HTTPS encryption by default
. That means that people using Search, Gmail and Drive, for example, automatically have a secure connection to Google.
Beyond our own stuff, we’re also working to make the Internet safer more broadly. A big part of that is making sure that websites people access from Google are secure. For instance, we have created resources to help webmasters
prevent and fix security breaches
on their sites.
We want to go even further. At
Google I/O
a few months ago, we called for “
HTTPS everywhere
” on the web.
We’ve also seen more and more webmasters adopting
HTTPS
(also known as HTTP over
TLS
, or Transport Layer Security), on their website, which is encouraging.
For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as
high-quality content
—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
In the coming weeks, we’ll publish detailed best practices (we’ll add a link to it from here) to make TLS adoption easier, and to avoid common mistakes. Here are some basic tips to get started:
Decide the kind of certificate you need: single, multi-domain, or wildcard certificate
Use 2048-bit key certificates
Use relative URLs for resources that reside on the same secure domain
Use protocol relative URLs for all other domains
Check out our
Site move article
for more guidelines on how to change your website’s address
Don’t block your HTTPS site from crawling using robots.txt
Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag
If your website is already serving on HTTPS, you can test its security level and configuration with the
Qualys Lab tool
. If you are concerned about TLS and your site’s performance, have a look at
Is TLS fast yet?
. And of course, if you have any questions or concerns, please feel free to post in our
Webmaster Help Forums
.
We hope to see more websites using HTTPS in the future. Let’s all make the web more secure!
Posted by
Zineb Ait Bahajji
and
Gary Illyes
, Webmaster Trends Analysts
Announcing Project Zero
July 15, 2014
Posted by Chris Evans, Researcher Herder
Security is a top priority for Google. We've invested a lot in making our products secure, including
strong SSL encryption by default
for Search, Gmail and Drive, as well as encrypting data moving between our data centers. Beyond securing our own products, interested Googlers also spend some of their time on
research that makes the Internet safer
, leading to the discovery of bugs like Heartbleed.
The success of that part-time research has led us to create a new, well-staffed team called Project Zero.
You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of
"zero-day" vulnerabilities
to target, for example,
human rights activists
or to conduct
industrial espionage
. This needs to stop. We think more can be done to tackle this problem.
Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted attacks. We're hiring the best practically-minded security researchers and contributing 100% of their time toward improving security across the Internet.
We're not placing any particular bounds on this project and will work to improve the security of
any
software depended upon by large numbers of people, paying careful attention to the techniques, targets and motivations of attackers. We'll use standard approaches such as locating and reporting large numbers of vulnerabilities. In addition, we'll be conducting new research into mitigations, exploitation, program analysis—and anything else that our researchers decide is a worthwhile investment.
We commit to doing our work transparently. Every bug we discover will be filed in an
external database
. We will only report bugs to the software's vendor—and no third parties. Once the bug report becomes public (typically once a patch is available), you'll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces. We also commit to sending bug reports to vendors in as close to real-time as possible, and to working with them to get fixes to users in a reasonable time.
We're hiring. We believe that most security researchers do what they do because they love what they do. What we offer that we think is new is a place to do what you love—but in the open and without distraction. We'll also be looking at ways to involve the wider community, such as extensions of our popular reward initiatives and guest blog posts. As we find things that are particularly interesting, we'll discuss them on
our blog
, which we hope you'll follow.
Maintaining digital certificate security
July 8, 2014
Posted by Adam Langley, Security Engineer
On Wednesday, July 2, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by the
National Informatics Centre
(NIC) of India, which holds several intermediate CA certificates trusted by the
Indian Controller of Certifying Authorities
(India CCA).
The India CCA certificates are
included in the Microsoft Root Store
and thus are trusted by the vast majority of programs running on Windows, including Internet Explorer and Chrome. Firefox is not affected because it uses its own root store that doesn’t include these certificates.
We are not aware of any other root stores that include the India CCA certificates, thus Chrome on other operating systems, Chrome OS, Android, iOS and OS X are not affected. Additionally, Chrome on Windows would not have accepted the certificates for Google sites because of
public-key pinning
, although misissued certificates for other sites may exist.
We promptly alerted NIC, India CCA and Microsoft about the incident, and we blocked the misissued certificates in Chrome with a
CRLSet
push.
On July 3, India CCA informed us that they revoked all the NIC intermediate certificates, and another CRLSet push was performed to include that revocation.
Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of widespread abuse and we are not suggesting that people change passwords.
At this time, India CCA is still investigating this incident. This event also highlights, again, that our
Certificate Transparency
project is critical for protecting the security of certificates in the future.
Update Jul 9:
India CCA informed us of the results of their investigation on July 8. They reported that NIC’s issuance process was compromised and that only four certificates were misissued; the first on June 25. The four certificates provided included three for Google domains (one of which we were previously aware of) and one for Yahoo domains. However, we are also aware of misissued certificates not included in that set of four and can only conclude that the scope of the breach is unknown.
The intermediate CA certificates held by NIC were revoked on July 3, as noted above. But a root CA is responsible for all certificates issued under its authority. In light of this, in a future Chrome release, we will limit the India CCA root certificate to the following domains and subdomains thereof in order to protect users:
gov.in
nic.in
ac.in
rbi.org.in
bankofindia.co.in
ncode.in
tcs.co.in
Google Drive update to protect to shared links
June 27, 2014
Posted by Kevin Stadmeyer, Technical Program Manager
At Google, ensuring the security of our users is a top priority, and we are constantly assessing how we can make our services even more secure. We recently received a report via our
Vulnerability Reward Program
of a security issue affecting a small subset of file types in Google Drive and have since made an update to address it.
This issue is only relevant if
all
of the following apply:
The file was uploaded to Google Drive
The file was
not
converted to Docs, Sheets, or Slides (i.e. remained in its original format such as .pdf, .docx, etc.)
The owner changed sharing settings so that the document was available to “Anyone with the link”
The file contained hyperlinks to third-party
HTTPS
websites in its content
In this specific instance, if a user clicked on the embedded hyperlink, the administrator of that third-party site could potentially receive header information that may have allowed him or her to see the URL of the original document that linked to his or her site.
Today’s update to Drive takes extra precaution by ensuring that newly shared documents with hyperlinks to third-party HTTPS websites will not inadvertently relay the original document’s URL.
While any documents shared going forward are no longer impacted by this issue, if one of your previously shared documents meets all four of the criteria above, you can generate a new sharing link with the following steps:
Create a copy of the document, via File > "Make a copy..."
Share the copy of the document with particular people or via a new shareable link, via the “Share” button
Delete the original document
See what your apps & extensions have been up to
June 10, 2014
Cross-posted from the
Chromium Blog
Extensions are a great way to enhance the browsing experience. However, some extensions ask for broad permissions that allow access to sensitive data such as browser cookies or history. Last year, we
introduced
the
Chrome Apps & Extensions Developer Tool
, which provides an improved developer experience for debugging apps and extensions. The newest version of the tool, available today, lets power users audit any app or extension and get visibility into the precise actions that it's performing.
Once you’ve installed the Chrome Apps & Extensions Developer Tool, it will start locally auditing your extensions and apps as you use them. For each app or extension, you can see historical activity over the past few days as well as real-time activity by clicking the “Behavior” link. The tool highlights activities that involve your information, such as reading website cookies or modifying web sites, in a privacy section. You can also search for URLs to see if an extension has modified any matching pages. If you’re debugging an app or extension, you can use the “Realtime” tab to watch the stream of API calls as an extension or app runs. This can help you track down glitches or identify unnecessary API calls.
Whether you’re a Chrome power user or a developer testing an extension, the Chrome Apps & Extensions Developer Tool can give you the information you need to understand how apps and extensions affect your browsing.
Posted by Adrienne Porter Felt, Software Engineer and Extension Tinkerer
Making end-to-end encryption easier to use
June 3, 2014
posted by Stephan Somogyi, Product Manager, Security and Privacy
Your security online has always been a top priority for us, and we’re constantly working to make sure your data is safe. For example, Gmail supported
HTTPS
when it first launched and now
always uses an encrypted connection
when you check or send email in your browser. We warn people
in Gmail
and
Chrome
when we have reason to believe they’re being targeted by bad actors. We also alert you to
malware and phishing
when we find it.
Today, we’re adding to that list the alpha version of a new tool. It’s called
End-to-End
and it’s a Chrome extension intended for users who need additional security beyond what we already provide.
“End-to-end” encryption means data leaving your browser will be encrypted until the message’s intended recipient decrypts it, and that similarly encrypted messages sent to you will remain that way until you decrypt them in your browser.
While end-to-end encryption tools like
PGP
and
GnuPG
have been around for a long time, they require a great deal of technical know-how and manual effort to use. To help make this kind of encryption a bit easier, we’re releasing
code
for a new Chrome extension that uses
OpenPGP
, an open standard supported by many existing encryption tools.
However, you won’t find the End-to-End extension in the
Chrome Web Store
quite yet; we’re just sharing the code today so that the community can test and evaluate it, helping us make sure that it’s as secure as it needs to be before people start relying on it. (And we mean it: our
Vulnerability Reward Program
offers financial awards for finding security bugs in Google code, including End-to-End.)
Once we feel that the extension is ready for primetime, we’ll make it available in the
Chrome Web Store
, and anyone will be able to use it to send and receive end-to-end encrypted emails through their existing web-based email provider.
We recognize that this sort of encryption will probably only be used for very sensitive messages or by those who need added protection. But we hope that the End-to-End extension will make it quicker and easier for people to get that extra layer of security should they need it.
You can find more technical details describing how we've architected and implemented End-to-End
here
.
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
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
.