Posted by Alex Klyubin, Android Security team

[Cross-posted from the Android Developers Blog]

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.
New Protections Mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next Steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com. HTTPS, Android-Security

Posted by Adrian Ludwig, Lead Engineer, Android Security
Today, for the second year in a row, we’re releasing our Android Security Annual report. This detailed summary includes: a look at how Google services protect the Android ecosystem, an overview of new security protections introduced in 2015, and our work with Android partners and the security research community at large. The full report is here, and an overview is below.

One important goal of releasing this report is to drive an informed conversation about Android security. We hope to accomplish this by providing more information about what we are doing, and what we see happening in the ecosystem. We strongly believe that rigorous, data-driven discussion about security will help guide our efforts to make the Android ecosystem safer.
Enhancing Google's services to protect Android users

In the last year, we’ve significantly improved our machine learning and event correlation to detect potentially harmful behavior.

• We protected users from malware and other Potentially Harmful Apps (PHAs), checking over 6 billion installed applications per day.
• We protected users from network-based and on-device threats by scanning 400 million devices per day.
• And we protected hundreds of millions of Chrome users on Android from unsafe websites with Safe Browsing.

We continued to make it even more difficult to get PHAs into Google Play. Last year’s enhancements reduced the probability of installing a PHA from Google Play by over 40% compared to 2014. Within Google Play, install attempts of most categories of PHAs declined including:

• Data Collection: decreased over 40% to 0.08% of installs
• Spyware: decreased 60% to 0.02% of installs
• Hostile Downloader: decreased 50% to 0.01% of installs

Overall, PHAs were installed on fewer than 0.15% of devices that only get apps from Google Play. About 0.5% of devices that install apps from both Play and other sources had a PHA installed during 2015, similar to the data in last year’s report.

It’s critical that we also protect users that install apps from sources other than Google Play. Our Verify Apps service protects these users and we improved the effectiveness of the PHA warnings provided by Verify Apps by over 50%. In 2015, we saw an increase in the number of PHA install attempts outside of Google Play, and we disrupted several coordinated efforts to install PHAs onto user devices from outside of Google Play.

New security features in the Android platform

Last year, we launched Android 6.0 Marshmallow, introducing a variety of new security protections and controls:

• Full disk encryption is now a requirement for all new Marshmallow devices with adequate hardware capabilities and is also extended to allow encryption of data on SD cards.
• Updated app permissions enable you to manage the data they share with specific apps with more granularity and precision.
• New verified boot ensures your phone is healthy from the bootloader all the way up to the operating system.
• Android security patch level enables you to check and make sure your device has the most recent security updates.
• And much more, including support for fingerprint scanners, and SELinux enhancements.

Deeper engagement with the Android ecosystem

We’re working to foster Android security research and making investments to strengthen protections across the ecosystem now and in the long run.

In June, Android joined Google’s Vulnerability Rewards Program, which pays security researchers when they find and report bugs to us. We fixed over 100 vulnerabilities reported this way and paid researchers more than $200,000 for their findings.

In August, we launched our monthly public security update program to the Android Open Source Project, as well as a security update lifecycle for Nexus devices. We intend the update lifecycle for Nexus devices to be a model for all Android manufacturers going forward and have been actively working with ecosystem partners to facilitate similar programs. Since then, manufacturers have provided monthly security updates for hundreds of unique Android device models and hundreds of millions of users have installed monthly security updates to their devices. Despite this progress, many Android devices are still not receiving monthly updates—we are increasing our efforts to help partners update more devices in a timely manner.

Greater transparency, well-informed discussions about security, and ongoing innovation will help keep users safe. We'll continue our ongoing efforts to improve Android’s protections, and we look forward to engaging with the ecosystem and security community in 2016 and beyond.

Posted by Kurt Thomas and Yuan Niu, Spam & Abuse Research
Every week, over 10 million users encounter harmful websites that deliver malware and scams. Many of these sites are compromised personal blogs or small business pages that have fallen victim due to a weak password or outdated software. Safe Browsing and Google Search protect visitors from dangerous content by displaying browser warnings and labeling search results with 'this site may harm your computer'. While this helps keep users safe in the moment, the compromised site remains a problem that needs to be fixed.

Unfortunately, many webmasters for compromised sites are unaware anything is amiss. Worse yet, even when they learn of an incident, they may lack the security expertise to take action and address the root cause of compromise. Quoting one webmaster from a survey we conducted, “our daily and weekly backups were both infected” and even after seeking the help of a specialist, after “lots of wasted hours/days” the webmaster abandoned all attempts to restore the site and instead refocused his efforts on “rebuilding the site from scratch”.

