Report on Mobile security

Table of Contents
1. INTRODUCTION
2. Anatomy of a Mobile Attack
3. Findings
4. OWASP Mobile Top 10 Risks
5. Mobile Security – Mobile Security Mobile phones today
6. CONCLUSION
7. REFERENCES

INTRODUCTION
The estimated number of mobile devices is around 5.8 billion, which is thought to
have grown exponentially within five years and is supposed to reach nearly 12
billion within four years. Hence, it will be an average of two mobile devices per
person on the planet. This makes us fully dependent on mobile devices with our
sensitive data being transported all over. As a result, mobile security is one of the
most important concepts to take in consideration. Mobile Security as a concept deals
with the protection of our mobile devices from possible attacks by other mobile
devices, or the wireless environment that the device is connected to.

Mobile Security − Introduction Mobile Security Following are the major threats
regarding mobile security:
 Loss of mobile device. This is a common issue that can put at risk not only you but
even your contacts by possible phishing.
 Application hacking or breaching. This is the second most important issue. Many
of us have downloaded and installed phone applications. Some of them request extra
access or privileges such as access to your location, contact, browsing history for
marketing purposes, but on the other hand, the site provides access to other contacts
too. Other factors of concern are Trojans, viruses, etc.
 Smartphone theft is a common problem for owners of highly coveted smartphones
such as iPhone or Android devices. The danger of corporate data, such as account
credentials and access to email falling into the hands of a tech thief is a threat. Mobile
Security 3 By definition, an Attack Vector is a method or technique that a hacker
uses to gain access to another computing device or network in order to inject a “bad
code” often called payload.
This vector helps hackers to exploit system vulnerabilities. Many of these attack
vectors take advantage of the human element as it is the weakest point of this system.

Following is the schematic representation of the attack vectors process which can be
many at the same time used by a hacker. Some of the mobile attack vectors are:
 Malware o Virus and Rootkit o Application modification o OS modification
 Data Exfiltration o Data leaves the organization o Print screen o Copy to USB and
backup loss
 Data Tampering o Modification by another application o Undetected tamper
attempts o Jail-broken devices
 Data Loss o Device loss o Unauthorized device access o Application vulnerabilities
Mobile Security − Attack Vectors Mobile Security 4 Consequencesof Attack
Vectors Attack vectors is the hacking process as explained and it is successful,
following is the impact on your mobile devices.
 Losing your data: If your mobile device has been hacked, or a virus introduced,
then all your stored data is lost and taken by the attacker.
 Bad use of your mobile resources: Which means that your network or mobile
device can go in overload so you are unable to access your genuine services. In worse
scenarios, to be used by the hacker to attach another machine or network
.  Reputation loss: In case your Facebook account or business email account is
hacked, the hacker can send fake messages to your friends, business partners and
other contacts. This might damage your reputation.
 Identity theft: There can be a case of identity theft such as photo, name, address,
credit card, etc. and the same can be used for a crime.
Anatomy of a Mobile Attack
Following is a schematic representation of the anatomy of a mobile attack. It starts
with the infection phase which includes attack vectors. Infecting the device Infecting
the device with mobile spyware is performed differently for Android and iOS
devices. Android: Users are tricked to download an app from the market or from a
third-party application generally by using social engineering attack. Remote
infection can also be performed through a Man-in-the-Middle (MitM) attack, where
an active adversary intercepts the user’s mobile communications to inject the
malware. iOS: iOS infection requires physical access to the mobile. Infecting the

device can also be through exploiting a zero-day such as the JailbreakME exploit.
Installing a backdoor To install a backdoor requires administrator privileges by
rooting Android devices and jailbreaking Apple devices. Despite device
manufacturers placing rooting/jailbreaking detection mechanisms, mobile spyware
easily bypasses them: Android: Rooting detection mechanisms do not apply to
intentional rooting.
Mobile Security 5 iOS: The jailbreaking “community” is vociferous and motivated.
Bypassing encryption mechanisms and exfiltrating information Spyware sends
mobile content such as encrypted emails and messages to the attacker servers in plain
text. The spyware does not directly attack the secure container. It grabs the data at
the point where the user pulls up data from the secure container in order to read it.
At that stage, when the content is decrypted for the user’s usage, the spyware takes
controls of the content and sends it on.
How Can a Hacker Profit from a Successfully Compromised Mobile? In most cases
most of us think what can we possibly lose in case our mobile is hacked. The answer
is simple - we will lose our privacy.
Our device will become a surveillance system for the hacker to observer us. Other
activities of profit for the hacker is to take our sensitive data, make payments, carry
out illegal activities like DDoS attacks.

