Advanced Persistent Threats and the rise of the app stores

Once upon a time, the battle between malware writers and antimalware (AM) protection writers was all about doing business in volume. In the old days of the untargeted attack, if the victim had antimalware protection, then the attack would fail and the attacker would move on to find another victim. The main objective was to create a botnet, so it didn't really matter which computers they compromised. Defenders responded with systems that blacklisted the machines running those botnets – in effect, building a virtual prison to contain the known or obviously malicious wrongdoers.

                                                                                           

Advanced Persistent Threat (APT) attacks, however, are precisely targeted. To maximize their success, attackers have adopted a version of the same Quality Assurance (QA) processes familiar to most engineers: Before releasing their malware in “the wild,” attackers test it against familiar AM products (or against their underground versions of services such as VirusTotal), tweaking the code until it effectively evades detection. This approach provides a huge advantage for the attackers and a huge disadvantage for defenders – not so much a technical advantage as a logical advantage of information asymmetry. The attackers know what will and won’t be detected, while the timing, vector, and scale of the attack continue to remain in their sole control. In this situation, blacklists are woefully ineffective.

 

Whereas blacklisting is like a prison system locking the bad guys in, human society also has another model for security -- a "gated community," in which the bad guys are outside the gates instead of inside. In the computer world, this model is called "whitelisting," and in a perfect world, whitelisting is an IT admin's dream, in which only allowed apps can enter the safe space and run. However, whitelisting has been violently rejected by the users when they can't get their work done because their favorite app is not allowed, resulting in whitelisting being deemed impractical. (One way of implementing whitelisting on a global scale without directly affecting the users was to use a certificate chain – a good idea in theory, however, during actual implementation there is some mistake in the trust chain.)

 

Then along came the app store, a central repository of apps. For the purposes of this post, I’ll use “app store” as a generic term for a central repository of available applications that is managed by a commercial entity or entities and made available to consumers as the exclusive option for downloading new applications. Android users of course are able to install third-party applications by overriding the default app store settings, and most mobile devices can be jailbroken, but such non-default configurations are beyond the scope of this post.

 

App stores are not brand new; for instance, Ubuntu had an app store of sorts for a long time, other Linux users are quite familiar with the repository model, and even Apple and Windows users have long had access to curated sites such as download.com. The main difference for mobile OSes from previous incarnations is that use of the app store is now mandatory.

 

 

DiffOutAndInFiltering.jpg

 

Figure 1. Difference between out-of-line and in-line filtering of apps

 

Let’s break the model down. Here, filtering is mandatory/in-line. The app must be registered, as must the app developer. This means that the only approved apps made by approved developers can get onto the machine. Basically, you need to have a license to become a developer, just as you need to have a license to drive a car, just as you need a license to practice medicine. 

 

In this model, filtering is centralized, not host-based. This means the malware writer cannot QA-test their new creations on their own machine -- and if an account is trying to submit malware, the malicious developer account can be tracked down. And though it might be easy enough to create a new app, it is not easy in this model to create multiple developer account personas. In short, the app store holds the power of life and death over every app by every developer.

 

To my libertarian engineering mind, this model is wrong. It's too draconian. I should be able to run any apps that you make, and able to distribute my own apps freely to everyone. Freedom and anonymity is the core of the Internet culture, and losing full control of our devices is a severe degradation of that freedom. Furthermore, if there is going to be a filter, or if a law is to be imposed, it should be stated explicitly, so that everyone will know exactly where the line is and where the holes are. Without that information, how do we know we are not bounded by the whims of whomever is in control of the app store filtering?

 

And yet I think the move to the app store model is the best security improvement in years.

 

So, what has changed to make this model an improvement? The industry’s focus and the burden of security awareness have shifted, changing with the rise of mobile OSes. It is not the "mobile" part of those OSes that made the difference, but consumers’ perception of what post-Internet, modern-era devices should be. Mobile devices are now computers with fully capable OSes, but they are no longer perceived as computers or as engineering machines – and not even as business machines, which users are trained to use and expected to operate with a certain degree of responsibility for keeping themselves safe. Instead, the devices are consumer products, along the lines of TVs and cars. And as with televisions and cars, modern mobile devices are managed devices. We don’t expect their users to make technical decisions about modern mobile devices any more than we expect them to service their own cable boxes or analyze the fuel  they put in their tanks.

 

It seems that we are going to live with the app store system for some time. Can we? The issue becomes a matter of trust – that is, whether we can trust the managers of the app stores to filter and evaluate their offerings appropriately. The Android app stores – we’ll use Google Play as a representative example -- are still full of questionable adware/grayware, since AM vendors and the Google Play store disagree on the definition of what is malicious. Meanwhile, iOS stores contain almost no malware, but iOS could be viewed as censoring store offerings too much. Gambling and adult contents apps are not allowed, nor are BitCoin apps. We could turn our heads and say those sites are too vulgar, but looking at Alexa’s top 500 sites, we can see the reality of Internet habit – gambling and adult contents are very, very popular. 

 

Technically, AM/app stores are all censoring their contents to some degree, and ideally -- if the organization is censoring in agreement with the users -- that is the best job that AM/the app store could do. Whether it’s legally or ethically the best practical course of action depends on whether we think of these mobile devices as critical infrastructure or as simply a (non-critical) consumer product.  

 

In the critical-infrastructure model, expert opinion can override the popular vote, and some authority figure, such as Apple or a government, can define what is good and require that the citizens should follow that rule. (This isn’t a democracy, in other words.) This critical-infrastructure model already exists in other contexts; for instance, FDA approval of new drugs is expert-driven. However, whether to define these mobile devices and the infrastructure they use as critical infrastructure is still up for a debate.

 

If, on the other hand, the computer device is best classified as a consumer product, the consumer should be able to have the most say in defining what should be allowed. In that situation, the experts’ role should be focused on explaining the deep technology in language that consumers can understand, so consumers are more readily be able to participate in the decision making. Unilateral censorship by AM/app store managers is far less defensible in this model.

 

Leaving aside the censorship question, how can we trust these centralized app stores to do the security job they’re taking on? Here the picture is murkier. Certainly there’s no free lunch in the software security ecosystem, unless you decide not to trust anything and are going to examine through every app line by line, you eventually have to trust someone or some entity to do that examination for you. In the system as it exists, that comes down to either the developer of the app or the manager of the site or store from which you’ve gotten it. The app store model is saying, "Trust us, instead of the app makers."

 

So can we? In my analysis, since app store owners are much bigger and more easily targeted for lawsuits, generally speaking the app store is more trustworthy than individual app makers when it comes to the safety of apps. Of course, the security mindset is always looking for potential flaws in models, and already a few questions come to mind. How can you be sure that the app you are downloading from the app store is the app that has been uploaded by the app maker? What if your specific copy is tainted? This might be too much paranoid thought, but in the world of security, someone has to ponder about these questions. I hope to take some of them up in a later blog post.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.