In order to find the best way to help webmasters clean-up from compromise, we recently teamed up with the University of California, Berkeley to explore how to quickly contact webmasters and expedite recovery while minimizing the distress involved. We’ve summarized our key lessons below. The full study, which you can read here, was recently presented at the International World Wide Web Conference.

When Google works directly with webmasters during critical moments like security breaches, we can help 75% of webmasters re-secure their content. The whole process takes a median of 3 days. This is a better experience for webmasters and their audience.
How many sites get compromised?

Number of freshly compromised sites Google detects every week.

Over the last year Google detected nearly 800,000 compromised websites—roughly 16,500 new sites every week from around the globe. Visitors to these sites are exposed to low-quality scam content and malware via drive-by downloads. While browser and search warnings help protect visitors from harm, these warnings can at times feel punitive to webmasters who learn only after-the-fact that their site was compromised. To balance the safety of our users with the experience of webmasters, we set out to find the best approach to help webmasters recover from security breaches and ultimately reconnect websites with their audience.
Finding the most effective ways to aid webmaster

1. Getting in touch with webmasters: One of the hardest steps on the road to recovery is first getting in contact with webmasters. We tried three notification channels: email, browser warnings, and search warnings. For webmasters who proactively registered their site with Search Console, we found that email communication led to 75% of webmasters re-securing their pages. When we didn’t know a webmaster’s email address, browser warnings and search warnings helped 54% and 43% of sites clean up respectively.
2. Providing tips on cleaning up harmful content: Attackers rely on hidden files, easy-to-miss redirects, and remote inclusions to serve scams and malware. This makes clean-up increasingly tricky. When we emailed webmasters, we included tips and samples of exactly which pages contained harmful content. This, combined with expedited notification, helped webmasters clean up 62% faster compared to no tips—usually within 3 days.
3. Making sure sites stay clean: Once a site is no longer serving harmful content, it’s important to make sure attackers don’t reassert control. We monitored recently cleaned websites and found 12% were compromised again in 30 days. This illustrates the challenge involved in identifying the root cause of a breach versus dealing with the side-effects.

Making security issues less painful for webmasters—and everyone

We hope that webmasters never have to deal with a security incident. If you are a webmaster, there are some quick steps you can take to reduce your risk. We’ve made it easier to receive security notifications through Google Analytics as well as through Search Console. Make sure to register for both services. Also, we have laid out helpful tips for updating your site’s software and adding additional authentication that will make your site safer.

If you’re a hosting provider or building a service that needs to notify victims of compromise, understand that the entire process is distressing for users. Establish a reliable communication channel before a security incident occurs, make sure to provide victims with clear recovery steps, and promptly reply to inquiries so the process feels helpful, not punitive.

As we work to make the web a safer place, we think it’s critical to empower webmasters and users to make good security decisions. It’s easy for the security community to be pessimistic about incident response being ‘too complex’ for victims, but as our findings demonstrate, even just starting a dialogue can significantly expedite recovery.

Posted by Nirdhar Khazanie, Product Manager and Yossi Matias, VP Engineering

Last July, we launched Eddystone, an open and extensible Bluetooth Low Energy (BLE) beacon format from Google, supported by Android, iOS, and Chrome. Beacons mark important places and objects in a way that your phone can understand. To do this, they typically broadcast public one-way signals ‒ such as an Eddystone-UID or -URL.

Today, we're introducing Ephemeral IDs (EID), a beacon frame in the Eddystone format that gives developers more power to control who can make use of the beacon signal. Eddystone-EID enables a new set of use cases where it is important for users to be able to exchange information securely and privately. Since the beacon frame changes periodically, the signal is only useful to clients with access to a resolution service that maps the beacon’s current identifier to stable data. In other words, the signal is only recognizable to a controlled set of users. In this post we’ll provide a bit more detail about this feature, as well as Google’s implementation of Eddystone-EID with Google Cloud Platform’s Proximity Beacon API and the Nearby API for Android and CocoaPod for iOS.

Technical Specifications

To an observer of an Eddystone-EID beacon, the AES-encrypted eight byte beacon identifier changes pseudo-randomly with an average period that is set by the developer ‒ over a range from 1 second to just over 9 hours. The identifier is generated using a key and timer running on the beacon. When the beacon is provisioned, or set up, the key is generated and exchanged with a resolution service such as Proximity Beacon API using an Elliptic Curve Diffie-Hellman key agreement protocol, and the timer is synchronized with the service. This way, only the beacon and the service that it is registered with have access to the key. You can read more about the technical details of Eddystone-EID from the specification ‒ including the provisioning process ‒ on GitHub, or from our recent preprint.