FINDINGS
The biggest trend in mobile security is dealing with the BYOD challenge. “People
bring their own devices to work and want to use those devices on corporate or
government networks,” said Gary Miliefsky, CEO, SnoopWall.
Given that the majority of consumers have no idea what mobile device hygiene
means, employees are putting their organizations at risk. The challenge for security
teams has become making employees happy while also securing the enterprise.
In a report published by Forrester Research, “Navigating the Future of Mobile
Security,” Stephanie Balaouras, vice president, research director and Andras Cser,
vice president, principal analyst wrote, “The single most important ingredient in
making employees happy is being able to get things done that they feel are important
— and mobile plays a key role.”
Balaouras and Cser found that, “Just like customers, employees have expectations
for their mobile experience. They are no longer willing to wait around for S&R
(security and risk) leaders to provision them with the mobile devices, apps, and
access they need to do their jobs effectively.” One of the most challenging trends in
mobile security, however, is that employees don’t fully understand the risks inherent
in mobile devices.
Because malware nowadays is virtually undetectable, according to Miliefsky, most
devices are exploited by adware, creepware, or malware. “There are four exploit
vectors that run in the background all the time. People want to listen to music, use
their phones as alarm clocks, run the emoji keyboards, and run a flashlight app.”
The lack of security in mobile apps combined with the access privileges that they
are granted in the privacy agreements are one reason why mobile is so risky.
The advent of free apps is what Miliefsky called a dirty little secret. “Apps used to
cost money. Developers sat in a room and got paid for something. Once they realized
that collecting keystrokes and accessing contact lists for marketing purposes was
more lucrative, though, apps started to make a lot more money by spying on
customers.”

Phones have become creepware devices in people’s pockets, and they are bringing
those to work, Miliefsky said.
There is a growing range of creepware, and developers use apps to monetize people
with their permission. “They collect data off devices, which makes the consumer
angle the first problem. They are leveraging the fact that people are going to be lazy,”
Miliefsky said.
When consumers are lazy, their own PII (personally identifiable information) is
exploited, but it’s not just consumer information that people are accessing on their
mobile devices. Balaouras and Cser wrote, “Many employees access sensitive
content such as customer information, nonpublic financial data, intellectual property,
and corporate strategy materials from their mobile devices.”
The phone or tablet then becomes the back door. “The real issue,” said Miliefsky,
“is employees are coming and going. I can lock down the network, and then along
come employees with Trojan horses on their mobile devices.”
In order to address the challenges in mobile security, security teams need to educate
employees about mobile hygiene. They are tasked with enabling the shift toward
more mobile initiatives in a way that also addresses mobile security risks.
Major corporations are talking about putting tablets on WiFi to enhance the customer
experience, but they need to keep in mind that records can be stolen over wireless
and most apps are written for convenience. Security is an afterthought, if it is
considered at all.
Even the trusted apps are potential viruses because of the data they collect, so
practitioners will need to approach mobile security in a different way. “The privacy
of data is sacrosanct, so they need to think about sandboxing, where only good apps
can run and geo-fencing, hardening and locking everything down during work hours
or while on premise,” said Miliefsky.
The lack of security in mobile applications makes the employee’s phone or the
customer designed tablet a security threat, but Balaouras and Cser wrote, “In

