Security Blog
The latest news and insights from Google on security and safety on the Internet
OnHub: Powerful protection for peace of mind
2016年9月27日
Posted by Chris Millikin, Public Defender (Security Engineering Manager)
[Cross-posted from the
Official OnHub Blog
]
Since OnHub launched, we've highlighted a variety of features that enable users to do the things they love online without having to deal with the annoying router issues that we've all experienced at one time or another. These include: Fast, reliable Wi-Fi for more than 100 devices at a time, easy streaming and sharing, and wide-ranging coverage that helps eliminate dead zones.
We haven't, however, highlighted one of OnHub's most powerful features: Industry-leading security. Your router is the first line of defense for your online world. Because bad actors are aware of the critical position routers occupy in the network, routers are frequently the target of security attacks.
OnHub’s security features go beyond those of the typical router: OnHub is hardened against a variety of attacks, protecting your home network from many online threats. Three features in particular help ensure OnHub protects your data and devices from a variety of threats.
Three Security features that set OnHub apart
1. Defense in Depth
There are many elements that go into creating a robust defense in depth.
Auto updates: OnHub regularly downloads automatic updates without you having to do anything--a long-established practice on mobile devices and software like Chrome, but one that appliances haven’t caught up with yet. These updates provide regular maintenance fixes and address critical vulnerabilities. They’re like the seatbelts of online security—
internet security experts
recommend that users always accept updates.
However, when updates don’t happen automatically, many people don’t bother. OnHub communicates directly with Google, and makes sure all software is signed and verified. For instance, when a vulnerability was found in a software library (
glibc
) earlier this year, we were able to update OnHub’s entire fleet of devices within just a few days. In comparison, the vast majority of other routers require active user intervention to protect against such threats.
Verified Boot: Verified Boot protects you by preventing compromised OnHubs from booting. We use this technology in Chromebooks,
strictly enforce it in Android Nougat
, and we implemented it in OnHub from the very beginning. This makes OnHub extremely difficult to attack or compromise. For instance, the device runs software that has been cryptographically signed by Google.
Cloud administration: A traditional router is commonly attacked through its local administration web interface, where attackers have taken advantage of exploits like
CSRF
to remotely take control and change critical settings like DNS, so we eliminated that from the beginning. Instead OnHub is managed through the cloud, with strong authentication and authorization, using a simple phone app. A read-only API is available only on the internal network, to provide important data to the OnHub app during setup and when troubleshooting.
Process isolation: We also layer multiple techniques such as process isolation (uid/gid separation, namespaces, capability whitelists) and
seccomp
filtering to isolate network-facing services, which helps reduce potential attack scenarios in a given application by preventing an attacker from making lateral movements in the system.
2. Hardware Provenance
Modern hardware devices include many types of chips, drivers, and firmware. It’s important to know what each part is doing and where it came from. Our security team works to track the origins of all hardware, software, and firmware that goes into OnHub, including those from third-party sources. If a vulnerability is ever found, OnHub security works to fix the problem immediately.
The same goes for the open source components of OnHub. Before shipping, we do comprehensive code reviews of critical attack surfaces (i.e. network facing daemons), looking for security vulnerabilities. For example, we reviewed miniupnpd, hostapd, and dnsmasq. As a result of those reviews, Google reported security bugs to the open source project maintainers and offered patches. Here are three that we fixed:
bugs
in
hosted
.
3. Cloud Intelligence
We use anonymized metrics from our fleet of OnHubs to quickly detect and counter potential threats. For example, since we know that DNS is often a target of attacks, we monitor DNS settings on all OnHub routers for activity that could indicate a security compromise. This is “cloud intelligence” – a benefit that Google is uniquely able to deliver. By connecting OnHub to the Google cloud, we provide the same level of protection you expect across all your Google apps and devices. Because you manage your router through the cloud using your secure Google identity, you don’t have to remember yet another password for managing your OnHub, and you don’t have to be at home to control it.
Security Improvements, Automatically
OnHub also participates in
Google’s Vulnerability Reward Program
, which started in 2010 to honor all of the cutting-edge external contributions that help us keep our users safe. Through this program, if you can find a qualifying bug in OnHub’s security, rewards range from $100 to $20,000. Click
here
for an outline of the rewards for the most common classes of bugs.
When it comes to security, not all routers are created equal. OnHub protects you and your network with security that continues to adapt to threats. We’re always improving OnHub security, and automatically update without users having to take any actions. As cybersecurity evolves and new threats emerge, OnHub will be ready to meet the latest challenges for years to come.
Reshaping web defenses with strict Content Security Policy
2016年9月26日
Posted by Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, and David Ross, Information Security Engineers
Cross-site scripting
— the ability to inject undesired scripts into a trusted web application — has been one of the top web security vulnerabilities for over a decade. Just in the past 2 years Google has awarded researchers over $1.2 million for reporting XSS bugs in our applications via the
Vulnerability Reward Program
. Modern web technologies such as
strict contextual auto-escaping
help developers avoid mistakes which lead to XSS, and
automated scanners
can catch classes of vulnerabilities during the testing process. However, in complex applications bugs inevitably slip by, allowing attacks ranging from harmless pranks to malicious
targeted exploits
.
Content Security Policy (CSP) is a mechanism designed to step in precisely when such bugs happen; it provides developers the ability to restrict which scripts are allowed to execute so that even if attackers can inject HTML into a vulnerable page, they should not be able to load malicious scripts and other types of resources. CSP is a flexible tool allowing developers to set a wide range of policies; it is supported — though not always in its entirety — by all modern browsers.
However, the flexibility of CSP also leads to its biggest problem: it makes it easy to set policies which appear to work, but offer no real security benefit. In a
recent Internet-wide study
we analyzed over 1 billion domains and found that 95% of deployed CSP policies are ineffective as a protection against XSS. One of the underlying reasons is that out of the 15 domains most commonly whitelisted by developers for loading external scripts as many as 14 expose patterns which allow attackers to bypass CSP protections. We believe it's important to improve this, and help the web ecosystem make full use of the potential of CSP.
Towards safer CSP policies
To help developers craft policies which meaningfully protect their applications, today we’re releasing the
CSP Evaluator
, a tool to visualize the effect of setting a policy and detect subtle misconfigurations. CSP Evaluator is used by security engineers and developers at Google to make sure policies provide a meaningful security benefit and cannot be subverted by attackers.
Even with such a helpful tool, building a safe script whitelist for a complex application is often all but impossible due to the number of popular domains with resources that allow CSP to be bypassed. Here’s where the idea of a nonce-based CSP policy comes in. Instead of whitelisting all allowed script locations, it’s often simpler to modify the application to prove that a script is trusted by the developer by giving it a nonce -- an unpredictable, single-use token which has to match a value set in the policy:
Content-Security-Policy: script-src 'nonce-random123'
<script nonce='random123'>alert('This script will run')</script>
<script>alert('Will not run: missing nonce')</script>
<script nonce='bad123'>alert("Won't run: invalid nonce")</script>
With '
strict-dynamic'
, a part of the upcoming CSP3 specification already
supported
by Chrome and Opera (and coming soon to Firefox), adopting such policies in complex, modern applications becomes much easier. Developers can now set a single, short policy such as:
script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'
and make sure that all static
<script>
elements contain a matching nonce attribute — in many cases this is all that’s needed to enjoy added protection against XSS since ‘strict-dynamic’ will take care of loading any trusted scripts added at runtime. This approach allows setting policies which are
backwards-compatible
with all CSP-aware browsers, and
plays well
with applications which already use a traditional CSP policy; it also simplifies the process of adopting CSP and doesn’t require changing the policy as the application evolves.
Adopting strict CSP
In the past months we’ve deployed this approach in several large Google applications, including
Cloud Console
,
Photos
,
History
,
Careers Search
,
Maps Timeline
,
Cultural Institute
and are working on many more. We believe this approach can also help other developers so today we’re publishing documentation discussing the
best strategies for implementing CSP
, including an overview of the
benefits of CSP
, sample policies, and examples of common
code changes
.
Further, today we’re releasing
CSP Mitigator
, a Chrome extension that helps developers review an application for compatibility with nonce-based CSP. The extension can be enabled for any URL prefix and will collect data about any programming patterns that need to be refactored to support CSP. This includes identifying scripts which do not have the correct nonce attribute, detecting inline event handlers, javascript: URIs, and several other more subtle patterns which might need attention.
As with the CSP Evaluator, we use the extension with our applications to help speed up the process of adopting nonce-based CSP policies nonce-based policies across Google.
Encouraging broader use of strict CSP
Finally, today we’re including CSP adoption efforts in the scope of the
Patch Reward Program
; proactive work to help make popular open-source web frameworks compatible with nonce-based CSP can qualify for rewards (but please read the
program rules
and
CSP refactoring tips
first). We hope that increased attention to this area will also encourage researchers to find new, creative ways to circumvent CSP restrictions, and help us further improve the mechanism so that we can better protect Internet users from web threats.
To reach out to us, email more-csp@google.com.
Even More Safe Browsing on Android!
2016年9月15日
Posted by Stephan Somogyi, Safe Browsing Team & William Luh, Android Security Team
During Google I/O in June, we
told everyone
that we were going to make a device-local Safe Browsing API available to all Android developers later in the year. That time has come!
Starting with
Google Play Services version 9.4
, all Android developers can use our privacy-preserving, and highly network as well as power-efficient on-device Safe Browsing infrastructure to protect all of their apps’ users. Even better,
the API is simple and straightforward to use
.
Since we introduced client-side Safe Browsing on Android, updated our
documentation for Safe Browsing Protocol Version 4
(pver4), and also released our
reference pver4 implementation in Go
, we’ve been able to see how much protection this new technology provides to all our users. Since
our initial launch
we’ve shown hundreds of millions of warnings, actively warning many millions of mobile users about badness before they’re exposed to it.
We look forward to all Android developers extending this same protection to their users, too.
Moving towards a more secure web
2016年9月8日
Posted by Emily Schechter, Chrome Security Team
[Updated on 12/5/16 with instructions for developers]
Developers
: Read more about how to update your sites
here
.
To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.
Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or
modify
the site before it gets to you.
A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we
released our HTTPS report
in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.
Studies show that users
do not perceive
the lack of a “secure” icon as a warning, but also that users become blind to warnings that occur too frequently.
Our plan
to label HTTP sites more clearly and accurately as non-secure will take place in gradual steps, based on increasingly stringent criteria. Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.
In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.
We will publish updates to this plan as we approach future releases, but don’t wait to get started moving to HTTPS. HTTPS is
easier and cheaper than ever before
, and enables both the
best
performance
the web offers and
powerful
new
features
that are too sensitive for HTTP. Check out our
set-up guides
to get started.
Keeping Android safe: Security enhancements in Nougat
2016年9月6日
Posted by Xiaowen Xin, Android Security Team
[Cross-posted from the
Android Developers Blog
]
Over the course of the summer, we previewed a variety of security enhancements in Android 7.0 Nougat: an increased focus on security with our
vulnerability rewards program
, a new
Direct Boot mode
, re-architected mediaserver and
hardened media stack
, apps that are protected from
accidental regressions to cleartext traffic
, an update to the way Android handles
trusted certificate authorities
, strict enforcement of
verified boot
with error correction, and
updates to the Linux kernel to reduce the attack surface and increase memory protection
. Phew!
Now that Nougat has begun to roll out, we wanted to recap these updates in a single overview and highlight a few new improvements.
Direct Boot and encryption
In previous versions of Android, users with encrypted devices would have to enter their PIN/pattern/password by default during the boot process to decrypt their storage area and finish booting. With Android 7.0 Nougat, we’ve updated the underlying encryption scheme and streamlined the boot process to speed up rebooting your phone. Now your phone’s main features, like the phone app and your alarm clock, are ready right away before you even type your PIN, so people can call you and your alarm clock can wake you up. We call this feature
Direct Boot
.
Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys. Essential apps can opt-in to run in a limited state after reboot, and when you enter your lock screen credential, these apps then get access your user data to provide full functionality.
File-based encryption better isolates and protects individual users and profiles on a device by encrypting data at a finer granularity. Each profile is encrypted using a unique key that can only be unlocked by your PIN or password, so that your data can only be decrypted by you.
Encryption support is getting stronger across the Android ecosystem as well. Starting with Marshmallow, all capable devices were required to support encryption. Many devices, like Nexus 5X and 6P also use unique keys that are accessible only with trusted hardware, such as the ARM TrustZone. Now with 7.0 Nougat, all new capable Android devices must also have this kind of hardware support for key storage and provide brute force protection while verifying your lock screen credential before these keys can be used. This way, all of your data can only be decrypted on that exact device and only by you.
The media stack and platform hardening
In Android Nougat, we’ve both hardened and
re-architected
mediaserver, one of the main system services that processes untrusted input. First, by incorporating integer overflow sanitization, part of Clang’s
UndefinedBehaviorSanitizer
, we prevent an entire class of vulnerabilities, which comprise the majority of reported libstagefright bugs. As soon as an integer overflow is detected, we shut down the process so an attack is stopped. Second, we’ve modularized the media stack to put different components into individual sandboxes and tightened the privileges of each sandbox to have the minimum privileges required to perform its job. With this containment technique, a compromise in many parts of the stack grants the attacker access to significantly fewer permissions and significantly reduced exposed kernel attack surface.
In addition to hardening the mediaserver, we’ve added a large list of protections for the platform, including:
Verified Boot: Verified Boot is now strictly enforced to prevent compromised devices from booting; it supports
error correction
to improve reliability against non-malicious data corruption.
SELinux: Updated SELinux configuration and increased Seccomp coverage further locks down the application sandbox and reduces attack surface. Library load order randomization and improved ASLR: Increased randomness makes some code-reuse attacks less reliable.
Kernel hardening
: Added additional memory protection for newer kernels by
marking portions of kernel memory as read-only
,
restricting kernel access to userspace addresses
, and further reducing the existing attack surface.
APK signature scheme v2
: Introduced a whole-file signature scheme that improves
verification speed
and strengthens integrity guarantees.
App security improvements
Android Nougat is the safest and easiest version of Android for application developers to use.
Apps that want to share data with other apps now must explicitly opt-in by offering their files through a
Content Provider
, like
FileProvider
. The application private directory (usually /data/data/) is now set to Linux permission 0700 for apps targeting API Level 24+.
To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are
no longer trusted by default
for apps targeting API Level 24+. Additionally, all new Android devices must ship with the
same trusted CA store
.
With
Network Security Config
, developers can more easily configure network security policy through a declarative configuration file. This includes blocking cleartext traffic, configuring the set of trusted CAs and certificates, and setting up a separate debug configuration.
We’ve also continued to refine app permissions and capabilities to protect you from potentially harmful apps.
To improve device privacy, we have further restricted and removed access to persistent device identifiers such as MAC addresses.
User interface overlays can no longer be displayed on top of permissions dialogs. This “clickjacking” technique was used by some apps to attempt to gain permissions improperly.
We’ve reduced the power of device admin applications so they can no longer change your lockscreen if you have a lockscreen set, and device admin will no longer be notified of impending disable via
onDisableRequested()
. These were tactics used by some ransomware to gain control of a device.
System Updates
Lastly, we've made significant enhancements to the OTA update system to keep your device up-to-date much more easily with the latest system software and security patches. We've made the install time for OTAs faster, and the OTA size smaller for security updates. You no longer have to wait for the optimizing apps step, which was one of the slowest parts of the update process, because the new JIT compiler has been
optimized
to make installs and updates lightning fast.
The update experience is even faster for new Android devices running Nougat with updated firmware. Like they do with Chromebooks, updates are applied in the background while the device continues to run normally. These updates are applied to a different system partition, and when you reboot, it will seamlessly switch to that new partition running the new system software version.
We’re constantly working to improve Android security and Android Nougat brings significant security improvements across all fronts. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at
security@android.com
.
More Safe Browsing Help for Webmasters
2016年9月6日
Posted by Kelly Hope Harrington, Safe Browsing Team
For more than
nine years
, Safe Browsing has helped webmasters via Search Console with information about how to fix security issues with their sites. This includes relevant Help Center articles, example URLs to assist in diagnosing the presence of harmful content, and a process for webmasters to request reviews of their site after security issues are addressed. Over time, Safe Browsing has expanded its protection to cover additional threats to user safety such as
Deceptive Sites
and
Unwanted Software
.
To help webmasters be even more successful in resolving issues, we’re happy to announce that we’ve updated the information available in Search Console in the Security Issues report.
The updated information provides more specific explanations of six different security issues detected by Safe Browsing, including
malware
,
deceptive pages
,
harmful downloads
, and
uncommon downloads
. These explanations give webmasters more context and detail about what Safe Browsing found. We also offer tailored recommendations for each type of issue, including sample URLs that webmasters can check to identify the source of the issue, as well as specific remediation actions webmasters can take to resolve the issue.
We on the Safe Browsing team definitely recommend
registering
your site in Search Console even if it is not currently experiencing a security issue. We send notifications through Search Console so webmasters can address any issues that appear
as quickly as possible
.
Our goal is to help webmasters provide a safe and secure browsing experience for their users. We welcome any questions or feedback about the new features on the
Google Webmaster Help Forum
, where
Top Contributors
and Google employees are available to help.
For more information about Safe Browsing’s ongoing work to shine light on the state of web security and encourage safer web security practices, check out our summary of trends and findings on the
Safe Browsing Transparency Report
. If you’re interested in the tools Google provides for webmasters and developers dealing with hacked sites, this
video
provides a great overview.
標籤
#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
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2023
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2022
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2021
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2020
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
7月
6月
4月
3月
2月
1月
2013
12月
11月
10月
8月
6月
5月
4月
3月
2月
1月
2012
12月
9月
8月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
2010
11月
10月
9月
8月
7月
5月
4月
3月
2009
11月
10月
8月
7月
6月
3月
2008
12月
11月
10月
8月
7月
5月
2月
2007
11月
10月
9月
7月
6月
5月
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow