A user manual: How to specify malware behaviour in LTL FO

Let us now look at some common Android malware behaviour and explain how to model this behaviour in terms of LTLFO _{formulae. The intention of this section is to} ease the understanding of specified attack patterns in the following section—or for the curious reader, to be able to write their own policies for protection against future

86 Proof of concept: Android malware detection

or otherwise unwanted behaviour occurring on Android phones.

Lots of malware is “spyware”, i.e., it sends private user data or sensitive device details “home” to remote locations. In order to access any of this information, “sand- boxed” malware has to request a system service; thus, a Binder call takes place and we can refer to its according action when writing a policy. In case of the device ID, we can write

G¬getDeviceId@IPhoneSubInfo,

meaning that an app should never query the device ID. As the methodgetDeviceId

has no arguments, the accordingU-operator is merely a proposition and therefore no quantifiers are needed. In case we do not want an app to read any names, addresses, etc. from the contact book of the phone, we write

G¬∃(uri, _):[email protected](uri, “.∗contacts.∗00),

meaning and app should not query a content provider, where the Uniform Resource Identifier(URI) matches the regular expression “.*contacts.*”. A content provider is a wrapper (here of an SQLite database that stores the contacts), which can be queried from other apps via RPC if having the right permissions. In other words, we check if the first argument of the method QUERY contains the URI “content://contacts/ phones”, as this unambiguously identifies a query to the contact database. Note that the method QUERY has more than one argument. For readability we use the “_”-symbol as a placeholder for all remaining variables that do not appear in the formula. Similarly, access to most other data stores on Android can be monitored, such as the one containing all SMS messages, the call history, etc. The predicate regex is an I-operator, which returns true if a string—here the one bound to uri— matches a regular expression. Note that in both cases above, the formulae resemble the “absence” pattern from the LTL specification patterns discussed in §2.4.

The examples above are generic and therefore likely generate false positives. Therefore, one usually wants to describe behaviour in a more specific way; for ex- ample, by expressing that after accessing sensitive information, an app should not forward the information to some “sink” on the device (e.g., the internet). How to specify this is discussed in the following.

All apps of typeAndroid/Actrack.Asend GPS location, battery and radio status to a central internet server controlled by the vendor at regular intervals. A policy we may want to monitor in regards to that, more generally, could be “no app should request the GPS location, and later connect to the internet (possibly to transmit said location)”, which is captured by the following formula, where sys_connect@syscall appears in a trace whenever the app under scrutiny triggers the Linux system call

sys_connectto some IP addressy, andgetLastLocation@ILocationManagerwhenever it requests the device’s current location:

G(∃x:[email protected](x, ”.∗gps.∗”)→

§6.3 Specifying malware behaviour 87

An example for the parameter ofgetLastLocationis “Request[ ACCURACY_FINE gps requested=0 fastest=0 num=1 ]; <app-package-name>”. This is an object of class LocationRequest printed as string, which tells Android how an app wants to request the location. For instance, “fastest=0” means that location updates are requested within the fastest interval possible, which is usually only necessary for navigation apps. Based on this information we could adapt the policy above to re- veal specifically tracking behaviour. The formula’s pattern is of type “absence” with scope “after”.

Android/NickiSpy, for example, represents a family of apps which secretly record a user’s phone conversation on SD card in the compressed .amr format (adaptive multi-rate). We can detect this family of malware via a simple policy,

G∀x:sd_write@syscall.¬regex(x, “.*\.amr00).

However, should there be legitimate recording of .amr files to SD card, the user is always able to ignore any reported violations of this policy.

As another example, consider the first ever Android Trojan (Trojan-SMS.An-

droidOS.FakePlayer.a), disguised as media player, which secretly sent SMS mes-

sages to expensive premium numbers [Leyden, 2010]. This could be monitored by a more general behaviour, i.e., to be notified ifanyapp sends an SMS to a numbernot in the contacts:

G∀x:[email protected](x).

While there may be legitimate violations of this policy, its monitoring at least lets users keep track of which apps exhibit this type of behaviour. It’s then up to them to decide to remove an app, if they feel it is not justified. It was predefined a special I-operator, contact, which is non-rigid, i.e., its return value can change for the same x depending if the number at the time queried is in the contact book or not. Recall that we discussed this example already earlier in §3.1. The framework Ltlfo2mon lets the user define further predicates for the specific need to check for certain behaviour, which is usually not supported by other specification languages. In other words, the feature of arbitrary computable predicates is needed for the following Android analysis.