December 2016, cybercriminals accessed the sensitive data of 34,000 patients of
Quest Diagnostics via the firm’s mobile health app.”
“When it comes to customer-facing applications, security teams have no purview to
install anything on their device — they have to build security into the application
itself,” wrote Balaouras and Cser.
The lack of mobile application security coupled with the rise in fake mobile
applications that have appeared in both the Apple and Android app stores, said
Miliefsky, means that security teams have to look for nextgen mobile device
security.
Agility is key to overcoming the challenges that security practitioners will face in
mobile security. Exploring solutions to mobile threats in a way that enables
productivity while enhancing security across devices will increase the organization’s
overall security posture.
“The refocusing of cyber threats from PCs and laptops to smartphones and mobile
devices is requiring CISOs and IT security teams to develop more expertise and
spend more time on mobile security” said Steve Morgan, founder and Editor-In-
Chief at Cybersecurity Ventures. “The IP traffic statistics suggest this trend will
continue through 2025, and we believe mobile security will become one of the
biggest challenges and spend areas through that time period.”
– Kacy Zurkus is a freelance writer for Cybersecurity Ventures and has contributed
to several other publications. She covers a range of cybersecurity and cybercrime
topics
Following is a schematic representation. Mobile Security 6 OWASPMobile Top 10
Risks When talking about mobile security, we base the vulnerability types on
OWASP which is a not-for-profit charitable organization in the United States,
established on April 21.
OWASP is an international organization and the OWASP Foundation supports
OWASP efforts around the world. For mobile devices, OWASP has 10 vulnerability

classifications. M1-Improper Platform Usage This category covers the misuse of a
platform feature or the failure to use platform security controls.
It might include Android intents, platform permissions, misuse of TouchID, the
Mobile Security 7 Keychain, or some other security control that is part of the mobile
operating system.
There are several ways that mobile apps can experience this risk. M2-Insecure Data
This new category is a combination of M2 and M4 from Mobile Top Ten 2014. This
covers insecure data storage and unintended data leakage. M3-Insecure
Communication This covers poor handshaking, incorrect SSL versions, weak
negotiation, clear text communication of sensitive assets, etc. M4-Insecure
Authentication This category captures the notions of authenticating the end user or
bad session management. This includes:
 Failing to identify the user at all when that should be required
 Failure to maintain the user's identity when it is required
 Weaknesses in session management M5-Insuficient Cryptography The code
applies cryptography to a sensitive information asset.

OWASP Mobile Top 10 Risks
When talking about mobile security, we base the vulnerability types on OWASP
which is a not-for-profit charitable organization in the United States, established on
April 21. OWASP is an international organization and the OWASP Foundation
supports OWASP efforts around the world.
For mobile devices, OWASP has 10 vulnerability classifications.
M1-Improper Platform Usage
This category covers the misuse of a platform feature or the failure to use platform
security controls. It might include Android intents, platform permissions, misuse of
TouchID, the Mobile Security Keychain, or some other security control that is part
of the mobile operating system. There are several ways that mobile apps can
experience this risk.
M2-Insecure Data
This new category is a combination of M2 and M4 from Mobile Top Ten 2014.
This covers insecure data storage and unintended data leakage.
M3-Insecure Communication
This covers poor handshaking, incorrect SSL versions, weak negotiation, clear text
communication of sensitive assets, etc.
M4-Insecure Authentication
This category captures the notions of authenticating the end user or bad session
management. This includes:
Failing to identify the user at all when that should be required
Failure to maintain the user's identity when it is required
Weaknesses in session management
M5-Insuficient Cryptography
The code applies cryptography to a sensitive information asset. However, the
cryptography is insufficient in some way. Note that anything and everything
related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all
when it should, that probably belongs

in M2. This category is for issues where cryptography was attempted, but it wasn't
done correctly.
M6-Insecure Authorization
This is a category to capture any failures in authorization (e.g., authorization
decisions in the client side, forced browsing, etc.) It is distinct from authentication
issues (e.g., device enrolment, user identification, etc.) If the app does not
authenticate the users at all in a situation where it should (e.g., granting anonymous
access to some resource or service when authenticated and authorized access is
required), then that is an authentication failure not an authorization failure.
M7-Client Code Quality
This was the "Security Decisions Via Untrusted Inputs Inputs", one of our lesser-
used categories.This would be the catch-all for code-level implementation
problems in the mobile client. That's distinct from the server-side coding mistakes.
This would capture things like buffer overflows, format string vulnerabilities, and
various other code-level mistakes where the solution is to rewrite some code that's
running on the mobile device.
M8-Code Tampering
This category covers binary patching, local resource modification, method
hooking, Method Once the application is delivered to the mobile device, the code
and data resources are resident there. An attacker can either directly modify the
code, change the contents of memory dynamically, change or replace the system
APIs that the application uses, or modify the application's data and resources. This
can provide the attacker a direct method of subverting the intended use of the
software for personal or monetary gain.
M9-Reverse Engineering
This category includes analysis of the final core binary to determine its source
code,libraries, algorithms, and other assets. Software such as IDA Pro, Hopper,
otool, and other binary inspection tools give the attacker insight into the inner
workings of the application. This may be used to exploit other nascent
vulnerabilities in the application, as well asrevealing information about back-end
servers, cryptographic constants and ciphers, and intellectual property.

