Common, recurring malware patterns

Based on the patterns from four different categories identified by Zhou and Jiang [2012] in the AMGP, Küster and Bauer [2015] have formally specified various key characteristics of malware behaviour in LTLFO_{. The outcome are the policies listed in} Table 6.2. For readability, we write ϕ_i∈[a,b], grouping policies of the same pattern together, whereψi,ψ0 orψ00 are auxiliary formulae listed in Table 6.3. We surround a

policyϕiwithnsquare brackets (calling it thenth refinement ofϕi), if its bad prefixes

are a strict subset of the bad prefixes of ϕi surrounded with n−1 square brackets.

For example, a bad prefix of[ϕ1]—the first refinement of ϕ1—has to contain as well

88 Proof of concept: Android malware detection

Table 6.2: Key characteristics of Android malware behaviour specified in LTLFO_. Personal information stealing

ϕ_i∈[1,14] G¬ψi

[ϕ_i∈[1,14]] G(ψi ⇒ ¬Fψ0)

[[ϕ_i∈[1,14]]] G(ψi∧ ¬ψ0 ⇒(¬ψ0W(N/A@ISurfaceComposer∧ ¬ψ0)))

[[ϕ_i∈[1,4]]]0 G(ψi ⇒ ¬Fψ00)

Privilege escalation

ϕ15 G¬∃(args):do_execv@syscall.

regex(args,00.∗su.∗ |pm(un)?install|amstart.∗00)

Launching malicious payloads

ϕ_i∈[16,17] G¬ψi

[ϕ17] G(ψ17⇒ ¬Fψ0)

[[ϕ17]] G(ψ17⇒ ¬Fψ00)

Financial charges

ϕ18 G∀(dest, _):[email protected](dest)

ϕ19 G(ψ17⇒ ¬F∃(w,x,y,z,abort): finishReceiver@IActivityManager.

regex(abort, “true”))

This describes from a practical point of view a more severe malware behaviour for the user.

Category1: Information stealing. The AMGP discovered that malware is often ac- tively harvesting various sensitive information on infected devices. Thus, the policies

ϕ_i∈[1,11] specify that an app should neither request any permission secured sensitive data, such as the device or subscriber ID, subscriber identity module (SIM) serial or telephone number, or device software version, nor should it query any of the content providers that contain the call history, contact list, phone numbers, browser book- marks, carrier settings or SMS messages. Policyϕ12covers the harvesting of installed

app or package names on a device. Policy ϕ13 covers the reading of system logs via

the Android logging system, called logcat. Note that before Android 4.1, an app could read other apps’logcatlogs, which might contain sensitive messages. Policy

ϕ₁₄specifies that neither the coarse grain location based on cell towers nor the more

precise GPS location should be accessed.

The policies [ϕ_i∈[1,14]] refine the policies above towards the more suspicious be- haviour that an app should not, after requesting the sensitive information, eventu-

§6.3 Specifying malware behaviour 89

Table 6.3: Auxiliary formulae for Table 6.2.

ψ1 getDeviceId@IPhoneSubInfo

ψ2 getSubscriberId@IPhoneSubInfo

ψ3 getIccSerialNumber@IPhoneSubInfo

ψ4 getLine1Number@IPhoneSubInfo

ψ5 getDeviceSvn@IPhoneSubInfo

ψ6 ∃(uri, _):[email protected](uri, “.∗calls.∗00)

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

ψ8 ∃(uri, _):[email protected](uri, “.∗phones.∗00)

ψ9 ∃(uri, _):[email protected](uri, “.∗bookmarks.∗00)

ψ₁₀ ∃(uri, _):[email protected](uri, “.∗preferapn.∗00)

ψ11 ∃(uri, _):[email protected](uri, “.∗sms.∗00)

ψ12 (∃(_):[email protected])∨

(∃(_):[email protected])

ψ13 ∃(args):[email protected](args, “.∗logcat.∗00)

ψ14 (∃(_):[email protected])∨

