Tuesday, September 15, 2015

Experimenting with Android Permissions



Background

Last year, as part of the curriculum for my Masters in Information Assurance, I took a class in Mobile Security.  I tested the new Android Permission Structure.  The year prior, I wrote a paper on the inadequacy of the older Android Permission Structure and wanted to test the new operating system to determine if it would remedy the problems that the older version had.

SMS Fake Player

The SMS Fake Player was, allegedly, the first Trojan targeted for Android devices back in 2010, as reported by Kaspersky labs. The Trojan, passing itself off as a media player, sends Short Message Service (SMS) messages to premium numbers at a rate of $6 per message. The Trojan has to be downloaded and installed in order to infect the Android device, thus it does NOT self-propagate. The user is prompted to give the application the authority to send SMS messages:

This is the only message users received warning them to potential danger.  Users have become complacent with regard to permissions during install time.
According to Felt, Chin, Hanna, Song and Wagner in an article titled “Android Permissions Demystified” in 2011 for the Association for Computing Machinery:
“Access to privacy- and security-relevant parts of Android‘s rich API is controlled by an install-time application permission system. Each application must declare upfront what permissions it requires, and the user is notified during installation about what permissions it will receive. If a user does not want to grant a permission to an application, he or she can cancel the installation process.”

Too Much Trust?

The same article stated:  “However, an install-time permission system is ineffective if developers routinely request more permissions than they require. Over privileged applications expose users to unnecessary permission warnings and increase the impact of a bug or vulnerability.”

Poor Documentation

Developers utilized Google Android documentation which, the aforementioned article stated, had inadequate information regarding Application permissions. As a result, developers often request more permissions than they will actually use for their applications, just to make it work. They also found 6 errors in the permissions documentation provided to developers.

Inadequate Protection of Permissions

An article in the April/May 2010 edition of IEEE Computer Magazine stated that the Android provided inadequate protection to their Application permissions using this model. This was 5 months prior to the release of the Trojan.
Some of the Application permissions that can be accessed at install time:
SEND_SMS –Sending text messages
READ_INPUT_STATE – Read keystrokes
CALL_PHONE- Dialing
BRICK-Render phone unusable
The ACM article found that approximately one-third of the applications they studied on the Android Market were over privileged.

Ask Yourself

From a developer perspective:
If you have been working on a program and are facing a deadline and did not have adequate documentation, but knew that including a .dll or .jar would solve your problem, would you include it?
From a User perspective:
How many times have you simply clicked ‘Yes’ or ‘OK’ while installing software?
Should a user be expected to know what functionality an application requires in order to function properly? 

As a developer, you are taught to abstract the users, as much as possible, from the inner workings of your program. Is it fair to blame the user for not knowing those inner workings?

Enter the Jelly Bean

June 27, 2012 Google introduced Jelly Bean to replace Honey Comb.  It introduced many security improvements including addressing the SMS issue.
Google improved the permission model.  The issue that allowed the SMS trojan to work has been mitigated with the addition of a warning message that appears when an application attempts to send a text to a number that is KNOWN to be a fee number.

My Experiment

I attempted to create a program that would show how differently the Honey Comb and Jelly Bean versions of Android handle premium rate SMS attempts.
The program performed the following:
Modified a program from a sample provided by “Beginning Android 4 Development”
Displays a gallery of thumbnail photos
When a thumbnail is clicked, the picture is enlarged AND a covert SMS message is sent.
Tools Used
Android emulator (Free)
Eclipse Integrated Development Environment (Free)

Premium Rate SMS Numbers

Android maintains an XML document holding known Premium Rate numbers.  Once I managed to find the file I was able to utilize one of the numbers in the XML file to test the Premium SMS blocking system for JellyBean.

shortcode country="us" 
pattern="\\d{5,6}" 
premium="20433|21(?:344|472)|22715|23(?:333|847)|24(?:15|28)0|25209|27(?:449|606|663)|28498|305(?:00|83)|32(?:340|941)|33(?:166|786|849)|34746|35(?:182|564)|37975|38(?:135|146|254)|41(?:366|463)|42335|43(?:355|500)|44(?:578|711|811)|45814|46(?:157|173|327)|46666|47553|48(?:221|277|669)|50(?:844|920)|51(?:062|368)|52944|54(?:723|892)|55928|56483|57370|59(?:182|187|252|342)|60339|61(?:266|982)|62478|64(?:219|898)|65(?:108|500)|69(?:208|388)|70877|71851|72(?:078|087|465)|73(?:288|588|882|909|997)|74(?:034|332|815)|76426|79213|81946|83177|84(?:103|685)|85797|86(?:234|236|666)|89616|90(?:715|842|938)|91(?:362|958)|94719|95297|96(?:040|666|835|969)|97(?:142|294|688)|99(?:689|796|807)" />


The Code…Seeking Permission


Using a simple modification to the ‘Image Switcher’ program provided in the ‘Beginning Android 4 Development’ area, I Added a request for SMS permissions.








The Code…Sending the Secret Message

 

I added a simple method using the sendTextMessage command.  When the item (thumbnail) is clicked, it will display the full picture, however, I have added code that will wait 5 seconds and then send a covert message to another device.
Running the Code
To ensure that both implementations executed, I added the code to send the covert messages to the app and installed it on both.  I opened and emulation running Jelly Bean and an Implementation running Honey Comb.
I started the application on both implementations and ran them:

Honey Comb Results

Clicking on the smaller thumbnail from the HoneyComb phone opens the larger picture and sends a message to the JellyBean phone.  However, no message is generated about the message sent to the “Premium” number.

1-555-521-5554: Secretly sent message is
sent without warning the user






























Jelly Bean Results

While the message from the JellyBean phone to the HoneyComb phone is allowed, the message that would go to the “Premium” number is caught and a message is presented to the user.


Provides users with a warning that the app is going to
send a message to a fee based number allowing them to stop it.











References:

Jon Oberheide (2011). “Dexcode Teardown of the Android SMS Trojan”. Jon.Oberheide.org. Retrieved from http://jon.oberheide.org/blog/2010/08/10/dexcode-teardown-of-the-android-sms-trojan/.
Bernadette Irinco (2010). “First Android Trojan in the Wild”. TrendMicro.com. Retrieved from http://blog.trendmicro.com/first-android-trojan-in-the-wild/.
Richard Adhikari (2011). “Rogue Android Devs Plant SMS-Crazy Trojan in App”. Linux Insider. Retrieved from http://www.linuxinsider.com/story/70598.html.
Denis Maslennikov (2011). “Android SMS Trojan Now Being Delivered via SEO Techniques”. Securlist. Retrieved from http://www.securelist.com/en/blog/2286/Android_SMS_Trojan_Now_Being_Delivered_via_SEO_Techniques.

No comments:

Post a Comment