M10-Extraneous Functionality
Often, developers include hidden backdoor functionality or other internal
development security controls that are not intended to be released into a production
environment. For example, a developer may accidentally include a password as a
comment in a hybrid app. Another example includes disabling of 2-factor
authentication during testing.
However, the cryptography is insufficient in some way. Note that anything and
everything related to TLS or SSL goes in M3. Also, if the app fails to use
cryptography at all when it should, that probably belongs in M2. This category is for
issues where cryptography was attempted, but it wasn't done correctly. M6-Insecure
Authorization This is a category to capture any failures in authorization (e.g.,
authorization decisions in the client side, forced browsing, etc.) It is distinct from
authentication issues (e.g., device enrolment, user identification, etc.) If the app does
not authenticate the users at all in a situation where it should (e.g., granting
anonymous access to some resource or service when authenticated and authorized
access is required), then that is an authentication failure not an authorization failure.
M7-Client Code Quality This was the "Security Decisions Via Untrusted Inputs",
one of our lesser-used categories. This would be the catch-all for code-level
implementation problems in the mobile client. That's distinct from the server-side
coding mistakes. This would capture things like buffer overflows, format string
vulnerabilities, and various other code-level mistakes where the solution is to rewrite
some code that's running on the mobile device. M8-Code Tampering This category
covers binary patching, local resource modification, method hooking, method
swizzling, and dynamic memory modification. Mobile Security 8 Once the
application is delivered to the mobile device, the code and data resources are resident
there. An attacker can either directly modify the code, change the contents of
memory dynamically, change or replace the system APIs that the application uses,
or modify the application's data and resources. This can provide the attacker a direct
method of subverting the intended use of the software for personal or monetary gain.
M9-Reverse Engineering This category includes analysis of the final core binary to
determine its source code, libraries, algorithms, and other assets. Software such as
IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight
into the inner workings of the application. This may be used to exploit other nascent
vulnerabilities in the application, as well as revealing information about back-end
servers, cryptographic constants and ciphers, and intellectual property. M10-

Extraneous Functionality Often, developers include hidden backdoor functionality
or other internal development security controls that are not intended to be released
into a production environment. For example, a developer may accidentally include
a password as a comment in a hybrid app. Another example includes disabling of 2-
factor authentication during testing. Mobile Security 9 End of ebook preview If you
liked what you saw…
Mobile Security – Mobile Security Mobile phones today
• Mobile phones changed our life in past 15 years (GSM & CDMA) – Mobile
phones became the most personal and private item we own
• Mobile smartphones change our digital life in past 5 years – Growing
computational power of “phones” – Diffusion of high speed mobile data networks –
Real operating systems run on smartphones Mobile Security
• Mobile phones became the most personal and private item we own
• Get out from home and you take: – House & car key – Portfolio – Mobile phone •
Trust between operators
• Trust between the user and the operators
• Trust between the user and the phone
• Still low awareness of users on security risks Mobile Security
10 Difference between mobile security & IT Security Users download
everything: new social risks!
• Users install *much more* applications than on a PC Titolo - Autore 11 50.000
users 500.000 users Too difficult to deal with
• Low level communication protocols/networks are closed (security trough entrance
barrier)
• Too many etherogeneus technologies, no single way to secure it – Diffused trusted
security but not omogeneous use of trusted capabilities
• Reduced detection capability of attack & trojan Mobile Security

