Security Blog
The latest news and insights from Google on security and safety on the Internet
Better protection against Man in the Middle phishing attacks
18. April 2019
Posted by Jonathan Skelker, Product Manager, Account Security
We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require
JavaScript to be enabled
in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like
Safe Browsing warnings
,
Gmail spam filters
, and
account sign-in challenges
.
However, one form of phishing, known as “
man in the middle
” (MITM), is hard to detect when an embedded browser framework (e.g.,
Chromium Embedded Framework
- CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the
restriction on webview
sign-ins announced in April 2016.
What developers need to know
The solution for developers currently using CEF for authentication is the same:
browser-based OAuth authentication
. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.
The Android Platform Security Model
18. April 2019
Posted by Jeff Vander Stoep, Android Security & Privacy Team
Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that
demonstrates
the
effectiveness
of
these
improvements
. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing
The Android Platform Security Model
. Specifically we discuss:
The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
The complex threat model Android must address.
How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
How Android’s security systems have evolved over time to address the threat model.
Android is fundamentally based on a multi-party consent
1
model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich
Notes
The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world.
↩
Gmail making email more secure with MTA-STS standard
10. April 2019
Posted by Nicolas Lidzborski, Senior Staff Software Engineer, Google Cloud and Nicolas Kardas, Senior Product Manager, Google Cloud
We’re excited to announce that Gmail will become the first major email provider to follow the new
SMTP MTA Strict Transport Security (MTA-STS) RFC 8461
and
SMTP TLS Reporting RFC 8460
internet standards. Those new email security standards are the result of three years of collaboration within
IETF
, with contributions from Google and other large email providers.
SMTP alone is vulnerable to man-in-the-middle attacks
Like all mail providers, Gmail uses Simple Mail Transfer Protocol (SMTP) to send and receive mail messages. SMTP alone only provides best-effort security with opportunistic encryption, and many SMTP servers do not prevent certain types of malicious attacks intercepting email traffic in transit.
SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection. Real attacks and prevention were highlighted in our
research published in November 2015
. MTA-STS will help prevent these types of attacks.
MTA-STS uses encryption and authentication to reduce vulnerabilities
A MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.
Gmail is starting MTA-STS adherence. We hope others will follow
Gmail the first major provider to follow the new standard, initially launching in Beta on April 10th 2019. This means Gmail will honor MTA-STS and TLS reporting policies configured when sending emails to domains that have defined these policies. We hope many other email providers will soon adopt these new standards that make email communications more secure.
Email domain administrators should set up DNS records and web server endpoint to configure MTA-STS and TLS reporting policies for incoming emails. Use our Help Center to find out
how to set up an MTA-STS policy with your DNS server
. G Suite admins can use the G Suite Updates blog to see what MTA-STS means for G Suite domains.
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
hacking
interoperability
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
2022
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2021
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2020
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2019
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2018
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2017
Dez.
Nov.
Okt.
Sep.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2016
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2015
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2014
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Apr.
März
Feb.
Jan.
2013
Dez.
Nov.
Okt.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2012
Dez.
Sep.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2011
Dez.
Nov.
Okt.
Sep.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
2010
Nov.
Okt.
Sep.
Aug.
Juli
Mai
Apr.
März
2009
Nov.
Okt.
Aug.
Juli
Juni
März
2008
Dez.
Nov.
Okt.
Aug.
Juli
Mai
Feb.
2007
Nov.
Okt.
Sep.
Juli
Juni
Mai
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow