Martin Thoma A blog about Code, Politics, and my life

Click at Your Own Risk: No App Store is Safe

· by

Contents
Comic drawing of a man in front of a computer screen showing a warning with a skull

Why do software marketplaces such as the Android Play Store, the iOS App Store, Docker’s Docker Hub, Python’s PyPI, or JavaScript’s npm have so much malware? Can’t they do more against it? Is it just a money question?

Let me show you the reasons!

Reality Check: Is it that bad?

Let me give you some of the titles of stories of malicious apps in software marketplaces:

To summarize: Malware is present in every software marketplace. The marketplaces with more users are targeted more often.

What are the core problems?

Why is it so hard to create a secure software marketplace?

  1. Too many app versions: Every day hundreds of software packages get uploaded to each marketplace. It’s just impossible to manually and thoroughly check all of them. Every new version could have malware. So it’s not enough to check the app once.
  2. Rinse and repeat: Assume malware was detected and removed from the marketplace. Then the attacker can upload the same malware with minor modifications.
  3. Automatic detection is flawed: It’s very hard to detect malicious software automatically.

What could software marketplaces do to fight malware?

№1: Clear Reporting Paths

Let users help you to identify malicious software. It sounds simple, but such a reporting path also means the marketplace needs a team dealing with the reports.

№2: Pay-to-Publish

Implementing a pay-to-publish option is rather easy for many software marketplaces if they already have a payment option. The effectiveness is low because malware can generate a high income. Additionally, this option has the severe drawback of closing the marketplace for some people.
Implementing a pay-to-publish option is rather easy for many software marketplaces if they already have a payment option. The effectiveness is low because malware can generate a high income. Additionally, this option has the severe drawback of closing the marketplace for some people.

The more expensive an action becomes, the more people try to avoid it. That means if app developers needed to pay something for every single app update, they would do it less often. The same goes for malware developers.

Let’s see who employs this tactic:

  • Apple App Store: 99 USD/year
  • Google Play Store: 25 USD (once)
  • PyPI (Python): Free
  • NPM (JavaScript): Free

№3: Identify uploaders

Requiring the identification of users to upload software means that the infrastructure to identify people needs to be created. That is very hard. If it should be effective, identifications need to be done in a similar way as banks do it. This means either eID or Video Identification. I assume this would be effective as it would be a lot harder to upload new versions. In the end, malware creators do not want to have the malware tied to their identities. The big drawback would be the identification: Some users will hate it, and the software store suddenly needs to deal with sensitive data (privacy).
Requiring the identification of users to upload software means that the infrastructure to identify people needs to be created. That is very hard. If it should be effective, identifications need to be done in a similar way as banks do it. This means either eID or Video Identification. I assume this would be effective as it would be a lot harder to upload new versions. In the end, malware creators do not want to have the malware tied to their identities. The big drawback would be the identification: Some users will hate it, and the software store suddenly needs to deal with sensitive data (privacy).

When people want to open a bank account in Europe, they have to be identified. The process is not perfect, but it does take some effort to fake this and it’s certainly nothing an attacker can do in bulk.

Similarly, if the software marketplaces would require identification to upload software, uploading malware would become much harder.

Identifying people makes it impossible for an attacker to re-upload the same malware again and again. They need to do it with other people, which is more time-consuming.

However, those other people might just be victims of hacks. For example, Gentoo’s GitHub mirror was hacked in 2018 and Canonical’s GitHub account was hacked in 2019.

№4: Sandboxing and Permissions

Implementing effective sandboxing is extremely difficult. Android and iOS have done it, but I don’t know if there is any option for desktop operating systems (Windows, Mac, Linux). Once a working sandboxing system is implemented, it is extremely effective in limiting malware. The malware needs to be more sneaky. The only drawback is usability: It’s hard for users to decide if a given set of permissions is reasonable.
Implementing effective sandboxing is extremely difficult. Android and iOS have done it, but I don’t know if there is any option for desktop operating systems (Windows, Mac, Linux). Once a working sandboxing system is implemented, it is extremely effective in limiting malware. The malware needs to be more sneaky. The only drawback is usability: It’s hard for users to decide if a given set of permissions is reasonable.

Sandboxing means that the smartphone or server running the software (the platform) allows the software less stuff to do. For example, restricting access to the network is a crucial one or to the local file system.

The more fine-grained this system is, the easier it is for a user to judge if something fishy might go on. For example, why would a flashlight need network access?

Android’s permission system has quite a lot of options. Many are related to sensors, but also access to some parts of the software like contacts or the calendar.
Android’s permission system has quite a lot of options. Many are related to sensors, but also access to some parts of the software like contacts or the calendar.

By default, the platform could forbid everything. The user has to give explicit permission to enable that — outside of the software.

How malware scanners work under the hood

Comic drawing of a man examining a smiling green pill in a parcel with a magnifying glass

Malware scanners take a software bundle and make a decision: Is it bad?

The tricky part is that software cannot decide for arbitrary other software what it does. It’s a consequence of the halting problem.

As a simple example, take Python code. We typically have the code in plain text which gives you way more options for analysis. And let’s assume that software is always malware when it accesses the internet. In Python, that is typically done with the requests library. Hence you could search for import requests to determine if you have malware.

This approach has two problems:

  1. False positives: You would identify tons of software as malware which has a legitimate reason to access the internet. For example, an application giving you a weather forecast.
  2. False negatives: Attackers can avoid this type of detection.

For example, attackers could create a new package not_requests that imports requests. Their software would then depend on not_requests. As a response, the automatic check could take the transitive closure of the package's dependencies (hence all dependencies, including their dependencies).

Then the attacker does a dynamic import which is also done by plugin systems:

import importlib

requests = importlib.import_module("requests")

Oh, and before you think the malware scanner could search for the string requests: The attacker can encrypt that string. It doesn’t matter that the decryption key is within the shipped code as the goal is only to prevent static analysis from detecting it. In the simplest case, they just apply base64. Or a self-written simple cipher. Nothing hard for a cryptographer to break, but impossible for a machine to automatically decipher when it’s part of a large code base.

Summary

Software marketplaces will never be perfectly safe. For that reason, users should be careful which software they install and use.