An Eddystone-EID contains measures designed to prevent a variety of nuanced attacks. For example, the rotation period for a single beacon varies slightly from identifier to identifier, meaning that an attacker cannot use a consistent period to identify a particular beacon. Eddystone-EID also enables safety features such as proximity awareness, device authentication, and data encryption on packet transmission. The Eddystone-TLM frame has also been extended with a new version that broadcasts battery level also encrypted with the shared key, meaning that an attacker cannot use the battery level as an identifying feature either.

When correctly implemented and combined with a service that supports a range of access control checks, such as Proximity Beacon API, this pattern has several advantages:

• The beacon’s location cannot be spoofed, except by a real-time relay of the beacon signal. This makes it ideal for use cases where a developer wishes to enable premium features for a user at a location.
• Beacons provide a high-quality and precise location signal that is valuable to the deployer. Eddystone-EID enables deployers to decide which developers/businesses can make use of that signal.
• Eddystone-EID beacons can be integrated into devices that users carry with them without leaving users vulnerable to tracking.

Integrating Seamlessly with the Google Beacon Platform

Launching today on Android and iOS, is a new addition to the wider Google beacon platform: Beacon Tools. Beacon Tools allows you to provision and register an Eddystone-EID beacon, as well as associate content with your beacon through the Google Cloud Platform.

In addition to Eddystone-EID and the new encrypted version of the previously available Eddystone-TLM, we’re also adding a common configuration protocol to the Eddystone family. The Eddystone GATT service allows any Eddystone beacon to be provisioned by any tool that supports the protocol. This encourages the development of an open ecosystem of beacon products, both in hardware and software, removing restrictions for developers.

Eddystone-EID Support in the Beacon Industry

We’re excited to have worked with a variety of industry players as Eddystone-EID develops. Over the past year, Eddystone manufacturers in the beacon space have grown from 5 to over 25. The following 15 manufacturers will be supporting Eddystone-EID, with more to follow:

Accent Systems	Bluvision	Reco/Perples
Beacon Inside	Estimote	Sensoro
Blesh	Gimbal	Signal360
BlueBite	Nordic	Swirl
Bluecats	Radius Networks	Zebra

In addition to beacon manufacturers, we’ve been working with a range of innovative companies to demonstrate Eddystone-EID in a variety of different scenarios.

• Samsonite and Accent Systems have developed a suitcase with Eddystone-EID where users can securely keep track of their personal luggage.
• K11 is a Hong Kong museum and retail experience using Sensoro Eddystone-EID beacons for visitor tours and customer promotions.
• Monumental Sports in Washington, DC, uses Radius Networks Eddystone-EID beacons for delivering customer rewards during Washington Wizards and Capitals sporting events.
• Sparta Digital has produced an app called Buzzin that uses Eddystone-EID beacons deployed in Manchester, UK to enable a more seamless transit experience.

You can get started with Eddystone-EID by creating a Google Cloud Platform project and purchasing compatible hardware through one of our manufacturers. Best of all, Eddystone-EID works transparently to beacon subscriptions created through the Google Play Services Nearby Messages API, allowing you to run combined networks of Eddystone-EID and Eddystone-UID transparently in your client code!

Posted by Nav Jagpal, Software Engineer

We launched Safe Browsing Alerts for Network Administrators over 5 years ago. Just as Safe Browsing warns users about dangerous sites, this service sends notifications to network administrators when our systems detect harmful URLs on their networks.

We’ve made good progress:

• 22k ASNs are being monitored, or roughly 40% of active networks
• 1300 network administrators are actively using the tool
• 250 reports are sent daily to these administrators

Today, to provide Network Admins with even more useful information for protecting their users, we’re adding URLs related to Unwanted Software, Malicious Software, and Social Engineering to the set of information we share.

Here’s the full set of data we share with network administrators:

• Compromised: Pages harming users through drive-by-download or exploits.
• Distribution: Domains that are responsible for launching exploits and serving malware. Unlike compromised sites, which are often run by innocent webmasters, distribution domains are typically set up with the primary purpose of serving malicious content.
• Social Engineering: Deceptive websites that trick users into performing unwanted actions such as downloading software or divulging private information. Social engineering includes phishing sites that trick users into revealing passwords.
• Unwanted Software: URLs which lead to software that violates our Unwanted Software Policy. This kind of software is often distributed through deceptive means such as social engineering, and has harmful software traits such as modifying users’ browsing experience in unexpected ways and performing unwanted ad injections. You can learn more about Unwanted Software, or UwS, here.
• Malware Software: Traditional malware downloads, such as trojans and viruses.

Network administrators can use the data provided by our service to gain insights into the security and quality of their network. By working together, we can make it more challenging and expensive for attackers to profit from user harm.

If you’re a network administrator and haven’t yet registered your AS, you can do so here. If you are experiencing problems verifying ownership, please contact us.