(∃x:[email protected](x, “.∗gps.∗00₎

c16 00.∗BOOT_COMPLETED.∗00

c17 00.∗SMS_RECEIVED.∗00

ψ_i∈[16,17] ∃(intent,txt, _):system#scheduleReceiver@IApplicationThread.

(regex(intent,ci)∧regex(txt, “.∗<pkg>.∗00))

ψ0 (∃(_):sys_connect@syscall. true)∨(∃(_):[email protected])∨

(∃(x,intent, _):startActivity@IActivityManager.

regex(intent, “action.SEND00)

ψ00 (∃(dest,x,msg, _):[email protected](msg, “.∗<sensitiveInfo>.∗00))∨

(∃(x,intent, _):startActivity@IActivityManager.

regex(intent, “.∗<sensitiveInfo>.∗00₎

ally connect to the internet, send an SMS or exchange data with another app. Even though a detected bad prefix for those policies does not guarantee that information has been leaked, the usage of above “sinks” bears at least its potential. As we treat apps as “black boxes” and sent data could have been encrypted or in other ways obscured by malware, we generally cannot prove leakage—unlike approaches for information flow analysis [cf. Enck et al., 2010]—based on traces we collect. Fur- thermore, [[ϕi∈[1,14]]] expresses that there should exist some screen rendering (via

90 Proof of concept: Android malware detection

N/A@ISurfaceComposer) in between information request and potential leakage. A de-

tected bad prefix would mean in this case that the sending of data could not have been caused by some normal user interaction with the app, but rather by some app’s malicious background service. Note that we represent with N/A method names which could not be decoded with DroidTracer. Further note that the first and sec- ond refinements are based on the “absence after” and “exists between” specification patterns, respectively.

[[ϕ_i∈[1,4]]]0 are further refinements, which only trigger if we find the device ID, etc., as cleartext (represented by the placeholder “<sensitiveInfo>”) in the trace. Category 2: Privilege escalation. The attack of exploiting bugs or design flaws in software to gain elevated access to resources that are normally protected from an application is called privilege escalation. From the samples in Zhou and Jiang [2012], 36.7% exploit a version-specific known software vulnerability of either the Linux kernel or some open-source libraries running on the Android platform (such as WebKit or SQLite) to gain root privileges (e.g., to replace real banking apps with a fake one, for phishing attacks). Therefore, policyϕ15lets us for example detect when

an app opens a root shell, secretly starts, installs, or removes other packages via the activity manager (am) or the package manager (pm). Monitoring of this behaviour is possible, because the system calldo_execveis exclusively used for the execution of any binary, shell command, or shell script on the underlying Linux OS.

However, not all root exploits need to use the sucommand to be executed (see, e.g., the “RageAgainstTheCage” exploit [cf. Drake et al., 2014, p.75], which leverages on the root shell obtained via the Android Debug Bridge (adb)). Therefore, it is not possible to detect root exploits in general with this formula. Once an app has gained root privileges, it can in principle not just unload MonitorMe’s kernel module, but also uninstall the app itself. In other words, malware on a compromised device would be able to successfully evade the detection from MonitorMe as well as any other mobile anti-virus software.

Category 3: Launching malicious payloads. Apps’ background services—which do not have any UI—cannot only be actively started when clicking on an app’s launch icon, but also by registering for Android’s system-wide events, calledbroadcasts. The AMGP discovered that 29 of the 49 malware families contain a malicious service that is launched after the system has been booted, or for 21 families when an SMS was received (i.e., they registered for the BOOT_COMPLETED or SMS_RECEIVED broadcast, respectively). Therefore, we consider it as suspicious if services are activated by the broadcasts mentioned above, which we specify in form of ϕ_i∈[16,17]. We replace “<pkg>” for each app individually with its package name. Note that to monitor this behaviour, we need to intercept system events of the Android system—which has UID 1000—as it starts the services that have registered for a certain broadcast via

scheduleReceiver@IApplicationThread. We add the prefix “system#” to those actions;

that is, to distinguish them from an app’s action in a trace. Since malware has access to the sender and content of an incoming SMS after registering for SMS_RECEIVED,