Critical analysis on the security of Android
communication applications
By
Shasi Chandra Pokharel
Supervisor
Dr. Raymond Choo
Associate Supervisor
Dr. Jixue Liu
A thesis submitted for the degree of
Bachelor of Information Technology (Honours)
School of Information Technology and Mathematical Sciences
Division of Information Technology, Engineering and the Environment
University of South Australia
October 2015
Acknowledgements
I would like to take this opportunity to express my gratitude to everyone, who guided,
motivated and helped me in every aspects while writing this thesis. Special thanks to my
supervisor Dr. Raymond Choo and associate supervisor Dr. Jixue Liu for their tireless support
and effort to guide me throughout this period.
Big Thanks to Dr. Jantanee Dumrak (DPM) for her support and all the motivation from
last four years. Also to Sherif Mostafa from School of Natural and Built environments and
Azfar Abdullah from Information Assurance Research group for sharing ideas and guidance
during this period.
Final and the most important thanks goes to my wife Anuka Bhandari for being there
with me all this time, coping with the fluctuations of my frustrations and excitements every
day. I am also grateful to all my friends inside and outside universities.
Disclaimer
I declare that this thesis does not incorporate without acknowledgment any material
previously submitted for a degree or diploma in any university; and that to the best of my
knowledge it does not contain any materials previously published or written by another person
except where due reference is made in the text.
Shasi Chandra Pokharel
25 October 2015
Abstract
The increasing popularity and dependency on mobile devices has resulted in legitimate security
and privacy concerns. For example, vulnerabilities in mobile devices, apps, and networks could be
exploited by criminals to target mobile device users. This thesis provides a critical analysis of two
commonly used communication mediums for Android devices, namely: lightweight web browsers and
Voice over Internet Protocol (VoIP) apps. An adversary model is used to model the capabilities of a
real-world attack. Using the adversary model, previously unpublished vulnerabilities were revealed in
four lightweight web browsers. In the five VoIP apps studied, it is demonstrated that app-to-app
communications between two of the apps could be decoded.
Contents
Acknowledgements ................................................................................................................................. 2
Disclaimer ............................................................................................................................................... 3
Abstract ................................................................................................................................................... 4
Introduction ............................................................................................................................................. 6
Can Android VoIP Voice Conversations be Decoded? .......................................................................... 7
Exploiting Cache Security weakness of lightweight browsers with an adversary model ..................... 24
Conclusion ............................................................................................................................................ 42
References ............................................................................................................................................. 43
Introduction
Security of mobile communication has become increasingly important in recent years as the
capabilities and scope of these devices keep growing. More and more users are now employing mobile
devices e.g., smartphones, tablets as tools for communication, making them more vulnerable and
preferred target of cyber-attacks. These devices transmit and store large amount of sensitive private
information. Therefore strong security measures should be implemented, both in operating system level
and individual application level to ensure such information is protected from unintended access.
According to recent market statistics, Android devices covers the 83 percentage of overall
mobile device market (Smartphone Vendor Market Share, 2015 Q2 2015). Another report shows that
Android devices are the primary targets of cyber attackers ranging 98 percent of mobile malwares
targeted to the Android in 2013 (Kaspersky Security Bulletin 2014). This thesis analyses the security
of communication applications, named Voice over Internet Protocol (VoIP) apps and Lightweight web
browser apps, in Android devices to determine whether the users of such applications are in risk of
cyber-attacks.
Our study has been presented in two different chapters. First chapter is focused on the security
of mobile VoIP applications and next chapter analyses the security in lightweight web browsers in
mobile device. Each of these sections represents an individual paper, prepared for academic journals.
Section 2 has been submitted for the journal "Concurrency and Computation: Practice and Experience"
and is currently under review. Section 3 is in the process of submission.
The last chapter is the conclusion of this thesis and covers the overall implication of our study.
Potential extension of this research and areas for further study are also suggested in this chapter.
Can Android VoIP Voice Conversations be Decoded?
Shasi Pokharel, Kim-Kwang Raymond Choo, Jixue Liu
University of South Australia, Australia
poksc001@mymail.unisa.edu.au; Raymond.Choo@unisa.edu.au; Jixue.Liu@unisa.edu.au
Abstract
Voice over Internet Protocol (VoIP) is increasingly used by both individuals and corporate
users. Recent studies had suggested that communications using VoIP apps may not be
encrypted although it has not been demonstrated that original conversations could be recovered
from unencrypted communications that were subsequently intercepted. In this research, we
propose a process for codec identification and decoding of captured communications from 15
popular Android VoIP apps. We are able to recover the original voice conversations from
intercepted app to app voice calls of nine applications and app to phone calls from ten
applications.
Keywords
Android VoIP apps, codec identification, VoIP communications,
1. Introduction
Voice over Internet Protocol (VoIP) services are increasingly popular, and this is, perhaps,
due to the ability to make cheap or free video and voice calls over existing networking
infrastructure and on Internet-connected devices (e.g. mobile devices). For example, Juniper
has predicted that the number of VoIP users will reach one billion by 2017 (Mobile Operators
to Generate $20bn from Internet Voice as 'Carrier ott' Matures 2014) which is three times
more than the estimated number of VoIP users in 2013 (Barnum 2013).
As with most new technologies, VoIP services can be used for criminal exploitation or be
targeted by individuals with criminal intent or even government agencies. For example, the
revelations by Edward Snowden revealed that the National Security Agency has been
conducting wide-scale government surveillance, including those targeting mobile device users.
With the increased use of mobile devices and mobile apps for VoIP, there is an increasing
need for users, including mobile device users, to have a better understanding of the associated
security and privacy risks. Researchers, such as Dantu et al. (2009), Zhang et al. (2009), Zhang,
R et al. (2010) have identified the potential vulnerabilities of VoIP communication and
suggested mitigation strategies. However, many VoIP providers have failed to follow best
practices; VoIP communication may be unprotected (Azfar, Choo & Liu 2014).
Previous studies on mobile VoIP apps are either focused on analysis of a single application
(Adami et al. 2012; Appleman, Bosma & Veerman 2011; Zhang, D et al. 2010) or were unable
to decode intercepted VoIP communications (Azfar, Choo & Liu 2014; Gomes et al. 2013).
We propose an algorithm to identify the codecs used in intercepted VoIP communication that
are not encrypted, and develop decoder tools attempting to decode the intercepted traffic. We
demonstrate the utility of our algorithm and decoder tools using 15 popular VoIP apps (as of
September 2015) as case studies.
The remainder of this paper is organized as follows. Sections 2 and 3 provide an overview
of related work and relevant background materials, respectively. Our research methodology is
outlined in Section 4. We present and discuss the findings in Section 5. The last section
concludes this paper and suggests future work.
2. Related Work
2.1. Codec Identification:
In a recent study, Matousek, Rysavy and Kmet (2014) presented an approach to detect
RTP stream by analysing individual packet headers and the flow of the UDP packets stream
over the network. The authors also proposed a codec identification method, based on the
calculation of timeframe difference in each RTP packet.
Several other methods have been proposed to identify the RTP packets and their codecs
based on the analysis of payload data, interpretation of RTP header, behavioural pattern and
analysis of statistical data. For example, Adami et al. (2012) and Zhang, D et al. (2010) used
both payload data with behavioural pattern of RTP stream in their approaches. As both
approaches are based on heuristic and statistical data and do not rely on individual packets,
they can also be used to identify encrypted RTP stream.
A different approach, by Hicsonmez, Sencar and Avcibas (2013) checks the average
variance value and entropy value of the encoded audio, to identify the associated codec. Gomes
et al. (2013) use entropy based codec signatures and other properties to identify the codecs used
by VoIP applications. In this method, they measure the heterogeneity of the packet lengths, etc.
to create the signature for each codec. This signature was then checked with the test data to
identify the possible codecs (similar to existing signature-based anti-malware solution). Similar
approach is used by Li, B, Ma and Jin to determine whether the used codec is a Constant bitrate
(CBR) or a Variable bitrate (VBR) codec (Li, B, Ma & Jin 2011).
2.2. Mobile VoIP Security
The security of VoIP communication is typically analysed based on an attacker’s
capability to intercept the communication and decode the intercepted data (Benini & Sicari
2008). A number of security measures have been proposed to disguise / hide VoIP traffic from
being identified, intercepted and decoded. For example, Mohajeri Moghaddam et al. (2012)
proposed using the protocol obfuscation method to hide the Skype traffic in TOR bridges.
Encryption is the most commonly proposed solution to secure VoIP communication.
This includes encrypting signaling control protocol, such as Session Initiation Protocol (SIP)
(Rosenberg, Schulzrinne & Camarillo 2005; Rosenberg et al. 2002), and media transfer
protocol, such as RTP packets (Alvestrand 2015; Lehtovirta, Naslund & Norrman 2007;
Zimmermann & Johnston 2011). A recently developed variant of Secure RTP, WebRTC, is
being increasingly adopted by VoIP apps, such as Facebook (Hancke 2015a), Google Hangout
(How does Hangouts use WebRTC? webrtc-internals analysis 2015) and WhatsApp (Hancke
2015b).
In 2012, Keromytis (2012) presented a comprehensive survey of VoIP security
research, which included 245 publications between 2000 and the first quarter of 2011.
However, the survey generally focuses on threats and vulnerabilities affecting traditional VoIP
systems (i.e. non-mobile). In the same year, Schrittwieser et al. (2012) examined the security
mechanism of nine popular VoIP applications and revealed that most of them are vulnerable to
hijacking attacks, mainly due to the weakness in the device’s user authentication scheme. One
potential solution is introducing an Attribute Authority (AA) server, such as those proposed by
Yang et al. (2014). This solution allows the provision of User Access Control (UAC) and
authentication for VoIP service in a mobile communication environment, based on the
permission levels.
Zhu and Fu examined the traffic in Skype communications to identify patterns that
could be used to distinguish the speaker with a reasonably high probability (Zhu & Fu 2011).
In another study, Appelman, Bosma and Veerman reverse engineered the Viber app and
analyzed the voice communications. They determined that Viber used a proprietary protocol,
and concluded that the voice data packets were scrambled and not encrypted (Appleman,
Bosma & Veerman 2011). Recently in 2014, Azfar, Choo and Liu examined ten popular VoIP
Android applications (also known as apps) and found that voice communication in six of them
is not encrypted. However, the authors were not able to decode the intercepted communications
that were determined as not encrypted (Azfar, Choo & Liu 2014) – a gap that we address in
this paper.
3. Background
3.1 VoIP Protocol
VoIP consists of signalling control protocols and media transfer protocols. The former is
responsible for user authentication, connection establishment and negotiation of codec and
encryption to be used by the media. Session Initiation Protocol (SIP) is a popular example of
signalling control protocols. The media transfer protocols are responsible for audio and video
transfer, and Real-time Transfer Protocol (RTP) is such a protocol.
To establish a connection between devices, SIP sends a number of SIP packets containing
messages of REGISTER, INVITE, RINGING and OK in a sequence. The connection is
established if the SIP packet contains OK, which is called a SIP (OK) packet.
The SIP (OK) packet encapsulates the Session Description Protocol (SDP) packet, which
contains the list of negotiated codecs along with associated Payload Type (PT). These codecs
are tagged in rtpmap attributes. Each rtpmap entry represents a codec with a name and sample
rate.
An example of a SDP packet captured during a Wicall communication is illustrated in Figure
1. The packet contains PCMA with PT value 0 and PCMU with PT value 8; suggesting the use
of G.711 codec.
Figure 1: SDP Packet of Wicall, which contains codec information.
Streaming of RTP packets will commence upon the completion of the connection
establishment. Each RTP packet contains a PT value in its header, which allows the receiver
device to know which codec was used for the encoding. This PT value should be the same as
the PT associated with one of the codecs in the SDP packet. Besides the main protocols of SIP
and RTP, the real-time control protocol (RTCP) may be used to monitor the transmission and
quality of services. RTCP packets are transmitted between user devices periodically during the
media transfer and carry information about packet loss, number of packets etc.
3.2 VoIP Codec
Voice codecs have parameters such as bitrate, sample size, and sample interval. Bitrate
refers to the required number of bits per second, transmitted during the voice call. Sample size
is the number of bytes used by the digital signal processor (DSP) to encode/decode the voice
and sample interval refers to the interval of encoding/decoding.
The choice of the codec determines the quality of voice in VoIP calls and efficiency of
bandwidth in network. A higher bitrate and sampling rate and smaller frame sizes will generally
result in better voice quality, but this requires more bandwidth. Therefore, VoIP service
providers may offer multiple codec options that could be negotiated based on the bandwidth
and other user requirement. For example, G.711 would be more appropriate when the user has
a high bandwidth, as the bitrate is 64 Kbps. Codecs such as G.729 and ILBC that transmit in
8Kbps are more suited for low bandwidth applications. GSM codec is used for cellular
telephony and uses 13Kbps bitrate.
VoIP traffic encoded using CBR codecs generally contains the RTP packets of equal length.
A major drawback of using CBR codec is that the transmission behaviour cannot be adapted
for different network environment. Hence, at times, using CBR codec fails to produce the
minimal quality of service standard.
VBR codecs, on the other hand, is capable of changing the bitrate throughout the VoIP
session. Hence, the size of the RTP packets is likely to vary. As VBR codecs are adaptive of
the network environment, they provide better voice quality and bandwidth efficiency (Li, FH,
Xiao & Zhang 2008). Popular examples of VBR codecs include the SILK codec (introduced
by Skype; bitrate between 6 and 40Kbps), Internet Speech Audio Codec (introduced by Global
IP solution in 2009 and acquired by Google in 2011; bitrate is between 10 and 32Kbps when
RTP protocol is used, and is between 10 and 52Kbps when webRTC protocol is used), Speex
(bitrate between 2.15 and 44.2Kbps), and opus (bitrate between 6 and 510 Kbps). VoIP apps,
such as Viber, may use proprietary codec; therefore, complicates effort to decode intercepted
communications. Table 1 shows the most popular codecs considered in this study.
Table 1: Popular codecs
Codec
Name
G.711
G.729
GSM
ILBC
ISAC
SILK
Speex
Opus
Type of
Codec
CBR
CBR
CBR
CBR
VBR
VBR
VBR
VBR
Standard
Bitrate
64
8
13
8
Variable
Variable
Variable
Variable
Frame Size
Default Δ time
20
20
20
20,30
30,60
20
20
variable
160
160
160
160,240
480,960
320,640
160,320
variable
In VoIP communication, codecs are represented by a value, Payload Type (PT), which is
included in the RTP header. Codecs, such as G.729, G.711, and GSM, have been assigned with
a fixed PT value by the International Assigned Number Authority (IANA). Many other codecs,
such as ISAC, ILBC, Speex, SILK, and Opus, can use any number between 96 and 127, but
both end devices must agree on the number and associated codec during the session
establishment process.
4. Research Methodology
4.1 Experiment Setup
In our experiment, we used two Android mobile devices, namely: a Samsung Galaxy S4
(Android version 4.4.2) and a Samsung Galaxy S5 (Android version 5.0). The Samsung Galaxy
S4 device was rooted using “Kingroot”. For packet capture, we installed the “Shark for root”
on the Samsung Galaxy S4 device. To avoid traffic noise, the other apps on the Samsung
Galaxy S4 device were turned off and the associated services terminated using the application
setting. We then used the 15 VoIP apps described in Table 1 to make voice calls; one at a time.
To ensure the reliability and consistency in this research, four calls were made for every app.
Captured packets were saved as separate pcap files for each call and transferred to a personal
computer for analysis using Wireshark tool.
As each of these codecs has different parameters and encoding/decoding behaviours, we
will need to use different decoder tools. For example, if the codec used in VoIP app X is CBR,
then we can decode the raw data in the entire stream using a relevant decoder tool. In the case
of VBR codec, we will need to parse each packet individually for the decoding. In this research,
we will use CloudShark (Cloudshark) to decode G.711 and GSM codecs, and open source tools
to decode for G.729 (VAG729) and ILBC ( ILBCfreeware). These tools take as input the raw
binary of the RTP payload and output the decoded voice communication.
VoIP
app
Mobile
Version
operating system No.
Android
iOS
BlackBerry
Windows
Table 2: VoIP apps used (information accurate as of September 2015)
Downloads
(in million)
Services provided
BBM




