Apr 30, 2013 ... them into the visor of spyware and fraudware. In the real world, malware can ......
attributed to strong Galaxy S3 sales. Traffic from iOS devices ...
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
SEVENTH FRAMEWORK PROGRAMME Trustworthy ICT Project Title:
Enhanced Network Security for Seamless Service Provisioning in the Smart Mobile Ecosystem
NEMESYS Grant Agreement No: 317888, Specific Targeted Research Project (STREP)
DELIVERABLE D1.1: State-of-the-Art for security threats and attacks against mobile devices & analysis of current practices Deliverable No. Workpackage No. Task No.
D1.1 WP1
Workpackage Requirements / Specification / Architecture Title (RTD)
T1.1
Benchmarking of current practices and State-of-the-Art for security threats and attacks against mobile devices
Task Title
Lead Beneficiary
TI
Dissemination Level
PU
Nature of Deliverable
R
Delivery Date
30 April 2013
Status
F: Final
File Name
NEMESYS_Deliverable_D1.1.doc
Project Start Date
01 November 2012
Project Duration
36 Months
April 2013
1
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Authors List Author’s Name
Partner
E-mail Address
TI IT
[email protected]
Rosalia D’Alessandro
TI IT
[email protected]
Roberta D’Amico
TI IT
[email protected]
Laurent Delosieres
HISPASEC
[email protected]
David Garcìa
HISPASEC
[email protected]
Konstantinos Filis
COSMOTE
[email protected]
Eftychia Nikolitsa
COSMOTE
[email protected]
Helen Theodoropoulou
COSMOTE
[email protected]
George Lyberopoulos
COSMOTE
[email protected]
Reviewer’s Name
Partner
E-mail Address
Ioannis Bekoulis
CERTH-ITI
[email protected]
Stavros Papadopoulos
CERTH-ITI
[email protected]
Boris Oklander
ICL
[email protected]
Gokce Gorbil
ICL
[email protected]
Leading Author / Editor Madalina Baltatu Co-Authors
Reviewers List
April 2013
2
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Abstract Nowadays smart mobile devices are ubiquitous, they are used for personal mobile communications, data storage, multimedia and entertainment, and therefore are becoming the fulcrum of billions of users’ digital lives. Their usage has grown by 60% in the last year in the United States, and similar trends are observed worldwide, where the number of smartphones in use has now broken the 1 billion mark. With the ITU (the International Telecommunication Union) estimating global mobile subscriptions at 6 billion at the end of 2011, it is calculated that global smartphone penetration is now 16.7%. Even if it has taken 16 years for smartphone penetration to reach 1 billion, it is estimated that it will only take three years to achieve the next billion. As far as the mobile OSes distribution is concerned, Android and Apple iOS combined account for the significant majority of the global smartphone installed base in 2012. Smartphones are often used to read enterprise email and documents, find local businesses, get deals on products, buy them and click on mobile ads. It is, therefore, evident that a possible compromise of banking and PayPal mobile applications, social networking and email accounts, wireless LAN and VPN applications by cybercriminals not only puts in jeopardy personal privacy, but can also threaten an important financial loss. Economic fraud often goes hand-in-hand with identity-related crime, and the spread of information and communication technologies augments the problem. It is obvious that the increasing popularity of smartphones and other mobile devices has moved them into the visor of spyware and fraudware. In the real world, malware can reach the mobile device by any means: via Bluetooth, SMS and MMS messaging, e-mail, Internet access, and is installed either by taking advantage of the vulnerabilities found on mobile devices, or with the user’s full consent (e.g., social engineering and phishing). In order to advance in the field of cyber security and counter and prevent mobile cyber-attacks, security techniques should become proactive and provide a defence before new threats materialize. Mobile security solutions, like antiviruses installed on mobile devices, are not enough for this ambitious purpose. Instead, there is an urgent need for an infrastructure able to collect attack traces against mobile devices, detect, analyse and understand the attack strategies and build appropriate countermeasures. Such an infrastructure, which will be based on the mobile honeypots deployment, will allow for the provisioning of secure and seamless mobile protection services. While there is a lot of experience in building honeypots for wire line networks, honeypots’ deployment in the mobile ecosystem is not a minor task. The majority of conventional honeypot types is mostly instrumented for the detection of undirected, widely spread attacks. Mobile malware usually perpetrate targeted attacks, hence the conventional honeypots are not fully appropriate in the mobile ecosystem. On the other hand, as mobile networks are becoming mainly data networks, moving to flatter and more open architectures (e.g., the IP-based LTE architecture), and the April 2013
3
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
traffic is growing exponentially, the mobile networks are becoming more vulnerable to security threats. While in 3G networks the traffic is encrypted from the mobile device through the NodeB and all the way to the RNC (thus both RAN and backhaul are protected), basically in LTE networks mandated encryption from the mobile device stops at the eNB, leaving the IP traffic in the backhaul unprotected. The current attacks and security practices in mobile security are presented from both the device and the core network perspectives, since the aim of NEMESYS is to build the primary tools in order to provide an infrastructure that can offer protection to all network elements. Towards this end, a thorough look at the state of the art in mobile malware and commonly adopted protection mechanisms is provided, in order to be able to propose and implement an architecture and a strategy that will allow the mobile network operators to deliver early warning of attacks on their customers’ mobile devices and their core mobile network.
April 2013
4
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Table of Contents Authors List .................................................................................................................... 2 Reviewers List ................................................................................................................ 2 Abstract .......................................................................................................................... 3 Table of Contents ........................................................................................................... 5 List of Figures ................................................................................................................. 6 List of Tables .................................................................................................................. 7 Abbreviations ................................................................................................................. 8 1 Introduction ......................................................................................................... 14 2 The Growth of the Mobile Market Worldwide .................................................... 15 2.1 Statistics & Forecasts..................................................................................... 15 2.2 Top Activities of Mobile Users ...................................................................... 16 2.3 Market penetration of mobile OSes ............................................................. 17 2.4 Statistics in the mobile network of Telecom Italia ........................................ 19 3 Mobile malware ................................................................................................... 21 3.1 A look at the real world ................................................................................. 21 3.2 Mobile malware taxonomy ........................................................................... 27 3.2.1 Mobile malware taxonomy in practice .................................................. 28 3.2.2 Infection vector-based taxonomy .......................................................... 32 3.2.3 Behaviour-based taxonomy ................................................................... 33 3.2.4 Malware typologies ............................................................................... 34 4 Current practices in mobile security .................................................................... 35 4.1 Device side security ....................................................................................... 36 4.2 Network side security.................................................................................... 38 4.2.1 3G Network Security .............................................................................. 42 4.2.2 LTE Network Security ............................................................................. 49 4.3 Vulnerabilities and attacks to 3G and 4G networks ...................................... 56 4.3.1 RACH Flood ............................................................................................ 56 4.3.2 SMS Flood .............................................................................................. 59 4.3.3 FakeBTS and Jamming............................................................................ 59 4.3.4 Signaling DoS .......................................................................................... 60 4.4 Femtocell security ......................................................................................... 64 4.4.1 FAP Physical Security ............................................................................. 66 4.4.2 FAP and CN Mutual Authentication and IPsec Tunnel Establishment ... 67 4.4.3 Location Verification .............................................................................. 68 4.4.4 Access Control ........................................................................................ 69 4.4.5 Protection of FMS traffic between FMS and FAP .................................. 69 4.4.6 Measures for Clock Protection .............................................................. 70 April 2013
5
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
4.5 State of the art in Attack traces collection.................................................... 70 4.5.1 Passive collection ................................................................................... 70 4.5.2 Active collection ..................................................................................... 71 5 NEMESYS Advances.............................................................................................. 73 6 Conclusions .......................................................................................................... 75 References ................................................................................................................... 77
List of Figures Figure 1: Worldwide mobile subscriptions evolution. ................................................. 15 Figure 2: Regional contribution to worldwide data traffic. ......................................... 17 Figure 3: The mobile market: the shares of the main mobile OSes 2011. .................. 18 Figure 4: The mobile market: the shares of the main mobile OSes 2012 (the first two quarters)....................................................................................................................... 18 Figure 5 Top smartphone OSes during 2012 and the first half of 2013. ..................... 18 Figure 6: Distribution of phones’ OSes in TI mobile network (from 1 day traffic, 1 st half of 2012). ................................................................................................................ 19 Figure 7: Distribution of data traffic per OS in TI mobile network (from 1 day observations, 1st half of 2012). .................................................................................... 19 Figure 8: From McAfee’s 2012 threat report: Mobile malware volume evolution. .... 21 Figure 9: New mobile threats families and variants received by F-Secure Labs per quarter during the two-year period 2011- 2012. ........................................................ 22 Figure 10: New malware distribution per OS in 2011 (McAfee data). ........................ 23 Figure 11: New malware distribution per OS in 2012, Q1 to Q3 (McAfee data). ........ 23 Figure 12: Android is the most affected platform by mobile malware (Kaspersky data). ............................................................................................................................ 24 Figure 13: HOTforSecurity: Android malware spread worldwide in August 2012. ..... 24 Figure 14: Risk scores distribution for market and malware apps. ............................. 25 Figure 15: Average risk scores for each risk category for market and malware apps. 26 Figure 16: Most encountered shell commands in apps from the market. .................. 26 Figure 17: Most encountered shell commands in Android malware. ......................... 27 Figure 18: Malware distribution during 2012 (source: F-Secure)................................ 30 Figure 19: Malware distribution during 2012 (Source: Kaspersky). ............................ 31 Figure 20: Malware detection capabilities of Google application verification system (University of North Carolina). ..................................................................................... 38 Figure 21: Security exposures in the 3G and 4G (LTE) networks [35]. ........................ 39 Figure 22: 3G network based on Release 99 [36]. ....................................................... 42 Figure 23: 3G network based on Release 4 [36]. ......................................................... 43 Figure 24 The generic structure of a 3G network. ....................................................... 44 Figure 25: LTE architecture [37]. .................................................................................. 50 April 2013
6
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 26: LTE security key hierarchy. ......................................................................... 52 Figure 27: LTE Subscriber authentication. ................................................................... 53 Figure 28: NAS security initiation and RRC security initiation. .................................... 54 Figure 29: RRC security completion. ............................................................................ 55 Figure 30: Femtocell Architecture [38]. ....................................................................... 64 Figure 31: Points of Attacks in Femtocell Architecture [40]. ....................................... 65 Figure 32: Certificate-based authentication with device integrity [44] ...................... 67 Figure 33: Combined Certificate and EAP-AKA-based Authentication [44]. ............... 68
List of Tables Table 1: Top 5 Activities in the Surveyed Countries (June 2012). ............................... 16 Table 2: Summary of Malware Taxonomy. .................................................................. 35 Table 3: Mobile network security vendors, gateways and modules [35]. ................... 40 Table 4 Basic security properties provided by mobile networks................................. 41 Table 5 Basic attack types to mobile networks. .......................................................... 42 Table 6 Signaling DoS attack scenarios. ....................................................................... 61 Table 7 Signaling DoS attack scenarios based on state inconsistencies. ..................... 63
April 2013
7
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Abbreviations ||
Concatenation
⊕
Exclusive or
2G
Second Generation
3G
Third Generation
3GPP
Third Generation Partnership Project
A
Interface between an MSC and an BSS
AAA
Authentication Authorization Accounting
Abis
Interface between a BTS and a BSC
ADSL
Asynchronous Digital Subscriber Loop
AES
Advanced Encryption Standard
AH
Authentication Header
AK
Anonymity Key used in 3G
AKA
Authentication and Key Agreement
AMF
Authentication Management Field
AN
Access Network
AP APK AS
Access Point Application Package (Android) Access Stratum
AuC
Authentication Centre
AUTN
Authentication Token
AUTS
Re-synchronization token
AV
Authentication Vector
BG
Border Gateway
BSC
Base Station Controller
BSS
Base Station Subsystem
BTS
Base Transceiver Station
CK
Cipher Key used in 3G
CKSN
Cipher Key Sequence Number
CN
Core Network
CS
Circuit Switched
April 2013
8
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
CSC
F Call Session Control Function
CSG
Closed Service Group
DES
Data Encryption Standard
DNS
Domain name system
DoI
Domain of Interpretation
DoS
Denial of Service
DDoS
Distributed Denial of Service
DPI
Deep Packet Inspection
DSCP
Differentiated Services Code Point
EIR
Equipment Identity Register
eNB
eNodeB
eNodeB
Evolved NodeB
ESP
Encapsulating Security Payload
E-UTRAN
Evolved Universal Terrestrial Radio Access Network
f1
Message authentication function used to compute MAC
f2
Message authentication function used to compute RES and XRES
f3
Key generating function used to compute CK
f4
Key generating function used to compute IK
f5
Key generating function used to compute AK
f8
3G ciphering function
f9
3G integrity function
FAP FMS
Femto Access Point FAP Management System
FRESH
Random value used to prevent replay of signaling messages
Gb
Interface between an SGSN and a BSS
GERAN
GSM/EDGE Radio Access Network
GGSN
Gateway GPRS Support Node
Gi
Reference point between GPRS and an external packet data network
Gn
Interface between two GSNs within the same PLMN
Gp
Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS network services across areas served by the co-operating GPRS PLMNs
GPRS
General Packet Radio Services
April 2013
9
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
GPS
Global Positioning System
GSM
Global System for Mobile communications
GTP
GPRS Tunnelling Protocols
GW H(e)NB
Gateway Home (evolved) Node B
HE, HN
Home Environment, Home Network
HLR
Home Location Register
HPM
Hosting Party Module
HTTP
HyperText Transfer Protocol
IESG
Internet Engineering Steering Group
IETF
Internet Engineering Task Force
IK
Integrity Key used in 3G
IKE
Internet Key Exchange
IKEv1
Internet Key Exchange version 1
IKEv2
Internet Key Exchange version 2
IMSI
International Mobile Subscriber Identity
IP
Internet Protocol
IPS
Intrusion Prevention Systems
IPsec
IP security - a collection of protocols and algorithms for IP security including key management
IT
Information Technology
ITU
International Telecommunication Union
Iub
3G interface between the NodeB and the RNC
Iubis
Interface between an RNC and a Node B
IuCS
Circuit-Switched interface between an RNC and a core network
IuPS
Packet-Switched interface between an RNC and a core network
Iur
Logical interface between two RNCs
IV
Initialisation Vector
K
Long-term secret key shared between the USIM and the AuC in 3G
KAC
Key Administration Center
Ks
Session secret key
LAI
Location Area Identity
LTE
Long Term Evolution
April 2013
10
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
M2M
Machine to Machine
MAC
Message Authentication Code
MAC-A
The message authentication code included in AUTN, computed using f1
MAP
Mobile Application Part
MAPsec
MAP security
ME
Mobile Equipment
MITM
Man In The Middle
MitMo
Man in the middle in the Mobile
Mm
Interface between a CSCF and an IP multimedia network
MME
Mobility Management Entity
MNO
Mobile Network Operator
MS
Mobile Station
MSC
Mobile Services Switching Centre
MT
Mobile Terminal
Mw
Interface between a CSCF and another CSCF
NAS
Non Access Stratum
NAT
Network Address Translator
NDS
Network Domain Security
NDS/IP
NDS for IP based protocols
NE
Network Entity
OS
Operating System
OSA
Open Service Architecture
PDN
Packet data network
PGW
Packet Gateway
PKIP
Public Key Infrastructure
PS
Packet Switched
P-TMSI
Packet-TMSI
Q
Quintet, UMTS authentication vector
RACH
Radio Access CHannel
RAI
Routing Area Identifier
RAN
Radio Access Network
RAND
Random challenge
April 2013
11
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
RCS
Rich Communication Services
Rel-4
Release 4
Rel-5
Release 5
RES
(expected) user response to challenge in GSM
RNC
Radio Network Controller
S1
LTE interface between an eNode, and an MME (S1-MME, control plane) or an SGW (S1-U, user plane)
SA
Security Association
SAD
Security Association Database (sometimes also referred to as SADB)
SD
Secure Digital
SEG
Security Gateway
SeGW
Security Gateway
SGi
LTE interface between the PGW and the PDN
SGSN
Serving GPRS Support Node
SGW
Serving Gateway
SIM
(GSM) Subscriber Identity Module
SIP
Session Initiation Protocol
SMS
Short Message Service
SN
Serving Network
SON
Self-organizing network
SPD
Security Policy Database (sometimes also referred to as SPDB)
SQN
Sequence Number
SQNHE
Sequence number counter maintained in the HLR/AuC
SQNMS
Sequence number counter maintained in the USIM
SS7
Signaling System No. 7
TCP
Transmission Control Protocol
TLS
Transport Layer Security
TMSI
Temporary Mobile Subscriber Identity
TPM TrE
Trusted Platform Module Trusted Environment
UE
User Equipment
UEA
UMTS Encryption Algorithm
UIA
UMTS Integrity Algorithm
April 2013
12
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
UICC
UMTS IC Card
UMTS
Universal Mobile Telecommunications System
USIM
(UMTS) Universal Subscriber Identity Module
UTRAN
Universal Terrestrial Radio Access Network
VLR
Visitor Location Register
VoIP
Voice over IP
VoLTE
Voice over LTE
X2
LTE interface between two eNodeBs, including X2-C (control plane) and X2-U (user plane)
XMAC
Expected Message Authentication Code
XRES
Expected Response
XRES
Expected Response
Za
Interface between SEGs belonging to different networks/security domains
Zb
Interface between SEGs and NEs and interface between NEs within the same network/security domain
April 2013
13
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
1 Introduction This document is the deliverable D1.1 resulting from the Task 1.1, “Benchmarking of current practices and State-of-the-Art for security threats and attacks against mobile”, of the project NEMESYS. Being the first technical deliverable of the project, D1.1 provides an overview of all the latest developments in the security of mobile devices and network infrastructures so as to pave the way for innovation to be brought by the NEMESYS project in as many directions as possible. The work included in D1.1 provides an exploratory analysis of the security threats and attacks against mobile devices, both from a mobile device perspective (exploitation of the device for economic fraud, stealing sensitive data, etc.) and a network infrastructure viewpoint (since they may enable the attacker to launch attacks against the core of the network). It also reports on the security practices in the mobile ecosystem, as well as on the current advances in the area of attack traces collection infrastructure and virtualized honeypot development for mobile devices, thus preparing for the advances to be introduced by the NEMESYS concepts. The document is divided into four main parts: after the introduction that comprises an overview regarding mobile malware as a threat for smartphone users and especially for Android users, the first main part of D1.1 provides an up to date taxonomy of mobile malware, taking into consideration the security threats recorded in the last two years. The taxonomy is based on several criteria, like the attacks vectors, the category and the behaviour of malware. The second part is a study of the security practices in the mobile ecosystem focusing on HSPA/HSPA+/LTE network infrastructure and femto access points architecture, while the third part provides the State of the Art in attacks traces collection. The last paragraph presents in brief the advances/innovation planned to be brought by NEMESYS and the deliverable is completed with the main results derived from the presented informative material. D1.1 will be used as input for the identification of the system and user requirements ( Task 1.2), which will then guide the definition of the system architecture (Task 1.3), and the subsequent development of NEMESYS techniques and solutions.
April 2013
14
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
2 The Growth of the Mobile Market Worldwide 2.1
Statistics & Forecasts
The worldwide mobile market has changed rapidly in the last years. At the end of 2011, ITU (the International Telecommunication Union) estimated 6 billion mobile subscriptions worldwide, which is equivalent to 87% of the world population. This can be considered a huge increase from 5.4 billion in 2010, and 4.7 billion mobile subscriptions in 2009. According to [1], the subscriber base is projected to grow at an annual rate of 6% between 2011 and 2016, and is thus expected to cross 8 billion by the end of 2016. The emerging markets are situated in Asia Pacific and Middle East, with annual rates of more than 7.7% and 7.4% respectively.
2009
2010
2011
2012 2013 2014 2015 2016
Figure 1: Worldwide mobile subscriptions evolution.
According to [2], countries like Russia, Germany, Brazil, Indonesia, United States and Japan have more mobile subscriptions than population. Taking into account both subscriber and application statistics, the authors of [1] make an interesting statement: ever since its inception, the growth of the mobile market worldwide, both in terms of subscriber numbers and the scale at which new services are being introduced and taken up, has repeatedly surpassed expert estimates. It is estimated that this trend will continue at least until 2016. As far as the smartphone market penetration is concerned, [2] states that the number of smartphones in use worldwide has now broken the 1 billion mark. With the ITU estimating global mobile subscriptions at 6 billion at the end of 2011, it is calculated that global smartphone penetration is now 16.7%. It has taken 16 years for smartphone penetration to reach 1 billion, but the authors of [3] believe that it will only take three years to achieve the next billion. Android and Apple iOS account for the significant majority of the global smartphone installed base in 2012. For April 2013
15
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
example, recent statistics [10] shows that, taken together, Google’s Android platform and Apple’s iOS accounted for a record 92% of global smartphone shipments in the fourth quarter of 2012. Furthermore, it appears that smartphones represent the technology that is spreading faster than any other technology in human history [11], and this happens even in developing countries. Thus, smartphones accounted for 36% of global mobile phone shipments in the first quarter of 2012, up from 25% an year earlier. It seems that only television had such spreading rates in the United States at the beginning of the 1950s.
2.2 Top Activities of Mobile Users It is interesting to also have a look at the main activities that users perform on their smartphones. In June 2011 Portio Research surveyed thousands of consumers across a number of countries; the next table (Table 1) illustrates the top 5 activities that consumers use their mobile devices for in the UK, China, India, the US, Chile and the UAE (United Arab Emirates). Rank
The UK
China
India
The US
Chile
The UAE
1
SMS & MMS
SMS & MMS
Voice Calling
SMS & MMS
Voice Calling
SMS & MMS
2
Voice Calling
Voice Calling
SMS & MMS
Voice Calling
SMS & MMS
Voice Calling
3
E-mail
Reading News/eBooks
Social Networking
E-mail
E-mail
E-mail
4
Social Networking
Instant Messaging
Music & Radio Streaming
Social Networking
Social Networking
Social Networking
5
Gaming
Mobile Search
Gaming
LocationBased Services
Gaming
Gaming
Table 1: Top 5 Activities in the Surveyed Countries (June 2012).
The percentage of regional distribution of the worldwide mobile data traffic at the end of 2011 is illustrated in Figure 2 (drawn from data provided in [1]). It is estimated that Asia Pacific will continue its dominance to 2015 (the end of the forecast period): the region will generate 41% of worldwide mobile traffic at the end of 2015, followed by Europe with 33.8%.
April 2013
16
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 2: Regional contribution to worldwide data traffic.
Another interesting trend is the modification of paradigm in mobile messaging. SMS is and will remain an important source of revenue for mobile operators, but with the advent of Over-the-Top (OTT) messaging applications (also called next generation messaging services), most of the OTT messaging traffic surpassed and will continue to overcome the SMS traffic. In reality, OTT and SMS traffic grow side by side [1], but the rates of growth of the overall volume of mobile P2P messaging is far superior to the rate of growth of common SMS traffic. Similarly, mobile e-mail, social networking and mobile applications downloads will significantly grow over the next years, with mobile application downloads showing an exponential growth to 2016. For the period from 2009 till 2012, the mobile application downloads show Europe at the second place after North America, while from 2012 to 2016 the European geographic region comes at the third place after North America and Asia and Pacific. In general, applications and services, such as mobile VoIP (e.g., Skype, Nimbuzz), social networking (e.g., Facebook, Twitter), mass messaging apps (e.g., SMS GupShup), Mobile Video Streaming (e.g., Youtube, MobiTV), mobile payments (e.g., Square), and, in general user-generated content dominate the mobile market and will continue to do so in the future.
2.3 Market penetration of mobile OSes The next two figures (Figure 2, and Figure 3) illustrate the market shares of the main mobile operating systems in 2011 and the first half of 2012 as presented in [4].
April 2013
17
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 3: The mobile market: the shares of the main mobile OSes 2011.
Figure 4: The mobile market: the shares of the main mobile OSes 2012 (the first two quarters).
These real-world data demonstrates that, in the last two years, the four most popular mobile platforms are, in order, Android, Apple iOS, Symbian and RIM (Blackberry). The same report shows that, even if the worldwide sales of mobile phones declined by 2.3% in the second quarter of 2012, the shares distribution does not change. The report of Strategy Analytics [5] illustrates that Android and Apple iOS combined account for the significant majority of the global smartphone installed base in 2012, while the rapid decline in the installed base of Symbian and BlackBerry continues. Looking forward to 2017, Android and Apple iOS will remain the dominant smartphone platforms. Strategy Analytics also forecasts that Microsoft will consistently gain installed base share as the platform matures. Nascent platforms, such as Tizen and Firefox OS will also grow in popularity, as the benefits of HTML5based ‘cloud phones’ become more apparent. We can now provide additional recent statistics from the IDC Worldwide Mobile Phone Tracker report, published in August 2013 and illustrated in figure below.
Figure 5 Top smartphone OSes during 2012 and the first half of 2013.
We can notice that in the first half of 2013 Android and iOS account for the 92.5% of the smartphones market. April 2013
18
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
2.4 Statistics in the mobile network of Telecom Italia Statistics from real data collected in the mobile network of Telecom Italia during a single day in 2012 (the first half of the year) shows us the distribution of the mobile operating systems of the devices registered to the network (Figure 6). We can see that 45.5% of the phones still run the Symbian OS. However, the distribution per OS of the traffic coming from these devices illustrates that 63% of the network data traffic is generated by iPhone smartphones (Figure 7).
st
Figure 6: Distribution of phones’ OSes in TI mobile network (from 1 day traffic, 1 half of 2012).
st
Figure 7: Distribution of data traffic per OS in TI mobile network (from 1 day observations, 1 half of 2012).
This observation is in line with the statistics extracted from traffic data collected worldwide [6], which shows iOS as leader and Android less used as a ‘real smartphone’ (i.e., for e-mail reading/sending, web browsing, app downloading etc.). April 2013
19
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
By the end of 2012, the situation has already changed in the TI mobile network comparing to the beginning of the year. Android has surpassed both Symbian and iOS, with 31% of the terminals registered to the network running Android, 29% Symbian OS and 21.6% iOS. BlackBerry is at the 4th place, while Nokia OS, Windows Phone, and Bada OS are run on a very small number of devices. The data traffic is still mainly generated by iOS phones, but we can see that Android is following up very fast. During 2012 a large number of mobile devices were launched: two new generations of iPad and an iPad Mini from Apple, Google’s Nexus 7 and Nexus 10, the iPhone 5, and Samsung Galaxy S3, etc. While tablets and mobile phones play many different roles in today’s world it is clear that more devices means more users surfing the Internet. The authors of [7] decided to see if these releases had any impact on the types of platforms that frequent the Web over the past few months. The company monitored advertisement impressions coming from iOS and Android devices from May 27 through November 27 2012, noting the differences in Web traffic volume. According to [7], 67% of the measured Web traffic during this time period came from iOS devices. Android accounted for about half of the overall traffic at 33%. Android traffic appeared to hit a peak around the end of August, which can likely be attributed to strong Galaxy S3 sales. Traffic from iOS devices saw a rise in October and November following Apple’s iPad 4 and iPad Mini release. While these numbers represent a sizeable discrepancy between operating systems, we can note that little has changed in the overall distribution between Android and iOS. This is largely because of Apple’s iPad, the data analysis website says. These findings are in line with the statistics performed on instantaneous data collected in TI networks. Quite recently instead, more precisely during the month of February 2013, a Cisco study cited by InfoWorld [8] shows that Android took the lead from iOS in mobile data traffic.
April 2013
20
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
3 Mobile malware During the last two years mobile malware has become a perceived threat for smartphone users, and, especially for Android users. In the present document we would like to present some significant statistics on mobile malware. In particular, we take into consideration all malware samples recorded in the last two years for the most popular mobile platforms, mainly Android OS, iOS (Apple), RIM OS (Blackberry) and Windows Phone. Symbian is also taken into consideration here mostly for historical reasons, due to the still significant presence of Symbian mobile phones in the user land, trend which is estimated to continue till 2016.
3.1 A look at the real world Mobile malware spreading increased steadily all along the last year, overriding the predictions, like shown in the following figure, where the mobile malware rates for the third quarter of 2012 are illustrated, and which amply outpace (four times) predictions, according to TrendLabs’ latest report [12]. Figure 8 illustrates the malware volume growth according to public statistics presented by McAfee [21].
Figure 8: From McAfee’s 2012 threat report: Mobile malware volume evolution.
Quite obviously, popularity comes at a price, since the most affected platform is Android, which can be also considered the most open and the most spread mobile OS at the moment. In fact, malware rates for the other platforms are rather insignificant compared to the amount of malware for Android, coming to an extent that, in the majority of mobile malware reports, the statistics are shown only for Android. The malware samples collected for the other mobile OSes (with the unique exception of Symbian) are very rare (at least till the end of 2013). In its final statistics for 2012 presented in [13], TrendLabs states that by the end of 2012, the number of Android malware grew to 350,000. This can be considered an unexpected growth from the 1,000 mobile malware TrendLabs counted at the end of 2011. According to the same analysts, much of this growth was driven by adware April 2013
21
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
and premium service abusers. An interesting fact these numbers are showing is that the popularity of Android in the mobile space means that Android is now facing threats similar to those that Windows has faced since till now. The dominance of Android as far as mobile malware is concerned is also illustrated in the mobile landscape report of the first three quarters of 2012 (Figure 9) provided by F-Secure Labs [14]. This statistics takes into consideration new malware families and variants and not new samples (which are instances of the same family). For example, if two samples are detected as, let us say, Trojan.Android/XXX.A, they are counted as one in the statistics. The variants of the same malware, Trojan.Android/XXX.A and Trojan.Android/XXX.B are counted as two. An instance is an individual sample within a particular family. Hence malware instances can often include very minor differences that distinguish them within a group. If two malware instances are different enough in construction, they may be defined as separate variants.
Figure 9: New mobile threats families and variants received by F-Secure Labs per quarter during the two-year period 2011- 2012.
McAfee offers still another view on the distribution of new malware during 2011 (Figure 10) and the first three quarters of 2012 (Figure 11) [15]. Even if the numbers April 2013
22
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
change slightly, the statistics still show Android as the unquestionable preferred target of attacks.
Figure 10: New malware distribution per OS in 2011 (McAfee data).
Figure 11: New malware distribution per OS in 2012, Q1 to Q3 (McAfee data).
Kaspersky Labs also provides an image of the mobile malware spreading during 2012 (Figure 13), where Android is the incontestable ‘leader’: 98,96% is Android malware [16]. This situation is also illustrated by McAfee 2012 report on mobile malware [21], which shows Android at 97%, followed by Symbian and Java ME. We can also note here a huge increase in Andorid malware, which almost doubled in Q4 with respect to Q3 of 2012.
April 2013
23
Deliverable D1.1
Dissemination Level: PU
0,97%
317888-NEMESYS
2012 98,96% Android J2ME Symbian
Others
Figure 12: Android is the most affected platform by mobile malware (Kaspersky data).
As far as the geographical distribution of malware is concerned, in August 2012, the analysts from HOTforSecurity offer a detailed statistics for Android malware spread in the world (Figure 13) [17].
Figure 13: HOTforSecurity: Android malware spread worldwide in August 2012.
During 2012, the Security Lab in Telecom Italia Information Technology registered some interesting statistics based on two databases built from GooglePlay free applications (the first) and Android malware observations in the wild (the second). The first database consists of a set of 41000 applications from GooglePlay, which is the official store for Android. The second database instead, contains 1488 known malware samples from 90 distinct families, downloaded from the Android Genome Project [18] and ContagioMiniDump [19]. April 2013
24
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Some statistics were extracted from these data sets, by means of a static analysis tool for Android application packages (apk) developed by our labs on top of Androguard [22]). Androguard computes risk scores for Android apks in a range of [0, 100]. The first interesting observation is that, surprisingly, 38% of the legitimate applications obtained a behaviour risk greater than 70, while 88% of malware apks obtained a risk greater than 70. Applications that obtain security risk scores greater than 70 are to be considered potentially damaging for the device and its user. Briefly, the risk categories examined by the tool are: Root privileges escalation, Encrypted code, Binary code, Internet, Dangerous API, Dynamic code loading, Exploit, Phone abuse, SMS activities, Money risk, Signature and system permission, Privacy violation. Legitimate applications obtained an unexpected high risk values on several categories like dynamic, exploit, root privileges, dangerous APIs, while the malware set obtained high values on money, Internet, SMS, and privacy violation categories, and significant risk on their archive files. As far as malware is concerned, User Privacy Violation is the most significant risk encountered, while, for applications downloaded from GooglePlay, the dangerous API usage risk is the highest. Besides risk scores, the analysis system extracts the suspect URLs and phone numbers identified in the applications. We found out that the most frequent URL addresses are related to PayPal websites. As far as the misuse of SMS and phone calls, we found that only a few malware samples use these unauthorised communications, since phone numbers called would be available and pretty easy to be found by the user. Figure 14 shows the risk scores distribution for applications in the legitimate and malware datasets. We can see that free applications from GooglePlay are concentrated in the score intervals from 60 to 80%, while malware in the intervals from 70 to 90%. There is a significant overlapping window which can imply both false positives and false negatives in anomaly based malware detection systems.
Figure 14: Risk scores distribution for market and malware apps.
April 2013
25
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
The histogram from Figure 15 shows the distribution of average application risk scores for each examined risk category for legitimate and malware sets. We can see that the shapes of the histograms are very different for the two databases.
Figure 15: Average risk scores for each risk category for market and malware apps.
Malware has conspicuous peaks on Dangerous, Money and Privacy violation risk categories. We also investigated the most common shell commands encountered in legitimate and malware applications. The results are presented in Figure 16 and Figure 17.
Figure 16: Most encountered shell commands in apps from the market.
April 2013
26
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 17: Most encountered shell commands in Android malware.
These histograms show that, practically, there is no difference between the percentage of the most recurrent shell commands identified in the two data sets. Note that good programming practices indicate that such commands should not be included in benign applications, since Android offers a rich SDK and APIs to perform practically any legitimate action on the device. A significant result of our tests is that a legitimate free application from Google PLay could not be as innocuous as users are inclined to think. This may be an effect of either a poor programming or the presence of potentially unwanted code (mainly related to adware or due to recycled code), but the risk is there, even for applications that users may be tempted to trust. This is somewhat in line with the findings of McAfee, which looked more closely at the nature of the risky apps downloaded by their user community, trying to understand what level and type of risks do real users really face. Of the applications their users downloaded between April and December of 2012, they found 16% - 1 in 6 applications - to be infected with malware or to contain links to risky URLs [20].
3.2 Mobile malware taxonomy At the present time, a univocal and universally accepted mobile malware taxonomy does not exist neither in the academic literature or in the security experts domain. We will start by taking into consideration the taxonomies implicitly proposed by the major mobile antivirus companies in their periodical reports.
April 2013
27
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
3.2.1 Mobile malware taxonomy in practice In this section we present the malware taxonomies as reported by the main malware analysis companies, which actively monitor the mobile malware spreading all over the world, we may say, “in near real time”. For example, in [23], Lookout estimates that, from more than six million people affected by Android malware from June 2011 to June 2012, many were affected by Toll Fraud applications. The prevalence of Toll Fraud malware grew explosively from 29% of the application-based threats in Q3 2011 to more than 62% in Q2 2012. Lookout also estimates that one sub-family of FakeInst1, the most prevalent Toll Fraud malware family during the examined period, has netted an approximate $10 million for its makers, mostly from Eastern European and Russian Android users. By taking into account the main categories of malware encountered in the wild during the last two years, Lookout proposes the following macro-taxonomy: toll fraud malware, spyware and other malware. Spyware is, hence, separated from malware. Detection rates of malware during 2012 continued to outpace those of spyware, a trend observed by Lookout 2011’s report. Lookout has seen a significant increase in the number of individual malware instances detected in the first half of 2012, with Toll Fraud malware emerging as the most significant threat category. In Q1 2012, detections of Toll Fraud malware alone started to surpass those of spyware, which incorporates both untargeted and targeted (‘Surveillanceware’) samples. In Q2 2012 Toll fraud and spyware samples are 81% from all mobile malware. From the same data collected in the wild, during 2011 and the first half of 2012, a more detailed taxonomy is also provided. The main categories of malware are:
Toll fraud, e.g., unauthorized usage of the phone for sending (possibly premium) SMS and placing (possibly premium number) calls;
Bot client, where the phone is registered to a mobile botnet and hence becomes remotely controlled by a Command & Control server;
App Downloader, e.g., unauthorized applications download;
Infostealer, i.e., the malware performs personal information exfiltration (data theft);
Contact Spammer, where the malware sends spam mails to all contacts;
Rooter, i.e., the malware roots2 the device without the user’s consent;
Destructive, e.g., the malware misconfigures the device, provokes system reboot or crash, drains the battery and computing resources. Lookout does not provide an exact percentage distribution of these malware categories in the wild.
1
The majority of malware samples mentioned in this document are described on the free mobile malware research site http://contagiominidump.blogspot.it/ 2
rooting is the process of allowing users of devices running the Android OS to attain privileged control (i.e., root access) within Android's sub-system. The same process in iOS is called “jailbreaking”.
April 2013
28
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
From the practical experience of Lookout, there has been a notable rise in the prevalence of Toll Fraud malware (basically designed for profit, which works by billing an unsuspecting victim through premium SMS services). Inspecting Lookout data closer, we can see that this massive increase can be attributed primarily to a single Toll Fraud family type dubbed ‘FakeInst’. FakeInst, also referred to as RuSMSMarket, OpFake, Fakebrows, and FakeWAM, is by far the most prevalent malware detected by Lookout to date (as shown in Figure 7 above). Classified as a Fake Installer, FakeInst pretends to act as an installer for legitimate popular apps such as the Opera Browser (hence the names ‘OpFake’ and ‘Fakebrows’) or WhatsApp Messenger. In most cases, Fake Installer malware does not perform installations. In fact, in most cases it does not contain much user-facing functional code at all. In 2011, GGTracker and RuFraud were two high-profile Toll Fraud families that caused significant financial damage to users in the US and Europe, respectively. Comparatively, FakeInst is almost exclusively directed at Eastern Europe and Russian users. Another taxonomy is proposed by the F-Secure team (Figure 18), in their report for the third quarter of 2012 [14]:
Trojan, i.e., a program that appears legitimate, but performs some illicit activity when it is run;
Riskware, i.e., a software, which actually was not programmed and intended as malware, but has security critical functions;
Monitoring Tool, i.e., a program that stealthy monitors device and user’s activity;
Trojan Spy, i.e., a Trojan program that performs information theft;
Spyware, i.e., a malware that performs information theft;
Adware, i.e., a program that displays unwanted advertisement;
Hack Tool, i.e., a program that performs various hacking activities (e.g., like device rooting)
Trojan Downloader, i.e. a Trojan that downloads applications without the user’s consent.
April 2013
29
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 18: Malware distribution during 2012 (source: F-Secure).
The percentage distribution of these malware in the wild is also given, according to the perception of F-Secure based on their malware database. We can see that we have a specific category for Trojans that are also spywares. This is an important disambiguation, because, as we can observe from the malware encountered in the wild, there is no way to compose a univocal taxonomy, without intersections between the categories. Yet another taxonomy is proposed by Kaspersky (Figure 19) in their report for 2012 [16]:
Trojan
Trojan SMS
Backdoor (a malware that opens a backdoor on the system, pretty the same as bot client above)
Adware
Monitoring
Trojan download
Risk tool.
April 2013
30
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
malware classification Trojan Trojan SMS Backdoor Adware Trojan Spy
Monitor Trojan downloader Risk tool
Figure 19: Malware distribution during 2012 (Source: Kaspersky).
We can see here that Trojans are classified in: spyware Trojans, SMS Trojans, Trojan downloaders and simply Trojans when neither of the above behaviors are displayed. In [24], a document on McAfee mobile security trends in 2013, McAfee proposes the following mobile malware classification, based on malware behaviour:
Send handset info (aka Info Stealers)
Spyware
Adware
Send Premium SMS
Fraud
Exploit
Rooting Malware
Backdoor/Botnet
Hacktool
Downloader/Installer
Destructive
SMS Spam. The distributions in the wild of these typologies are also given for a long period of observation, from 2007 to 2012, where info stealers, spyware, SMS senders and adware are placed on top of the list. We can see that the major companies offer taxonomies based on malware behaviour, or mixed taxonomy based on behaviour and malware nature (e.g., trojan). Other taxonomies are also possible. In the followings, we try to give different views on this issue and try to make a tentative to define a coherent taxonomy, based on different well specified criteria.
April 2013
31
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
3.2.2 Infection vector-based taxonomy An important criterion for malware classification is given by the distribution methods (also called infection vectors). Malware developers use a variety of techniques to establish the broadest possible distribution across devices. We review some of the most notable new distribution trends that have been seen during 2012. From the Lookout experience, the main infection vectors specific to mobile malware are:
Generic network-based
Unwanted downloads
Advertising
Web-based. As we can see, all infection vectors are based on some form of network interaction. Generic network-based: Developers use network distribution techniques to promote their applications as well as drive downloads and generate profit. Traditional networks enable developers to increase downloads and website visits by offering promoters a share of revenue generated by such actions. The means by which malicious promoters distribute applications are: inside-application advertisements, links, web-based pop-ups, third-party application stores. When a mobile user taps on the promotion, the malicious application is downloaded. If a user also installs and activates the downloaded application, the application begins its fraudulent behavior. Unwanted Downloads: An unwanted download is a distribution technique where a web page automatically starts downloading an application when a user visits it. These downloads can be combined with social engineering techniques to appear as if they are legitimate and desirable. Since mobile browsers do not automatically install downloaded applications, an attacker also needs to convince the user to install the application in order to successfully infect the device with malware. Advertising: In this case we talk about malvertising (malicious advertising) which leverages mobile advertising as a distribution technique. Since developers commonly run advertisements in other applications to attract new users, it is not uncommon to download applications through advertisements. In the case of malvertising, a malware writer buys legitimate mobile ads and directs users to download malware on legitimate markets or from a fake site designed to imitate legitimate markets. Web-Based: Web-based threats (phishing, malicious and compromised websites) are becoming significant for mobile users, particularly because users on mobile devices can encounter threats targeting PCs. This category includes phishing scams that use email or social networks as distribution mechanisms, as well as mobile-specific tactics such as SMS-based spam and phishing. Some web-based threats, such as phishing attacks, do not discriminate based on mobile platform, i.e., they affect Android, iOS and PCs in the same way. Lookout found that the likelihood of encountering a web-based threat within a given year varies from an estimated 10% to 40% globally (remember that McAfee estimates it to 16%). It is also estimated that in the United States alone, 4 in 10 users click on an unsafe link on a mobile device. April 2013
32
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
A more generic taxonomy having as criterion the infection vectors, can roughly take into consideration the ingress points of a mobile device: SMS/MMS, Bluetooth, Wi-fi and Internet access, file duplication with USB. SMS/MMS are also used as infection vectors today. Usually such SMSes include a direct download link for the malicious application. Bluetooth-enabled devices must be in a range of 10-100 meters to communicate with each other and the malware spreading in this case can use the default password vulnerability in Bluetooth implementation. Smartphones can access the Internet using Wi-fi networks or 3G/4G networks, which allow users to surf the web, send and receive emails, download applications, etc. Therefore the smart phones are exposed to the same threats as common PCs. USB file duplication is not documented as a practical infection yet, but is very probable that a smartphone become infected, for example, during synchronization with and a compromised PC.
3.2.3 Behaviour-based taxonomy Common malware taxonomy is based on its behavior on the compromised devices. Basically, an application is classified as malware if it does one or more of the following actions:
Information leakage: exposes device or personal information (including user credentials) without the user’s permission;
User activity leakage: spies on and records user’s activity (browsing history, messages, phone calls, videos played, etc.);
Fraud and click fraud: sends premium rate SMS messages, makes premium rate calls, makes subscription to data paid services, etc.;
Exploit: exploits a vulnerability or software bug on the device to cause it to do something the user does not expects (often through downloading and installation of additional malware files);
Rooting: roots (or jailbreak) the device to give an attacker control over it;
Device remote control: installs a backdoor or turns the device into a bot client, often collecting personal information as a side effect, also installs a hacking application that allows the attacker to remotely control the device;
Malware download: downloads a secondary piece of malicious code from a website (using a http/https channel) or an arbitrary remote server (e.g., by using an IP raw socket);
Phone abuse: is destructive to the device (i.e., sw or hw misconfiguration, battery draining, provokes a system reboot or crash, etc.) or data stored therein;
Spammer: sends spam messages via SMS or spam e-mails from the device;
Ransom: steal private user’s information and publish it on the Internet, demanding a price to delete the information. A more generic taxonomy can classify mobile malware in the following categories:
April 2013
33
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
System damage: change system configurations, rooting, disabling system functions, battery drain (e.g., through continuous stealth Internet activity), etc.
Economic loss: SMS and calls to premium-rate numbers, deleting important data, subscription to mobile paid services, etc.
Information leakage: privacy breach, remote surveillance and control (e.g., mobile botnets), stealing account information (e.g., bank account information in the case of the Trojan Zeus MitMo).
Damage to mobile networks: DoS by generating high-rate and high-volume network traffic, signaling channel attacks, DDoS to specific services by mobile botnets.
3.2.4 Malware typologies Malware can also classified based on its type: worm, Trojan, backdoor, rootkit. Some taxonomies consider virus a separate type of malware. A virus though, is a type of malware that penetrates into a smart phone (and in general into a computer system) without the user’s knowledge, by either hardware or software means, and attaches itself to an executable file. In our opinion, this is quite a generic definition that covers all types of mobile malware. In some cases a virus is considered different from a worm, because a virus needs human intervention for its spreading. A worm is a type of malware that penetrates into the system without the user’s permission, and operates without the user’s knowledge, and it has the property to replicate or spread without human intervention. A Trojan is a harmful piece of code hosted inside a legitimate program/application. When the application is started, the Trojan starts and can generate a lot of damage from the infection and deactivation of other applications, phone abuse (which can leave the phone unusable), to the leakage of data to a remote server, and other fraud related activities (premium rate calls and SMS), mobile botnets, etc. With this type of malware, the user interaction is essential for the activation of the virus. A backdoor program is essentially a remote administration utility that can allow the attackers to control the system in any way without user’s knowledge and authorization. A rootkit is a special type of malware that hides itself in specific system files and processes, usually achieving its goal by loading a special driver program or by modifying the kernel. In the mobile ecosystem, a similar type of attack (called rooting in Android and jailbreaking in iOS) is often performed by the users themselves in order to have unlimited access to system resources! If we look at the mobile malware found in the wild during the last two years, we can see that the majority of them are Trojans, with rare worm cases. Sometimes such Trojans also include a rootkit (rootsmart, gingerbreak), but in the majority of cases the Trojans that are meant for rooted devices relay on the fact that the device has already been rooted. Table 2 offers a summary of the presented malware taxonomy.
April 2013
34
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Categories Criterion
Main Categories
Detailed categories
Infection vector
Internet access
Unwanted downloads from the web (through phishing and Social engineering) Advertising Voluntary downloads
3G/4G access
SMS infections MMS infections
Behaviour
Other network access
Bluetooth
Physical access
File duplication with USB
System damage
Wi-fi change system configurations rooting disabling system functions resources drain
Economic loss
SMS and calls to premium-rate numbers deleting important data subscription to mobile paid services
Information leakage
privacy breach (personal and device data) remote surveillance and control (e.g., mobile botnets) stealing accounts information
Damage to mobile networks
DoS by generating high-rate and highvolume network traffic signaling channel attacks DDoS to specific services by mobile botnets
Malware type
Worm Trojan Backdoor Rootkit Table 2: Summary of Malware Taxonomy.
4 Current practices in mobile security At the present time, mobile security is mainly focused on the implementation of device side countermeasures, i.e., the installation of an antivirus or some other April 2013
35
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
security suit on mobile devices that can support them. Network operators are now starting to investigate the possibility to protect the mobile network from attacks. This chapter investigates on current practices in mobile security, from both the user and the network perspectives.
4.1 Device side security Mobile devices are based on classic operating systems which offer native security features, such as: traditional access control, application provenance control (through code signing), data confidentiality, authentication and integrity through standard encryption and authentication algorithms, isolation (also known as application sandboxing), and permission-based access control. In the present document, we will only introduce the various security mechanisms employed by mobile operating systems used in the current most popular smart phones (Android, iOS, Windows-based, RIM and Symbian). For a more detailed description please consult deliverable D2.1 of our project [25]. Briefly, we review the following security mechanisms implemented by current mobile OSes: access restriction to system API functionalities, remote device activation, remote device wiping and deactivation, code signing, trusted boot sequences, sandboxing and data caching, privilege separation. Access to system API functionality, critical data and hardware functions in mobile OSes is granted (or restricted) through capabilities. There are different modalities to secure these capabilities:
They are implicitly granted by the user at installation time (e.g., the Android model).
Instead of making responsible the user, they are granted through external entities, which are trusted. This involves a review process, code signing and a secure distribution mechanism, such as an application market. This is the model encountered in iOS and Symbian.
They can be Self-signed, adopted when an external trusted party is not available, and can be combined with the implicit involvement of the user granting capabilities (as in Android).
They can be directly granted by the device manufacturer. Some vendors require the remote activation of the device, in order to allow to link the device to the user. This mechanism is used when the vendor also controls the application distribution, and can be later used to control the user’s data. Some vendors provide remote device wiping and deactivation, techniques which are useful in cases such as: stolen devices, infected devices which can become malicious and dangerous for the network, and illegal software on devices. These features are useful for both user (in case of device theft) and network operators (which can deactivate a malicious device). Code signing is used to be able to confirm the origin of an application in a reliable way (with authentication and no repudiation). Sometimes the trust is backed up by a trustworthy certification authority, but there can also be solutions where the code is signed based on self-signed certificates. Such solutions may be able to provide code April 2013
36
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
integrity, but they do not provide means to trust the author of the code. The decision whether to trust the code or not is taken by the user at installation. Trusted or secure boot schemes allow the construction of a chain of trust across the components involved in the boot process. Typically, there are cryptographic checks to be performed after each stage of the boot process. If one of these checks fails, the boot is aborted. Sandboxing means the separation between different components of the system by putting them into logically separated areas. Sandboxes are considered as a “jailed” or controlled environment from which the sandboxed component is not able to break out. In mobile OSes sandboxing is implemented with different granularity: the whole OS can run in a sandbox, applications run in sandboxes, or even OS processes which host the applications at runtime. An alternative option is to use data caging (like in Symbian OS), which is a form of access control which aims to separate data from code. In mobile OSes it refers to applications and users only having access to certain predefined areas of the file system. It is important to restrict access to the OS system image in order to prevent attacks that aim to replace the original image to a malicious one. Read-only system image is a common practice, which uses trusted boot to secure the image at early stages. Privilege separation aims at the minimization of the risk of applications misusing system components to damage user’s data or the OS itself. Maliciously escalating privileges is typically considered an important step to gain control over a system. Vendors restrict the users (in mobile OSes the applications) to run in user mode for security purposes. But the process of “rooting” the device is quite common for users that want to unlock the device’s features that are not accessible to regular users, like low level OS functions that enable backup of user data. The most used mobile OSes today provide all these security mechanisms with different granularity and different implementation approaches. For a detailed discussion on the security models together with their vulnerabilities please consult deliverable 2.1 [25]. It is necessary to mention that the real implementation of these mechanisms is not flawless [26] - [30], therefore the mobile OSes are not to be considered immune to attacks. Often the user itself facilitates the hackers by rooting the phone and installing applications that request dangerous permissions. Most of the time, in order to secure the smart phone, especially for enterprise devices, a security suite is installed. This can be a mere antivirus or a more sophisticated product which can also offer, among other security features, file system encryption, remote wiping, secure data backup and phone localization in case of theft. OS vendors themselves now offer services to verify the security of an application the user downloads on her/his device. We consider the example of Google, which provides a real time application verification service based on Google cloud for Android OS version 4.2 and above. A study performed at the University of North Carolina [32] demonstrates that the Google application verification system is not very effective. This study performs a comparison between ten representative anti-virus engines from VirusTotal [33] (i.e., Avast, AVG, TrendMicro, Symantec, BitDefender, ClamAV, F-Secure, Fortinet, April 2013
37
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Kaspersky, and Kingsoft), and shows (see Figure 20) that the detection rates of these representative anti-virus engines range from 51.02% to 100%, while the detection rate of the new Google service is 20.41%. The malware samples used for tests are the samples from the Genome project [18].
Figure 20: Malware detection capabilities of Google application verification system (University of North Carolina).
The new application verification service relies on the server component in the Google cloud to determine whether an application is malicious or not. It is evident that that the server side cannot have all existing malware samples. The client side, in the current implementation, does not have any detection capability, which suggests possible opportunity for enhancement. However, due to the limited processing and communication power on mobile devices, we need to strike a delicate balance on how much detection capability can and should be offloaded. This represents a challenge for the NEMESYS project as well. Other online and free application verification services are available now for the most popular mobile OSes (especially for Android, which is also the most “attacked” platform) and many free tools for apk reverse engineering [22], [31]. Not all these instruments are easily employed by common users, but their presence is a clear sign that the users are becoming increasingly aware of the importance of securing their device.
4.2 Network side security Smart mobile devices are served mainly by 3G networks (UMTS/HSPA/HSPA+) and the emerging 4G networks (LTE). Therefore, in the following sections the current practices in mobile security regarding the aforementioned technologies will be presented. As mobile operators increase their broadband subscriber base and become Internet service providers (ISPs), new security threats are emerging that impact the mobile network or have the potential to impact it in the future. Emerging threats include the growth in application layer vulnerabilities, risks presented by smartphone application developers and mobile operating systems, the issue of excessive signaling in the network being generated by smartphones and smartphone applications, and new security risks presented by the new LTE architecture. April 2013
38
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
To keep up with changes in the security threat landscape, those responsible for protecting the availability and integrity of the mobile network will have to undertake substantial upgrades of their network security architecture and equipment. Vendors are bringing new feature roadmaps and toolsets to the market, to enable mobile operators to better protect their networks and subscribers. Driven by enterprise as well as carrier demand, most vendors of firewall and intrusion prevention system (IPS) products are evolving to next-generation solutions. Leading router vendors are adding IPsec termination capabilities on their carriergrade platforms to align with mobile operators' LTE security requirements. Distributed denial of service and other threat-mitigation vendors are developing bespoke solutions to reduce the impact of smartphone signaling, and many security vendors are looking at tighter integration with the 3rd Generation Partnership Program's (3GPP's) policy management domain. The deployment of LTE is a primary driver behind the evolving requirements for mobile security gateways. As shown in Figure 21, the LTE architecture is much flatter and much more IP-centric than 3G, which has a number of security implications, particularly where the backhaul network is concerned. In LTE, IP backhaul is mandatory, while the RNC node is eliminated, giving a potential attacker a straighter path to the network core. Also, there are many more signalling and bearer paths between network elements. In addition, the encryption of user traffic terminates in the eNodeB rather than the RNC, making the backhaul a potential security exposure for user plane data.
Figure 21: Security exposures in the 3G and 4G (LTE) networks [35].
A new generation of security-oriented capabilities and products is coming onto the market. Many of these have a growing number of capabilities and features that are uniquely tailored to the security needs of the mobile network. Table 3 lists some of the equipment vendors that are leading the security industry in building new features and products to meet the emerging security needs of mobile operators. April 2013
39
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Table 3: Mobile network security vendors, gateways and modules [35].
The cellular network infrastructure is massive and very complex with multiple entities coordinating together, such as the IP Internet coordinating with the core network. And therefore it presents a challenge for the network to provide security at every possible communication path. There are several generic security issues (summarized in Table 4) that have to be taken into consideration when deploying a mobile network, and the importance of which has increased with the evolution towards advanced networks like 3G and LTE. Security Property
Description in the mobile
Authentication
Mobile networks have a large number of subscribers whose identity has to be authenticated.
Integrity
Guarantees that the data transported by the mobile network is not modified in transit.
Confidentiality
The data transported over the network cannot be eavesdropped by attackers.
Access Control
The device might access a database where some sort of role based access control is necessary.
Intrinsic security of mobile OSes
Most mobile devices have capabilities similar to the ones offered by the common desktop computers. Vulnerabilities in the mobile OSes may
April 2013
40
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
give rise to security holes that can be exploited. Prevention of location detection
The actual location of a device needs to be kept hidden for privacy issues. With the move to IP based networks, the issue arises that a user may be associated with an access point and therefore their location information might be leaked.
Malware detection
Important because an infected device can be used to attack the mobile network infrastructure (e.g., by becoming a bot client in a botnet used to launch DoS attacks against the network).
Device physical protection
A lost or stolen device needs to be protected from unauthorized use so that potential sensitive information such as emails, documents, phone numbers etc. cannot be accessed.
Table 4 Basic security properties provided by mobile networks.
Due to the complex and heterogeneous architecture of a mobile network, there are a variety of attacks that the infrastructure is open to: Attack
Description in the mobile
DoS and DDoS
Caused by sending excessive data to the network elements, more than they can handle, resulting in users being unable to access network resources. Usually the attack is launched by mobile botnets.
Channel jamming
A technique used by attackers to jam the radio channel and therefore deny network access to legitimate users.
Unauthorized access
An attacker gains access to a network and then uses it to access further services that he might not be authorized for.
Eavesdropping
If the traffic on the radio link is not encrypted, or encryption can be broken, then an attacker can eavesdrop and intercept sensitive communication such as confidential calls, sensitive documents etc.
Message forgery
If integrity is not provided or can be broken, an attacker can intercept
April 2013
41
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
sensitive information. Message replay
Even if communication channel is secure, an attacker can intercept an encrypted message and then replay it back at a later time.
Man in the middle attack
An attacker can sit in between a mobile device and an access station and intercept messages in between them and also modify them.
Session hijacking
A malicious user can highjack an already established session, and can act as a legitimate base station. Table 5 Basic attack types to mobile networks.
An extensive list of attacks to 3G networks is presented in [80], while for LTE an interesting study is offered by the author of [101]. In the following section we will describe in more detail some of the possible attack scenarios sue to the flaws of the security architectures of 3G and 4G, and the topic is also resumed in NEMESYS deliverable D1.2.
4.2.1 3G Network Security Today there are two major architectures for the deployment of 3G networks. The first (and older) one is known as 3GPP Release 99 and is based on a clear split between a CS and PS domain, as shown in (Figure 22):
Figure 22: 3G network based on Release 99 [36].
The CS domain is mainly used for voice traffic and legacy CS data services. The MSC supports call control and switching functions. The interfaces between nodes are TDM-based in 2G networks, and ATM-based in 3G networks. April 2013
42
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
The PS domain is used for data applications. IP is used at the application level, between the mobile terminal and the PDN9, and at the transport level between RNC SGSN and GGSN. The Gb (Gigabit) interface is generally frame relay-based, while IuPS is ATM-based. The second (and newest) 3G architecture is also known as NGN (Next Generation Network) and has been standardized since 3GPP Release 4. It is shown in Figure 23.
Figure 23: 3G network based on Release 4 [36].
There is no change in the PS domain; but major changes are applied in the CS domain. The main characteristics of such a NGN architecture are:
A clear split between the control and transport layers; The legacy MSC is replaced by two new nodes: o An MSC server for call control; o An MGW for user plane handling. An MSC server controls one or several MGWs.
Although still managed in the CS domain, voice traffic is now transported through an IP backbone that can thus transport both CS and PS traffic. The MGWs are in charge of converting the format of the voice traffic from RAN to IP packets. An IP/MPLS backbone enables traffic separation and handling according to the QoS of the different types of traffic. IP introduction in the RAN will enable the IP backbone to progressively encompass some radio sites. Security protection in 3G-networks requires the consideration of several aspects and issues, such as the wireless access, the end-user mobility, the particular security threats, the type of information to be protected, and the complexity of the network architecture. The radio transmission is by nature more susceptible to eavesdropping than wired transmission. The user mobility and the universal network access April 2013
43
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
certainly provoke security treats. The different types of data, such as user data, charging and billing data, customer information data, and network management data, which are conveyed or are resident in mobile networks, require different types and levels of protection. There are five generic different sets of security features that are part of the 3G security architecture as described in [34]: 1. Network access security: provides users with secure access to 3G services, and protects against attacks on the (radio) access link; 2. Network domain security: enables nodes in the provider domain to securely exchange signalling data, and protects against attacks on the wire line network; 3. User domain security: secures access to mobile stations; 4. Application domain security: enables applications in the user and in the provider domain to securely exchange messages; 5. Visibility and configurability of security: informs a user whether a security feature is in operation or not and whether the use and provision of services should depend on that particular feature. These security features are to be intrinsically provided by the network and standard equipment manufacturers, with different levels or degrees of security strength foreseen by the standards and supported by the particular operator’s network and equipment. Depending on the security level adopted by the operator, and also on the vulnerabilities and flaws present on the equipment provided by the vendors, some of the attacks presented in Table 5 might still be possible. Such attacks have been extensively demonstrated in the literature, for example, in [30].
Figure 24 The generic structure of a 3G network.
April 2013
44
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
The generic structure of an UMTS (3G) network together with the standard names of the various interfaces between its components are presented in Figure 24. During the mobile station registration and connection within UMTS with a CS service domain and a PS service domain, as in GSM/GPRS, user (temporary) identification, authentication and key agreement take place independently in each service domain. User plane traffic is ciphered using the cipher key agreed for the corresponding service domain while control plane data is ciphered and integrity protected using the cipher and integrity keys from either one of the service domains. Detailed procedures are defined in [34] and when not otherwise stated they are used in both service domains. Network Access Security provides user identity confidentiality, entity authentication, data confidentiality, data integrity and mobile equipment authentication. User identity confidentiality is achieved through the implementation of following security features:
IMSI confidentiality: guarantees that the permanent user identity (IMSI) of a user to whom a service is delivered cannot be leaked on the radio access link; Location confidentiality: guarantees that the presence or the arrival of a user in a certain area cannot be determined through eavesdropping of the radio access link; Un-traceability: guarantees that an intruder cannot deduce whether different services are delivered to the same user by eavesdropping on the radio access link.
To achieve these security properties, the user is normally identified by a temporary identity (TIMSI) by which she/he is known by the visited serving network (SN). To avoid traceability, which may lead to the compromise of user identity confidentiality, the user is not identified for a long period by means of the same temporary identity. In addition it is required for any signalling or user data that might reveal the user's identity to be encrypted on the radio access link. Entity authentication is mutual in 3G networks: the user is authenticated (the SN has to be confident of the identity of the user) and also the network is authenticated to the user, who has to be confident that she/he is connected to a SN that is authorised by the user's home environment/network (HE) to provide him/her with services; this also includes the guarantee that the authorisation is recent. Two authentication mechanisms have been foreseen: an authentication mechanism using an authentication vector (AV) delivered by the user's HE to the serving network, and a local authentication mechanism using the integrity key established between the user and serving network during the previous execution of the authentication and key establishment procedures. The authentication and key establishment mechanism establishes a secret cipher key and integrity key between the user and the serving network. This mechanism is invoked by the serving network after a first registration of a user in a serving network and after a service request, location update request, attach request, detach
April 2013
45
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
request or connection re-establishment request, when the maximum number of local authentications using the derived integrity key have been reached. Data confidentiality is provided by the following security features:
Cipher algorithm agreement: the MS and the SN securely negotiate the algorithm that they will use subsequently; Cipher key agreement: the MS and the SN agree on a cipher key that they will use subsequently; Confidentiality of user data: user data cannot be eavesdropped on the radio access interface; Confidentiality of signalling data: signalling data cannot be eavesdropped on the radio access interface.
Cipher algorithm agreement and key agreement are part of the mechanism for authentication and key agreement (AKA). Once the user and the network have authenticated each other, they begin secure communication: a cipher key is securely shared between the core network and the terminal. User and signalling data sent over the radio interface is encrypted by means of a symmetric synchronous stream cipher algorithm and a 128-bit secret cipher key CK. The encryption/decryption process takes place in the MS and the RNC on the network side. As far as data integrity is concerned, the radio interface in 3G mobile networks has been designed to support integrity protection on the signalling channels. This enables the receiving entity to be able to verify that the signalling data has not been modified in an unauthorized way since it was sent. Furthermore, it ensures that the origin of the received signalling data is indeed the one claimed. The integrity protection mechanism is not applied to the user plane due to performance reasons. Data Integrity is provided by the following security features:
Integrity algorithm agreement: MS and the SN can securely negotiate the integrity algorithm that they use subsequently; Integrity key agreement: MS and the SN agree on an integrity key that they may use subsequently; Data integrity and origin authentication of signalling data: guarantees that the receiving entity (MS or SN) is able to verify that signalling data has not been modified in an unauthorised way since it was sent by the sending entity (SN or MS) and that the data origin of the signalling data received is indeed the one claimed.
The integrity algorithm agreement is realised by means of a mechanism for security mode negotiation between the user equipment and the network. In UMTS, an integrity function is used to authenticate the integrity and the origin of signalling data between the MS and the RNC. This function computes a 32-bit Message Authentication Code (MAC), which is appended to the frame, and is checked by the receiver. The main inputs to the algorithm are a 128-bit secret integrity key IK, and the variable-length frame content. April 2013
46
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
The equipment identification is achieved using the International Mobile Equipment Identifier (IMEI). The SN may request the MS to send it the IMEI or IMEISV of the terminal. The IMEI is securely stored in the terminal. However, the presentation of this identity to the network is not considered a security feature and the transmission of the IMEI or IMEISV may be unprotected. Although it is not a security feature, it was not deleted from UMTS, as it is useful for other purposes. As we have seen above, in UMTS AKA (Authentication and Key Agreement) is the security mechanism used to accomplish the authentication features and all of the key agreement features described above. The mechanism achieves mutual authentication, by the user and the network both showing knowledge of a secret key K which is shared between and available only to the USIM and the AuC in the user's HE. In addition, the USIM and the HE keep track of counters, SQNMS and SQNHE respectively, to support network authentication. The sequence number SQN HE is an individual counter for each user, and the sequence number SQNMS denotes the highest sequence number the USIM has accepted. The method was chosen in such a way as to achieve maximum compatibility with the GSM security architecture and facilitate migration from GSM to UMTS. The method is composed of a challenge/response protocol identical to the GSM subscriber authentication and key establishment protocol. As we can see in the following sections, these security functionalities provide robustness against basic attacks described for GSM networks (2G and 2.5G), but they do not always guarantee adequate security against new attack scenarios. Network Domain Security (NDS): The absence of security in Signalling System No. 7 (SS7) networks is an identified security weakness in 2G systems. This was formerly perceived not to be a problem, since the SS7 networks were the provinces of a small number of large institutions. This is no longer the case, and so there is now a need for security precautions. For 3G networks and beyond it is a clear goal to be able to protect the core network signalling protocols, and by implication this means that security solutions must be found for both SS7 and IP based protocols. Various protocols and interfaces are used for control plane signalling within and between core networks. The security services that have been identified as necessary are confidentiality, integrity, authentication and anti-replay protection. These are ensured by standard procedures, based on cryptographic techniques. IP-based protocols The UMTS network domain control plane is sectioned into security domains, which typically coincide with the operator borders. Security gateways (SEGs, which in a real network are the SGSNs illustrated in Figure 24) are entities at the borders of the IP security domains used for securing native IP-based protocols. It is noted that NDS does not extend to the user plane, which means that packet flows over the Gi interface (Figure 24) are not protected by the SGSNs. The basic idea to the NDS/IP architecture is to provide hop-by-hop security, which makes it easy to operate separate security policies internally and towards other external security domains. April 2013
47
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
In NDS/IP only the Security Gateways (SGSN) engage in direct communication with entities in other security domains for NDS/IP traffic. SGSNs establish and maintain IPsec secured ESP Security Associations in tunnel mode between security domains. SGSNs normally maintain at least one IPsec tunnel available at all times to a particular peer SGSN. The SGSN also maintain logically separate SAD and SPD databases for each interface. Other NEs may be able to establish and maintain ESP Security Associations as needed towards a SGSN or other NEs within the same security domain. All NDS/IP traffic from a NE in one security domain towards a NE in a different security domain is routed via a security gateway and will be afforded hop-by-hop security protection towards the final destination. Operators may decide to establish only one ESP Security Association between two communicating security domains. This would make for coarse-grained security granularity. The benefits to this is that it gives a certain amount of protection against traffic flow analysis while the drawback is that one will not be able to differentiate the security protection given between the communicating entities. This does not preclude negotiation of finer grained security granularity at the discretion of the communicating entities. SS7-based Protocol NDS for SS7-based protocols is mainly found at the application layer. Specifically, in case that the transport relies on SS7, or on a combination of SS7 and IP, then, security shall be provided at the application layer. On the other hand, whenever the transport is based on IP only, security may be provided at the network layer exclusively, or in addition to the application layer security, by using IPsec. User domain security, as defined in [34], ensures secure access to the MS. It is based on a physical device called UMTS Integrated Circuit Card (UICC), which can be easily inserted and removed from terminal equipment, containing security applications such as the USIM. The USIM (Figure 24) represents and identifies a user and his association to an HE. It is responsible for performing subscriber and network authentication, as well as key agreement, when 3G services are accessed. It may also contain a copy of the user’s profile. The USIM access is restricted to an authorized user, or to a number of authorized users. To accomplish this feature, the user and the USIM must share a secret (e.g. a PIN). The user gets access to the USIM only if he proves knowledge of the secret. Furthermore, access to a terminal or to other user equipment can be restricted to an authorized USIM. To this end, the USIM and the terminal must also share a secret. If a USIM fails to prove its knowledge of the secret, then, access to the terminal is denied. Application domain security deals with secure messaging between the MS and the SN or the SP over the network with the level of security chosen by the network operator or the application provider. Application-level security mechanisms are needed because the lower layers’ functionality may not guarantee end-to-end security provision. Lack of end-to-end security could be envisioned when, for instance, the remote party is accessible through the Internet. April 2013
48
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
USIM Application Toolkit provides the capability for operators or third party providers to create applications that are resident on the USIM. To assure secure transactions between the MS and the SN or the SP, a number of basic security mechanisms such as entity authentication, message authentication, replay detection, sequence integrity, confidentiality assurance, and proof of receipt, have been specified and integrated in the USIM Application Toolkit. Visibility: in general the security features are transparent to the user, nevertheless for certain events and according to the user's concern, greater user visibility of the operation of security features are provided. Therefore, the user can be informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up. In the same way, the user may be informed on the level of security that is provided by the visited network, in particular when a user is handed over or roams into a network with lower security level (3G>2G). Configurability: the user can configure whether the use or the provision of a service should depend on whether a security feature is or not in operation. A service can only be used if all security features, which are relevant to that service and which are required by the configurations of the user, are in operation. The following configurability features are suggested [34]:
Enabling/disabling user-USIM authentication: the user should be able to control the operation of user-USIM authentication, e.g., for some events, services or use.
Accepting/rejecting incoming non-ciphered calls: the user should be able to control whether the user accepts or rejects incoming non-ciphered calls;
Setting up or not setting-up non-ciphered calls: the user should be able to control whether the user sets up connections when ciphering is not enabled by the network;
Accepting/rejecting the use of certain ciphering algorithms: the user should be able to control which ciphering algorithms are acceptable for use.
4.2.2 LTE Network Security The radio technology chosen for LTE networks is not merely an incremental improvement or modification of the WCDMA radio technology used in UMTS, but a new RAT based on OFDM, similar to the radio technology used by WiMAX. The most important characteristics are:
The complexity of Diversity Combining/Soft Hand-Over (i.e., the same signal is sent to the mobile via two different cells) is abandoned, therefore the RNC is no longer required;
Much higher throughput: o Transmission bandwidth is up to 20 MHz (5MHz in UMTS); o Targeted spectrum efficiency is 5 bit/s/Hz for downlink, and 2.5 bit/s/Hz for uplink; o Consequently, the peak rates are 100 Mbit/s/cell for downlink and 50 Mbit/s/cell for uplink.
April 2013
49
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Much lower latency: the latency radio budget is targeted to be below 10 ms; hence, very stringent real-time behaviour is conceivable;
Support of high-speed mobility between cells, up to 350 km/h.
A SAE system has a full packet architecture. It is the first 3GPP system without a CS domain. Communication services are provided over the IMS architecture.
Very low end-to-end latency is targeted for both user and control plane traffic.
The number of nodes is reduced. This enables reduced latency, and also simplifies IOT20, network management and future evolution.
A SAE network supports mobility with legacy 2G/3G networks in the PS domain.
Interworking with the legacy CS domain has to be supported. Thanks to a new Release 7 feature called VCC21, a voice call set up in IMS can continue in a legacy CS domain.
Mobility between heterogeneous access networks has to be ensured, for example handover between 3GPP and WiMAX or between 3GPP and 3GPP2 networks. The generic architecture of the LTE network is illustrated in Figure 25.
Figure 25: LTE architecture [37].
From a four-node architecture in previous releases, the LTE/SAE network has a twonode only architecture:
The SAEGW: a multi-standard access system. It is the anchor point for the mobility between different access systems.
The eNB, which gathers all the purely radio-oriented functionalities.
April 2013
50
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
As in UTRAN in LTE the radio interface includes both the Access Stratum (AS) and the Non Access Stratum (NAS). Briefly, the AS includes all protocols used by the communication between eNodeB and the UE, control plane protocols (signaling) and data plane (user data traffic). The NAS is the higher level of the control plane, basically the communication between the UE and the MME. Most of the security requirements for 3G networks that have been described in the previous section also hold for LTE networks, since the most important requirement for the new networks is that at least the same level of security as exists in the 3G networks should be guaranteed. The new security features that have been introduced to the E-UTRAN to satisfy these requirements are presented in the paragraphs that follow. The first feature is a completely new ciphering mechanism and integrity protection for NAS signaling messages. On the radio interface this new NAS security leads to situations with double ciphering. On top of the protocol stack the NAS messages exchanged between the UE and MME are encrypted and the underlying RRC that acts as the transport layer for NAS is secured by ciphering mechanisms as well, so that the ciphered NAS message is ciphered together with its RRC transport message a second time. The second new security feature is the option to secure the complete IP-based transport of the control plane and user plane on the S1 reference point using Secure IP (IPsec). IPsec usage requires the monitoring software to be informed about which IPsec ciphering parameters (which can be changed frequently) are currently used in each of the involved endpoints of the IP connection. In a typical case these endpoints are the eNB and the MME or S-GW. To allow deciphering, there must be a dedicated Application Programming Interface (API) installed that allows the monitoring software to access IPsec-relevant parameters for deciphering. Besides these new security features, all the security elements from previous standards such as mutual authentication and masking of subscriber identity by using temporary identities can be found in the E-UTRAN. There is only a minor change here: the TMSI will be replaced by the new GUTI parameter. The overall LTE security concept is based on the introduction of a new hierarchical key system in which keys can be changed for different purposes. This LTE security key hierarchy, shown in Figure 26, includes the following keys: KeNB, KNASint, KNASenc, KUPenc, KRRCint, and KRRCenc.
April 2013
51
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Figure 26: LTE security key hierarchy.
KeNB is a key derived by the UE and MME from KASME or by the UE and target eNB from KeNB during eNB handover. KeNB should only be used for the derivation of keys for RRC traffic and the derivation of keys for UP (User Plane) traffic, or to derive a transition key KeNB during an eNB handover. KNASint is a key which should only be used for the protection of NAS traffic with a particular integrity algorithm. This key is derived by the UE and MME from K ASME, as well as an identifier for the integrity algorithm. KNASenc is a key which should only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by the UE and MME from K ASME, as well as an identifier for the encryption algorithm. KUPenc is a key which should only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by the UE and eNB from K eNB, as well as an identifier for the encryption algorithm. KRRCint is a key which should only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by the UE and eNB from KeNB, as well as an identifier for the integrity algorithm. KRRCenc is a key which should only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by the UE and eNB from KeNB as well as an identifier for the encryption algorithm. Whenever a call is established the security functions will work as shown in Figure 27 to Figure 29. The start trigger of the security functions is when an initial NAS signaling message sent by the UE that contains UE security capability information April 2013
52
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
arrives at the MME as shown in Figure 27. The security capability list informs the MME for instance about which ciphering and integrity protection algorithms are supported by this UE.
Figure 27: LTE Subscriber authentication.
After the MME has received the initial NAS message and it has not been in contact with this subscriber before, or if all previously received security tokens sent by the HSS have been used, the MME must contact the HSS to receive new tokens. Thus, the MME sends a DIAMETER authentication information request message to the HSS that contains the subscriber's identity. The HSS holds the secret network key "K" that is also stored on the USIM card of each subscriber. "K" is unique to every network operator. From "K" and the subscriber's identity the HSS derives three of the four parameters found inside the DIAMETER authentication information response message: the security key KASME, the Authentication Token (AUTN), and the Expected Response (XRES) parameter. The random number parameter RAND is truly just a random number. After the MME has received these four parameters, it produces three more derivatives from KASME. These derivatives are the NAS encryption key KNASenc, the NAS integrity protection key KNASint, and the security key for the eNB KeNB. What follows is the authentication procedure between the MME and the UE. The MME sends the unencrypted NAS authentication request message that includes the random number RAND and the AUTN. Now the UE must use its secret key "K" from the USIM card to calculate another number based on "K," AUTN, and RAND. The number is the UE's authentication response number RES. April 2013
53
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
RES is sent back to the MME by using the authentication response message, and in the last step of the authentication procedure the MME compares the value of RES to the value of XRES, which is the XRES value computed previously by the HSS. If RES and XRES have the same value the UE has successfully authenticated itself to the network and the NAS signaling connection can proceed.
Figure 28: NAS security initiation and RRC security initiation.
At this point, after successful authentication, it is time to activate the NAS security functions: namely, NAS ciphering and NAS integrity protection, as shown in Figure 28. Thus, the MME sends the NAS security mode command message to the UE including the security key KASME received previously from the HSS, and the algorithms for EPS encryption and EPS integrity protection that have been selected from the UE capability list and will be used to secure this NAS signaling connection. After the UE has received the NAS security command, it computes on behalf of the assigned EPS encryption/integrity algorithms and the KASME key the keys for NAS encryption and NAS integrity protection that are identical to those already stored in the MME. Now NAS security is in service the UE sends back the NAS security mode complete message, which is the encrypted and integrity protected NAS message. It is not mandatory to use NAS encryption and integrity protection. It is always up to the operator to decide what is required to secure the network. After the NAS security functions are in service, the underlying RRC connection and the ciphering for user plane traffic need to be activated. For this purpose, first a socalled security context is installed between the MME and eNB. Since security is not the only context-related information to be exchanged between these two network elements, the S1AP initial context setup message will also contain other parameters April 2013
54
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
besides the UE security capabilities and the eNB's security key KeNB. Note that the UE security capabilities so far are unknown to the eNB. Now the eNB derives the keys for RRC encryption (KRRCenc), RRC integrity protection (KRRCint), and user plane encryption (KUPenc) from KASME. Then the eNB sends the RRC security mode command message to the UE. This message contains the AS encryption algorithm and AS integrity protection algorithm bundled with the START parameters for the AS security activation procedure.
Figure 29: RRC security completion.
The UE computes the keys for RRC encryption (KRRCenc), RRC integrity protection (KRRCint), and user plane encryption (KUPenc) from the KASME together with the received keys and activates the requested security functions using these parameters as shown in Figure 29. After successful activation, the UE sends the RRC security mode complete message (i.e., ciphered and/or integrity protected) back to the eNB. And the eNB confirms the successful establishment of the security context to the MME by sending the S1AP successful outcome message for the procedure code "Initial Context Setup". Finally, regarding signalling in LTE, 3GPP mandates the use of Diameter, an IP-based open protocol that can handle better than SS7 (used in 3G) the increase in signalling traffic volume. Diameter is used for signalling across all core network elements and is crucial to billing, traffic and subscriber management, subscriber authentication, roaming, and mobility management. As a result, security of Diameter traffic is highly sensitive, because the traffic includes user passwords, location data, network addresses and cryptographic keys. IPsec or TLS are used to secure Diameter traffic, especially when it is used to share information with partners, for instance for roaming, or, more generally, when traversing unsecure parts of the network. While IPsec provides traffic encryption, operators need to take further actions to protect themselves from signalling flood threats, which may be caused either by malicious activity explicitly directed at the mobile network, or accidentally, for instance as an unintended and indirect effect of upgrades or through applications April 2013 55
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
that generate large amounts of signalling when they are widely adopted. Regardless of the cause, signalling floods block or limit subscriber access, and they may also compromise the overall security of the network as some of the core elements’ functionality is lost. Diameter signalling floods are an emerging threat to mobile networks, and the industry – mobile operators and vendors alike – does not yet fully understand their causes, forms and impact. Understanding and preventing the sources of signalling floods is the first priority. This requires better network intelligence and visibility into the dynamics of network traffic, to identify the network’s vulnerable entry points and how malicious threats are evolving with time. Tools like topology hiding can be used to prevent or contain attacks directed at the core network. In the event of a signalling flood attempt, operators also have to be able to rely on effective traffic management, including load balancing, policy enforcement, and validation of legitimate signalling traffic to minimize disruption [79].
4.3 Vulnerabilities and attacks to 3G and 4G networks In the following, we provide a discussion of the possible attack scenarios and known vulnerabilities of mobile networks. The mobile network industry currently lacks sufficiently capable tools for monitoring the network for the identification of the discussed threats, although specific countermeasures to some of these threats are known, which can be applied only after their detection. Among the possible threats to the mobile network, denial-of-service (DoS) attacks are the most significant due to their practicality and possible impact on the users and mobile network [69], [65]. Potentially, the impact can extend to the entire targeted cell (all the UEs registered therein). However, the severity of the impact is not easy to be esteemed, it basically depends on the amount of resources available to the attackers, the importance and the capacity of the attacked cell, etc. We will not focus here on the risk evaluation of the described attacks, but some discussion on this issue can be found in [30]. The DoS attacks examined in this section are:
RACH Flood: sending a massive number of access requests in order to trigger radio channel allocations;
FakeBTS and Jamming: by using a Fake BTS or a radio interference generator, prevent the users under coverage to connect to the real mobile network;
SMS Flood: sending a massive number of SMS messages to a high number of users or to a specific target service so as to provoke network congestion and/or overload of the receiver’s buffer;
Signaling Flood: sending unprotected (and hence forgeable) signaling messages to the network.
4.3.1 RACH Flood The RACH is the uplink channel used to send the request for the radio resources allocation in order to start the communication (both voice and data communication). A standard GSM UE usually sends 3 RACH requests in order to have a higher probability of success in finding a free slot on the radio channel. If it does not receive April 2013
56
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
a valid acknowledgment ACGH (immediate assignment on the ACGH channel) before a timeout period, it sends other 3 RACH requests. These requests do not contain any authenticated identification information, they only contain a random code generated by the UE. As a consequence, it is possible for an attacker to send a high number of such requests and exhaust the radio channel: the BSS cannot identify the attacking terminal and cannot stop the attack. This anonymous DoS attack scenario was examined in [66], [69], [72]. Thanks to the availability of open source tools, like Osmocom [68], this attack is very easy to set up. In GPRS, the first request the UE does is the uplink channel request (Packet Channel Request, PRACH), but it can also use the RACH channel like in GSM. If the PRACH channel is used, the network responds with a Packet Uplink Assignment on the PAGCH channel, or an immediate assignment on the AGCH channel. In both cases, the message contains the indications of the Packet Dedicate Channel (PDCH) to use in uplink. GPRS implements congestion control mechanisms (admission control): for example, when the BSS does not have enough resources answers with a Packet Queuing Notification (containing a Temporary Queueing Identifier), such as to block subsequent requests from the same UE, which cannot be satisfied at the moment. The UE waits for a Packet Polling Request before sending further requests. The PRACH message contains the number that identifies the reason of the request (the Radio Priority code) and a random number. Therefore, it is still possible to set up an anonymous DoS by sending a large number of requests, like in GSM. The admission control mechanism previously described does not offer protection against this flood attack, quite the contrary: the UEs not generating requests reduces the channel collision probability and the attacker(s) are facilitated on their work. As far as the feasibility of the attack is concerned, there are no open source tools to use to implement it, but it seems that the Osmocom Community is working on an open source implementation of the GPRS stack [80]. In UMTS, the RACH/PRACH channel is used to start a voice or data communication through a RRC Connection Request. Here the RACH channel can be used to transport other message types (e.g., the Cell Update message to indicate that errors are present at the RLC level) or small amounts of packet data from the terminal to the network (low bit rate data). There are some differences from the previous architectures: first, a short burst on the RACH channel is sent, the terminal waits for the response on the AICH channel and then the real RACH message is sent. The procedure is explained in detail in [64], [67]. In this procedure it is possible to find two critical issues: the UE sends RACH requests with a strength that increases exponentially till an ACK is received, and two or more UE can use the same preamble data at a given instance. By exploiting these vulnerabilities it is possible to generate a DoS towards other users. A software was made available for ad hoc terminals, able to generate arbitrary RACH requests correctly decoded by NodeBs, such that it is possible for an attacker April 2013
57
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
to send a high number of sequences containing the right network signatures, thus generatin conflicts amongst victim terminals [61], [64]. These terminals cannot connect to NodeB because of the strong radio interference created by the attackers and themselves: since they do not receive a response from the network, they elevate their radio level and provoke further interference. WCDMA [67] is particularly sensitive to this kind of disturbing attack. In conclusion, in UMTS it is still possible to set up a RACH requests flood, but this will not exhaust RNC resources. In UMTS there is no dedicated radio channel assignment after a RACH request, but shared channels are used. The dedicated channel is assigned in a second phase (through the RRC Connection Request). Hence it seems that a large number of requests cannot compromise the RNC, but it can provoke radio jamming and DoS to other users that are in the proximity of the attacker. In LTE the radio access technique is based on OFDMA, where each user is assigned a certain band for a given time. The cell research in LTE uses two synchronization signals the Primary Synchronization Signal (PSS) and the Secondary Synchronization Signal (SSS). The detection of these signals permits the synchronization in downlinkand offers to the terminal the basic OFDM information. The terminal can then start a RACH requests to also obtain an uplink synchronization and be able to start voice and data communications. There are two possible RACH procedures: Contention Based and Non Contention Based. In Contention Based each terminal chooses a random preamble (signature) to send; hence a probability exists for a collision to manifest (i.e., two terminals that send the same signature). The eNB has to run a process named “contention resolution”. In Non Contention Based the eNB assigns to a terminal a dedicated signature in order to prevent collisions. This procedure is applied in case of a handover or in the case that there are no new downlink data for the requesting terminal. The RACH LTE procedure is similar to the one of UMTS: the eNB can configure the use of “power ramping” mechanisms, such that the transmission power of a preamble can be increased by a fixed value when the terminal does not obtain a RAR response to its request. However, since the preambles for the RACH access in LTE are orthogonal to other uplink transmissions, the necessity to use such a mechanism is minor than in UMTS WCDMA. Therefore, the percentual of successful first RACH requests is probably higher than the one experienced in UMTS. The main critical point of the RACH LTE procedure is related to the collision that can be present when two or more terminals send the same preamble in the same resource (i.e., in the same time-frequency frame). A malicious user could send to all resources announced by eNB all the possible signatures such as to generate continuous collisions to legitimate users. The eNBs are designed to manage RRC Connection Request messages collisions. As a consequence, one of these artificially generated requests is successfully decoded by the eNB, while the others will not receive a response. It is then possible to provoke the re-transmission of a RACH request. If a high number of RACH requests are generated is very probable that the requests generated by the legitimate terminals cannot obtain the response because of the collisions and experiment a DoS situation. April 2013
58
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
It is highly improbable to use RACH flooding to saturate the eNB, because there is no immediate dedicated channel assignment after a RACH request. As far as the availability of practical attack tools is concerned, some initial work exists on an open eNB LTE software implementation (like [82]).
4.3.2 SMS Flood This type of DoS attack was identified in GSM [92] and is based on the possibility to send SMS messages from the Internet through service gateways that connect SMSC to Internet. The procedure to send an SMS is quite complex and engages different radio and core network resources. The network sends paging messages to locate the user at the level of a location area (which might have more BSS systems). 1. The MS or UE responds with the activation of the RACH request procedure which concludes with the assignment of a SDCCH channel. 2. A Location Update procedure follows with or without authentication (depending on the network configuration). The SMS flood consists in sending a large amount of SMS messages to various users, thus trying to saturate the radio resources (congestion) and the message buffers on the single terminals. Some massive SMS spam campaigns can cause, as a side effect, an SMS Flood. For example, for Android phones an application is available (suggestively named SMS Bomber) able to send a configurable number of SMS messages to all contacts. The GPRS network is vulnerable to this kind of attack because the radio interfaces are shared with the still existing GSM networks. An SMS Flood in GSM can hence have an more or less large influence on the GPRS network. The UMTS network is vulnerable to this kind of attack, but the impact of this attack is very low, thanks to the introduction of admission control and QoS control mechanisms. The LTE network could be vulnerable to SMS Floods in the early deployment stages, when the SGs interface between MSC-S and MME has to be active for the CS Fallback management on 2G and 3G to be able to convey SMSes on the LTE access. The impact of the attack is to be considered low because of the congestion control mechanisms present in LTE.
4.3.3 FakeBTS and Jamming A DoS attack through Fake BTS is based on the usage of a faked physical BTS that generate a signal which is more powerful than the signal of the BTS of a real MNO (mainly because it is placed nearer the UE). When the UE tries to connect to this fake BTS, the UE is detached from the real network, hence it cannot use any of its resources. Another attack scenario can be: the attacker uses a FakeBTS to forward traffic from and for the network and can try to block or manipulate some messages, for example, April 2013
59
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Authentication Response, TMSI reallocation complete, UMTS Counter Check Response, UMTS Security Mode Failure, and, in general all messages that are not protected with integrity controls. This can cause DoS to some users, but also inconsistent states in UE or in some core network elements. For example, the standards do not define what happens if the RNC does not receive the Counter Check Response message. This scenario is straightly related to another attack scenario, called Signalling DoS, described in one of the following section. Another attack technique uses jamming of the frequencies used by the mobile telephony. This attack is very easy and cheap to perpetrate for all existing architectures (450$ for a noise generator and 400$ for a power amplifier at 100W). These attacks are very difficult to detect/prevent by the operator.
4.3.4 Signaling DoS Some of the most dangerous DoS attacks to mobile networks are realized by sending or provoking the exchange of a large number of signaling messages. Mostly, these are messages that are not protected by any security mechanisms (e.g., integrity or encryption). The attack scenarios might be: 1. DoS to the network and its users; 2. Inconsistency of the victim UEs and network elements internal states. The first DoS scenario is possible in all architectures 2G, 3G and even 4G, because in all of them unprotected signaling messages are exchanged. Therefore, an attacker can forge such messages, and especially those messages that require onerous procedures that consume many computational resources on the CN nodes. In the following table we give some possible examples.
Message
Location Update IMSI Attach
Routing Area Update GRPS Attach
RRC Connection Request
April 2013
Network
Description
GSM, UMTS
Sending large numbers of IMSI Attach requests. This starts the authentication procedure which involves the network elements MSC, HLR and AuC.
GPRS, UMTS
Sending large numbers of GPRS Attach requests. This starts the authentication procedure which involves the network elements MSC, HLR and AuC.
UMTS, LTE
In UMTS, sending a large number of RRC Connection Requests containing security capabilities and Initial Identity of the UE. This starts the AKA procedure, which involves the 60
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
MSC/SGSN, HLR and AuC. In LTE, sending a large number of RRC Connection Requests, each containing a random value* in UE Identity and Establishement Cause set to “Mobile Originating Signalling” to indicate to the network that the connection request arrives to initiate an Attach procedure. Each of these requests initiates the assignment of a dedicated channel on which the EPS AKA authentication procedure is subsequently run. Such procedure involves the MME and the HLR. Obviously the procedure fails, but network resources are uselessly assigned and occupied. Table 6 Signaling DoS attack scenarios.
All the protocols used in AS and NAS use timers to manage the data exchange and the state transitions of the protocol state machine. If we analyze these timers and the protocol state machines’ behaviour in case of anomalies, we may envision multiple attack scenarios due to their blocking or manipulation by a malicious user. In the following table we examine some possible examples. Message
Location Update Accept/Failure
TMSI-REALL-CMD
TMSI REALL-COMPLETE
April 2013
Network
Description
GSM, UMTS
We assume that the attacker manages to block these messages. When the T3120 timer expires on the victim UE, the T3211 timer is started. When this timer expires, the UE restarts the procedure.
GPRS, UMTS, GSM
The attacker manages to block this message. When the T3218 and T3210 timers expire, the UE cancels some data (SRES and RAND) and restarts the procedure. The network waits for a TMSI Reallocation Complete message which will not arrive. When the timer T3250 expires, the network could drop the connection (at level 2).
GPRS, UMTS, GSM
The attacker manages to block this message. The network maintains the new and old TMSI/IMSI associations till this message arrives. When there are repeated TMSI Allocation failures 61
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
(a threshold is configured by the operator), the MSC/SGSN can take actions that are not defined by the standards. ATTACH Accept
ATTACCH COMPLETE
Counter Check Response
RRC Connection Request
April 2013
GSM, GPRS, UMTS
The attacker manages to block this message and the UE cannot complete the network registration procedure.
GSM, GPRS, UMTS
The attacker manages to block this message and the network retransmits the previous message (Attach accept or TMSI REALL CMD).
UMTS
The RRC connection procedure in user plane is protected by an integrity control implemented through the periodic local authentication procedure. This means that the MS and the RNC periodically control that no packets have been inserted in the communication by looking at the CountCUE (amount of data sent by the MS) and CountCRNC (amount of data received by the RNC) counters. When CountCRNC reaches a limit, the RNC sends to the MS a Counter Check containing the most significant bits of the CountC counter for each active bearer. The MS controls the bits, computes the difference and sends it in a Counter Check Response to the RNC. If at least one difference is > 0, then the RNC drops the connection by sending a RRC Release. These messages are all protected by an integrity code, but the standard does not specify what happens if a malicious modification is detected by the RNC, which can drop the connection, but also wait indefinitely for a valid Counter Check Response.
UMTS, LTE
In UMTS, an attacker (by using a fake BTS) can intercept the RRC Connection procedures initiated by the UEs. An UE in idle mode sends a RRC Connection Request with its security capabilities 62
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
(SC) and Initial Identity. The attacker intercepts these messages and modifies the sc. The procedure goes on and the AKA terminates when the UE receives the Security Mode Command. This message includes the modified sc and the UE sends a Security Mode Failure. By continuously repeating this procedure a DoS can be provoked to the target terminals. In LTE, an attacker can use a fake BTS and simulates the behaviour of the network towards the victim UE and of the terminal towards the network. During the EPS AKA procedure the attacker modifies the security capabilities (SC). When the Security Mode Command arrives including the modified SC, the procedure fails and the UE sends a Security Mode Failure. By continuously repeating this procedure a DoS can be provoked to the target terminals. For the attack to succeed the victim UE does not have to be previously registered to the network, because in this last case the RRC request is protected through encryption and integrity, by using the security protocols previously negotiated and the modification of the SC is impossible. Table 7 Signaling DoS attack scenarios based on state inconsistencies.
Some of these signaling attack scenarios are discussed in the deliverable D1.2 of the project, since the detection of signaling based attacks is one of the use case that NEMESYS will try to illustrate. Other attacks, like identity spoofing, eavesdropping on various links, voice call hijacking, TMSI tracking, etc., are also well described in the literature. At the moment such attacks are difficult to be detected by the existing conventional security tools, but some of them can be detected by the NEMESYS tools implemented at the network side, as explained, for example, in deliverable D1.2 of the project.
April 2013
63
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
4.4 Femtocell security Due to the physical characteristics of the radio waves in the high frequencies that the cellular networks use, the provision of good network coverage in indoor locations is problematic, and it poses a serious challenge for the mobile carriers to overcome. To address the bandwidth and quality of coverage demanded by their subscribers, mobile operators are turning to femtocell systems. Femtocell Access Points (FAPs) are close-range, limited-capacity base stations that utilize residential broadband connections to connect to carrier networks. The use of such distributed base station architecture improves reception and allows the operators to deliver fast, seamless, high-bandwidth cellular coverage inside the homes and offices of their end customers. The deployment of femtocell solutions is overwhelmingly attractive to mobile network operators as they successfully address coverage and mobile data bandwidth requirements by leveraging widely available broadband connections without the extraordinary cost associated with the alternative macro-cell deployment. Like all communications technologies, though, femtocells also require robust security. The basic femtocell system architecture is depicted in Figure 30:
Figure 30: Femtocell Architecture [38].
The system architecture has the following features:
The backhaul link, being unsecure through the Internet, is connected from the Femto AP (FAP) to the operator’s core network via a SeGW (Security Gateway).
The SeGW, being the entry point to the operator’s core network, performs mutual authentication with FAP.
An AAA server authenticates the hosting party module, a SIM card based mechanism that is optionally deployed in the Femto architecture to help the operators to effectively manage the FAP.
Security tunnel is established between FAP and SeGW to protect information transmitted in backhaul link.
Femto AP Management System (FMS) can configure the FAP according to the operator’s policy (e.g. spectrum reuse policy, location policy, etc.). FMS is also capable of installing software updates on the FAP. The FMS server may be
April 2013
64
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
located inside the operator’s core network (accessible on the Mobile Network Operator’s Intranet) or outside of it (accessible on the public Internet), depending on operator’s model or preference. However, secure communication is required between FAP and FMS (e.g. TLS or IPsec).
A Femto GW and/or FAP perform(s) the access control in case nonCSG (Closed Subscriber Group) capable UEs or non-CSG capable FAPs are deployed depending on the level of equipment deployed. Femto is capable of being deployed in various scenarios to accommodate equipment from different releases of 3GPP specifications thus achieving backward compatibilities.
FMS and/or Femto GW perform location verification of FAP to ensure that the FAPs operate in an area where the operator has licensed spectrum to operate. FAPs (or Home (evolved) Node Bs – H(e)NBs) and security gateways leverage ubiquitous broadband (ADSL, ADSL2+, cable, etc.) IP communications for the backhaul of cellular voice and data communications. As with any IP-based networking architecture, the communications between the client device, the FAP, and the carrier’s core network must be secured against eavesdropping, fraud, and other malicious activity. Third-party attacks on networks (Figure 31) include man-in-the middle, traffic snooping/redirection, fake base station attacks, and authentication snooping. These attacks target the communications between the handset and the FAP and/or the FAP and the FGW for the purpose of eavesdropping, service disruption, attack staging, or billing fraud.
Figure 31: Points of Attacks in Femtocell Architecture [40].
Security concerns associated with femtocell-enabled networks can be classified into three main categories:
Device and network authentication: FAPs and the network must mutually authenticate to become part of the cellular network.
Data privacy: When the connection to the carrier is over a public, hostile, and unreliable IP network, the privacy and therefore confidentiality of data shared between the FAP and the network and handsets must be ensured.
April 2013
65
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Integrity: When the FAP is physically vulnerable to tampering by malicious users, the validity of billing, subscription, and device data must be secured. The security mechanisms designed to fulfil these requirements are the following [83]:
FAP Physical Security
FAP and Core Network mutual authentication and IPSec tunnel establishment
Location Verification
Access Control
Protection of FMS traffic between FMS and FAP
Measures for Clock Protection.
4.4.1 FAP Physical Security 4.4.1.1 Trusted Environment (TrE) To provide FAP physical security, the logical entity of Trusted Environment (TrE) is defined and used based on an irremovable, hardware-based root of trust by way of a secure boot process, which will occur whenever a FAP is turned on or goes through a hard reset. An example implementation of such a TrE may be realized in the form of existing technology, such as a trusted platform module (TPM) commonly found in today’s high end personal computers. It is important that the root of trust is physically bound to the FAP and that a secure boot process is used that includes checking the integrity of every loaded or started component of the TrE and only allow components to be loaded or started upon successful integrity validation. 4.4.1.2 Device Integrity Check FAP and TrE will perform a device integrity check upon booting and before connecting to the core network and/or to the FMS. The device integrity check is based on one or more trusted reference value(s) and the TrE:
The integrity of a component is verified by comparing the result of a measurement (typically a cryptographic hash) of the component to the trusted reference value. If these values agree, the component is successfully verified and can be loaded and/or started.
The integrity of the device is verified if all components necessary for trusted operation of the device are verified.
4.4.1.3 FAP validation FAP supports a device validation method where the device implicitly indicates its validity to the SeGW or FMS by successful execution of device authentication. But various validation techniques are possible: 1. Autonomous validation 2. Remote validation 3. Semi-autonomous validation 4. Hybrid validation In an autonomous validation, FAP’s validity is assessed internally within the FAP itself without depending on external network entities. In a remote validation, an external April 2013
66
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
platform validation entity assesses the validity of the FAP after it receives comprehensive evidence for the validation generated by the FAP’s TrE. In a semiautonomous validation, the FAP’s validity is first assessed internally by the TrE without depending on external entities. After the TrE makes such an assessment, the assessment and any additional required evidence are sent securely to an external platform validation entity that subsequently makes its own decisions based on whether to grant access. In a Hybrid validation, a FAP powering up will execute a secure start-up procedure to bring it to a determined and trustworthy state. Additionally, FAP will gradually bring the rest of the system, modules, and other components to a trustworthy state.
4.4.2 FAP and CN Mutual Authentication and IPsec Tunnel Establishment Since there may be two trusted entities (e.g. FAP itself and the hosting party module) in the FAP, the FAP supports the following authentication procedures:
Device authentication: Mutual authentication of FAP device and the operator’s network is mandatory performed when a FAP accesses the network.
Hosting Party Authentication: Authentication of the hosting party by the operator’s network is based on credentials contained in a separate Hosting Party Module (HPM) in FAP. This authentication may be optional depending on an operator’s network configuration.
A combined authentication is also possible to maximize efficiency without sacrificing security
4.4.2.1 Device Authentication Device authentication of FAP (H(e)NB) is based on device certificate for FAP and network certificate for the core network with the TrE securely protecting the FAP’s credentials and critical security functions, including the authentication function. An example of certificate -based device Authentication Call-flow is shown in Figure 32.
Figure 32: Certificate-based authentication with device integrity [44]
April 2013
67
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
4.4.2.2 Hosting Party Authentication The authentication of the hosting party is based on an AKA credentials contained in a separate Hosting Party Module (HPM) in FAP. The SeGW acts as an EAP authenticator and forwards the EAP protocol messages to the AAA server to retrieve an authentication vector from the operator’s authentication centre via HSS/HLR. An example call flow between the FAP, SeGW and AAA server is shown in Figure 33. This example illustrates a certificate based mutual authentication between the FAP and the core network, followed by an EAP-AKA-based HP authentication exchange between the FAP/HPM and the AAA server.
Figure 33: Combined Certificate and EAP-AKA-based Authentication [44].
4.4.2.3 IPsec Tunnel Establishment After the device authentication, HPM authentication or combined authentication, IPsec tunnel is established between the FAP and the SeGW, setting up a pair of unidirectional security associations. After that point onward, all signalling, user, and management plane traffic over the interface between FAP and SeGW will be sent through that tunnel operating in IPsec ESP tunnel mode.
4.4.3 Location Verification Operators require assurance of the FAP location to satisfy various security, regulatory and operational requirements due to the fact that the FAP, being a network component, requires the use of licensed spectrum which the operator has acquired for specific geographical location or region. The FMS and/or femto GW may act as the verifying node to perform location verification. The verifying node needs one or more of the following information elements to perform location verification: April 2013
68
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
The public IP address of the broadband access device provided by the FAP The IP address and/or access line location identifier provided by the broadband access provider Information of macro cells surrounding the FAP provided by the FAP Geo-coordinates provided by a global navigation system satellite receiver embedded into the FAP.
4.4.4 Access Control To prevent unauthorized access, only the authorized users can be allowed to access a FAP. An authorized user may be the FAP purchaser’s friends and family but not his neighbour. To set up such an access control, the user may need to enter a list of cell phone numbers that are allowed to be connected to the FAP in an access control list, either through his own phone or through a web interface provided by the operator. Due to the capabilities of the user’s mobile equipment, it is necessary to consider the cases when the mobile is non-CSG capable and when the mobile is CSG capable. 4.4.4.1 Non-CSG Method Older equipment that does not support CSG can be either a non-CSG capable mobile or a non-CSG capable FAP. In this case, Femto GW and/or FAP will perform the optional access control based on the access control list stored in Femto GW and FAP. 4.4.4.2 CSG Method For newer equipment that are CSG capable (mobiles or FAPs), other network elements in operator’s core network (e.g. mobility management entity) will perform access control for UE for accessing FAP.
4.4.5 Protection of FMS traffic between FMS and FAP 4.4.5.1 Connection to FMS Accessible on MNO Intranet When FMS is accessible on within the operator’s network, FMS traffic will be protected through the support of one of the three security mechanisms determined by the Network Operator’s Security Policies:
Hop-by-hop: FMS traffic is protected between FAP and SeGW in one security association and then between SeGW and FMS in yet another security association. Network security mechanisms will be used to protect FMS traffic between SeGW and FMS when the path from SeGW to FMS is considered as insecure.
End-to-end: FMS TLS tunnel is established between Femto AP and FMS.
End-to-end within IPsec between FAP and SeGW: The end-to-end TLS tunnel may be ignorant of the existence of an already established IPsec tunnelled between FAP and SeGW.
4.4.5.2 Connection to FMS Accessible on Public Internet When the FMS is accessible on the public Internet (in case the FMS is managed by a third party other than the operator), the FMS is exposed to attackers located in insecure network. FMS traffic will be protected by TLS tunnel established between April 2013
69
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
FAP and FMS. In this case, mutual authentication between Femto AP and FMS will be based on device certificate for the FAP and network certificate for the FMS.
4.4.6 Measures for Clock Protection For a FAP that does not rely on strict chip-level synchronization, an internal clock may be considered as extraneous. However, the availability of the correct current time is important for certificate validation and thus for the establishment of secure links (IKEv2 and/or TLS). In addition, the internal clock and the network clock should be synchronized upon establishing a secure connection to the core network. To ensure the security of the current time, the last time at which the FAP was active before the current power-up should be recorded and saved in the TrE.
4.5 State of the art in Attack traces collection There are two types of trace collection techniques existing nowadays: passive and active. The passive collector waits for an attack and might interact with the attacker’s infrastructure while recording traces, whilst the active collector initiates the communication to the attacker’s infrastructure by executing a malware or browsing a web page containing malicious code while recording traces. Both of them use sensors to collect the traces. A sensor is a program or a device that monitors a resource, such as network traffic.
4.5.1 Passive collection For collecting passive traces, the sensors can be host-based, i.e., the collection of data is at the end-user level, or network-based, i.e., the data are collected at the network level, or both. 4.5.1.1 Host-based sensors Host-based Intrusion Detection Systems (HIDS) detect potential security breaches at the host level. The detection is carried over by placing sensors at the host to collect traces by monitoring the internal communications of the host and check if the traces contain patterns of attacks. For instance, they can monitor the file system changes, the messages that are sent out and received, etc. Virtualization technologies can be used as environments for launching and tracing attacks at the host level. Massicotte et al. [42] have used it to create a virtual network in one physical machine. The purpose was to study the attacks in a network, e.g., detecting vulnerabilities of software, etc. For this, they have used the VMware Workstation 5.0 [41] to create virtual hosts simulating a network of computers. The VMware technology enables to easily create templates of virtual machines with different configurations (e.g., Operating System, etc.). Since the network is virtual, the attack propagation is confined and the network traffic can be easily cleaned up. Viruses, generally having malicious purposes, can also be used for good purposes, e.g., collecting traces. HP [43] used them for protecting its network from the worm Blaster. The virus code was popping up a warning to every unpatched machine of the firm’s network. Another initiative was to disconnect every machine that was unpatched.
April 2013
70
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
Cyber weapon is nowadays a fact. Projects [44] and [45] at the country level would be carried over to trace and disable attacks at a large scale. The virus would infect an overwhelming majority of computers. It would log the traffic data and assess if an attack is occurring in which case it counterattacks. This would also enable to know the attacks’ sources. Honeypots are also used for collecting traces. They will be explained in the next section. 4.5.1.2 Network-based Network Intrusion Detection System consists in inspecting the network to detect any potential security breaches. It is carried over by placing sensors in a network which trace the network traffic. Generally, Intrusion Detection Systems (IDS) set one or more interfaces in promiscuous mode, which makes them stealthy. They are useful to spot unusual traffic trends. Snort [46] is a good free and open source version of IDS. Chen et al. [47] have sniffed the real traffic of several networks aiming to extract attack sessions. These attacks were later on replayed in networks of other Internet Service Provider in order to test and tune up their Intrusion Prevention System (IPS). IPS is an extension of IDS but unlike IDS, they block detected attacks automatically. By tuning up, we intend the diminution of false detection rate and increasing of the true positive rate of IPS. The traffics were sniffed by means of the PCAP library which is also used by the software “Wireshark” [48]. Lakhina et al. [49] have proposed a way of detecting distributed attacks by sniffing the network-wide flow traffic. Their experiment consisted in sniffing the IP level traffic at 11 points of presence in the US continent. They were interested in tracing the Origin Destination (OD) flows of a whole network. The origin is defined by the router with the ingoing traffic and the destination router with the outgoing traffic. The hop-by-hop IP traceback [50] is used for tracing large and continuous packet flows that are generated by an ongoing Denial of Service (DoS) in a network. This traceback consists in identifying the routers that have been used to forward the traffic used by the DoS in a backward manner. For this, the closest router to the victim is firstly identified and then the other routers upstream, until the router at the boundary of the network forwarding the attack is found. Backscatter [51] is a technique used for tracing the flood of packets issued by a Distributed Denial of Service (DDos) attack. It consists in redirecting the traffic of the DDoS to a blackhole which is represented by a machine. These packets participating at the DDoS are blocked by the routers upon detection of a un-assigned IP address. The un-assigned addresses are often used in DDoS attacks. When such packet is detected, it is dropped and an ICMP is sent to the blackhole. The blackhole records the ICMP’ issuers and uses this information to trace the attacks, i.e., the routers at the outermost boundary of an ISP that were used to forward the traffic of the DDoS. Honeynets are also used for collecting traces. They will be explained in the next section.
4.5.2 Active collection Honeyclients are active collectors as opposed to honeypots. Unlike honeypots, honeyclients initiate the attack by executing a malware binary for instance or April 2013
71
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
browsing a web page containing malicious code. These honeyclients are confined to avoid the propagation of the malware over the network. The confinement is generally carried over by emulators such as Android emulator [52], VirtualBox [53], VMWare [41], etc. Antivirus programs can also be considered active collectors. Before a program is executed, it is statically analyzed, for searching for malicious codes. For this, the antivirus collects traces which are pieces of code and compare them against malware signatures. Upon matching, the program is either quarantined or deleted. Anomaly detectors unlike antivirus programs detect the malware while executing the binaries. In order to compare the malware profile with the model of goodware and see their deviation, they first need to create the profile. The profile is created as a result of the interactions between the binary and the system such as internal communications, or/and communications with other systems, i.e., traces. Androguard [22] is a tool, written in Python, aiming to analyze Android applications, execute them, and collect the traces generated by the applications. The traces can be system calls, SMS sent, network traffic. Anubis [31] is a service which analyzes Android malware but also Windows malware. The service executes the malware in a confined environment, traces the applications and its interactions, and gives a report. The tool records the list of Dynamic Link Libraries (DLL) imported, the packer that has been used, the entries in the Windows registry that have been modified and accessed, the files read and written, the communication, etc. Strace [54] is a debugging utility for Linux and other Unix systems. It enables to capture the system calls used by a program and all the signals. A system call is a call from a user land to the kernel land in which a program asks for the service of the kernel (e.g., accessing the hard driver, send message over the network, etc.). This tool was used for instance by Burguera et al. [55] to create a trace of an Android application and later on classify it into the malware set or the goodware set. Similar tools exist such as truss [56], ltrace [57], etc. TaintDroid [58] is a dynamic taint tracking for Android OS which is capable of tracking multiple sources of sensitive data (e.g., emails, phone contacts, etc.). This taint tracking is dynamic and reposes on the principle of source and sink. The system tracks the data that are issued from the source, i.e., sensitive data until the sink, i.e., the network. If a sensitive data arrives until the sink, it means that a sensitive data has been sent out. This mechanism enables to collect the traces, i.e., which sensitive data have been sent out.
April 2013
72
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
5 NEMESYS Advances The protection of the mobile devices is a domain for further investigation and open to advancements regarding security in mobile ecosystem. As far as the wireless networks are concerned, the exploitation of network intelligence and the visualization of traffic information in real time could contribute to the detection of attacks and the comprehension of their impact on the mobile network. In addition, mobile security can be improved by the adoption of additional solutions that are suitable for the protection of IP-based LTE and other networks (small cells, femtocells, corporate, WiFi hotspots, etc.), which are integrated in the mobile networks and are increasingly accessed by mobile devices. Taking into account the State-of-the-Art in mobile security ecosystem, as described in the previous Sections, NEMESYS aims to:
Gather and analyse information about the nature of vulnerabilities found on mobile devices
Adopt the honeypot scheme for a smartphone platform
Develop an infrastructure to gather, detect and provide early warning of attacks on mobile devices
Understand the modus operandi of cyber-criminals that target mobile devices
Reveal possible shifts in the manner in which cyber-criminals launch attacks against mobile devices vs. wireline networks.
The technical and scientific objectives of NEMESYS are the following:
Detection of existing and emerging threats in the mobile ecosystem through root cause identification and correlation of new findings with known attack patterns.
Implementation of a virtualized honeypot prototype for the most common mobile platform utilizing virtualization technology for increased efficacy and security.
Development of a comprehensive set of analysis tools: o A high-interaction honeyclient for the identification and prediction of abnormal behaviour patterns. o Modules for the detection of abnormal events in mobile networks and within femtocell architectures. o An interactive, scalable and future proof visual analytics tool that facilitates the role of the security analyst in reasoning, hypothesis testing and decision. o Innovative methods to analyze security issues arising from technological evolution and emergence of new attacks (e.g., mobile botnets).
April 2013
73
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
o Attack detection and classification algorithms, using normal user behavior statistics and synthetic “typical” user playbacks. The main innovations of NEMESYS concept comprise the development of:
Novel security framework for the identification and prediction of abnormal behaviour observed on smart mobile devices, as well as for gathering and analyzing information about the nature of cyber-attacks targeting mobile devices, so that appropriate countermeasures can be taken to prevent them.
Virtualized honeypots for mobile devices and data collection infrastructure and the introduction of novel attack attribution and visual analytics technologies for the mining, presentation and representation of large amounts of heterogeneous data that are related to the smart mobile ecosystem.
April 2013
74
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
6 Conclusions Today, there is a widespread adoption of smart mobile devices built on a fullyfledged mobile operating system, with more advanced computing capability connectivity than an ordinary mobile phone. Smart phones started by supporting the functions of a personal digital assistant (PDA), followed by the functionality of portable media players, low-end compact digital cameras, pocket video cameras, GPS navigation units , high-resolution touch screens and web browsers to eventually provide high-speed data access by Wi-Fi and mobile broadband, while the current rapid development of mobile application markets and of mobile commerce have been major drivers of smartphone adoption in everyday life. Smart phones have experienced the fastest worldwide adoption since the advent of television. As we have seen in the first part of the present document, mobile devices are attractive not only for end users but also for cybercrime and malware developers. In terms of malware widespread and sophistication it seems that the trend is similar to that followed by malware developed for PC platforms, but in a much faster way. Moreover, differently from traditional PC platforms, smartphones are natively a source of profit (the user’s phone/data traffic credit), and this makes them very attractive to cybercriminals. From the network perspective, and focusing on the advanced 3G (UMTS/HSPA/HSPA+) and the emerging 4G (LTE) access network technologies, emerging threats include the growth in application layer vulnerabilities, risks presented by smartphone application developers and OSs, excessive signalling in the network generated by smartphones and smartphone applications. Especially the flatter LTE IP-based architecture (IP backhaul, RNC node elimination, termination of the user’s traffic encryption in the eNodeB, more signalling and bearer paths between network elements) gives a potential attacker a straighter path to the network core through devices, the RAN, backhaul and external third party networks. With the move to IP based networks, security issues such as the compromise of the user’s location, digital rights management, Spyware or Adware download, the compromise of users’ sensitive information (emails, documents, phone numbers etc.) in case a device is lost or stolen, the list not being exhaustive, need to be addressed. Last but not least, Diameter signalling floods are an emerging threat to LTE networks, and the industry – mobile operators and vendors alike – does not yet fully understand their causes, forms and impact. Security protection in 3G-networks requires the consideration of several aspects and issues, such as the wireless access, the end-user mobility, the particular security threats, the type of information to be protected (user data, charging and billing data, customer information data, network management data, etc.), and the complexity of the network architecture/topologies including the heterogeneity of the involved technologies. Most of the security requirements for 3G networks hold also for LTE networks, so that at least the same level of security as in the 3G networks is guaranteed in LTE. In addition, two main new security features introduced in LTE: a) a completely new ciphering mechanism and integrity protection for NAS signaling messages and b) the April 2013
75
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
option to secure the complete IP-based transport of the control plane and user plane on the S1 reference point using Secure IP (IPsec). However, even though IPsec provides traffic encryption, MNOs need to take further actions to protect themselves from signalling flood threats. Security mechanisms for the communications between the client device and the carrier’s core network (against eavesdropping, fraud, service disruption, and other malicious activity) have also been designed for the IP-based FAPs, namely: FAP Physical Security, FAP and Core Network mutual authentication and IPSec tunnel establishment, Location Verification, Access Control, Protection of FMS traffic between FMS and FAP and Measures for Clock Protection. As a result, considering the network security/protection, there is a variety of appropriate countermeasures, such as: advanced firewall and intrusion prevention system (IPS) products, addition of IPsec termination capabilities on platforms, solutions to reduce the impact of smartphone, features of network security architecture including authentication, key mechanism, encryption, etc. are available, for the mobile operators to deploy. However, the protection of the mobile core network from an attack coming from a user device that is utilized as a stepping stone for this purpose still remains a challenge to be investigated and addressed, so as to enable the mobile operators to protect their networks and provide a safe environment for their subscribers. We can conclude that the spreading of smartphones represents many opportunities for users themselves and for MNOs. However, there are certain major challenges imposed on the network side of a MNO associated with providing services to smart mobile devices. These challenges include securing transmissions to and from devices and protecting the network and the devices themselves. NEMESYS will respond to these challenges by designing a comprehensive security infrastructure which aims to offer protection to both the devices and the mobile networks they are connected to.
April 2013
76
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
References [1] Portio Research Ltd. UK, “Mobile Factbook 2012”, http://www.portioresearch.com/media/1797/Mobile%20Factbook%202012.pdf [2] mobiThinking, “Global mobile statistics 2012 Part A”, http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/a#subscribers [3] Strategy Analytics, “Worldwide Smartphone Population Tops 1 Billion in Q3 2012”, http://blogs.strategyanalytics.com/WDS/post/2012/10/17/Worldwide-SmartphonePopulation-Tops-1-Billion-in-Q3-2012.aspx [4] Gartner, “Market Share: Mobile Devices, Worldwide, 2Q12", available at http://www.gartner.com/resId=2117915 [5] Strategy Analitics, “Global Smartphone Installed Base Forecast by Operating System for 88 Countries: 2007 to 2017”, https://www.strategyanalytics.com/default.aspx?mod=reportabstractviewer&a0=78 34 [6] ZDNet, “iOS users generate twice as much web traffic than Androis users”, http://www.zdnet.com/ios-users-generate-twice-as-much-web-traffic-as-androidusers-7000008292/ [7] Chitika Insights, “Six-Month Study: Apple iOS Users Consume Growing Amount of Web Traffic”, December 2012, http://insights.chitika.com/2012/six-month-study-ios-vs-android/#mc_signup [8] InfoWorld, “Android takes the lead from iOS in mobile data traffic”, February , 2013, http://www.infoworld.com/t/mobile-technology/android-takes-the-lead-ios-inmobile-data-traffic-212415 [9] Trend Micro, “Mobile malware surged from 30K to 175K”, Q3 2012, http://www.trendmicro.com/cloud-content/us/pdfs/securityintelligence/reports/rpt-3q-2012-security-roundup-android-under-siege-popularitycomes-at-a-price.pdf [10] Strategy Analytics, http://blogs.strategyanalytics.com/WSS/post/2013/01/28/Android-and-Apple-iOSCapture-a-Record-92-Percent-Share-of-Global-Smartphone-Shipments-in-Q42012.aspx [11] Technology Review, "Are Smart Phones Spreading Faster than Any Technology in Human History?", http://www.technologyreview.com/news/427787/are-smartphones-spreading-faster-than-any-technology-in-human-history/ [12] Trend Micro, TrendLabs 3Q 2012 Security Roundup, “Android under Siege”, http://www.trendmicro.com/cloud-content/us/pdfs/securityintelligence/reports/rpt-3q-2012-security-roundup-android-under-siege-popularitycomes-at-a-price.pdf [13] Trend Micro, TrendLabs 2012 Annual Security Roundup, http://www.trendmicro.com/cloud-content/us/pdfs/securityintelligence/reports/rpt-evolved-threats-in-a-post-pc-world.pdf
April 2013
77
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
[14] F-Secure Labs, ”Mobile Threat Report Q3 2012”, http://www.fsecure.com/static/doc/labs_global/Research/Mobile%20Threat%20Report%20Q3%2 02012.pdf [15] McAfee, McAfee Threats Report: Third Quarter 2012, http://www.mcafee.com/it/resources/reports/rp-quarterly-threat-q3-2012.pdf [16] Kaspersky Labs, “Kaspersky Security Bulletin 2012. The overall statistics for 2012”, http://www.securelist.com/en/analysis/204792255/Kaspersky_Security_Bulletin_20 12_The_overall_statistics_for_2012 [17] HOTforSecurity, “Android mobile malware report 2012”, http://www.hotforsecurity.com/blog/android-mobile-malware-report-august-20123459.html [18] Genome Project, Department of Computer Science North Carolina State University, http://www.malgenomeproject.org/ [19] Contagio malware, Mobile malware mini dump, http://contagiominidump.blogspot.it/ [20] McAfee, Mobile Security: McAfee Consumer Trends Report, http://www.mcafee.com/it/resources/reports/rp-mobile-security-consumertrends.pdf [21] McAfee, McAfee Threats Report: Fourth Quarter 2012, http://www.mcafee.com/it/resources/reports/rp-quarterly-threat-q4-2012.pdf [22] Androguard, Reverse engineering, Malware and goodware analysis of Android applications, http://code.google.com/p/androguard/ [23] Lookout Inc. US, State of mobile security 2012, https://www.lookout.com/resources/reports/state-of-mobile-security-2012 [24] McAfee, Mobile Security: McAfee Consumer Trends Report 2013, http://www.mcafee.com/it/resources/reports/rp-mobile-security-consumertrends.pdf [25] NEMESYS Deliverable 2.1, Survey of Smart Mobile Platforms [26] J. Burns, Mobile Application Security on Android, Black Hat USA 2009 [27] M. Grace, Y. Zhou, Z. Wang, X. Jiang, Systematic Detection of Capability Leaks in Stock Android Smartphones, North Carolina University [28] E. Chin, A. Porter Felt, K. Greenwood, D. Wagner, Analyzing Inter-Application Communication in Android, University of California at Berkeley [29] C. Papathanasiou, N.J. Percoco, This is not the droid you’re looking for…, DEF CON 18, July, 2010 [30] ASMONIA Project Team, Threat and Risk Analysis for Mobile Communication Networks and Mobile Terminals, D5.1(II)-1.0, December 2012 [31] Andrubis, A Tool for Analyzing Unknown Android Applications, http://blog.iseclab.org/2012/06/04/andrubis-a-tool-for-analyzing-unknown-androidapplications-2/ [32] Xuxian Jiang, An Evaluation of the Application ("App") Verification Service in Android 4.2, http://www.csc.ncsu.edu/faculty/jiang/appverify/ [33] Virustotal, Free Online Virus, Malware and URL Scanner https://www.virustotal.com/
April 2013
78
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
[34] ETSI TS 133 102 V11.5.0 (2013-02) Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; 3G security; Security architecture (3GPP TS 33.102 version 11.5.0 Release 11) [35] http://www.heavyreading.com/details.asp?sku_id=2806&skuitem_itemid=1382 [36] http://www.lucent.com/enrich/v1i12007/article_c4a4.html [37] LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 11.4.0 Release 11) [38] http://www.yumpu.com/en/document/view/3498978/security-architecture-inumts-third-generation-cellular-networks [39] http://ltesignaling.blogspot.gr/2011/12/lte-security-standards-protocols-and.html [40] http://infoscience.epfl.ch/record/149153/files/secu-LTE-femtocells-BJH-final.pdf [41] VMware Virtualization Software for Desktops, Servers & Virtual Machines, http://www.vmware.com/, Feb 2013. [42] F. Massicotte, M.Couture, A.Demontigny, Using a VMware Network Infrastructure to Collect Traffic Traces for Intrusion Detection Evaluation, 21st Annual Computer Security Applications Conference (ACSAC), Tucson, Arizona, December 2005. [43] HP uses virus code to protect its networks from worms, http://www.computerweekly.com/news/2240053269/HP-uses-virus-code-toprotect-its-networks-from-worms, Feb 2013. [44] Japan Building a Cyber-Weapon which Traces and Disables Cyber-Attack, http://www.devicemag.com/2012/01/05/japan-building-a-cyber-weapon-whichtraces-and-disables-cyber-attack, Jan 2012. [45] Cyberweapon: Virus can trace, disable sources of cyber-attacks, http://www.cyberwarzone.com/cyberwarfare/cyberweapon-virus-can-trace-disablesources-cyber-attacks, June 2012. [46] Snort, http://www.snort.org/, 2010. [47] Chen, I-Wei and Lin, Po-Ching and Luo, Chi-Chung and Cheng, Tsung-Huan and Lin, Ying-Dar and Lai, Yuan-Cheng and Lin, Frank C., Extracting Attack Sessions from Real Traffic with Intrusion Prevention Systems, In Proceedings of the 2009 IEEE international conference on Communications, IEEE Press, p. 889-893, 2009. [48] Wireshark, http://www.wireshark.org/, feb 2013. [49] A. Lakhina, M. Crovella, C. Diot, Detecting Distributed Attacks using Network-Wide Flow Traffic, In Proceedings of FloCon 2005 Analysis Workshop, Sept 2005. [50] H. Lipson, Tracking and Tracing Cyber-Attacks:Technical Challenges and Global Policy Issues, Software Engineering Institute, Carnegie Mellon University, 2002. http://www.sei.cmu.edu/library/abstracts/reports/02sr009.cfm [51] Backscatter, http://en.wikipedia.org/wiki/Denial-of-service_attack [52] Android Emulator, http://developer.android.com/tools/help/emulator.html, Feb 2013. [53] VirtualBox, https://www.virtualbox.org/, Feb 2013. [54] strace, http://linux.die.net/man/1/strace, Feb 2013. [55] I. Burguera, U. Zurutuza, S. Nadjm-Therani, Crowdroid: Behavior-Based Malware Detection System for Android, In SPSM '11, ACM, p. 15-26, 2011. [56] truss, http://www.unix.com/man-page/OpenSolaris/1/truss/, 2009.
April 2013
79
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
[57] ltrace, http://linux.die.net/man/1/ltrace, Feb 2013. [58] W. Enck, P. Gilbert, B. Chun, L. Cox, J. Jung, P. McDaniel, A. Sheth, TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones, In OSDI'10, USENIX Association Berkeley, 2010. [59] http://www.f5.com/pdf/white-papers/wireless-security-lte-networks-wp.pdf [60] Kameswari Kotapati, Peng Liu, Yan Sun, Thomas F. LaPorta, A Taxonomy of Cyber Attacks on 3G Networks http://insr.cse.psu.edu/tech_report/NAS-TR-0021-2005.pdf [61] U.Meyer, S.Wetzel. “A Man-in-the-Middle Attack on UMTS”. Proceedings of the ACM Workshop on Wireless Security (WiSe), 2004, pp. 90-97. [62] P.P.C. Lee, T. Bu, T. Woo, “On the detection of signaling DoS attacks on 3G/WiMax Wireless Networks”, Computer Networks, Accepted for publication, 2009, Elsevier. [63] D.C. Nash, T.L. Martin, D.S. Ha, M.S. Hsiao, “Towards an intrusion detection system for battery exhaustion attacks on mobile computing devices”, 3rd IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW'05), pp.141-145, 2005. [64] M. Khan, A. Ahmed, A.R. Cheema, “Vulnerabilities of UMTS Access Domain Security Architecture”, 9th ACIS International Conference on Software Engineering, Networking, and Parallel/Distributed Computing, pp. 350-355, Phuket, Thailand, Aug. 2008. [65] G. Kambourakis, C. Kolias, S. Gritzalis, J. H. Park, "Signaling-oriented DoS Attacks in UMTS Networks", Proceedings of the ISA 2009 3rd International Conference on Information Security and Assurance, pp. 280-289, 2009, Seoul, Korea, LNCS 5576, Springer. [66] E.Gadix. GSM and 3G Security, Asia BlackHat http://www.blackhat.com/presentations/bh-asia-01/gadiax.ppt [67] H.Holma, A.Toskala. WCDMA for UMTS 3rd Editions. 2004, Wiley Ltd. [68]www.osmocom.org [69] F.Ricciato, A.Coluccia, A.D’Alconzo. “A review of DoS attack models for 3G cellular Networks from a system-design perspective”. Computer Communications 33 (2010), pag. 551-558, Elsevier. [70] R.Kreher, T.Ruedebusch. “UMTS Signaling: UMTS Interfaces, Protocols, Message Flows and Procedures Analyzed and Explained”. Wiley, 2005. [71] P.S. Pagliusi. “A Contemporary Foreword on GSM Security”. 2002 [72] GSMA. “SMS Spam and Mobile Messaging Attacks. Introduction, Trends and Examples”. January 2011. [73] Barbuzzi, F.Ricciato, G.Boggia. “Discovering parameter setting in 3G networks via active measurements”. 2008 [74] GPRS Security http://dsns.cs.nctu.edu.tw/blog/components/com_agora/img/members/9/6-2GPRS-doc.pdf [75] Srlabs (K.Nohl) https://srlabs.de/gprs/ [76] Peter McGuiggan. “GPRS Operations”. PMCG Consulting Ltd, 2000 [77] G.Kambourakis, C.Kolias, S.Gritzalis, J.H.Park, ” DoS Attacks Exploiting Signaling in UMTS and IMS”. [78] Haral Welte blog. http://planet.osmocom.org/
April 2013
80
Deliverable D1.1
Dissemination Level: PU
317888-NEMESYS
[79] Dieter Spaar blog. http://www.mirider.com/weblog/ [80] The OpenBSC-GPRS project. http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS [81] Roger Piqueras Jover, Security Attacks Against the Availability of LTE Mobility Networks: Overview and Research Directions, AT&T Security Research Center [82] OpenLTE, http://openlte.sourceforge.net, http://bellard.org/lte [83] http://www.yumpu.com/en/document/view/3498978/security-architecture-inumts-third-generation-cellular-networks
April 2013
81
