How we fought bad apps and developers in 2021

Posted by Steve Kafka and Khawaja Shams, Android Security and Privacy Team

Providing a safe experience to billions of users continues to be one of the highest priorities for Google Play. Last year we introduced multiple privacy focused features, enhanced our protections against bad apps and developers, and improved SDK data safety. In addition, Google Play Protect continues to scan billions of installed apps each day across billions of devices to keep people safe from malware and unwanted software.

We continue to enhance our machine learning systems and review processes, and in 2021 we blocked 1.2 million policy violating apps from being published on Google Play, preventing billions of harmful installations. We also continued in our efforts to combat malicious and spammy developers, banning 190k bad accounts in 2021. In addition, we have closed around 500k developer accounts that are inactive or abandoned.

In May we announced our new Data safety section for Google Play where developers will be required to give users deeper insight into the privacy and security practices of the apps they download, and provide transparency into the data the app may collect and why. The Data safety section launched this week, and developers are required to complete this section for their apps by July 20th.

We’ve also invested in making life easier for our developers. We added the Policy and Programs section to Google Play Console to help developers manage all their app compliance issues in one central location. This includes the ability to appeal a decision and track its status from this page.

In addition, we continued to partner with SDK developers to improve app safety, limit how user data is shared, and improve lines of communication with app developers. SDKs provide functionality for app developers, but it can sometimes be tricky to know when an SDK is safe to use. Last year, we engaged with SDK developers to build a safer Android and Google Play ecosystem. As a result of this work, SDK developers have improved the safety of SDKs used by hundreds of thousands of apps impacting billions of users. This remains a huge investment area for our team, and we will continue in our efforts to make SDKs safer across the ecosystem.

Limiting access

The best way to ensure users’ data stays safe is to limit access to it in the first place.

As a result of new platform protections and policies, developer collaboration and education, 98% of apps migrating to Android 11 or higher have reduced their access to sensitive APIs and user data. We’ve also significantly reduced the unnecessary, dangerous, or disallowed use of Accessibility APIs in apps migrating to Android 12, while preserving the functionality of legitimate use cases.

We also continued in our commitment to make Android a great place for families. Last year we disallowed the collection of Advertising ID (AAID) and other device identifiers from all users in apps solely targeting children, and gave all users the ability to delete their Advertising ID entirely, regardless of the app.

Pixel enhancements

For Pixel users, we had even more great features to help keep you safe. Our new Security hub helps protect your phone, apps, Google Account, and passwords by giving you a central view of your device’s current configuration. Security hub also provides recommendations to improve your security, helping you decide what settings best meet your needs.

In addition, Pixels now use new machine learning models that improve the detection of malware in Google Play Protect. The detection runs on your Pixel, and uses a privacy preserving technology called federated analytics to discover bad apps.

Our global teams are dedicated to keeping our billions of users safe, and look forward to many exciting announcements in 2022.

/by

A lookback under the TA410 umbrella: Its cyberespionage TTPs and activity

ESET researchers reveal a detailed profile of TA410: we believe this cyberespionage umbrella group consists of three different teams using different toolsets, including a new version of the FlowCloud espionage backdoor discovered by ESET.

The post A lookback under the TA410 umbrella: Its cyberespionage TTPs and activity appeared first on WeLiveSecurity

/by

The trouble with BEC: How to stop the costliest internet scam

BEC fraud generated more losses for victims than any other type of cybercrime in 2021. It’s long past time that organizations got a handle on these scams.

The post The trouble with BEC: How to stop the costliest internet scam appeared first on WeLiveSecurity

/by

Webcam hacking: How to know if someone may be spying on you through your webcam

Camfecting doesn’t ‘just’ invade your privacy – it could seriously impact your mental health and wellbeing. Here’s how to keep an eye on your laptop camera.

The post Webcam hacking: How to know if someone may be spying on you through your webcam appeared first on WeLiveSecurity

/by

Cybersecurity threats to critical infrastructure – Week in security with Tony Anscombe

As the Five Eyes nations warn of attacks against critical infrastructure, we look at the potentially cascading effects of such attacks and how essential systems and services can ramp up their defense

The post Cybersecurity threats to critical infrastructure – Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by

Critical infrastructure: Under cyberattack for longer than you might think

Lessons from history and recent attacks on critical infrastructure throw into sharp relief the need to better safeguard our essential systems and services

The post Critical infrastructure: Under cyberattack for longer than you might think appeared first on WeLiveSecurity