2.9.0.51
100-500
5.4.1
100-500
App to app text message, multimedia
message, voice call, picture and video
sharing.
App to app text message, multimedia
message, voice and video call, app to
phone call
App to app text message, multimedia
message, voice and video call, app to
phone call
App to app text message, Multimedia
Message, Voice and Video Call
LINE




Tango


Yahoo




1.8.8.16
003
50-100
ICQ




6.1
10-50
TextPlu
s
Fringe



5.9.9
10-50


4.5.2.2
10-50
Nimbuz
z


4.0.0
10-50
Libon


3.15.1
5-10
WiCall
Vonage




78
2.9.5
1-5
1-5
Maaii


2.5
1-5
NextPlu
s
Nanu
Mo+


1.3.5
1-5




1.7
2.3.7
1-5
1-5
3.18.170 100-500
419


App to app text message, voice and video
call, content sharing
App to app text message, multimedia
message, voice call, app to phone call
App to app text message, Voice and Video
call. App to phone call.
App to app text message, multimedia
message, voice and video call, app to
phone call
App to app text message, multimedia
message, voice call, app to phone call
App to phone voice call and text message
App to app text message, multimedia
message, voice and video call, app to
phone call
App to app text message, multimedia
message, voice call, app to phone call
App to app text message, multimedia
message, voice call, app to phone call
App to app and app to phone voice call
App to app text message, multimedia
message, voice and video call, app to
phone call
For the VBR codecs, we developed separate RTP decoder tools for the ISAC, Speex and
opus codecs. Both Opus and Speex decoder tools use official libraries, provided by the creators
of these codecs to decode the individual RTP packets (See Section 4.3). We were unable to
create the decoder for SILK because the official decoder library is not accessible to third-party
developers. Similarly, ISAC library is only available as a part of WebRTC, which encrypts the
VoIP traffic. Therefore, in this research, applications determined to be using SILK or ISAC
codec will be marked as "unable to determine".
We selected 15 popular mobile VoIP apps from Google Play store. These apps have more
than one million downloads from Google Play store, and are available in at least one other
(iOS, Windows, etc.) platform. We did not choose Facebook messenger, Skype and Viber as
voice communications using these apps have been determined to be encrypted (Appleman,
Bosma & Veerman 2011; Hancke 2015a; Zhu & Fu 2011). Of the 15 selected apps (see Table
2), 11 provide calling service in both app to app and app to phone settings. The remaining three
apps provide only app to app communication and one app provides only app to phone call
service.
4.2 Identification of used Codec
Our codec identifier method is based on the Codec Mapper Table (CMT), similar to the
approached used by Li, B, Ma and Jin (2011) and Matousek, Rysavy and Kmet (2014). Both
approaches use the timestamp difference of RTP packets as the key feature to map the codecs.
However, in this study, we use approximate bitrate calculation in addition to timestamp
difference (∆time) to identify codecs, and our approach could also identify VBR codecs.
Bitrate is calculated by formula 1. As the input packets are captured on per second
count, it may not cover the accurate value of transmitted bits. Therefore, we consider this value
as an approximate bitrate value. A more accurate bitrate can be obtained by counting the RTP
payload transmitted per millisecond. For this study, approximate values suffice to distinguish
between the possible codecs from the CMT (Table 1).
Formula 1: Bitrate calculation
Input: S = Sequence of RTP Packets
Output:
b = Bitrate of RTP Packets
Do:
Let S1 be the packets per second in S.
If the header of s[0] contains PT, then
𝑏=∑
𝑠. 𝑝𝑎𝑦𝐿𝑜𝑎𝑑𝑆𝑖𝑧𝑒 ∗ .008
𝑠∈𝑆1
Else: 𝑏 = 0;
Return b
Recall that ∆ time is the difference between timestamps of adjacent RTP packets in the
same RTP stream. For given adjacent packets i and j, ∆ time is calculated as tj – ti, where tj >
ti. Generally, this value remains constant throughout the session.
In Algorithm 1, findCodec() function outputs the codec name, using the RTP stream
and SDP packet (if available) as the input. As a first condition, we check whether the RTP
packets have a readable header. If the RTP header is not readable or RTP stream is not detected,
we will determine that this is encrypted, and abort.
If the RTP header is readable, we will check the rtpmap array of SDP packet. This array
contains the codec name and sample rate associated with the PT value. Therefore, the codec in
use can be easily identified. However, if the SDP packet is not available or encrypted, we will
use Formula 1 to calculate the approximate bitrate. A constant bitrate value will indicate that
the CBR codec is used (recall that RTP packets of a single RTP stream using this codec have
a constant length); otherwise, we will check the bitrate value against Table 1 to identify the
codec.
Algorithm 1: VoIP Decoding
Input: A SIP packet 𝑝, a sequence S of all RTP packets of a session
Output: Decoded voice communications
Do:
Let codeclist = findCodecs(p, S)
If codeclist==null, print “Decoding cannot be performed”.
Let voiceArray = decode(S, codeclist)
For (voice in voiceArray), play(voice)
End
Function: findCodecs (p, S)
Input: p: SDP packet; S: a sequence of RTP packet
Output:
codeclist: a list of codecs and associated bitrate possibly used for encoding voice
Do:
If header(S[0]) is not readable, return null. //RTP stream is encrypted, so cannot be decoded
Else if (SIP has a readable SDP section) {
Let rtmpMedia = p.SDP.rtpmap // a list [rtpmap1 , …, rtpmapn ]
//find codec name with matching RTP. PT value
Array codeclist; // identified codec and bitrate will be saved in this array
For each (m in rtmpMedia){
If (S[0].PT == m.PT){ //Match the PT value in RTP header with PT of rtpmap.
codeclist.add(m.codec); }}
return codeclist;}
Else if (SIP is encrypted) { //codec information from SIP/SDP packet is not available
b = calcualteBitrate(S) //find bitrate for each second using formula 1.
if (b!=0) &&(b is constant throughout the session){
//select codec whose bitrate is the closed to b
Array codeclist = “SELECT codecName FROM Table1
WHERE (b is closest to bitrate of codecName AND Δtime is
same)”
return codeclist;}
else if (b!=0) && (b varies frequently) //Used codec is identified to be VBR
{
codeclist.add("opus")
codeclist.add("SILK")
codeclist.add("ISAC")
codeclist.add("Speex")
}
else return null; }
Function: decode (S, codeclist)
Input: S: all RTP packets of a call session; codeclist: array of (codec name and bitrate)
Output:
Decoded voice array
Do:
For ( m in codeclist) {
// decode S using codec m
voice.add( decoder(m.codecName, m.bitrate, S) ) }
return voice;
If the calculated bitrate is associated with more than one codec, we will map the value
of the timestamp difference (∆ time) with the associated codec. For example, G.729 and ILBC
codec have a bitrate of 8 kbps, but they have different ∆ time value. For VBR codecs, the
findCodec() function of Algorithm 1 will return an array of possible VBR codecs.
4.3. Decoding RTP data
In Algorithm 1, the decode() function is designed to decode intercepted packets (R)
using the identified codecs (from the findCodec() function).
Figures 2 and 3 outline the decoding process of CBR codecs. For G.711 (PCMA and
PCMU) and GSM, we can follow the procedure (see Figure 2) in cloudshark, which returns the
decoded voice communication. For G.729 and ILBC, we need to extract the encoded RTP
payload data in a raw file and pass it to the decoder tool for decoding (See Figure 3).
Figure 2: Decoding RTP streams in Cloudshark
If the codec used is determined to be VBR, we will parse each RTP packet individually
using the native decoder library during decoding. In this research, we convert the captured
.pcap file into Packet Detail Markup Language (PDML) file, which saves each packet,
including the header fields in XML like tree structure. Our decoder tool filters the RTP packets,
based on these headers and passes them to the embedded native library (e.g. opus library or
Speex library). These libraries decode the RTP into linear voice. When decoded, our tool adds
the wave header for those packets and save it as the wave file (See Figure 4).
Figure 3: Decoding G.729 and ILBC encoded RTP stream
Figure 4: Decoding RTP stream encoded with VBR codecs
5. Discussion
We found that the apps, with the exception of Wicall and Vonage (in app to phone setting),
encrypt their signaling control protocol packets and use dynamic Payload Type (PT) Value.
However, we were able to identify the codecs in most of these apps, both in app to app
communication and app to phone communication. We now detail our findings of the 15 VoIP
apps.
BBM is a cross-platform communication app belonging to Blackberry Corporation, which
is known for communication security. Interestingly, our study determined that the Android app
does not encrypt the RTP packets. Hence, such communications will be vulnerable to
eavesdropping. Although its signaling control session was encrypted, we were able to read the
RTP headers and analyse the streaming from the captured packets.
Based on the length of the RTP packets and our calculation of the bitrate, we determined
that BBM uses the opus codec. We were also successful in decoding the intercepted VoIP
communication using our decoder tool, and recover the original voice conversation.
LINE uses a client-server architecture for media transfer, and voice communications were
encapsulated in the STUN protocol. We determined that the signaling control session was
encrypted, but we were able to obtain the RTP packets by dissecting the STUN header.
Analysis of packet length and our bitrate calculation suggest that the app uses VBR codec. For
both app to app and app to phone communications, the calculated Δ time value is 960. As
explained by [13], a Δ time value of 960 is associated with the ISAC codec with frame size
60ms. Using Formula 1, we determined that the bitrate ranges between 10.5 kbps and 18.9 kbps
throughout the session, which also suggested the use of the ISAC codec. However, ISAC codec
is only available as a part of WebRTC, we were unable to decode the intercepted conversation.
Different behaviours were observed in the intercepted communication packets of Tango in
the app to app conversation and the app to phone conversation. In the app to app conversation,
we were unable to recover the flow of the RTP stream. Although the RTP header has a match
with the G.711 codec, the remaining headers values (e.g. SSRC and port number) are
randomized. Analysis of the packets in wireshark tool resulted as 'malformed packet'.
Therefore, we determined that Tango either encrypts or uses header confiscation method to
protect the VoIP data. However, in app to phone communication, we were able to identify the
codec used as ILBC, based on the bitrate and Δ time calculations. Using the ILBC decoder
tool, we were successful in decoding and recovering the original voice conversation.
RTP packet size of Yahoo's VoIP traffic suggests the use of the CBR codec. Using Formula
1, we calculated the bitrate to be between 7.8 and 8.3. This value is similar to that of G.729 and
ILBC. We then calculated the Δ time value, which was 240. By checking this value against
those listed in Table 1, we determined that Yahoo uses the ILBC codec. Again, we were
successful in decoding and recovering the original voice conversation.
In Nimbuzz, the signaling control traffic packets were encrypted, in app to app and app to
phone settings. However, similar to Yahoo, we were able to determine that ILBC codec was
used based on our calculations of the bitrate and Δ time. Therefore, we were successful in
decoding and recovering the original voice conversation.
We determined that the VBR codec was used in ICQ, and we were able to decode the
intercepted packets using our opus decoder and recover the original voice conversation.
TextPlus and NextPlus are developed and operated by the same company; the latter is
considered as the improved version of the former app. However, we determined that this
improvement does not appear to extend to the security of the communications. In both apps,
RTP packets are unencrypted. Although the signaling control session was encrypted, we were
able to decode and recover the original voice conversations from the intercepted RTP packets
using our opus decoder tool. Similarly, we were able to identify the used codec "opus" in both
Maai and Libon apps. Subsequently, we were successful in recovering the original voice
conversation using our decoder tool.
Wicall provides only app to traditional phone VoIP call services. We determined that the
app does not encrypt VoIP communication – both signaling control and RTP. We were able to
obtain user information, such as SIP user ID and the phone numbers of both callers and callees.
We also determined that Wicall uses G.711 PCMU codec, and were able to decode the RTP
packets, and recover the original voice conversation.
We determined that Vonage encrypts signaling control protocol packets in app to app
conversation. However, we were able to determine that the app uses the VBR codec. Hence,
we were able to decode and recover the original voice conversation. In the app to phone
communication, we determined that Vonage does not encrypt the communication packets,
including signaling control protocol and RTP packets. We were, therefore, able to obtain
session establishment data, such as SIP username, user phone number, device detail, and
negotiation of codecs. This also implies that the service is vulnerable to a man-in-the-middle
(MITM) attack. Because it the negotiated codec name, sample rate and associated PT value
were revealed in the SDP packet, we were able to identify the use of opus codec in the RTP
packets. Using our opus decoder tool, we successfully decoded and recovered the original voice
conversation.
In the case of Fring and Nanu apps, we were unable to identify RTP packets in the
intercepted packet captures. we believe that both apps encrypt the signaling control packets
and RTP packets prior to transmitting over the network.
In Mo+, we were not able to detect the RTP packets in the app to app setting. Similar to
Fring and Nanu, we determined that the RTP packets are encrypted. However, we were able to
detect the RTP packets and read its header in the app to phone conversations. We determined
that the opus codec is used, and successfully decoded the RTP packets using our opus decoder
tool to recover the original voice conversation.
Table 3: Summary of findings
Application
BBM (By
Blackberry)
Line
Line
Tango
Tango
Yahoo
Icq
TextPlus
TextPlus
Fringe
Fringe
Nimbuzz
Nimbuzz
Libon
Libon
Wicall
Vonage
Vonage
Maai
Maai
NextPlus
NextPlus
Nanu
Nanu
Mo+
Mo+
Type of
communication
app-app
Identified
codec
Opus
Decoded?
Applied security measures
Yes
app-app
app-phone
app-phone
ISAC
ISAC
G.711
No
No
No
app-phone
app-app
app-app
app-app
app-phone
app-app
app-phone
app-app
app-phone
app-app
app-phone
app-app
app-app
app-phone
app-app
app-phone
app-app
app-phone
app-app
app-phone
app-app
app-phone
Opus
ILBC
Opus
Opus
Opus
Unidentified
Unidentified
ILBC
ILBC
Opus
Opus
G.711
Opus
Opus
Opus
Opus
Opus
Opus
Unidentified
Unidentified
Unidentified
Unidentified
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Signaling Control protocol (SCP)
encrypted
Undetermined
Undetermined
SCP encrypted
RTP header obfuscation
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
All VoIP traffic encrypted
All VoIP traffic encrypted
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
None
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
SCP encrypted
All VoIP traffic encrypted
All VoIP traffic encrypted
All VoIP traffic encrypted
All VoIP traffic encrypted
6. Conclusion and Future Work
While VoIP services can potentially result in significant cost reduction and convenience for
both individual and organizational users (e.g. the capability to communicate with two or more
individuals in real-time using mobile devices), users need to be aware of the privacy risks
associated with the use of VoIP services. For example, VoIP services are a potential attack
vector for attackers seeking to eavesdrop on conversations between two or more individuals.
As the popularity of VoIP services grows, this will become an even greater issue, particularly
as users become more comfortable with such services and organizations change their telephony
services to VoIP.
In this paper, we examined 15 popular Android VoIP apps in order to contribute towards a
better understanding of the privacy risks associated with the use of popular VoIP apps. Findings
from our research suggest that the security of mobile VoIP services appear to be less of a focus
for VoIP providers, than the quality of the voice. This is, perhaps, due to the competitive nature
of the consumer market. We determined that more than half of these apps do not encrypt the
voice communications, and we were able to recover the original voice conversations from
intercepted communications.
The increasing use of VBR codecs (i.e. opus) is also concerning, and there is a pressing
need to secure RTP communications, particularly due to their increasingly popularity in VoIP
applications, such as Skype and Facebook (webRTC is also been used in applications, such as
Facebook messenger, WhatsApp, and Google Hangout). However, a major concern about
encrypting RTP streams is the addition requirements in memory usage, processing power and
bandwidth. This may be the reason why many apps only encrypt the signaling control packets
rather than the RTP data, although previous studies have suggested that RTP encryption may
have negligible impact on the user experience or performance (Keromytis 2012; Lehtovirta,
Naslund & Norrman 2007; Li, B, Ma & Jin 2011).
Our research also shows that applications, such as Tango and Mo+, only encrypt the
communications between app and app, and not between app and phone. Consequently,
communications in the app-to-phone setting are vulnerable to eavesdropping. Although it may
not be possible to provide end-to-end encryption in an app to phone setting, we recommend
that the communication between the device / app and the VoIP server to be encrypted to ensure
the privacy of the users.
Future work would include extending our research to examine popular VoIP apps for iOS,
Windows and other popular mobile platforms.
References
Adami, D, Callegari, C, Giordano, S, Pagano, M & Pepe, T 2012, 'Skype‐Hunter: A real‐time system for
the detection and classification of Skype traffic', International Journal of Communication Systems, vol.
25, no. 3, pp. 386-403.
Alvestrand, H 2015, Transports for WebRTC, <https://tools.ietf.org/html/draft-ietf-rtcweb-transports09>.
Appelman, M, Bosma, J & Veerman, G 2011, 'Viber Communication Security Unscramble the
Scrambled'.
Azfar, A, Choo, K-KR & Liu, L 2014, 'A study of ten popular Android mobile VoIP applications: Are the
communications encrypted?', System Sciences (HICSS), 2014 47th Hawaii International Conference on,
IEEE, pp. 4858-4867.
Barnum, T 2013, Mobile Voip Users Will Reach 1 Billion By 2017?
<http://blog.voxox.com/blog/bid/302293/Mobile-VoIP-Users-Will-Reach-1-Billion-by-2017>.
,
Benini, M & Sicari, S 2008, 'Assessing the risk of intercepting VoIP calls', Computer Networks, vol. 52,
no. 12, pp. 2432-2446.
Cloudshark, <https://www.cloudshark.org/ >.
Dantu, R, Fahmy, S, Schulzrinne, H & Cangussu, J 2009, 'Issues and challenges in securing VoIP',
computers & security, vol. 28, no. 8, pp. 743-753.
Gomes, JV, Inacio, PR, Pereira, M, Freire, MM & Monteiro, PP 2013, 'Identification of peer-to-peer
voip sessions using entropy and codec properties', Parallel and Distributed Systems, IEEE Transactions
on, vol. 24, no. 10, pp. 2004-2014.
Hancke, P 2015a, Messenger Exposed, Investigative Report, <https://webrtchacks.com/wpcontent/uploads/2015/05/messenger-report.pdf>.
Hancke, P 2015b, What’s up with WhatsApp and WebRTC ? , <https://webrtchacks.com/whats-upwith-whatsapp-and-webrtc/>.
Hicsonmez, S, Sencar, HT & Avcibas, I 2013, 'Audio codec identification from coded and transcoded
audios', Digital Signal Processing, vol. 23, no. 5, pp. 1720-1730.
How
does
Hangouts
use
WebRTC?
webrtc-internals
<https://webrtchacks.com/hangout-analysis-philipp-hancke/>.
ILBCfreeware, <http://www.ilbcfreeware.org/software.html >.
analysis
2015,
Keromytis, AD 2012, 'A comprehensive survey of voice over IP security research', Communications
Surveys & Tutorials, IEEE, vol. 14, no. 2, pp. 514-537.
Lehtovirta, V, Naslund, M & Norrman, K 2007, Integrity Transform Carrying Roll-Over Counter for the
Secure Real-time Transport Protocol (SRTP), <https://tools.ietf.org/html/rfc4771>.
Li, B, Ma, M & Jin, Z 2011, 'A VoIP traffic identification scheme based on host and flow behavior
analysis', Journal of Network and Systems Management, vol. 19, no. 1, pp. 111-129.
Li, FH, Xiao, Y & Zhang, J 2008, 'Variable bit rate VoIP in IEEE 802.11 e wireless LANs', Wireless
Communications, IEEE, vol. 15, no. 1, pp. 56-62.
Matousek, P, Rysavy, O & Kmet, M 2014, 'Fast RTP Detection and Codecs Classification in Internet
Traffic', Journal of Digital Forensics, Security and Law, vol. 9, no. 2, pp. 101-112.
Mobile Operators to Generate $20bn from Internet Voice as 'Carrier ott' Matures 2014, Juniper
Research.
Mohajeri Moghaddam, H, Li, B, Derakhshani, M & Goldberg, I 2012, 'Skypemorph: Protocol
obfuscation for tor bridges', Proceedings of the 2012 ACM conference on Computer and
communications security, ACM, pp. 97-108.
Rosenberg, J, Schulzrinne, H, Camarillo, G, Johnston, A, Peterson, J, Sparks, R, Handley, M & Schooler,
E 2002, SIP: Session Initiation Protocol, <https://tools.ietf.org/html/rfc3261>.
Rosenberg, J, Schulzrinne, H & Camarillo, G 2005, The Stream Control Transmission Protocol (SCTP) as
a Transport for the Session Initiation Protocol (SIP), <https://tools.ietf.org/html/rfc4168>.
Schrittwieser, S, Frühwirt, P, Kieseberg, P, Leithner, M, Mulazzani, M, Huber, M & Weippl, ER 2012,
'Guess Who's Texting You? Evaluating the Security of Smartphone Messaging Applications', NDSS.
VAG729,
<https://github.com/muggot/myphone3/tree/master/h323plus/plugins/audio/VoiceAgeG729/va_g7
29>.
Yang, H-K, Moon, J-K, Choi, C-R & Ryou, H-B 2014, 'User Access Control and Authentication System for
VoIP Service in Mobile Communication Environments', International Journal of Distributed Sensor
Networks, vol. 2014.
Zhang, D, Zheng, C, Zhang, H & Yu, H 2010, 'Identification and analysis of Skype peer-to-peer traffic',
Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, IEEE, pp.
200-206.
Zhang, R, Wang, X, Farley, R, Yang, X & Jiang, X 2009, 'On the feasibility of launching the man-in-themiddle attacks on VoIP from remote attackers', Proceedings of the 4th International Symposium on
Information, Computer, and Communications Security, ACM, pp. 61-69.
Zhang, R, Wang, X, Yang, X & Jiang, X 2010, 'On the billing vulnerabilities of SIP-based VoIP systems',
Computer Networks, vol. 54, no. 11, pp. 1837-1847.
Zhu, Y & Fu, H 2011, 'Traffic analysis attacks on Skype VoIP calls', Computer Communications, vol. 34,
no. 10, pp. 1202-1212.
Zimmermann, P & Johnston, A 2011, ZRTP: Media Path Key Agreement for Unicast Secure RTP,
<https://tools.ietf.org/html/rfc6189>.
Exploiting Cache Security weakness of lightweight browsers with
an adversary model
Shasi Pokharel, Kim-Kwang Raymond Choo, Jixue Liu
University of South Australia, Australia
poksc001@mymail.unisa.edu.au; Raymond.Choo@unisa.edu.au; Jixue.Liu@unisa.edu.au
Abstract
Lightweight browsers are gaining popularity among mobile device users because of their
faster resource loading capabilities. These browsers use client side efficiency measures like
larger cache storage and less plugins implementation. However implementation of such
measures in security of users' data in those browsers is not studied. In this paper, we propose
an adversary model to steal users' private data, handled and stored by four lightweight browsers
in Android device without users' knowledge. We are able to steal sensitive data including
browsers history, email content, bank account details etc. from these browsers' cache. We are
also successful to replace the images of cache in one browser making them to display as
legitimate website's content.
1. Introduction
Recent years have seen a rapid shift in internet traffic from personal computer (PC) to
mobile. People are increasingly browsing website from mobile device for shopping,
communicating and other purposes (The U.S. Mobile App Report 2014). As a result,
lightweight browsers on mobile devices have become more and more used.
Lightweight browsers are popular for their faster resource loading capabilities, especially
in large media files or gaming environments. However, in many cases, this speed comes as a
trade-off of reducing user functionalities and security mechanisms which are defined as basic
browser security requirements by W3C(Roessler & Saldhana 2010) and are implemented in
most of the popular 'browser suites' like Google Chrome and Mozilla Firefox (Amrutkar,
Traynor & van Oorschot 2015). For example, some lightweight browsers are not capable to
display the digital certificate and lack phishing URL filter (See table 1).
Browsers are security sensitive applications, because they access private information like
bank accounts, emails and personal accounts in various websites. These communication can be
vulnerable to exploitation in various stages of communication e.g., in client device applications
(browsers), in network transmission and in server application. Among them, network security
and server security have gained significant interest from researchers like Das and Samdaria
(2014), Desmet and Johns (2014), Virvilis et al. (2015). However, the security of browsers in
mobile device appears to be an understudied area. For example, the problem whether cache
and other files stored by browsers are secure (e.g., encrypted or stored with strict file
permission) from being accessed by unintended person or applications has not been well
studied.
In this paper, we attempt to evaluate the security of users' information, stored by browsers
in mobile device. Using an adversary model, we examine four popular lightweight browsers in
Android device and exploit their weakness. Our contributions are as follows.
a. Propose an adversary model to steal lightweight mobile browser's cache resources
b. Evaluate the security of cache storage of lightweight browsers
Next section analyses the background of browsers in reference to their file storage
mechanism and associated performance issue e.g., browsing speed. Related works on browser
security and exploitation of Android's file permission architecture are explained in section 3.
In section 4, we present our proposed adversary model. Experiment setup and exploitation
process is explained in section 5 and 6 respectively. Section 7 presents the findings of our
experiment and we discuss potential ideas to mitigate these security vulnerabilities in section
8. Section 9 contains the conclusion with potential research ideas in this field.
2. Background: Mobile Browsers
Browsing a web page requires loading multiple sets of resources e.g., HTML, CSS,
JavaScript and media files. According to Wang et al. (2011) loading of such resources can be
slower in mobile devices than in personal computers because of the architectural difference.
For example, many mobile devices run in smaller processing power and memory.
Speed is one of the most important user concerns when browsers are used. According to
the research form Aberdeen Group, 1 second delay in webpage loading can cause up to 11%
reduction in web views and 16% reduction in customer satisfaction (The performance of Web
Application 2008). Similar reports by Amazon (Linden 2006) and Google (Bustos 2012) also
supports view.
Lightweight browsers apply client side efficiency solutions to improve the browsing speed
of web pages. This includes creating larger cache storage and avoiding any plugins that can
cause delay in loading of web resources. Cache is the temporary storage to save downloaded
web resources. Next time if user attempts to access the same page or URL, browser checks
whether the content of those pages already exists in the cache. If the files are already there,
browsers can load the resources from the cache, saving time and network resources required
for downloading the pages.
Popular browsers, like Google Chrome, Mozilla Firefox, Opera etc. now use so called
standard Web Storage to store cache data. This method was introduced as a part of HTML5
and now is being standardized by World Wide Web Consortium (W3C). It contains two major
parts: Local Storage and Session Storage, which behave similarly to the persistent cookies and
session cookies respectively. Session storage stores web resources until the page is open. In the
case of Local Storage, generated cache still remains in the device even when the browser is
closed (Web Storage 2015).
In both desktop and mobile environment, Web Storage is considered secure than native
browser cache .According to W3C, such storage can be used to store sensitive user information
also(Web Storage 2015), if implemented properly. In Android, Web Storage is established in
internal storage, generally inside /data/data/PackageName/ directory. It means the items stored
in these cache storage cannot be accessed by other users or applications, except the owner
application.
However, web storage is limited by cache size. For general use, W3C recommends the use
of 5MB storage size per origin of website, but this can be much smaller when implemented in
mobile device. Lightweight browsers mostly rely on large cache storage to improve the
browser's loading speed. So they store large amount of cache data outside of Web Storage,
often in external storage.
In Android, internal storage is generally considered securer for application data, because,
by default, stored data can be accessed or modified by only the creator application. In
comparison, any resources, stored in external storage can be accessed, modified or deleted by
any applications that have READ_ EXTERNAL_STORAGE Permission.
3. Related Work:
Web security has been an attractive topic for researchers from many years. Browsers – both
in desktop and mobile devices share the same basic rule of loading web pages and
communicating with servers. So, many literatures on browser security are based on the desktop
browsers and focused on either network security or on detecting malicious websites(Du et al.
2014; Felt et al. 2014; Hanif et al. 2015; Hothersall-Thomas, Maffeis & Novakovic 2015; Tsalis
et al. 2015) .
In 2014, Wadkar, Mishra and Dixit proposed 'system call' monitoring approach to prevent
information leakage from the browser. System call is an interface between the browser
application and Operating System (Linux) kernel, which is invoked during the execution of
browser process. Authors proposed an intermediate layer between the Kernel and the
application layer that controls the system calls and filters the personal information being leaked
during the browsing (Wadkar, Mishra and Dixit 2014).
Virvilis et al. (2015) evaluated the effectiveness of Blacklist filtration approach of the
browsers, both in desktop and mobile devices, to protect users from visiting rouge or malicious
web pages. In another comprehensive study, Amrutkar et al. (2012) presented a new threat
model, in which architectural weakness of mobile device and browsers are exploited by an
adversary to steal information. Authors showed how the attack vectors like display ballooning,
Cross Site Request Forgery (CSRF) and clickjacking can be used for phishing or directly
stealing information from the users' device.
Recently, Amrutkar, Traynor and van Oorschot (2015) evaluated the security indicators
used in popular browsers in mobile (and tablet) devices. These indicators were based on the
security guidelines of W3C (Roessler & Saldhana 2010) and check the capabilities browsers to
protect users from malicious web pages. For example: whether the browser display the identity
of site owner and certificate issuer and whether it uses anti-phishing URL filter. Results of this
study in Google Chrome and Mozilla Firefox is presented in table 1.
Table 4: Implementation of Security indicators in mobile browsers
Browser Suites (Amrutkar, Traynor & van Oorschot 2015)
Browsers
Anti-Phishing Filter Display
of
providers identity
Google Chrome
Y
Y
Mozilla Firefox
Y
Y
Lightweight Browsers (Result from our evaluation)
Dolphin
N
Y
UC Browser
N
N
Samsung
Stock N
Y
Browser
Display of Certificate
Y
Y
Y
N
Y
Table 1 also shows the availability of security indicators in lightweight mobile browser, it
represents the result of our study on three lightweight browsers, using the similar standards and
methods, as used in Amrutkar, Traynor and van Oorschot (2015). We determined that Dolphin,
UC Browser and Samsung's stock browsers lack the implementation of basic security
mechanisms.
Previous studies have already identified that cache can be exploited as a tool of
attacking users privacy over browser communication (Bansal, Preibusch & Milic-Frayling
2015; Brumley 2015; Saraswat et al. 2014). In 2005, Bernstein presented an AES power attack
over Cache missed incidents in browser. In this method, adversary can identify the users web
browsing behaviours by calculating the content loading time (Bernstein 2005). Since then,
several solutions are proposed to mitigate the risk of this attack (Käsper & Schwabe 2009;
Könighofer 2008; Osvik, Shamir & Tromer 2006).
Most of these studies are focused on protecting the users' information when transmitting
over the network. In mobile device, browsers follow the similar user permission scheme, file
storage method and same network tools used by other applications. So these browsers inherit
the security issues, e.g., exploitation of user permission, file permission etc., which are already
associated with the mobile device. For example Hay (2011) showed how the security flaws of
Opera browser can be easily exploited by adversaries to steal the personal information of the
browser (Hay 2011). This study revealed that the file permission of Opera browser's cache
would allow unintended user to access the content in it. Since the publication of this report,
Opera has now solved this issue.
Recently, Liu et al. (2015) studied the unsafe data storage behaviours of Android
applications. Authors examined the data stored by communication apps like Weibo, Facebook,
Instagram, LINE, Skype, Viber etc. to see how much private data an adversary can steal from
the device without users' acknowledgement. This report suggests that security of users' private
data relies on the judgement of application developers, on how they define such data as
sensitive or insensitive. Among them, insensitive considered data is stored in shared memory
of external storage, leaving them accessible to other users. However such definition of
sensitiveness of data varies among different applications, in some cases, authors were able to
retrieve users' phone number, contact list and other private information from the public shared
files.
So, study of mobile browsers security should cover multiple areas, i.e., security of
communication, security of application and security of stored data/cache. However in many
cases, mobile browsers are studied in conjugation of desktop browser, applying same methods
to evaluate the security measures of desktop and mobile browsers. Recently Jia et al. (2015a)
evaluated the security strength of five desktop and fifteen mobile browsers cache to determine
whether they are vulnerable of Browser Cache Poisoning (BCP) over Man in The Middle
(MITM) attack. Authors concluded that over 99% of desktop browsers and most of the mobile
browsers are vulnerable to such attack. Jia et al. (2015b) presented an approach to identify the
users' geo location i.e., country, city and neighbourhood by sniffing on the browser cache and
by measuring the timing of browser cache queries. In another study Liang et al. (2014)
presented an approach to sniff users browsing history by implementing timing attack over
browser cache.
4. Proposed Adversary Model:
In this section we briefly review some adversary models proposed to study the security
of mobile device and explain our proposed model.
In a recent literature, Liu et al. (2015) evaluated the applications behaviour of storing
private data in Android device. Using adversary model, authors installed an application with
EXTERNAL_STORAGE_WRITE, EXTERNAL_STORAGE_READ and INTERNET
permission to steal the files stored in public storage. Another research used adversary model to
steal the data and send it via browser using URI ACTION_VIEW intent (Zhou, X et al. 2013).
However, this method, named as, zero permission adversary model and can transmit data only
when the phone screen is on or is running.
Do, Martini and Choo (2015) proposed the first adversary model for Android covert
data exfiltration. In this model, adversary had the capabilities of intercepting, injecting,
modifying, deleting, encrypting/decrypting, transmitting and listening to the communication.
With the influence of this model, D'Orazio & Choo (2015) presented an adversary model,
capable of capturing real-world capability of Digital Rights Management (DRM) attacker in
iOS devices. In this paper, we modify the model presented by D'Orazio and Choo and by
reducing the required capabilities of adversary to exploit the weakness of lightweight browser
in Android device.
Our adversary model contains an Android application equipped with the capability to
read files and write files in device's external shared memory. To obtain this capability, our
adversary
application
will
use
READ_
EXTERNAL_STORAGE
and
WRITE_EXTERNAL_STORAGE user permissions. Among these permissions, READ_
EXTERNAL_STORAGE permission is granted automatically if the application has obtained
WRITE_EXTERNAL_STORAGE Permission. To transmit the stolen data from user device to
the adversary's server this application will require INTERNET permission also. However,
Android applications don’t need to notify or ask for users' approval to use this permission
because Android provides this permission to all the applications, if declared in manifest file.
Another permission that our adversary application require is ACCESS_NETWORK_STATE,
which allows to know what type of network the device is connected to e.g., Wi-Fi or 3G/4G .
So, our adversary application will require user's approval for only two permissions –
WRITE_EXTERNAL_STORAGE and ACCESS_NETWORK_STATE.
One of the major challenges of our adversary application is avoiding the suspicion from
users and malware filters. Many malware filter algorithms are based on the evaluation of user
permission (Adebayo & Aziz 2015; Aung & Zaw 2013; Talha, Alper & Aydin 2015) and
activity behaviour. These algorithms consider an application as suspicious if it acquires too
many permissions or permissions for cost incurring user activities like sending message,
making calls etc. (Burguera, Zurutuza & Nadjm-Tehrani 2011; Isohara, Takemori & Kubota
2011; Zhou, Y & Jiang 2012). Because our application uses only few and mostly used user
permissions, it can easily avoid the scrutiny of malware filters.
Excessive drainage of battery or high consumption of network bandwidth are reasons
that raise user's suspicion. To avoid the use of excessive battery power, our adversary
application will use Android's in-built listener functions only. Similarly, to avoid the suspicion
over bandwidth usage, our adversary application will upload users' information to the adversary
server, only when user is connected to the Wi-Fi network. If the user is browsing web pages in
3G/4G data, our application will copy the browser's cache data to application's private folder
and wait for the user to be connected to the Wi-Fi. Detail implementation of attack process is
explained in section 6.
Goals:
Our adversary model aims to steal the contents from browser cache from Android device
without users' knowledge. Following are the goals of our model that we aim to achieve by using
our adversary application. We will consider that any mobile browser is insecure if any of these
goals are met.
Goal 1: The adversary learns the URL history of the browser, without user’s knowledge
Goal 2: The adversary learns the terms searched by users in browser
Goal 3: The adversary learns the content of the webpage e.g., users email content, bank account
information without users' knowledge
Goal 4: The adversary can change the content (image file) in the cache
5. Experiment Setup
Data from Google play statistics show that Google Chrome, Mozilla Firefox and UC
browsers are the most popular browser applications in Android. Among them, Chrome and
Firefox are considered as browser suites, which contain cross-platform browsing compatibility
and implementation of various security measures. However, previous researches have shown
that some of these lightweight browsers are better than the large browser suites in resources
loading speed (Chris 2015), especially while loading large media files and gaming
environments.
For this study, we have selected three most popular lightweight browsers for Android:
Dolphin, CM Browser and UC Browser (Based on Google Play Downloads: up to September
2015). To cover the diversity of experiment, we have included Samsung's stock browser
(package name: com.sec.android.app.sbrowser) also, pre-installed in Samsung Galaxy S4 with
Android version 4.4.2.
Table 5: Selected Lightweight Browsers
S.No.
Browser Name
Version No.
1.
2.
3.
4.
UC Browser
Dolphin
CM Browser
Samsung Stock
Browser
V10.6.2
V11.4.19
5.20.06
N/A
Downloads
Google Play
millions (on …)
100-500
50-100
10-50
N/A
in Remarks
in
Pre-installed with Samsung
mobiles, so total user
number and application
version cannot be identified.
Table 1 shows the information about selected browser applications. We now briefly
explain the cache storage behaviour of selected browser applications.
UC browser is one of the most popular browser in Android with more than 100 million
downloads. File inspection in Android device shows that UC browser stores a large portion of
Cache files in external shared memory, including HTML files of visited web pages, JavaScript,
CSS, image files and range of databases filled with users browsing activity. These databases
not only reveal the information about which webpages were browsed by the user, but also
shows the number of times the pages were accessed, the times when they were accessed and
what was the response from the server every time. It also reveals how much data (bandwidth)
was used while accessing those pages individually.
Table 6: Targeted cache and file storage locations of the browsers
Browser
Dolphin
Targeted Cache Location
/sdcard/TunnyBrowser/cache/speeddial_covers
/sdcard/TunnyBrowser/cache/tablist_cache
/sdcard/TunnyBrowser/cache/webViewCache
/sdcard/CheetahBrowser/.data/
Important Contents
URLS saved as speed dial
screenshot images
All cache files (HTML, CSS,
JavaScript, media)
All cache files
TrafficStatus.db; contains client
server communication timing
and response
ApplicationCache.db; contains
data
for
cache
loading
management
Browsers URL history
UC
Browser
/sdcard/UCDownloads/cache/
/sdcard/UCDownloads/config/
/data/data/com.sec.android.app.sbrowser/files/
Screenshots image file
/sdcard/UCDownloads/offline/
CM
Browser
Samsung
Stock
Browser
Dolphin browser is one of the oldest lightweight browser introduced for Android.
Inspection of its cache storage shows that Dolphin browser stores most of the cache resources
in external shared memory in /sdcard/TunnyBrowser/cache/ directory.
It has three sub-directories - named: speeddial_covers, tablist_cache and
webviewCache. speed dial refers to the option for users to save their favourite or mostly used
URLs on the browser’s front screen thumbnails. Speeddial_covers directory stores the URL
and associated files of those websites.
We found that Dolphin stores the screenshots of the displayed web content, when user
browses more than one tab at a time. These screenshots are used to display as the preview of
currently running web pages in each browser tabs when user attempts to change those tabs. For
this purpose, each of these screenshots are recreated every time when displayed content of
every tab is changed. In Dolphin, each screenshot is around the size of 50 KB and saved in
tablist_cache directory. All other cache files including HTML, JavaScript, CSS and media files
are stored in webViewCache directory.
CM browser is a subsidiary application of the same company, which owns the mobile
security and antivirus application- clean master. File inspection in Android device shows that
CM browser stores most of the cache files safely in internal memory. We could see the
implementation of Local Storage inside app_webview directory, similar to the standard cache
storage proposed in HTML5. However it stores the list of visited URLs in a file stored in shared
memory.
In the case of Samsung stock browser, it stores all the cache files, including HTML,
JavaScript and media files in internal storage. Similar to the Dolphin browser, it also saves the
screenshots bitmap file each time new content is loaded in the browser. This bitmap might be
used to display the preview of running applications when user accesses the fast app switcher
key in device or when user attempts to change the tabs in browser.
By default, files stored in internal memory are considered private and are only
accessible by the owner application. However this permission can be changed by the creator
application,
by
using
MODE_APPEND,
MODE_WORLD_READABLE
or
MODE_WORLD_WRITABLE flags when creating such file. This behaviour is considered as
'Serious Security flaw' by Android and deprecated from Android API level 17 but this issue
still exist with the Samsung's stock browser. Our investigation shows that the screenshot image
stored by the Samsung stock browser in its cache is assigned with chmod 644 (rw-r--r--) user
permission, which means it can be accessed by any other applications.
To implement our adversary model we used Samsung Galaxy S4 (unrooted) with
Android 4.4.2 version. Proposed adversary’s application, as described in next section is
installed in this device and its attack function will run as background process all the time. To
test the result more effectively, each browser is run for at least five minutes, opening multiple
URLs in multiple tabs. The adversary application run in both network environment: Wi-Fi and
4G network.
6. Exploitation Process
Using the adversary model we now construct an exploitation process targeting Android
lightweight browsers. As explained in section 4, our adversary has the capability of installing
application in Android device. This application is capable of copying files from public shared
external storage, storing data in internal and external storage and accessing internet for data
transmission. In this section we discuss the processes for each of these acts in detail.
Activity 1: Know when browser starts running:
Android provides multiple methods to return current running application. One of the
effective method was to create broadcast receiver for targeted browser application using
ActivityManager.getRunningAppProcess(), but this feature has been deprecated by Android
since version 21. So we will use Android's native fileObserver feature, which notifies the
application when some changes in target file or directory occurs. FileObserver uses inotify
subsystem of kernel which extends the fileSystems to fire notifications when given directory
is accessed by the browser.
Activity 2: Copying cache files:
Since the Android doesn’t have “cp” command, we will use the native inputstream and
outputstream to copy the files from browser's cache directory. Copied files will be stored in
adversary application’s cache directory to avoid the user’s suspicion over the copied files. To
minimise the use of resources, we will set the maximum size of adversary application's cache
directory as 5MB so, the system will delete the older files when this limit exceeds. This may
create a problem if the user keeps browsing the websites in 3G/4G network for long time, which
will cause the files to be lost before being uploaded to the server. However this is the risk we
propose to take, to avoid suspicion from user over their bandwidth usage.
Adversary application will use the following code to copy all the files from browser’s
cache to application’s cache directory.
Step 1: List the cache files to copy
File applicationCache=this.getCacheDir();
File browserCache = new File(Environment.getExternalStorage().getAbsolutePath()
+"/cacheDirectoryName");
String[] fileName = browserCache.list();
for (int i = 0; i < browserCache.listFiles().length; i++) {
copyFiles(new File(browserCache, fileName[i]),
new File(applicationCache, fileName[i]));
}
Step 2: Copy files to the application cache:
copyFiles(File source, File dest){
InputStream toCopyFile = new FileInputStream(source);
OutputStream copiedFile = new FileOutputStream(dest);
byte[] buff = new byte[1024];
int leng;
while ((leng = toCopyFile.read(buff)) > 0) {
copiedFile.write(buff, 0, leng);
}
toCopyFile.close();
copiedFile.close();
}
These functions creates a cache directory for adversary application in internal memory
and copy all files from the targeted browser's cache storage to the cache memory. To improve
the efficiency of the application and avoid copying same file multiple times, we can implement
'file already exist' check.
Activity 3: Checking network connection and file transfer
Uploading cache files frequently from client device can cause large amount of network
bandwidth usage. It can incur cost and unnecessary suspicion to the user, especially if the
network used is limited to a data plan subscribed from telephone network provider. To avoid
it, our application will check whether the connection is Wi-Fi or not.
ConnectivityManager manager = (ConnectivityManager)
getSystemService(CONNECTIVITY_SERVICE);
NetworkInfo wifiConn =
connManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI);
return wifiConn.isAvailable();
This code returns whether the connection is Wi-Fi. If the return value is false, copied
data will be stored into private storage of our application. We will create a broadcast receiver
to listen to the change of network state, so as soon as the Wi-Fi connection is established, stored
files will be uploaded to the server.
Uploading files to the server can be a lengthy and resource consuming process. Because
our application runs as a service in the background, we will use ‘asyncTask’ for uploading the
files. Application will loop multiple times to upload the files and each files, when the upload
is completed, will be deleted from. Figure 1 shows the activity flowchart of the adversary
application.
FileObserverListener
()
Check if Browser is
installed
FileAccessed
Event
Wi_Fi
Connected?
Copy to Application's
Private Directory
WiFiConnectionListener
()
Upload to the Server
WiFiConnected
Event
Figure 5: Flowchart of the attack procedure
Activity 4: Insert Malicious Image in Cache/Cache Poisoning
As the application has WRITE_EXTERNAL PERMISSION, we can insert our image
to the cache directory of the browser. Whether the browser will load inserted file depends on
many conditions like expiry time, type of cache file, frequency of users' access to the associated
URL etc. So, inserted content may not be loaded. However our application will use following
steps to insert the content.
Step 1: Check if the cache file is image:
BitmapFactory.Options imageOptions = new BitmapFactory.Options();
imageOptions.inJustDecodeBounds = true;
BitmapFactory.decodeFile(file.getPath(), imageOptions);
if(options.outWidth != -1 && options.outHeight != -1)
return true;
Step 2: Replace the image file:
byte[] buff = new byte[1024];
int leng;
while ((leng = new FileInputStream(toBeCopied).read(buff)) > 0) {
toBeReplaced.write(buff, 0, leng);
}
toBeCopied.close();
toBeReplaced.close();
7. Findings
In this section, we describe the result from our experiment for each browsers
Dolphin:
For Dolphin, we assigned the root directory of cache storage
(/sdcard/TunnyBrowser/Cache) in fileObserver() function to listen when the browser is started
by the user. We were successful to copy all the files inside this directory and its subdirectories
and upload them into the adversary's database.
By checking the uploaded files in server, we were able to retrieve the URL history of
the browser, view the content (including media files) of the webpage, accessed by the user. In
many cases, we were able to retrieve the private content of web page e.g., image and wall post
of users Facebook page, by accessing the link in HTML file. Uploaded screenshot images
revealed email content, bank account details and other sensitive user information.
We also found that Dolphin saves the cache images without making any changes to the
header. Generally, when users attempt to access the same URL, browser checks with the server
cache to determine whether stored cache has been modified. However in this case, Dolphin
was unable to recognize the changes in cache. For our experiment, we browsed the home page
amazon (https://www.amazon.com/) and found that all the product images are stored in cache.
Then we replaced few of those files with our images files, with same name, and browsed the
same page for second time. In the second time browsing, we were successful to see our image
loaded as a content of amazon website instead of the legitimate image. The browsing time
difference between first time browsing and second time browsing was less than 2 minutes.
UC Browser:
In UC browser, we were successful to copy and upload all the data stored inside the
cache root directory (/sdcard/UCDownloads). Although we weren't able to identify the
screenshots as in Dolphin and Samsung Stock browser, we were successful to map the in depth
web browsing history and behaviour of the user, based on other cache files and databases. This
includes which web page is accessed, at what time and how many times the site was accessed.
In many cases we were able to retrieve the content of the accessed web page also.
Unlike in Dolphin, changing content in cache was not successful. We found that UC
browser make changes to the file header while storing in the cache. This may be the reason,
when the content of cache was changed, browser downloaded the files from server, instead of
loading from the cache.
Samsung Stock Browser:
As explained in Section 5 Samsung Stock browser stores all its cache resources in
internal storage of the device. However we were successful to copy and upload the screenshot
images from the device, every time new content is loaded in the browser. Those images could
reveal users all browsing activity and content of the visited pages, including email contents,
bank account details. Because the file is stored in chmod 644 permission, we were not able to
make any changes in the content.
CM Browser:
Although considered as Lightweight browser, CM browser leaves very little
information to our proposed adversary, when compared to other three browsers. It stores all
cache files, including screenshot for the multi-tabs navigation, database, HTML files and media
files inside the internal storage, with private mode. Only information it leaves open is the list
of URLs visited by the user. In a single file stored inside the /sdcard/CheeahBrowser/.data/ it
updates the URLs as user visits them.
Table 4 shows the result of our adversary model in reference to the goals, as explained in
section 4.
Table 7: Result of the experiment
Browsers
1
2
3
4
Dolphin Browser
CM Browser
UC Browser
Samsung Stock Browser
Goal1:
Browser
history
Goal:
Searched
Terms
√
√
√
√
√
√
Goals
Extract
(knowledge)
of
web
content
√
Change
content
Cache
of
√
√
√
8. Discussion
Our study exploits the security weakness of lightweight browsers based on their cache
storage location and file permission issues. Out of four browsers we studied, three (Dolphin,
CM browser and UC browser) store sensitive user information in external shared storage.
Samsung stock browser stores such files in internal memory but implements weak file
permission that can allow other users or applications to access them.
In individual application's level, this security flaw is the result of improper file storage
behaviour of the browser. However, it also raises the issues on Android's file storage and file
permission behaviour that allows unintended users to access files created by other applications.
For browsers, loading content from internal memory is faster (Kim, Agrawal & Ungureanu
2011) and secure than loading from external storage, but many browsers still select external
memory due to the size availability. So, simply suggesting browsers to store their files in
internal memory cannot solve this problem, unless the issue of file permission is solved in
operating system level (Liu et al. 2015; Wu & Chang 2011). As a temporary solution, browsers
can choose to store only large media files in external storage, but after notifying the user that
these files may be accessed by other applications.
9. Conclusion
In this study, we exploited the security weakness of popular lightweight mobile browsers
in Android and showed how an adversary can steal users' personal information and alter the
cache files with malicious content. We proposed an adversary model with the capabilities of
installing an application in users' device. We were successful to steal users browsing history in
all four browsers and contents of the browsed websites from Dolphin, UC Browser and
Samsung Stock browser. Our adversary model was successful to change the cache files and
load malicious contents also in Dolphin browser.
This determines that users of lightweight browsers in Android are in risk of losing their private
information to the attackers. Future work includes identifying the solutions for secure file
storage and file permission solutions both in application level and operating system level.
References:
Adebayo, OS & Aziz, NA 2015, 'Static Code Analysis of Permission-based Features for
Android Malware Classification Using Apriori Algorithm with Particle Swarm Optimization',
Journal of Information Assurance & Security, vol. 10, no. 4.
Amrutkar, C, Singh, K, Verma, A & Traynor, P 2012, 'VulnerableMe: Measuring systemic
weaknesses in mobile browser security', Information Systems Security, Springer, pp. 16-34.
Amrutkar, C, Traynor, P & van Oorschot, PC 2015, 'An empirical evaluation of security
indicators in mobile Web browsers', Mobile Computing, IEEE Transactions on, vol. 14, no. 5,
pp. 889-903.
Aung, Z & Zaw, W 2013, 'Permission-based Android malware detection', International
Journal of Scientific and Technology Research, vol. 2, no. 3, pp. 228-234.
Bansal, C, Preibusch, S & Milic-Frayling, N 2015, 'Cache Timing Attacks Revisited: Efficient
and Repeatable Browser History, OS and Network Sniffing', ICT Systems Security and Privacy
Protection, Springer, pp. 97-111.
Bernstein, DJ 2005, Cache-timing attacks on AES.
Brumley, BB 2015, 'Cache Storage Attacks', Topics in Cryptology–-CT-RSA 2015, Springer,
pp. 22-34.
Burguera, I, Zurutuza, U & Nadjm-Tehrani, S 2011, 'Crowdroid: behavior-based malware
detection system for android', Proceedings of the 1st ACM workshop on Security and privacy
in smartphones and mobile devices, ACM, pp. 15-26.
Bustos, L 2012, Speed Kills Conversion Rates, <http://www.getelastic.com/site-speedinfographic/>.
Chris, P 2015, Best Android browsers, 2015 edition: speed, features, and design, updated 8
April
2015,
phonearena.com,
viewed
12
September
2015,
<http://www.phonearena.com/news/Best-Android-browsers-2015-edition-design-featuresand-performance_id67848>.
D'Orazio, C & Choo, K-KR 2015, 'An adversary model to evaluate DRM protection of video
contents on iOS devices', Computers & Security.
Das, ML & Samdaria, N 2014, 'On the security of SSL/TLS-enabled applications', Applied
Computing and Informatics, vol. 10, no. 1, pp. 68-81.
Desmet, L & Johns, M 2014, 'Real-time communications security on the web', Internet
Computing, IEEE, vol. 18, no. 6, pp. 8-10.
Do, Q, Martini, B & Choo, K-KR 2015, 'Exfiltrating data from Android devices', Computers
& Security, vol. 48, pp. 74-91.
Du, W, Yang, L, Kizza, J & Yuan, X 2014, 'New hands-on labs on browser security',
Proceedings of the 45th ACM technical symposium on Computer science education, ACM, pp.
717-717.
Felt, AP, Reeder, RW, Almuhimedi, H & Consolvo, S 2014, 'Experimenting at scale with
google chrome's SSL warning', Proceedings of the 32nd annual ACM conference on Human
factors in computing systems, ACM, pp. 2667-2670.
Hanif, M, Vighio, MS, Hussain, Z & Memon, NA 2015, 'Comparative Study of Top-Ranked
Web Browsers', Bahria University Journal of Information & Communication Technology, vol.
8, no. 1, p. 93.
Hay, R 2011, Opera Mobile Cache Poisoning XAS, September.
Hothersall-Thomas, C, Maffeis, S & Novakovic, C 2015, 'BrowserAudit: automated testing of
browser security features', Proceedings of the 2015 International Symposium on Software
Testing and Analysis, ACM, pp. 37-47.
Isohara, T, Takemori, K & Kubota, A 2011, 'Kernel-based behavior analysis for android
malware detection',
Computational Intelligence and Security (CIS), 2011 Seventh
International Conference on, IEEE, pp. 1011-1015.
Jia, Y, Chen, Y, Dong, X, Saxena, P, Mao, J & Liang, Z 2015a, 'Man-in-the-browser-cache:
Persisting HTTPS attacks via browser cache poisoning', Computers & Security, vol. 55, pp.
62-80.
Jia, Y, Dong, X, Liang, Z & Saxena, P 2015b, 'I know where you've been: Geo-inference
attacks via the browser cache', Internet Computing, IEEE, vol. 19, no. 1, pp. 44-53.
Käsper, E & Schwabe, P 2009, 'Faster and timing-attack resistant AES-GCM', Cryptographic
Hardware and Embedded Systems-CHES 2009, Springer, pp. 1-17.
Kim, H, Agrawal, N & Ungureanu, C 2011, 'Examining storage performance on mobile
devices', Proceedings of the 3rd ACM SOSP Workshop on Networking, Systems, and
Applications on Mobile Handhelds, ACM, p. 6.
Könighofer, R 2008, 'A fast and cache-timing resistant implementation of the AES', Topics in
Cryptology–CT-RSA 2008, Springer, pp. 187-202.
Liang, B, You, W, Liu, L, Shi, W & Heiderich, M 2014, 'Scriptless timing attacks on web
browser privacy', Dependable Systems and Networks (DSN), 2014 44th Annual IEEE/IFIP
International Conference on, IEEE, pp. 112-123.
Linden, G 2006, Make data useful.
Liu, X, Zhou, Z, Diao, W, Li, Z & Zhang, K 2015, 'An Empirical Study on Android for Saving
Non-shared Data on Public Storage', ICT Systems Security and Privacy Protection, Springer,
pp. 542-556.
Osvik, DA, Shamir, A & Tromer, E 2006, 'Cache attacks and countermeasures: the case of
AES', Topics in Cryptology–CT-RSA 2006, Springer, pp. 1-20.
The
performance
of
Web
Application
2008,
Aberdeen
<http://v1.aberdeen.com/launch/report/research_report/5136-RR-performance-webapplication.asp>.
Group.
Roessler, T & Saldhana, A 2010, Web Security Context: User Interface Guidelines,
<http://www.w3.org/TR/wsc-ui/>.
Saraswat, V, Feldman, D, Kune, DF & Das, S 2014, 'Remote cache-timing attacks against
AES', Proceedings of the First Workshop on Cryptography and Security in Computing
Systems, ACM, pp. 45-48.
Talha, KA, Alper, DI & Aydin, C 2015, 'APK Auditor: Permission-based Android malware
detection system', Digital Investigation, vol. 13, pp. 1-14.
Tsalis, N, Virvilis, N, Mylonas, A, Apostolopoulos, T & Gritzalis, D 2015, Browser Blacklists:
A utopia of phishing protection, Springer.
The U.S. Mobile App Report 2014, ComScore.
Virvilis, N, Mylonas, A, Tsalis, N & Gritzalis, D 2015, 'Security Busters: Web browser security
vs. rogue sites', Computers & Security, vol. 52, pp. 90-105.
Wadkar, H, Mishra, A & Dixit, A 2014, 'Prevention of information leakages in a web browser
by monitoring system calls', Advance Computing Conference (IACC), 2014 IEEE
International, IEEE, pp. 199-204.
Wang, Z, Lin, FX, Zhong, L & Chishtie, M 2011, 'Why are web browsers slow on
smartphones?', Proceedings of the 12th Workshop on Mobile Computing Systems and
Applications, ACM, pp. 91-96.
Web Storage 2015, W3C.
Wu, D & Chang, RK 2011, 'Indirect File Leaks in Mobile Applications'.
Zhou, X, Demetriou, S, He, D, Naveed, M, Pan, X, Wang, X, Gunter, CA & Nahrstedt, K 2013,
'Identity, location, disease and more: Inferring your secrets from android public resources',
Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security,
ACM, pp. 1017-1028.
Zhou, Y & Jiang, X 2012, 'Dissecting android malware: Characterization and evolution',
Security and Privacy (SP), 2012 IEEE Symposium on, IEEE, pp. 95-109.
Conclusion
It is determined from this study that communication applications e.g., VoIP apps and
Lightweight mobile browser in Android devices are significantly weak in protecting the private
information of their users. Voice communications through many VoIP applications can be
decoded back into the original spoken voice if intercepted in the network. Similarly, many
lightweight browsers have failed to secure their cache storage, which means attackers can
easily steal users private information, such as bank details, email contents etc. without users'
knowledge. Strong security measures should be applied in both; operating system level and
individual application level as soon as possible. Development of efficient but strong security
measures to overcome these weaknesses can be further area of research.
References
Kaspersky Security Bulletin 2014, Kaspersky Lab Global Research and Analysis Team.
<http://media.kaspersky.com/pdf/ksb_2013_en.pdf>.
Smartphone Vendor Market Share, 2015 Q2 2015, IDC, <http://www.idc.com/prodserv/smartphonemarket-share.jsp>.