12 Difference between mobile security & IT Security Too many sw/hw
platforms
• Nokia S60 smartphones – Symbian/OS coming from Epoc age (psion)
• Apple iPhone – iPhone OS - Darwin based, as Mac OS X - Unix
• RIM Blackberry – RIMOS – proprietary from RIM
• Windows Mobile (various manufacturer) – Windows Mobile (coming from
heritage of PocketPC)
• Google Android – Linux Android (unix with custom java based user operating
environment)
• Brew, NucleOS, WebOS,… Mobile Security – - 13 Difference between mobile
security & IT Security Vulnerability management
• Patching mobile operating system is difficult – Carrier often build custom
firmware, it’s at their costs and not vendor costs – Only some environments provide
easy OTA software upgrades – Almost very few control from enterprise
provisioning and patch management perspective – Drivers often are not in hand of
OS Vendor – Basend Processor run another OS – Assume that some phones will just
remain buggy Mobile Security
Mobile Security Reduced security by hw design
• Poor keyboard -
• Poor password Type a passphrase: P4rtyn%!ter.nd@’01 Mobile Security – - 17
Mobile Device Security Reduced security by hw design
• Poor screen, poor control
• User diagnostic capabilities are reduced. No easy checking of what’s going on
• Critical situation where user analysis is required are difficult to be handled (SSL,
Email) Mobile Security Mobile Device Security Devices access and authority
• All those subject share authority on the device –
OS Vendor/Manufacturer (1) – Carrier (2) – User – Application Developer
(1) Blackberry banned from france government for spying risks
http://news.bbc.co.uk/2/hi/business/6221146.stm

(2) Etisalat operator-wide spyware installation for Blackberry
http://www.theregister.co.uk/2009/07/14/blackberry_snooping/ Mobile Security – -
19 Mobile Device Security Devices access and authority
• All those subject share authority on the device – OS Vendor/Manufacturer (1) –
Carrier (2) – User – Application Developer
(1) Blackberry banned from france government for spying risks
http://news.bbc.co.uk/2/hi/business/6221146.stm
(2) Etisalat operator-wide spyware installation for Blackberry
http://www.theregister.co.uk/2009/07/14/blackberry_snooping/ Mobile Security – -
20 Mobile Device Security About security model
• Pre-exploitation – Technical vectors
• Type-safe devel languages
• Non-executable memory... (same as non-mobile) – Social vectors
• Ease of app delivery
• Application signing policies
• App store inclusion policies
• Post-exploitation – Technical vectors
• Privileges/permissions
• App sandboxing – Social vectors
• Ease of removal
• Remote kill/revocation
• Vendor blacklist Titolo - Autore 21
• Source: Jon Oberheide (cansecwest09) About security model
• Security means control
• Restricted vs. open platforms – Allow self-signed apps? – Allow non-official app
repositories? – Allow free interaction between apps? – Allow users to override
security settings? – Allow users to modify system/firmware?

• Telephony is a market that come back from monopolies, financial impact of
keeping things under control is very relevant for business reasons
• ¾ of high yield bonds in European debt market comes from TLC Titolo - Autore
22
• Source: Jon Oberheide (cansecwest09) Mobile security model: old school
• Windows Mobile and Blackberry application – Authorization based on digital
signing of application – Everything or nothing – With or without permission requests
– Limited access to filesystem (BB)
• No granular permission fine tuning Cracking blackberry security model with 100$
key
http://securitywatch.eweek.com/exploits_and_attacks/cracking_the_blackberry_wit
h_ a_100_key.html Mobile Security
Mobile Device Security Mobile security model old school but Enterprise
• Windows Mobile 6.1 (SCMDM) and Blackberry (BES) – Deep profiling of
security features for centrally managed devices
• Able to download/execute external application
• Able to use different data networks
• Force device PIN protection
• Force device encryption (BB)
• Profile access to connectivity resources (BB) Mobile Security –
Mobile Device Security Mobile security model iPhone
• Heritage of OS X Security model
• Centralized distribution method: appstore
• Technical application publishing policy
• Non-technical application publishing policy AppStore “is” a security feature
• Reduce set of API (upcoming iPhone OS 4)
• Just some enterprise security provisioning
• General rooting capabilities