/by

Is your Lenovo laptop vulnerable to cyberattack?

Here’s what to know about vulnerabilities in more than 100 Lenovo consumer laptop models and what you can do right away to stay safe – all in under three minutes

The post Is your Lenovo laptop vulnerable to cyberattack? appeared first on WeLiveSecurity

/by

How can we support young people in harnessing technology for progress?

Young people are not passive victims of technology or helpless addicts. They are technology creators and agents with diverse backgrounds and interests.

The post How can we support young people in harnessing technology for progress? appeared first on WeLiveSecurity

/by

When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops

ESET researchers discover multiple vulnerabilities in various Lenovo laptop models that allow an attacker with admin privileges to expose the user to firmware-level malware

The post When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops appeared first on WeLiveSecurity

/by

How to SLSA Part 3 – Putting it all together

Posted by Tom Hennen, software engineer, BCID & GOSST 


In our last two posts (1,2) we introduced a fictional example of Squirrel, Oppy, and Acme learning to SLSA and covered the basics and details of how they’d use SLSA for their organizations. Today we’ll close out the series by exploring how each organization pulls together the various solutions into a heterogeneous supply chain.

As a reminder, Acme is trying to produce a container image that contains three artifacts:

  1. The Squirrel package ‘foo’
  2. The Oppy package ‘baz’
  3. A custom executable, ‘bar’, written by Acme employees.

The process starts with ‘foo’ package authors triggering a build using GitHub Actions. This results in a new version of ‘foo’ (an artifact with hash ‘abc’) being pushed to the Squirrel repo along with its SLSA provenance (signed by Fulcio) and source attestation. When Squirrel gets this push request it verifies the artifact against the specific policy for ‘foo’ which checks that it was built by GitHub Actions from the expected source repository. After the artifact passes the policy check a VSA is created and the new package, its original SLSA provenance, and the VSA are made public in the Squirrel repo, available to all users of package ‘foo’.

Next the maintainers of the Oppy ‘baz’ package trigger a new build using the Oppy Autobuilder. This results in a new version of ‘baz’ (an artifact with hash ‘def’) being pushed to a public Oppy repo with the SLSA provenance (signed by their org-specific keys) published to Rekor. When the repo gets the push request it makes the artifact available to the public. The repo does not perform any verification at this time.

An Acme employee then makes a change to their Dockerfile, sending it for review by their co-worker, who approves the change and merges the PR. This then causes the Acme builder to trigger a build. During this build:

  • bar is compiled from source code stored in the same source repo as the Dockerfile.
  • acorn install downloads ‘foo’ from the Squirrel repo, verifying the VSA, and recording the use of acorn://foo@abc and its VSA in the build.
  • acme_oppy_get install (a custom script made by Acme) downloads the latest version of the Oppy ‘baz’ package and queries its SLSA provenance and other attestations from Rekor. It then performs a full verification checking that it was built by ‘https://oppy.example/slsa/builder/v1’ and the publicized key. Once verification is complete it records the use of oppy://baz@def and the associated attestations in the build.
  • The build process assembles the SLSA provenance for the container by:
    • Recording the Acme git repo the bar source and Dockerfile came from, into materials.
    • Copying the reported dependencies of acorn://foo@abc and oppy://baz@def into materials and adding their attestations to the output in-toto bundle.
    • Recording the CI/CD entrypoint as the invocation.
    • Creating a signed DSSE with the SLSA provenance and adding it to the output in-toto bundle.

Once the container is ready for release the Acme verifier checks the SLSA provenance (and other data in the in-toto bundle) using the policy from their own policy repo and issues a VSA. The VSA and all associated attestations are then published to an internal Rekor instance. Acme can then create an SBOM for the container leveraging data about the build as stored in Rekor. Acme then publishes the container image, the VSA, and the SBOM on Dockerhub.

Downstream users of this Acme container can then check the Acme issued VSA, and if there are any problems Acme can consult their internal Rekor instance to get more details on the build allowing Acme to trace all of their dependencies back to source code and the systems used to create them.
Conclusion

With SLSA implemented in the ways described in this series, downstream users are protected from many of the threats affecting the software supply chain today. While users still need to trust certain parties, the number of systems requiring trust is much lower and users are in a much better position to investigate any issues that arise.

We’d love to see the ideas in this series implemented, refuted, or used as a foundation to build even stronger solutions. We’d also love to hear some other methods on how to solve these issues. Show us how you like to SLSA. 

/by