Smartphone
Security
An overview of
emerging threats.
By Slawomir Grzonkowski, Alejandro Mosquera,
Lamine Aouad, and Dylan Morss
© CanStock Photo/3DMask
T
he mobile threat landscape has undergone
rapid growth as smartphones have increased in popularity. The first generation of mobile threats saw
attackers relying on various scams delivered through
SMS. As the technology progressed and Web browsers, e-mail clients, and custom applications became standard
on smartphones, attackers started exploiting new possibilities
beyond traditional e-mail spam and phishing attacks. The
landscape continues to evolve with mobile bitcoin miners,
botnets, and ransomware.
ATTACK VECTORS AND STYLES
The main vector for mobile attacks, specifically SMS spam
[1], is unwanted messages. While e-mail attacks may go
unread or be deleted, it is far more likely that a victim will
open and read a short text message. With attacks like these,
the sophistication level is much lower because there is usually no need for the victim to install malicious binaries.
The monetization strategy is also fairly simple; the majority
of mobile attacks use social engineering tactics to convince the
targeted user to sign up for a service (dating portals are
Digital Object Identifier 10.1109/MCE.2014.2340211
Date of publication: 2 October 2014
common) or to subscribe to attacker-controlled premium SMS.
A successful social engineering message is shown in Figure 1.
This attack did not require any programming skills, but
that did not stop it from being tremendously successful. Fake
surveys are another popular class of often-observed attacks.
This type of attack works by inviting a victim to participate
in a survey and then providing an invitation at the end to participate in a drawing to win a phone, tablet, or other prize.
These rewards are nonexistent, and their only purpose is to
trick the user into subscribing to a premium service.
A large percentage of attacks rely on similar strategies to
convince the victim to join various dating portals. After joining,
the victim then receives occasional spam messages from a bot
to entice them into paying for portal membership to read these
messages. In these attacks, the victim is usually in contact with
a bot that has learned to communicate as a chat partner.
IMEI AND IMEISV NUMBERS: AN OVERVIEW
In many cases, mobile threats begin with communications
that do not contain a malicious payload. The attacker’s goal is
to entice the victim to reveal private information, such as his
or her international mobile station equipment identity (IMEI)
number. This behavior may not be perceived as malicious as
it is not destructive in an obvious way like typical malware or
40 IEEE Consumer Electronics Magazine ^ october 2014
2162-2248/14©2014IEEE
Authorized licensed use limited to: University of London: Online Library. Downloaded on June 27,2023 at 07:51:42 UTC from IEEE Xplore.
Restrictions apply.
as clear in its goal as spam based around premium services.
However, revealing device-specific information can be as
devastating as installing a malicious application.
An IMEI number is a unique identifier for mobile devices. Its
original purpose was to allow Global System for Mobile Communications operators to identify legitimately distributed devices and
blacklist stolen ones. This countermeasure can be difficult to
enforce because it can be easily circumvented by spoofing the IMEI
number. The number can be spoofed with any random value or,
more efficiently, with some other number that is no longer in use.
An IMEI number is not random; it contains structured
information that is guaranteed to generate unique values for
each new manufactured device and to reflect various details
about the associated device. The number is based on the
“IMEI Allocation and Approval Guidelines” [2], which specify how to learn about the origin, model, and serial number
(SNR) of the device.
An IMEI number is composed of three elements:
▼▼ a type allocation code (TAC) of eight digits
▼▼ a unique individual SNR of six digits used to identify each
piece of equipment within the TAC
▼▼ a check digit (CD), also referred to as a spare digit, of one
digit calculated using the Luhn formula (ISO/IEC 7812); its
original purpose was to avoid manual transmission errors.
In some cases, the IMEI number is replaced with a similar
standard, called the international IMIE and software version
(IMEISV) number. The only difference lies in the last component. In this case, the CD is replaced with a software version number (SVN) of two digits that identifies the SVN of
the mobile equipment. The SVN is allocated by the manufacturer, and its value of 99 is reserved for future use.
With both the IMEI and the IMEISV, the TAC is issued by
a central body, while the SNR is allocated by manufacturers
in a sequential order. This causes the SNs to grow in a predictable manner and leak additional information, which
allows the production date to be estimated.
The TAC and SNR used for the IMEI number are the same as
the ones used for the IMEISV number. Both numbers are used
interchangeably and can be converted from one format to the other.
Although the IMEI number was created for a valid purpose, it has been more frequently misused. While it was
intended to blacklist stolen phones, a tactic that is difficult
to enforce due to various rules and legislations for different
countries and carriers, instead it has created new opportunities for targeted exploit kits, data leaks, and privacy issues.
IMEI AND IMEISV NUMBERS:
THE LEAKY BUCKETS OF SMARTPHONES
With an IMEI or IMEISV number, specific details about the
OS, display, CPU type, release date, and battery type can be
inferred (Figure 2). With this knowledge, a skilled attacker
can craft appropriate social engineering messages and prepare targeted exploits for a particular device model.
We have observed two main ways for privacy-leaking applications to obtain this information. For the first approach, attackers
send the IMEI number directly to their command-and-control
Hi! You looked nice
when I sawyou . Its
Melanie, respond back
to me at
. com
FIGURE 1. A social engineering message.
(C&C) servers. This approach is fairly easy to detect because suspicious traffic is generated and can be logged during a behavioral
malware analysis. For the second approach, malware authors
place clickable icons that embed a URL with encoded GET
parameters on the user screens. For example, one of the analyzed
samples with default device parameters gave the following result:
http://somebadhost.xyz/?eduid=MTUwNA==&did=MDA
wMDAwMDAwMDAwMDAw&anid=ZTBiZTdlY2NkZT
E2MGQyZg==&ver=NC4yLjI=&car=QW5kcm9pZA==
&mod=c2Rr&pn=aGVyby5mb29kLmxpdGU= HTTP/1.1
This information allowed us to learn that this application is
leaking some data encoded in base 64. For example, the decoded
value of the “did” parameter corresponds to “000000000000000,”
which was the IMEI number of our virtualized device. A closer
look into the transmitted string tells us that “ver” corresponds to
the OS version and “car” stores information about the subscriber
carrier name. Other parameters reveal the more application-specific data that were used to track the subscriber.
Attackers may prefer the second approach because if a
user clicks on such a desktop icon, it will be opened in the
default device browser and could reveal even more detailed
information. This information may include the user agent
string, which, in our case, was the following:
User-Agent: Mozilla/5.0 (Linux; U; Android 4.1.1;
en-us; sdk Build/JB_MR1.1) AppleWebKit/534.30
(KHTML, like Gecko) Version/4.0 Safari/534.30
From this, we can learn that the client is using a system that is
likely to be vulnerable to targeted attacks using exploits known as
“Reverse Heartbleed” or the “Android Web View” exploit [3].
THE POORLY CODED SOFTWARE PROBLEM
Despite the popularity and ubiquity of SSL, its numerous implementations have already gained a reputation for being poorly
written [4]. This is because many cryptographic APIs are confusing for developers and present pitfalls for creating nonbrowser software. Some recent examples of such implementation
mistakes include the infamous “goto fail” (CVE-2014-1266 [5])
and “heartbleed” (CVE-2014-0160 [6]) vulnerabilities.
Heartbleed was the result of an implementation error for
server-side software that allowed anyone to read the system-protected memory when affected versions of OpenSSL were used.
The bug stemmed from the attacker’s ability to control the size
of the data chunk that was returned. This allowed the attacker to
2014 ^ IEEE Consumer Electronics Magazine
Authorized licensed use limited to: University of London: Online Library. Downloaded on June 27,2023october
at 07:51:42
UTC from IEEE Xplore. Restrictions apply.
41
step entirely. The vulnerability was
craft requests that retrieved the maxifixed by simply removing the infamum amount of data allowed (64 kb)
mous instruction from the code.
with no limit on the number of the
It should be noted that both heartrequests that could be sent.
bleed and goto fail were introduced
As we recently learned, under certo the source code at a later stage of
tain conditions, Heartbleed can allow
these projects, and they only affect
for the exploitation of client-side softcertain versions of the software.
ware. Such a scenario is called
The lack of sufficient attention to
“Reverse Heartbleed” [7], and it
detail and the negligence in impleenables a malicious server to keep
menting the cryptographic part of the
retrieving Web browser memory from
communication protocols were not the
vulnerable clients. Certain smartonly drawbacks identified by security
phones, such as Android devices
researchers. For example, Fahl et al.
using OS 4.1.1, are vulnerable to this
[9] identified a number of other vultype of attack [8].
nerabilities related to various aspects
To fix this vulnerability, a small
of SSL implementation for the
modification involving the addition of
Android OS. When compared to deskcorresponding check conditions in
top computers, the absence of visual
the code was made (Figure 3). This
security indicators showing that SSL
change stopped zero-length heartis working quickly becomes apparent.
beats, and it made sure that the actual
These visual indicators are crucial
record length was sufficiently long.
since, despite their popularity, plugins
This solution demonstrates that it was
not a fundamental flaw in the provid- FIGURE 2. Information inferred from an IMEI or such as HTTPS-everywhere are not
yet available for mobile devices. This
ed cryptographic algorithms but rath- IMEISV number.
puts smartphones in a more vulnerable
er an issue of oversight or negligence
position than PCs in regard to attacks such as SSL striping.
during the development process. Whatever the reason, it jeoparNevertheless, there are ways to address this problem. One
dized the information on hundreds of thousands of Web servers
such way is with SSL pinning, which relies on the fact that, if an
and for millions of their users.
application intends to use a service, it limits the chain of trust to
The goto fail bug was the result of an even simpler procertificate authorities (CAs) on this domain and any sibling
gramming error. The bug received this name because the vulcompanies. Doing this effectively limits the risk of trusting a
nerable code had one additional goto instruction that altered its
compromised CA. This could be difficult because applying such
logic in an unintended way (Figure 4).
a solution requires additional effort from application developers
The instruction was misplaced within a conditional statement
to learn about the internal functions of the applied SSL API,
without the necessary surrounding brackets. As a result of the
implementing this functionality manually, and making changes
error, the program path always leads to either the first or the secfor each new application. It would also require maintaining a
ond goto fail instruction; thus, an important block of certificate
key store and performing additional certificate validations for
tests is omitted. This guarantees that the flow is always the same
each app. Although this step can significantly reduce the risk of
despite the results of the preceding comparison. The returned
man-in-the-middle attacks, it has not been widely used for even
value is not properly validated, and it successfully passes the
the most popular applications [9].
“Server Key Exchange” verification. This small mistake allows
man-in-the-middle attackers to spoof SSL servers using an arbitrary private key for the signing step or by omitting the signing
SECURITY AND THE HUMAN FACTOR
Even the best technical solutions must be designed in a way so
that users can understand them properly. However, in security, the
human factor is considered the weakest link in many solutions.
/* Read type and payload length first */
In the case of Android OSs, the ultimate responsibility for
If (1 + 2 + 16 > s->s3->rrec.length)
verifying if an application is behaving in a harmless way has
return 0; /* silently discard */
been delegated to the end user. Attackers have exploited this situhbtype = *p++;
ation to trick users with less technical understanding into installn2s(p, payload)
ing unwanted software. The AndroidManifest.xml file from
If (1 + 2 + payload +16 > s->s3->rrec.length)
Android.Pikspam4 (Figure 5) provides an excellent example.
return 0; /* silently discard per RFC 6520 sec. 4 */
The file contains the application’s functionality as requested
pl = p;
by developers, and approving such a request is entirely the
user’s responsibility. This pirated version of a popular game
appeared to be legitimate, but it requested permission to send
FIGURE 3. A heartbleed bug code fix.
42 IEEE Consumer Electronics Magazine ^ october 2014
Authorized licensed use limited to: University of London: Online Library. Downloaded on June 27,2023 at 07:51:42 UTC from IEEE Xplore. Restrictions apply.
and receive text messages, access the
static OSStatus
external user’s storage, read the user’s conSSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
tacts, and access the Internet (Figure 6).
SSLBuffer signedParams, uint_t *signature, UInt16 signatureLen)
Examining these permissions could
{
OSStatus err;
have revealed the malicious nature of the
...
pirated application. Yet, despite the clear
if ((er r= SSLHashSHA1.update(&hashCtx, &serverRandom)) !=0)
indication that this application could be
goto fail;
harmful, many users decided to install it
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) !=0)
anyway. The motivation to obtain a pirated
goto fail;
app may have caused users to install softgoto fail;
Altered Logic
ware from unknown third-party repositoif ((err = SSLHashSHA1.final(&hashCtx, &hasedOut)) !=0)
goto fail;
ries without any security measures. By
...
Omitted Code
accepting these permissions, users granted
err = sslRawVerify(ctx, ctx->peerPubKey, dataToSign,
attackers the ability to spam other numdataToSignLen, signature, signatureLen);
...
bers that were received from an external
fail:
command-and-control server. Attackers
SSLFreeBuffer(&signedHashes);
were also able to access the victim’s conSSLFreeBuffer(&hashCtx);
tact list and spam their contacts to continreturn err;
}
ue distributing malicious software. This is
a common tactic in spam attacks because a
FIGURE 4. The instruction block responsible for the goto fail bug.
link received from a friend is more credible than one received from a stranger.
claimed to be antivirus software, but, when used, only
This brings us back to the human factor as a security flaw.
paused for a few seconds and then displayed a message sayThe fact that the users are relying on predescribed permissions
ing the scan was complete and no viruses had been found. It
suggested by the app developers is very problematic. Even
did not perform any malicious actions on the compromised
when looking at the permissions, it can be difficult to know
device. What it did do was charge people US$3.99 to downexactly what an application will do before installing it because
load and install an antivirus application that did not actually
it can be unclear or misleading. Users can check ratings and
detect viruses. It became the number-one-ranked applicareviews, but even those can be used to violate the user’s trust
tion for a few days, but, after 10,000 downloads, it was disand mislead them into installing a malicious application.
covered to be fake antivirus software. These types of scams
Android.Virusshield [10] is an excellent example of an
are very difficult to detect with automated systems because
application with misleading permissions. This application
<!-- namespace prefix=“android” uri=“http://schemas.android.com/apk/res/android” -->
<mainfest android:versionCode=1 android:versionName=“1.0”
package=“com.example.smsmessaging”>
<uses-sdk android:minSdkVersion=8 android:targetSdkVersion=15/>
<!CDATA “\n\xA0\xA0\xA0\xA0\n”/>
<uses-permission android:name=“android.permission.INTERNET”/>
<uses-permission android:name=“android.permission.RECEIVE_SMS”/>
<uses-permission android:name=“android.permission.READ_SMS”/>
<uses-permission android:name=“android.permission.SEND_SMS”/>
<uses-permission android:name=“android.permission.WRITE_SMS”/>
<uses-permission android:name=“android.permission.READ_CONTACTS”/>
<uses-permission android:name=“android.permission.WRITE_EXTERNAL_STORAGE”/>
...
<application android:theme=@01030055 android:label=@7F040000
android:icon=@7F020001 android:debuggable=true>
...
<service android:label=“My Service” android:name=“.TestService” android:enabled=true/>
<receiver android:name=“MyReceiver”>
<intent-filter android:priority=100>
<action android:name=“android.provider.Telephony.SMS_RECEIVED”/>
</intent-filter>
</receiver>
...
</application>
</manifest>
<!-- namespace-end prefix=“android” uri=“http://schemas.android.com/apk/res/android” -->
Declaration of
Requested
Permissions
Declares
Broadcast
Receiver
FIGURE 5. The AndroidManifest.xml takes advantage of users’ trust.
2014 ^ IEEE Consumer Electronics Magazine
Authorized licensed use limited to: University of London: Online Library. Downloaded on June 27,2023october
at 07:51:42
UTC from IEEE Xplore. Restrictions apply.
43
network, code obfuscation, or
advanced cryptography. The architecture of modern smartphones is quite
complex and contains many legacy
components that have not been targeted by attackers, such as real-time
OSs. While the mobile threat landscape may not be changing right now,
it is certainly much bigger than what
we can see today.
they often require the full context
before they can be properly assessed.
THE GROWING LANDSCAPE
OF THREATS
Taking into account the most recent
trends, the number of mobile vulnerabilities that was reported decreased
between 2013 and 2012 by 69%, from
416 to 127 vulnerabilities [11].
Despite the fact that 97% of documented mobile threats are associated
ABOUT THE AUTHORS
with the Android OS, 82% of docuSlawomir Grzonkowski (slawomir_
mented mobile vulnerabilities are
grzonkowski@symantec.com) is a prinassociated with iOS [11]. This indicipal research engineer at Symantec.
cates that the presence of vulnerabiliAlejandro Mosquera is a senior
ties does not necessarily lead to
principal SMS research engineer at
malware that exploits them. It is more
Symantec.
difficult for attackers to take advantage
Lamine Aouad is a principal
of software weaknesses that require
research engineer at Symantec.
more time and computer science
Dylan Morss is a director of develskills than it is for them to exploit the FIGURE 6. Pirated software permissions.
opment at Symantec.
human factor.
Mobile adware (madware), a core part of the business
REFERENCES
[1] L. Aouad, A. Mosquera, S. Grzonkowski, and D. Morss, “SMS spam:
model for free apps [12], saw an increase in 2013. The numA holistic analysis,” in Proc. 11th Int. Conf. Security and Cryptography,
ber of ad libraries grew from 65 for Android in October 2013
SECRYPT, Vienna, Austria, Aug. 2014.
to 88 by the end of the year [12]. Madware creates privacy
[2] GSM Association, IMEI Allocation and Approval Guidelines, Version
risks for users as it collects information such as device infor6.0, 2011-07-27.
mation, location coordinates, or network parameters in
[3] Android WebView exploit, CVE-2012-6636. [Online]. Available:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-6636
exchange for apps. Typically, it results in targeted ads that are
[4] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V.
presented on the notification bar and in the application.
Shmatikov, “The most dangerous code in the world: Validating SSL cerAlthough they collect the same information as malware and
tificates in non-browser software,” in Proc. 2012 ACM Conf. Computer
pose privacy risks, it is more difficult to properly categorize
and Communications Security (CCS’12), pp. 38–49.
them as malicious because their behavior is typically speci[5] Goto fail, CVE-2014-1266. [Online]. Available: http://cve.mitre.org/
cgi-bin/cvename.cgi?name=CVE-2014-1266
fied as the part of the end-user agreement.
CONCLUSION
In the mobile world, simple SMS spam [1] or aggressively
targeted ads can be more devastating for users than technically advanced threats. When attackers choose human weaknesses as the target, they do not need to rely on exploiting a
new zero-day vulnerability that can be patched; they just
need to exploit the human factor. This has proven so effective
that traditional threats, such as backdoors, downloaders, and
other malware make up only about 20–25% of mobile threats
[11]. Today, tracking users and stealing information are the
two largest threats faced by smartphone users. This can be
credited to mobile adware and to the fact that IMEI numbers
and phone numbers makes these activities much easier.
There are no indications of the mobile threat landscape
changing any time soon. We suspect that malware authors
will continue to design new families of malicious code or
prepare variations of the existing families. To date, we have
only observed a few examples of more advanced mobile
malware that took advantage of the TOR anonymity
[6] Heartbleed, CVE-2014-0160. [Online]. Available: https://cve.mitre.
org/cgi-bin/cvename.cgi?name=CVE-2014-0160
[7] E. Chien. (2014, June 16). Heartbleed poses risk to clients and the
Internet of Things. [Online]. Available: http://www.symantec.com/­
connect/blogs/heartbleed-poses-risk-clients-and-internet-things
[8] C. Arthur. (2014, June 16). Heartbleed makes 50m Android phones
vulnerable, data shows. [Online]. Available: http://www.theguardian.
com/technology/2014/apr/15/heartbleed-android-phones-vulnerabledata-shows
[9] S. Fahl, M. Harbach, T. Muders, L. Baumgärtner, B. Freisleben, and
M. Smith, “Why Eve and Mallory love Android: An analysis of Android
SSL (in)security,” in Proc. 2012 ACM Conf. Computer and Communications Security (CCS’12), pp. 50–61.
[10] M. Crider. (2014). The #1 new paid app in the Play Store costs $4, has
over 10,000 downloads, a 4.7-star rating... and it's a total scam [Updated].
[Online]. Available: http://www.androidpolice.com/2014/04/06/
the-1-new-paid-app-in-the-play-store-costs-4-has-over-10000-downloadsa-4-7-star-rating-and-its-a-total-scam/
[11] “Symantec Internet security threat report for 2014,” Symantec Corp.
Mountain View, CA, vol. 19, Apr. 2014.
[12] B. Uscilowski, “Mobile adware and malware analysis,” Symantec
Corp., Mountain View, CA, Version 1.0, Oct. 2013.
44 IEEE Consumer Electronics Magazine ^ october 2014
Authorized licensed use limited to: University of London: Online Library. Downloaded on June 27,2023 at 07:51:42 UTC from IEEE Xplore. Restrictions apply.