Software Integrity

 

How to mitigate your third-party mobile keyboard risk

What is the best form of cyber security defense? Well, as I always maintain, it’s user awareness! The implementation of a comprehensive user awareness policy carries a lot of weight and, when abided by, effectively complements the many technological solutions available.

Mobile devices are used regularly within enterprise operations, and by nearly all consumers. The risks of using these devices and apps must still always be gauged against the obvious benefits of being mobile, but rarely are.  A worrisome situation exists which holds the potential to allow any mobile user to unknowingly share every keystroke made on their mobile device with several third-parties, unbeknownst to that user. Recording keystrokes or injecting malicious keystrokes is a very effective means of gaining access to a device, a network, or an account through re-using the many keystrokes made by the unwitting user.

Within this post, I’ll discuss how user data can be stolen through third-party mobile keyboard apps.

Keyboard loggers: the spies of the past

One very effective way to record a person’s keystrokes used to be through a hardware keystroke logger. Spies would access an individual’s laptop or keyboard and insert a small, concealed, undetectable keyboard logger. These little hardware devices faithfully record each and every stroke of the keyboard, which are then transmitted through the Internet to the malicious party.

Hardware loggers are much preferred for laptop and desktop computers over malware that does the same job. (Malware is eventually detected and removed thanks to the widespread use of popular anti-virus tools.) However, today we live in a mobile world where more and more people are using mobile devices (i.e. tablets and smartphones) to perform the vast majority of their tasks. This has vastly reduced the attack surface once available to hardware keyboard loggers; after all, you simply can’t put one in a mobile device.  But danger still lurks everywhere.

Criminal or careless “full access” innovation

With the release of iOS 8 in September 2014, Apple joined Google and enabled the use of third-party mobile keyboards to provide enhanced functionality, emoticons, support multiple languages, and enable new methods for entering data. So what’s the issue? These new keyboards open a new avenue for recording keystrokes and much, much more.

In order to use one of these third-party mobile keyboards, the user must agree to the terms and conditions and then set permissions for the keyboards. These permissions are very important to understand as they have privacy and thus security implications. In short, these keyboards in some instances require the user to grant what’s known as “Full Access.” This full access means the keyboard app requires access to the Internet to communicate with server-side apps that will exist in the cloud or the developer’s network to provide an enhanced functionality that’s often more appealing than a basic keyboard.

Keystrokes are recorded to assist the third-parties with analytics and auto completion algorithms. The multiple language characters, the many fonts, emoticons, and other fanciful features all reside on a server-side app. In other words, they are not local. They are off board – on someone’s server – someone you, the user, the Director of Security, the CISO, do not know. Thus, exposing your keystrokes to parties unknown is very real.

The “SwiftKey” keyboard, which has been downloaded more than 10 million times from Google Play, is one example of an Android third-party mobile keyboard that requests full access. When a user allows this access, the user risks sharing their keystrokes with parties unknown. It must also be realized that in some cases, full internet access is not required; a keyboard can store all keystrokes to a file that other applications could possibly access. Or, it could automatically alter bank account numbers while being entered so that a specific one is entered instead (e.g. in fund transferal situations).

Mitigate your risk

Apple and Google, along with their third-party developers, have recognized these threats. In response, they have implemented several security controls to minimize risks. Apple now provides a very explicit notification of the inherent risks associated with using third-party mobile keyboards. They have also implemented a control in iOS  that automatically switches to the native keyboard for sensitive fields including passwords and credit card numbers. Even with these protections, the risks may be greater than most users are willing to accept.

To give you a recent example, this summer a vulnerability was discovered in about 600 million Samsung devices which used SwiftKey for language character sets. If a user needed to load a language character set, the download session would be conducted over HTTP. The danger is the HTTP, but the irony is that the native keyboard and its SwiftKey component is an integral part of the device’s operating system, and resides in the firmware which resides on the hardware. Didn’t I just mention that, in the past, one very effective way to record a person’s keystrokes was achieved through the use of a hardware keystroke logger…? You see where I’m going with all this.

To minimize your risk, such keyboards should never be used in the enterprise environment. If they are, assess the risks and what the impact is of enterprise data becoming accessible to an unknown third-party or a known third-party you have no control over.

If you are a consumer, just be aware of the fact that your keystrokes are going to places you have no control over. If, as a consumer you wish not to deny full access, only use apps or vendors that require native keyboards for entering sensitive data. Or, make sure you switch to the native keyboard when using a banking app or an app that uses sensitive data. At the end of the day, user awareness, user training, and constant vigilance are equally important.

Learn how third-party security can help your organization secure your software development supply chain from end to end.