Security Blog
The latest news and insights from Google on security and safety on the Internet
Landing another blow against email phishing
January 30, 2012
(Cross-posted from the
Gmail Blog
)
Posted by Adam Dawes, Product Manager
Email phishing, in which someone tries to trick you into revealing personal information by sending fake emails that look legitimate, remains one of the biggest online threats. One of the most popular methods that scammers employ is something called
domain spoofing
. With this technique, someone sends a message that seems legitimate when you look at the “From” line even though it’s actually a fake. Email phishing is costing regular people and companies millions of dollars each year, if not more, and in response, Google and other companies have been talking about how we can move beyond the solutions we’ve developed individually over the years to make a real difference for the whole email industry.
Industry groups come and go, and it’s not always easy to tell at the beginning which ones are actually going to generate good solutions. When the right contributors come together to solve real problems, though, real things happen. That’s why we’re particularly optimistic about
today’s announcement
of DMARC.org, a passionate collection of companies focused on significantly cutting down on email phishing and other malicious mail.
Building upon the work of previous mail authentication standards like
SPF
and
DKIM
, DMARC is responding to domain spoofing and other phishing methods by creating a standard protocol by which we’ll be able to measure and enforce the authenticity of emails. With DMARC, large email senders can ensure that the email they send is being recognized by mail providers like Gmail as legitimate, as well as set policies so that mail providers can reject messages that try to spoof the senders’ addresses.
We’ve been active in the leadership of the DMARC group for almost two years, and now that Gmail and several other large mail senders and providers — namely Facebook, LinkedIn, and PayPal — are actively using the DMARC specification, the road is paved for more members of the email ecosystem to start getting a handle on phishing. Our recent data indicates that roughly 15% of non-spam messages in Gmail are already coming from domains protected by DMARC, which means Gmail users like you don’t need to worry about spoofed messages from these senders. The phishing potential plummets when the system just works, and that’s what DMARC provides.
If you’re a large email sender and you want to try out the DMARC specification, you can learn more at the
DMARC website
. Even if you’re not ready to take on the challenge of authenticating all your outbound mail just yet, there’s no reason to not sign up to start receiving reports of mail that fraudulently claims to originate from your address. With further adoption of DMARC, we can all look forward to a more trustworthy overall experience with email.
Tech tips that are Good to Know
January 17, 2012
Posted by Alma Whitten, Director of Privacy, Product and Engineering
(Cross-posted from the
Official Google Blog
)
Does this person sound familiar? He can’t be bothered to type a password into his phone every time he wants to play a game of Angry Birds. When he does need a password, maybe for his email or bank website, he chooses one that’s easy to remember like his sister’s name—and he uses the same one for each website he visits. For him, cookies come from the bakery, IP addresses are the locations of Intellectual Property and a correct Google search result is basically magic.
Most of us know someone like this. Technology can be confusing, and the industry often fails to explain clearly enough why digital literacy matters. So today in the U.S. we’re kicking off
Good to Know
, our biggest-ever consumer education campaign focused on making the web a safer, more comfortable place. Our ad campaign, which we introduced in the U.K. and Germany last fall, offers privacy and security tips: Use
2-step verification
! Remember to lock your computer when you step away! Make sure your connection to a website is
secure
! It also
explains
some of the building blocks of the web like cookies and IP addresses. Keep an eye out for the ads in newspapers and magazines, online and in New York and Washington, D.C. subway stations.
The campaign and
Good to Know website
build on our commitment to keeping people safe online. We’ve created resources like
privacy videos
, the
Google Security Center
, the
Family Safety Center
and
Teach Parents Tech
to help you develop strong privacy and security habits. We design for privacy, building tools like
Google Dashboard
,
Me on the Web
, the
Ads Preferences Manager
and
Google+ Circles
—with more on the way.
We encourage you to take a few minutes to check out the
Good to Know site
, watch
some
of
the
videos
, and be on the lookout for ads in your favorite newspaper or website. We hope you’ll learn something new about how to protect yourself online—tips that are always good to know!
Update
1/17
: Updated to include more background on Good to Know.
Expanding Safe Browsing Alerts to include malware distribution domains
December 1, 2011
Posted by Nav Jagpal, Security Team
For the past year, we’ve been sending notifications to network administrators registered through the
Safe Browsing Alerts for Network Administrators
service when our automated tools find phishing URLs or compromised sites that lead to malware on their networks. These notifications provide administrators with important information to help them improve the security of their networks.
Today we’re adding distribution domains to the set of information we share. These are domains that are responsible for launching exploits and serving malware. Unlike compromised sites, which are often run by innocent webmasters, distribution domains are set up with the primary purpose of serving malicious content.
If you’re a network administrator and haven’t yet registered your AS, you can do so
here
.
Reminder: Safe Browsing version 1 API turning down December 1
November 22, 2011
Posted by Brian Ryner, Security Team
In May we
announced
that we are ending support for the Safe Browsing protocol version 1 on December 1 in order to focus our resources on the
new version 2 API
and the
lookup service
. These new APIs provide simpler and more efficient access to the same data, and they use significantly less bandwidth. If you haven't yet migrated off of the version 1 API, we encourage you to do so as soon as possible. Our
earlier post
contains links to documentation for the new protocol version and other resources to help you make the transition smoothly.
After December 1, we will remove all data from the version 1 API list to ensure that any remaining clients do not have false positives in their database. After January 1, 2012, we will turn off the version 1 service completely, and all requests will return a 404 error.
Thanks for your cooperation, and enjoy using the next generation of Safe Browsing.
Protecting data for the long term with forward secrecy
November 22, 2011
Posted by Adam Langley, Security Team
Last year we introduced
HTTPS by default for Gmail
and
encrypted search
. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling
forward secrecy
by default.
Most major sites supporting HTTPS operate in a non-forward secret fashion, which runs the risk of retrospective decryption. In other words, an encrypted, unreadable email could be recorded while being delivered to your computer today. In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today’s email traffic.
Forward secrecy requires that the private keys for a connection are not kept in persistent storage. An adversary that breaks a single key will no longer be able to decrypt months’ worth of connections; in fact, not even the server operator will be able to retroactively decrypt HTTPS sessions.
Forward secret HTTPS is now live for Gmail and many other Google HTTPS services(*), like SSL Search, Docs and Google+. We have also
released the work
that we did on the open source OpenSSL library that made this possible. You can check whether you have forward secret connections in Chrome by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections will have a key exchange mechanism of ECDHE_RSA.
We would very much like to see forward secrecy become the norm and hope that our deployment serves as a demonstration of the practicality of that vision.
(* Chrome, Firefox (all platforms) and Internet Explorer (Vista or later) support forward secrecy using elliptic curve Diffie-Hellman. Initially, only Chrome and Firefox will use it by default with Google services because IE doesn’t support the combination of ECDHE and RC4. We hope to support IE in the future.)
Safe Browsing Alerts for Network Administrators is graduating from Labs
October 6, 2011
Posted by Nav Jagpal, Security Team
Today, we’re congratulating Safe Browsing Alerts for Network Administrators on its graduation from Labs to its new home at
http://www.google.com/safebrowsing/alerts/
We
announced
the tool about a year ago and have received a lot of positive feedback. Network administrators, large and small, are using the information we provide about malware and phishing URLs to clean up their networks and help webmasters make their sites safer. Earlier this year,
AusCert recognized our efforts
by awarding Safe Browsing Alerts for Network Administrators the title of “Best Security Initiative.”
If you’re a network administrator and haven’t yet registered your AS, you can do so
here
.
Gmail account security in Iran
September 8, 2011
Posted by Eric Grosse, VP Security Engineering
We
learned last week
that the compromise of a Dutch company involved with verifying the authenticity of websites could have put the Internet communications of many Iranians at risk, including their Gmail. While Google’s internal systems were not compromised, we are directly contacting possibly affected users and providing similar information below because our top priority is to protect the privacy and security of our users.
While users of the Chrome browser were protected from this threat, we advise all users in Iran to take concrete steps to secure their accounts:
Change your password. You may have already been asked to change your password when you signed in to your Google Account. If not, you can change it
here
.
Verify your account recovery options. Secondary email addresses, phone numbers, and other information can help you regain access to your account if you lose your password. Check to be sure your recovery options are correct and up to date
here
.
Check the websites and applications that are allowed to access your account, and revoke any that are unfamiliar
here
.
Check your Gmail settings for suspicious
forwarding addresses
or
delegated accounts
.
Pay careful attention to
warnings that appear
in your web browser and don’t click past them.
For more ways to secure your account, you can visit
http://www.google.com/help/security
. If you believe your account has been compromised, you can start the recovery process
here
.
An update on attempted man-in-the-middle attacks
August 29, 2011
Posted by Heather Adkins, Information Security Manager
Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).
Google Chrome users were protected from this attack because Chrome was able to
detect
the fraudulent certificate.
To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also
moved quickly
to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates. Microsoft also has
taken prompt action
.
To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.
Update
Aug 30:
Added information about Microsoft's response.
Update
Sept 3:
Our top priority is to protect the privacy and security of our users. Based on the findings and decision of the Dutch government, as well as conversations with other browser makers, we have decided to reject all of the Certificate Authorities operated by DigiNotar. We encourage DigiNotar to provide a complete analysis of the situation.
Four Years of Web Malware
August 17, 2011
Posted by Lucas Ballard and Niels Provos, Google Security Team
Google’s Safe Browsing initiative has been protecting users from web pages that install malware for over five years now. Each day we show around 3 million malware warnings to over four hundred million users whose browsers implement the Safe Browsing API. Like other service providers, we are engaged in an arms race with malware distributors. Over time, we have adapted our original system to incorporate new detection algorithms that allow us to keep pace. We recently completed an analysis of four years of data that explores the evasive techniques that malware distributors employ. We compiled the results in a technical report, entitled “
Trends in Circumventing Web-Malware Detection
.”
Below are a few of the research highlights, but we recommend reviewing the
full report
for details on our methodology and measurements. The analysis covers approximately 160 million web pages hosted on approximately 8 million sites.
Social Engineering
Social engineering is a malware distribution mechanism that relies on tricking a user into installing malware. Typically, the malware is disguised as an anti-virus product or browser plugin. Social engineering has increased in frequency significantly and is still rising. However, it’s important to keep this growth in perspective — sites that rely on social engineering comprise only 2% of all sites that distribute malware.
Number of sites distributing Social Engineering Malware and Exploits over time
Drive-by Download Exploit Trends
Far more common than social engineering, malicious pages install malware after exploiting a vulnerability in the browser or a plugin. This type of infection is often called a drive-by download. Our analysis of which vulnerabilities are actively being exploited over time shows that adversaries quickly switch to new and more reliable exploits to help avoid detection. The graph below shows the ratio of exploits targeting a vulnerability in one CVE to all exploits over time. Most vulnerabilities are exploited only for a short period of time until new vulnerabilities become available. A prominent exception is the MDAC vulnerability which is present in most exploit kits.
Prevalence of exploits targeting specific CVEs over time
Increase in IP Cloaking
Malware distributors are increasingly relying upon ‘cloaking’ as a technique to evade detection. The concept behind cloaking is simple: serve benign content to detection systems, but serve malicious content to normal web page visitors. Over the years, we have seen more malicious sites engaging in IP cloaking. To bypass the cloaking defense, we run our scanners in different ways to mimic regular user traffic.
Number of sites practicing IP Cloaking over time
New Detection Capabilities
Our report analyzed four years of data to uncover trends in malware distribution on the web, and it demonstrates the ongoing tension between malware distributors and malware detectors. To help protect Internet users, even those who don’t use Google, we have updated the Safe Browsing infrastructure over the years to incorporate many state-of-the-art malware detection technologies. We hope the findings outlined in this report will help other researchers in this area and raise awareness of some of the current challenges.
Fuzzing at scale
August 12, 2011
Posted by Chris Evans, Matt Moore and Tavis Ormandy, Google Security Team
One of the exciting things about working on security at Google is that you have a lot of compute horsepower available if you need it. This is very useful if you’re looking to
fuzz
something, and especially if you’re going to use modern fuzzing techniques.
Using these techniques and large amounts of compute power, we’ve found hundreds of bugs in our own code, including Chrome components such as WebKit and the PDF viewer. We recently decided to apply the same techniques to fuzz Adobe’s Flash Player, which we include with Chrome in partnership with Adobe.
A good overview of some modern techniques can be read
in this presentation
. For the purposes of fuzzing Flash, we mainly relied on “corpus distillation”. This is a technique whereby you locate a large number of sample files for the format at hand (SWF in this case). You then see which areas of code are reached by each of the sample files. Finally, you run an algorithm to generate a minimal set of sample files that achieves the code coverage of the full set. This calculated set of files is a great basis for fuzzing: a manageable number of files that exercise lots of unusual code paths.
What does corpus distillation look like at Google scale? Turns out we have a large index of the web, so we cranked through 20 terabytes of SWF file downloads followed by 1 week of run time on 2,000 CPU cores to calculate the minimal set of about 20,000 files. Finally, those same 2,000 cores plus 3 more weeks of runtime were put to good work mutating the files in the minimal set (bitflipping, etc.) and generating crash cases. These crash cases included an interesting range of vulnerability categories, including buffer overflows, integer overflows, use-after-frees and object type confusions.
The initial run of the ongoing effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following Adobe's initial triage. As these bugs were resolved, many were identified as duplicates that weren't caught during the initial triage. A unique crash signature does not always indicate a unique bug. Since Adobe has access to symbols and sources, they were able to group similar crashes to perform root cause analysis reducing the actual number of changes to the code. No analysis was performed to determine how many of the identified crashes were actually exploitable. However, each crash was treated as though it were potentially exploitable and addressed by Adobe. In the final analysis, the Flash Player update Adobe shipped earlier this week contained about 80 code changes to fix these bugs.
Commandeering massive resource to improve security is rewarding on its own, but the real highlight of this exercise has been Adobe’s response. The
Flash patch
earlier this week fixes these bugs and incorporates UIPI protections for the Flash Player sandbox in Chrome which Justin Schuh contributed assistance on developing. Fixing
so many issues
in such a short time frame shows a real commitment to security from Adobe, for which we are grateful.
Labels
#sharethemicincyber
#supplychain #security #opensource
AI Security
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
Sep
Aug
Jul
Jun
May
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