Rice University logo
 
Top blue bar image
A graduate seminar: current topics in computer security
 

Archive for the ‘Smishing’ Category


More confused deputies

November 7th, 2012 by bss4

I started following blogs listed on the course blog’s information security links of which this Russian blog is a part. The blog reported on a recently discovered capability leak on several Android phones by a group of researchers at NC State University. Let’s look into the issue in a little more detail.

Capability leak

Let’s start by defining a capability leak. Think of capabilities as Android permissions. Now let’s say system app A (e.g., Android’s messaging app) acts as a deputy to third-party apps wanting to send SMSs via app A i.e., while a third-party app B can request app A to send a particular SMS message to an outbound number, it does not have the authority to do so by itself. Since sending SMS is a security critical functionality, one would expect app A to check if app B has the required SEND_SMS permission before it acts on app B’s behalf. If app A does do the required check, it guards its privilege (capability) of sending an SMS. Otherwise, there is a privilege (capability) leak allowing virtually any app without the requisite permissions to send SMSs via app A.

The attack

A description of the attack itself is linked earlier in this article. To summarise, it has been found that the WRITE_SMS permission (call it capability) is being leaked. In the extreme case, this means that an app without WRITE_SMS permission (or no requested permissions at all) could write a fake SMS via the system messaging app. Not surprisingly, this could be used for phishing end-users; it seems fashionable to call it “Smishing”, short for SMS Phishing.

While such a leak is not new (the first description of the problem dates back to Hardy’s article published in the year 1988), the fact that something seemingly evident such as the WRITE_SMS permission leak has not been brought to notice before is alarming. More so, the attack is claimed to be deployable on the latest and greatest version of Android OS (and prior versions as well) and across phones from multiple OEMs.

More to come?

Researchers who discovered the leak have published a paper earlier this year about the framework they built to automatically discover capability leaks in the Android source code (AOSP). Although this particular leak finds no mention in the paper, it seems as though the leak was found in the process of experimenting with their framework (Woodpecker) and probing for more leaks. It shouldn’t be surprising if more leaks are uncovered.

Having said that the framework built by the researchers has several limitations: (1) It does not consider capability leaks in C code; Android has a significant native code base, (2) It does not consider the case where multiple malicious applications can collude to achieve the same end-result as that of capability leaks, and (3) It only scans for leaks of 13 out of more than 200 default Android permissions and only in those cases where the originator of the leak is a pre-loaded app (apps in the stock image); it is realistic for third-party apps to be doing the same thing.