Why does my Android App READ SMS?

I have been wanting to write a blog on this topic for quite a while and finally here I'm.

With the rampant adoption and popularity of Android phones, Android apps and android market place are gaining wide spread popularity. I have noticed that most of the apps that we see/use now ask for seemingly harmless permissions like "READ PHONE STATE", "READ_SMS" etc. This post highlights the dangers and security flaws associated with "READ_SMS" permission on Android devices.


I have heard arguments in favor of "READ_SMS" permission that sounds something like - "this feature does not cost money to end user as it merely reads messages". The security flaw mentioned below was first observed by me and my colleague Jason back in 2010. However, to our surprise, we weren't the only ones to spot it - the same flaw was leveraged by GEINIMI, an Android trojan, to take over a phones SMS channel as its own command & control channel.

FUNCTIONALITY:
So what exactly am I talking about? The "READ_SMS" is a permission that allows an  Android application to receive and be NOTIFIED when a new SMS message reaches the phone. 
<uses-permission android:name="android.permission.READ_SMS"/>
This is an excellent functionality that provides applications with the ability to read SMS messages and even use the SMS channel for receiving alerts from servers (analogous to port directed SMS in Blackberry).

ARCHITECTURE:
However, In Android ecosystem, the SMS channel is implemented as an ORDERED BROADCAST.
In simple words, SMS is delivered to different apps as per the app's registered priority to receive SMS on that particular Android device, i.e. for example - APP A with priority 10 will be notified of new SMS messages before APP B with priority 5. Most applications like the SMS Inbox, do not explicitly specify a priority and hence get allocated with the default system priority. However, applications also have the ability to explicitly request priority values of their own choice, as follows:
<receiver android:name=".receiver.SMSReceiver">
<intent-filter android:priority="50000">
THREAT:
When a user installs an application, the user is not aware of the Priority of the "READ_SMS" receivers permission, requested by the application. As shown above, if an application requests a priority of 50000 and if there are no other applications with higher priority on that device, this particular app becomes the most privileged and first application to receive notification of new incoming SMS messages.

To make matters worst, these SMS receiving applications have the ability to parse the content of an SMS message and block the message from being delivered to other applications on the phone. For example, an application with SMS read priority of 50000 as shown above, will always receive new SMS messages, even before the SMS Inbox of the device.  This application can not only read the SMS but also send out a command to the Android system - instructing it to abort sharing of SMS messages with any other apps on the device. By doing so, the app can receive remote commands from a server via SMS channel and the user will not even be alerted of new SMS messages. Code snippet of abort command:
if (msgs[0].getMessageBody().equalsIgnoreCase("xxxxxxxxxxxx"))
{            
                       this.abortBroadcast();
}
 Hence a seemingly innocuous Android application with "READ_SMS" permission has the capability to hijack and control the SMS channel of an Android device. This behavior of SMS broadcast on Android devices can be further leveraged by malicious apps to trigger actions based on specific commands. This security flaw was leveraged by Android trojan called GEINIMI to turn Android devices as bots. According to lookout security, GEINIMI was the most sophisicated Android malware seen at that time.

To summarize my point, Keep an eye for applications that require permission to "READ_SMS". Not all applications may be malicious, but the ones that are - could be dangerous.

Popular posts from this blog

Gmail Session Management Vulnerability (Mobile Browsers)

iPhone's Persistent Connection to Apple

Potential DoS Vulnerability with Android System