Mobile App Security: App Store vs. Google Play

Oct 24, 2017 10:46:08 AM / by Himanshu Dwivedi

A Statistical Security Comparison
Part 2: Third-Party Keyboards

A keylogger is an attacker’s best friend, period. A keylogger—software that captures keystrokes on a keyboard—is used by attackers to gather a tremendous amount of data from their victim. Once a keylogger is installed, which can range from easy to very hard depending on the platform, an attacker can simply sit back and wait for powerful credentials, including admin-level passwords, to land in their lap.
A bit of background on keyloggers
Not long ago, FakeGINA was the tool of choice. It was a fairly stable .dll targeting Windows operating systems. Unlike other keyloggers, FakeGINA was able to capture keystrokes after a user selected CTRL-ALT-Delete on a Windows machine, which not only captured the username/password to their workstation, but also possibly their domain username/password as well. If the targeted user was a “Domain Admin” or some type of power user, the attacker was gifted with the ability to compromise thousands of systems with one simple keylogger, as the trust model within Active Directory allows Domain Admins to access any machine on the domain.
On a given day, an attacker may target 1000 workstations, successfully installing a keylogger on 5%. In this case 50 people are now compromised, potentially leading to 50 or 5000 other machines being compromised, depending on the victim’s level of access within their corporate network. This doesn’t even include the number of web portals the attacker can now compromise thanks to the keylogger, which may lead to even more systems and data under the attacker's control. With all of this in only a single’s day of work, imagine the control of an attacker after a few months, or even years, of effort.
The keylogger threat is not new to anyone who has been in enterprise security: It is a well-known, somewhat old problem with several solutions. For example, most modern antivirus systems, including Windows itself, can detect when the real GINA library has been modified and therefore can prevent standard keylogger tools from the past (still an ongoing concern though, as the attacker tools have evolved as well).


*For what it’s worth, FakeGINA was replacing a legitimate file on Windows call GINA, which stands for Graphical Identification and Authentication, a library leveraged during the authentication process in Windows NT and beyond.

Third-party Keyboards: A new version of an old problem
Knowing that keyloggers can lead to the eventual death of enterprise data, one would imagine that new ecosystems—like the App Store and Google Play—would prevent such behavior on their platforms, learning from the mistakes of the past. Unfortunately not.
In 2014, iOS began to support 3rd-party keyboards within mobile applications. Starting in iOS 8, a 3rd-party keyboard can be used on all apps on the device itself. If this 3rd-party keyboard is legitimate, there’s no problem; however, if the 3rd-party keyboard is not legitimate, collecting all user key taps for example, then an old attacker’s dream has resurfaced anew: A modern-day keylogger for mobile devices.
So if keyloggers are “death to enterprise data,” why would Apple introduce a feature that could be an attacker’s best friend? Quite simply, it’s due to the significant amount of popularity of 3rd-party keyboards on Android.
Android enjoys a very healthy and active community on 3rd-party keyboards. Due to the horrible user experience with keyboards, all sorts of communities, including for-profit organizations, developed 3rd-party keyboards on Android with a large number of downloads and a better user experience. Since default keyboards can present a UX problem for mobile apps, users simply wanted something better, right?
Consumer wants winning out over enterprise needs
Not so fast. We do not recall hearing a large number of enterprises from banking, healthcare, financial tech, or even government agencies banging down doors in Mountain View and Cupertino asking for 3rd-party keyboards for their enterprise apps.
In fact, the following things were never heard around Silicon Valley:
  • “Hey, wouldn’t it be great if our mobile banking users could use software written by some unknown person, especially when it has access to passwords?”
  • “In exchange of typing faster, can our health care app share medical history with perfect strangers?”
  • “I’d like to put the security of our mobile app in the hands of our users, where the best list of emojis will determine how strong our security model is.”
The list could go on and on, but if this was so obvious to the enterprise sector, why would Apple still allow these keyboards? Because it is what *their* users wanted, specifically what their consumer users wanted.
As written in part 1 of this series, the App Store and Google Play were not built for the enterprise. They don’t take enterprise needs as their highest priority, as they are forced to chase after consumer features to stay ahead of each other (e.g. withdrawing ATS 10 days before the deadline in 2016).
If Android is blazing the way on 3rd-party keyboards and has a large, growing user base that makes UX better on consumer apps such as Facebook, SnapChat, and Tinder, how could Apple sit back and just let that happen without jumping in as well? We really can’t fault Apple or Google, they are consumer companies after all.
That is why we stress that the App Store and Google Play don’t have the needs of the enterprise as their number one priority, nor should anyone expect them to. Putting it simply: What’s good for Tinder (3rd-party keyboards) may not be good for the enterprise (mobile banking, healthcare, government, etc).
How Apple and Google are (or aren’t) trying to mitigate 3rd-party keyboard risks
To be fair, it appears Apple may slightly agree with the narrative above, as the warning given to users when installing a 3rd-party keyboard is enough to scare most people off (See Figure 1).
blog pic oct 2017.png
From the scary/aggressive message, it is clear to us that Apple does understand this potential keylogger issue and probably is familiar with FakeGINA as well. Furthermore, Apple gives App publishers the ability disable custom keyboards from 3rd party sources (see “Secure Code to Protect Your App”).  
On the Android side, the story is not so good. Android does not give app publishers any ability to disable 3rd-party keyboards, no option at all. If a mobile banking user on Android prefers to use a third party keyboard from an unknown source, then the security model of that bank app is now in the hands of the best emoji writer. Let’s think about this for a second. If you were an attacker, and keyloggers were your best friend, wouldn’t you make a concerted effort to make an excellent keyboard for people—your victims—to download? How is that any different than an attacker trying to penetrate your network over a long period of time?
Our scan results & requests of Apple and Google 
Data Theorem scanned all the apps in the App Store and Google Play. The results below show how many apps have disabled the ability to use a 3rd-party keyboard:
  • App Store: 96% of apps have not disabled 3rd-party keyboards.
Our request: @apple: Make custom keyboards disabled by default
  • Google Play: 100% of apps have not disabled 3rd-party keyboards, as Android does provide any such option whatsoever to app publishers. 
Our request: @google: Allow apps to disable 3rd-party keyboards, and make custom keyboards disabled by default
How risky are 3rd-party keyboards today?
Easy to get on a device, hard to enable. Users download 3rd-party keyboards every day, as can can be bundle with apps, so if one of them happens to be rogue and collects keystrokes, then it is “easy” in the sense that the user initiates the download without much (if any) enticement. The rogue keyboard casts a wide net on the hopes it catches something interesting.
On the other hand, if an attacker wants to target a specific person, then it takes both some tech talent and some serious social engineering, making the attack much more difficult and time-consuming.
Regardless of the difficulty involved, the point remains that 3rd-party keyboards are still an enticing attack vector. After all, a 3rd-party keyboard was one of the tools used by the “Hacking Team” when it targeted a human rights activist in the UAE.
App publishers: Want to disable 3rd-party keyboards? Here’s how
If you are an app publisher and want to remove the threat of a keylogger being used on your app, use the Secure Code below to disable 3rd party keyboards on your iOS app:
    • // To be added to the App's UIApplicationDelegate
      - (BOOL)application:(UIApplication *)application shouldAllowExtensionPointIdentifier:(UIApplicationExtensionPointIdentifier)extensionPointIdentifier
         // Disable third-party keyboards on iOS 8+
         return NO;

Monitor Your Apps  LEARN MORE 


Topics: Mobile App Security, Google Play

Himanshu Dwivedi

Written by Himanshu Dwivedi

CEO of Data Theorem, Inc.