• 2 Months ago Vincenzo Iozzo & Charlie Miller presented iphone safari exploit that
remotely dump the user SMS database just by visiting a website
• Google for: pwn2own 2010 iphone hacked sms
• Extremely easy reverse engineering Mobile Security – Mobile Device Security
Mobile security model Symbian
• Trusted computing system with capabilities
• Strict submission process if sensible API are used
• Sandbox based approach (data caging)
• Users have tight control on application permissions – Symbian so strict on digital
signature enforcement but not on data confidentiality – Symbian require different
level of signature depending on capability usage
• Some enterprise security provisioning with no real official endorsment by Nokia
• Private API issues
• Opensource what? Mobile Security –
Mobile Device Security Mobile security model – Android
• No application signing
• No application filters
• User approved application permissions (still require deep granularity)
• Sandboxed environment (process, user, data)
• NO memory protection
• NO serious enterprise security provisioning
• Google want to be free… but operators? Mobile Security –
Mobile Device Security Brew & NucleOS
• Application are provided *exclusively* from mnu facturer and from operator
• Delivery is OTA trough application portal of operator
• Full trust to carrier Mobile Security – - 28 Mobile Device Security Development
language security

• Development language/sdk security features support are extremely relevant to
increase difficulties in exploiting Mobile Security – - 29 Mobile Device Security
Blackberry RIMOS J2ME MIDP 2.0 No native code Iphone Objective-C NX
Stack/heap protection Windows Mobile .NET / C++ GS enhanced security
Nokia/Symbian C++ Enhanced memory management / trusted Android/Linux Java
& NDK Java security model Mobile Hacking & Attack vector Mobile Security – -
30 Mobile Security Mobile security research
• Mobile security research exponentially increased in past 2 years – DEFCON
(USA), BlackHat (USA, Europe, Japan), CCC(DE), ShmooCon (USA), YSTS (BR),
HITB (Malaysia), CansecWest (CAN), EuSecWest)NL, GTS(BR), Ekoparty (AR),
DeepSec (AT) *CLCERT data
• Hacking environment is taking much more interests and attention to mobile
hacking
• Dedicated security community: – TSTF.net , Mseclab , Tam hanna Mobile Security
– - 31 Mobile Hacking & Attack Vector Mobile security research - 2008 – DEFCON
16 - Taking Back your Cellphone Alexander Lash – BH DC / BH Europe –
Intercepting Mobile Phone/GSM Traffic David Hulton, Steve– – BH Europe -
Mobile Phone Spying Tools Jarno Niemelä– – BH USA - Mobile Phone Messaging
Anti-Forensics Zane Lackey, Luis Miras – Ekoparty - Smartphones (in)security
Nicolas Economou, Alfredo Ortega – BH Japan - Exploiting Symbian OS in mobile
devices Collin Mulliner– – GTS-12 - iPhone and iPod Touch Forensics Ivo Peixinho
– 25C3– Hacking the iPhone - MuscleNerd, pytey, planetbeing – 25C3 Locating
Mobile Phones using SS7 – Tobias Engel– Anatomy of smartphone hardware Harald
Welte – 25C3 Running your own GSM network – H. Welte, Dieter Spaar – 25C3
Attacking NFC mobile phones – Collin Mulliner Mobile Security –

Conclusion:
This report is showing the current users and current devices .it includes Application
hacking or breaching ,hacking,encryption/decryption,OWSAP,networking issues
and threats.there are two types of mobile phones that is CDMA or GSM based.
 Too many technologies
 Security model are too differents among platforms
 Operators and manufacturer does not like user freedom on-device and on-
network
 The security and hacking environment is working a lot on it
 We must take in serious consideration the mobile security issues
Refrences:
1. www.tutorialspoint.com
2. https://www.slideshare.net/fpietrosanti/2010-mobile-security-whymca-developer-
conference?qid=8653eed0-81a1-4896-bd8a-e9611cf5d8d2&v=&b=&from_search=10
3. https://www.slideshare.net/search/slideshow?searchfrom=header&q=mobile+security

Report on Mobile security

More Related Content

What's hot (20)

Similar to Report on Mobile security (20)

More from Kavita Rastogi (8)

Report on Mobile security