mobile sec 1a Flashcards
Native code: Classic 3-Tier Architecture
: Native applications may be written in languages that
execute without the benefit of a VM or rigorous sandbox.
1. These applications may be written in unsafe languages (for instance,
Objective-C) and have increased access to other apps and resources as
compared to browser-based apps.
2. Even when mobile platforms implement app sandboxing, the user is quickly
coerced into granting broad and powerful permissions that easily bypass
much of the platform-provided controls.
Classic 3-Tier Architecture
- Native code:
• 2. OS access
• 3. Internet access
OS access Classic 3-Tier Architecture
Software running in a browser has limited access to the underlying OS, its libraries, file system access, inter-process
communication, and its system calls.
Internet access Classic 3-Tier Architecture
Whereas home PCs, and to an extent laptops, often
connect from a home network, mobile devices commonly use their
mobile carrier’s network and public WiFi to connect to the Internet.
These means of access may provide increased opportunity for manin-the-middle (MiTM) attacks from hackers! (esp free wifi spots
which normally has no password protection!)
r manin-the-middle (MiTM)
Whereas home PCs, and to an extent laptops, often
connect from a home network, mobile devices commonly use their
mobile carrier’s network and public WiFi to connect to the Internet.
These means of access may provide increased opportunity for manin-the-middle (MiTM) attacks from hackers! (esp free wifi spots
which normally has no password protection!)
Most threats against mobile apps are
variations on MiTM,
• whether it be MiTB (browser),
• MiTOS (operating system),
• or good old-fashioned MiTM (network).
• This is a natural consequence of the mobile model from the
app perspective—it’s surrounded by hostile (or at least
semitrusted) software.
Attack Surfaces Specific to Mobile Devices
•Physical theft allows access to the user
interface, physical storage, the IO bus etc.
•The opportunity for a threat to gain access
to a physical device probably represents the
singular largest difference between mobile
devices and other client endpoints.
Attack Surfaces Specific to Mobile Devices
• App publication allows the threat to distribute either
• a Trojan horse app or
• other malware centrally with an appearance of legitimacy based on the
curator’s endorsement.
• The threat’s app may have relaxed access to
• OS resources,
• interprocess communication, and
• an unsandboxed environment with which to attack its victim,
depending on the state of the mobile platform (jailbroken/rooted),
• weak app permission configuration, end-users’ over-permissive
settings, and so on).
Key to Security – Understand Risk Model
• The client-side threat model is much more aggressive, given the
promiscuous exposure to communications (wide area and close-in),
physical access, plus the usual software attack and exfiltration vectors
like email, mobile web, and apps.
• And the impact of compromise is much more “personal”: location,
camera/photos, instant messaging—there are plenty of embarrassed
public figures who can attest to this.
Risks Area #1-Physical Risk
• Physical access to the device is impossible to defend against for very long.
• The whole rooting/jailbreaking phenomenon proves this.
• Neither Google nor Apple have yet to prevent this because it is very hard
and probably impossible.
• Experts say it’s hard to find a mobile app that they could not defeat given
physical access, including many rudimentary “anti-rooting” mechanisms
and even mobile device management (MDM) software.
• If your mobile risk model assumes that info can be securely stored
indefinitely on a mobile device, you are wrong and will have to relearn this
painful lesson the hard way if there is ever a breach.
Risks Area #1-Physical Risk ELABORATE
• One often overlooked corollary of this principle is that close proximity
to a mobile device is effectively the equivalent of a physical attack.
• In other words, if an adversary can get close enough to you with a
rogue cellular base station, your phone will join his rogue cellular
network, and he now “owns” your device
• Remedy?
• Sorry, there is nothing you can do about this today, other than put
your device in Airplane Mode and use it like an expensive,
unconnected brick!
Risks Area #2-Service Risk
• Next major area of risk arise in the mobile ecosystem?
• Naturally, most of the attention on mobile focuses on the mobile
device and associated client-side software.
• Contrary to this focus, experts observe more problems on the server
side in their consulting and research (2/3 bugs server side!)
Risks Area #2-Service Risk ELABORATE
Another often overlooked aspect of modern Internet-based
applications risks is customer support.
• By design, support helps people regain access to their valuable stuff—
a hacker’s dream come true!
• Experts have seen devastating vulnerabilities in over 20 years of their
experience has resulted from support-related issues like customer
self-help password reset;
• if you make a mistake here, the consequences can have a huge impact.
• Imagine a flaw that allowed anonymous attackers to reset account passwords
via the self-help web portal— get the picture?
Risks Area #2-Service Risk ELABORATE MORE
• For a real-world example of what can go wrong with these
interrelationships, see Wired reporter Mat Honan’s nightmare story
about how hackers from Lulz leveraged customer-support trickery to
• social engineer their way into his Gmail account and
• then pivoted through his Amazon data;
• remotely erased all of the data on his iPhone, iPad, and MacBook; and
• hijacked his Twitter account (see wired.com/gadgetlab/2012/08/appleamazon-mat-honan-hacking/).
say another issue that happened with service risk
• This is such a recurring and important problem, see another realworld example of a horrible customer support vulnerability, see
• The Verge’s (theverge.com) March 2013 report on a serious vulnerability in
Apple’s iForgot self-help password reset tool that allowed anyone with your
email address and date of birth to reset your password.
what is a silver lining with service risk
• 1 silver lining on the service-side, the good ol’ security gateway still
performs well to protect Internet-facing services.
• Products like the Vordel Application Gateway (vordel.com) effectively
protect mobile service XML endpoints from skilled penetration
testers.
• You should definitely consider products like Vordel as part of your
mobile application security architecture.
App Risks
Apps (interacting with platform
features) are the primary attack
surface on the mobile client.
• After all, the apps and the mobile OS are the primary touch points for
end users and other software, so this is where all the trouble occurs.
primary attack
surface on the mobile client
Apps (interacting with platform
features)
App Risks ELABORATE
• The centrality of apps in today’s mobile risk model mirrors the
evolution of security on platforms like the desktop PC:
• early attacks focused on the network layer and then
• migrated to the OS (and especially Microsoft Windows).
• Recently, we’ve seen larger numbers of published exploits in desktop
applications, like web browsers, Adobe Acrobat, and Microsoft Office.
• At the pinnacle of this evolution, we see attacks against “Layer 8,” in other
words, the human beings operating the technology.
• Socially driven attacks like phishing represent this trend.
Layer 8
human beings operating the technology
App Risks - Fragmentation
• One security fundamental we’ve learned over the years:
• quickly patching vulnerable systems usually reduces risk from easy
compromise by folks trolling the Internet with home-grown malware that
exploits unpatched, well-known vulnerabilities.
• Unfortunately, patching your mobile software is challenging owing to one of
the key features of the current market: fragmentation.
• Fragmentation results from one of the age-old debates in tech
industry: open versus closed platforms.
• We are seeing this play out again in the mobile device space between
today’s two biggest competitors, Google and Apple.
App Risks - Fragmentation GIVE AN EXAMPLE
In 2003, even renowned mobile hacker Charlie Miller are admitting
that Apple iOS is much tougher to victimize because of the rigid
controls built into the platform:
• code must be signed by Apple in order to run, address space layout
randomization (ASLR), better code sandbox, no shell, and so on.
how is android when it comes to fragmentation
Android - the need to develop custom OS versions for each device
manufacturer creates fragmentation that leads to negative security
consequences.
• For example, upgrading to the newest version of Android depends on
collaboration between the device’s hardware vendor and the mobile network
operator (MNO) and makes distributing security patches and other important
updates that much harder.
why are consumers idiots
Consumers tend to be more
accepting of bleeding-edge features
and faults, and security is an
afterthought!
• The fact that many Android and iOS users root/jailbreak their phones
is a prime example of the immaturity that persists in the market.
• App marketplaces
These centralized app delivery mechanisms are driven
• not by security,
• but by the desire to control the user experience,
• attract developers with simple distribution models,
• and monetize software downloads to devices
• 99USD for Apple, 25USD for Google (as of 2013)
