I tried my hand at reverse engineering an application from the top 100 of the App Store; the result is pretty good. Or rather, it is heartbreaking. Security chronicles are the very unattractive sin of mobile applications. From a mobile application security perspective, 2019 can be considered an annus horribilis. Let’s remember: with a simple phone call, hackers took control of dozens of targeted WhatsApp accounts.
The day after the release of Tchap, the government’s secure messaging application, 1 hour 15 minutes was enough for a security expert to get into it. In Japan, the 7-Eleven grocery store payment application was deactivated three days after its launch: hackers had robbed a thousand customers of around €500 each. These setbacks would serve as a lesson to mobile application publishers. Yet not a month has gone by without a company falling victim to hacking via the mobile channel.
- In April 2020, security researchers (SecOps) highlighted the possibility of elaborate attacks against the native iOS Mail application.
- In May, the “social survey” app Wishbone was attacked: the private data of 40 million users, including passwords, were stolen… The firm had already been the victim of a similar hack in 2017, involving “only” 2 million email addresses.
- Finally, on a less dramatic note, in February, three ethical and certainly gourmet hackers from Hamburg combined several vulnerabilities in the McDonald’s app to offer themselves burgers in potentially unlimited quantities… They informed McDonald’s, which admitted to having noticed nothing.
Four Reasons Why Safety Accidents Are Too Frequent
Why does this litany of industrial accidents not dry up? Several explanations can be put forward.
- The first is due to the extraordinary popularity of smartphones: today, there are 3.5 billion of them, half of the world’s population. Apps used by more than 100 million people are not uncommon. WhatsApp has more than 1.5 billion regular users, including, necessarily, high-ranking personalities. Such a base is an unrivaled source of desire for attackers, some of whom are ready to implement extraordinary means to achieve their goals proportional to the value of their target.
- The second paradoxically relates to the high security of iOS and Android development platforms. Apple and Google are competing to see who can best protect the data and privacy of their customers, with Apple going so far as to make a marketing argument for its choice of “ privacy by design.” The application execution environments offered by these OS are certainly particularly impervious to intrusions (“sandbox” technique). The other side of this coin is an illusion of security that pushes developers to let their guard down: why worry about security if my OS takes care of it for me?
- The third is due to the relative youth of mobile development professions. The iPhone has only just celebrated its 13th anniversary. While the platforms have certainly developed at a high speed, the teams that design mobile solutions have only sometimes been able to perpetuate their knowledge. Thus, the 7-Eleven flaw mentioned above is really a sign of youth: on the page allowing you to change your password, it was possible to have a reset link sent… to the address of your choice (the one hacker, for example)! We are amazed by such lightness, which is hard to imagine in more traditional software.
- The result of the two previous points is a glaring lack of “security culture” among those involved in mobile development, not only among many developers but also among designers and event management teams.
Different from UX, a field where almost intercultural collaborations between developers, designers, and project managers are numerous and fruitful, security is primarily forgotten in mobile design. Instead of being everyone’s business, it is no one’s business. This is a textbook case of the “not my job” syndrome: if I am not responsible for the security of my app, then I will not be guilty either if it gets hacked.
The Most Famous Applications Neglect Basic Security Rules
One might believe that security problems, it is well known, only happen to others and that one must, in any case, deploy ultra-sophisticated techniques to compromise an app – like the astonishing methods of technicality deployed by NSO Group when it attacked WhatsApp. It is not so. Let’s take a concrete example with the most basic reverse engineering of an application chosen at random from the Top 100 of the App Store.
To avoid quoting her, we will agree on the assumed name: Doe. It is a digital content distribution app that is in the Top 10 in its category. With more than 10 million users, Doe is playing in the big leagues. October 25, 2020. Let’s allow one minute to download Doe. In two minutes, using a tool as mundane as Apple Configurator, a developer with no particular talent will be able to get their hands on Doe’s compiled code and resources (its .ipa) and then browse them freely.
Two more minutes and the app traffic will be redirected to a proxy (Charles, for example): this is what we call a man-in-the-middle (MIM) attack, which allows, when successful, to view all network exchanges. If these two analyses, static for the first and dynamic for the second, do not give results quickly, there is a good chance that the apprentice hacker will become discouraged – and that is the least we would expect. From an app to 10 million users! Now, what do we discover in Doe?
- The compiled code reveals long alphanumeric strings that look very similar to API keys.
- The MIM attack works smoothly: the communication between Doe and its servers is perfectly readable. We find the API key seen in the previous step.
- Not only is the traffic readable, but it is not even encrypted: exchanges are done using standard HTTP (HTTP-non-S), going against all recommendations.
What risks do these vulnerabilities pose to Doe? They are considerable. Equipped with the API keys and a detailed understanding of the app’s communication (thanks to flaws 1 and 2), it is easy to build, for example, a competing service exploiting, at Doe’s expense, its private APIs; or more sneakily, coordinate an attack to suck up a good part of Doe’s catalog, or the shared data of its users.
The 3rd flaw can be exploited by a competitor to generate a terrible bad buzz, to the tune of: “Do you know, Doe users, that by connecting to your favorite app via, for example, your company’s wifi, your employer can have clear access to all your consumption? »
However, these three flaws are easy to plug! We know that an app should only store secrets like API keys in hard copy (at least not with a minimum of obfuscation). The effective countermeasure of certificate pinning to curb MIM attacks has long been known. Above all, we cannot ignore that Internet exchanges should be done in HTTPS: on iOS, since the launch of
App Transport Security in 2015, unsecured HTTP calls fail… unless you activate a particular setting, dangerous, strongly discouraged, and for which Apple typically requires justification when submitting to the App Store. We could also criticize Apple for double-talk, which, on the one hand, claims to offer the most secure platform and authorizes developers to disconnect this security without warning their users.
Thinking about security is not a vain thought: user data, intellectual property, keys, secrets… we know the value of the assets to be protected. And when it comes to how to protect them, we’re not alone: entire books have been written, tons of information is available online… The OWASP Foundation offers a free guide to evaluating app security, with a very complete 84-point checklist, translated into five languages: who refers to it? Too few players, according to the “Mobile Security Index” study (Verizon, 2020): 43% of companies surveyed freely admit to having “sacrificed security” in the past year. This very high figure leaves us in great silence.
Safety culture as the only salvation
Is all lost? No, but better spreading the culture of safety requires a drastic change in mentality. The first step consists of considering security as a commercial asset, as Apple does, and attractiveness, like Leboncoin: to recruit developers fond of security, who tend to stick their noses everywhere, they targeted those by hiding in the HTML source code of their pages… a job offer pointing to their recruitment site! Drawing inspiration from other sectors of activity will also be profitable.
Can we imagine giving control of an airliner to someone who does not have the license to pilot it? Or market a car without it having passed a technical inspection and crash tests (the IT equivalent of which are intrusion tests)? No, of course. From this, on security issues, digital companies could advantageously put aside their penchant for disruption and reconnect with the good practices of their more traditional counterparts.
Also Read: An Exploratory Testing Tester’s Guide to Mobile Apps
