WEB AND MOBILE SECURITY

(CY5010)

UNIT 1 : INTRODUCTION

Presented By: Vishvendu Bhatt, AMTICS

1.1 Introduction to Web Security
• Definition: Web security refers to the practices, measures, and technologies
used to protect websites, web applications, and web services from various
security threats and attacks.

• It involves safeguarding the confidentiality, integrity, and availability of data

and resources accessed through the internet.

• Web security aims to prevent unauthorized access, data breaches, malware,

denial of service attacks, and other vulnerabilities that could compromise
user data or the functionality of a website or web service.
• A Story:

• You (the wizard) have data (fruit) that you'd like to share with some people.
But you know that if you just let everyone have free access to your server
farm (orchard), there'll be disastrous results. People will deface your
servers (vandalize the trees), they'll install botnets or other mal ware to
take the servers over for themselves (steal the trees), and they'll try to deny
service to the servers so no one can use them (burn the trees down).
• In response to these threats, you erect a firewall (lava moat) to keep
everyone out. This is good because it keeps the attackers out, but
unfortunately it keeps all your legitimate users out too.
• So, you write a web application (a giant) that can pass through the firewall.
The web application needs a lot of privileges on the server (the way a giant
is very powerful and strong) so it can access the system's database and the
file system.
• However, while the web application is very powerful, it's not necessarily
very smart, and this is where web application vulnerabilities come in.
• By exploiting logic flaws in the web application, an attacker can essentially
"trick" the web application into performing attacks on his behalf (getting
the giant to do his bidding).
• He may not be able to just connect into the servers directly to vandalize
them or steal from them any more, but if he can get a highly privileged
application to do it for him, then that's just as good. He may even be able to
read the application source code (the wizard's scrolls) out of the file
system.
1.2 The OWASP Top Ten List
• OWASP (Open Web Application Security Project) is an open-source project
with the goal of improving web application security.

• OWASP is basically a loose coalition of individual contributors and sponsor

companies who come together to contribute resources to the project.

• These resources include guidance documents to explain how to write more

secure code, scanning tools to help users find vulnerabilities in
applications, and secure coding libraries users can use to prevent
vulnerabilities from getting into applications in the first place.

• But the best-known OWASP resource by far is its Top Ten List.

• The OWASP Top Ten List of the Most Critical Web Application Security Risks
is compiled from both objective and subjective data.

• Objective data: numbers of database attacks, browser attacks and so on

have been seen by contributing organizations.
1.2 The OWASP Top Ten List
• Subjective data: Subjective rankings of the severity or potential damage of
such vulnerabilities.

• Since web application vulnerability risks change, becoming comparatively

more or less critical over time, the OWASP Top Ten List is periodically
updated to reflect these changes. The first version of the list was created in
2004, then updated in 2007 and again in 2010 (its most recent version as of
this writing). The list is ranked from most risk to least risk, so the# I issue
(injection) is considered to be a bigger problem than the #2 issue (cross-
site scripting), which is a bigger problem than broken authentication and
session management, and so on.
1.2 The OWASP Top Ten List
• 1. Injection:
• SQL injection is a type of attack where malicious SQL code is inserted into a
query, allowing attackers to manipulate the database. Here’s a basic
example:
SELECT * FROM users WHERE username = 'user_input' AND
password = 'password_input';
• If an attacker enters the following input in the form:
Username: admin Password: ‘” OR '1'='1’
The query becomes:
SELECT * FROM users WHERE username = 'admin' AND password = ''
OR '1'='1';
• This query will always return true because '1'='1' is a valid condition,
allowing the attacker to bypass authentication. The attacker can then gain
unauthorized access to the system.
• Search engine text can be manipulated by entering the keywords that forms
a query to be executed on the server.
• Another forms of injections are: XQuery injection, LDAP injection, command
injection
1.2 The OWASP Top Ten List
• 2. Cross-site scripting (XSS)
• Cross-site scripting vulnerabilities are actually a specific type of injection
vulnerability in which the attacker injects his own script code (such as
JavaScript) or HTML into a vulnerable web page.
• Attackers use cross-site scripting holes to steal victims' login passwords,
set up phishing sites, and even to create self-replicating worms that spread
throughout the target website.
• Cross-site scripting is dangerous not just because it can have such high-
impact effects, but also because it's the most pervasive web application
vulnerability.
• You're potentially creating cross-site scripting vulnerabilities whenever you
accept input from a user and then display that input back to them-and this
happens all the time.
• Blogs, Wikis, Sites that displays users search back  Open door for XSS
1.2 The OWASP Top Ten List
• 3. Broken Authentication and Session Management
• HTTP request – reply mechanism.
• web applications almost always need to associate incoming messages with
a particular user.
• Since the underlying HTTP protocol doesn't keep state, web applications
are forced to implement their own state keeping methods.
• the way they do this is to generate a unique token (a session identifier) for
each user, associate that user's state data with the token value and then
send the token back to the user.
• whenever the user makes a subsequent request to the web application, he
includes his session identifier token along with the request. When the
application gets this request, it sees that the request includes an identifier
token and pulls the corresponding state data for that token into memory.
• Problems do come about because of insecure ways of implementing this
design.
• instead of using cryptographically strong random numbers for session
identifiers, an application might be programmed to use incrementing
integers.
• Attacker can easily alter his token identifier values to other values can
access other users’ communication.
1.2 The OWASP Top Ten List
• 3. Broken Authentication and Session Management
• Another example of a poor state management implementation is when the
application returns the session token as part of the page URL, like
www.site.cxx/page?sessionid= 12345..
• It's easy for a user to accidentally reveal this token. If a user copies and
pastes the page URL , from her browser and posts it on a blog, not only is
she posting a link to the page she was looking at but she's also posting her
personal token, and now anyone who follows the link can impersonate her
session.
1.2 The OWASP Top Ten List
• 4. Insecure Direct Object References
• When a web application reveal any internal resource names such as data
file names.
E.g, Displaying internal reference name in URL like,
http://www.myapp.cxx/page?datafile= 12345.txt

• Attacker certainly take the opportunity to change that parameter and see
what other internal data he can get access to. He might set up an automated
crawler to find all the datafiles in the system, from " l .txt" through
"99999999.txt". Or he might get even sneakier and try to break out of the
application's data directory entirely, by entering a datafile parameter like
"../..1../passwords.txt".
1.2 The OWASP Top Ten List
• 5. Cross-Site Request Forgery (CSRF)
• Another type of attack that takes advantage of the disconnected, stateless
nature of HTTP.
• A web browser will automatically send any cookies it's holding for a web
site back to that web site every time it makes a request there.
• This includes any active session identification or authentication token
cookies it has for that site too.
• Attacker may send the specially crafted email messages or lure messages
which will make your browser request for any site on the internet,
• The site receives the request, sees that the request includes your current
session token, and assumes that you really did mean to send it.
• every site on the Internet that relies on cookies to identify its users - and
there are millions of these sites - is vulnerable to this attack by default.
1.2 The OWASP Top Ten List
• 6. Security Misconfiguration
• configuration vulnerabilities when development settings are accidentally
carried over into production environments.
• Web applications in particular are designed to be easy to deploy.
• Sometimes deployment is as simple as copying the files from the
developer's machine to the production server.
• However, developers usually set their configuration settings to give them as
much debugging information as possible, to make it easier for them to fix
bugs.
• If a developer accidentally deploys his configuration settings files onto the
server, then that whole treasure trove of internal data may now be visible to
potential attackers.
• Attacker may exploit any other vulnerability on the system.
1.2 The OWASP Top Ten List
• 7. Insecure Cryptographic Storage
• Sensitive data like passwords should never be stored unencrypted in
plaintext on the server. In fact, it's rarely necessary for passwords to be
stored at all.
• Whenever you can, it's better to store a one-way cryptographic hash of a
user's password rather than the password itself.
• The benefit of this approach is that hash functions only work in one
direction: it's easy to compute the hash of a string, but it's impossible to
recompute the original string from the hash. Even if an attacker somehow
manages to obtain the list of password hashes, he' II still have to take a
brute-force approach to testing for an original value that matches my SHA-1
hash.
1.2 The OWASP Top Ten List
• 8. Failure to Restrict URL Access
• One way that web applications sometimes keep unauthorized users out of
certain pages on the site is to selectively hide or display the links to those
pages.
• If the only thing keeping attacker out is the fact that he is not supposed to
know the site is there, that's not sufficient protection.
• If someone on the inside accidentally reveals the secret site, or if attacker
just happen to guess it, then he will be able to just get straight in.
1.2 The OWASP Top Ten List
• 9. Insufficient Transport Layer Protection
• Using Hypertext Transfer Protocol Secure (HTTPS) for your website gives
you many security benefits that regular HTTP does not. HTTPS uses either
the Secure Sockets Layer (SSL) protocol or, better yet, the Transport Layer
Security (TLS) protocol, which provides cryptographic defenses against
eavesdropping attackers or "men-in-the-middle."
• SSL/TLS encrypts messages sent between the client and the web server,
preventing eavesdroppers from reading the contents of those messages. It
also uses message authentication codes (MACs) to ensure that the
messages haven 't been modified in transit.
• Unfortunately, because HTTPS is slower than standard HTTP (and therefore
more expensive since you need more servers to serve the same number of
users), many web applications don't use HTTPS as thoroughly as they
should.
1.2 The OWASP Top Ten List
• 10. Unvalidated Redirects and Forwards
• There shouldn’t be any invalidated redirects and forwards in the web
application.
1.3 Input Validation
• NEVER TRUST THE USER

• WE NEED-OUR USERS TO TRUST US - We ask a lot from them

• Validate the data that users input into systems.

• BLACKLIST VALIDATION: is a security technique used to prevent

unwanted or malicious input, traffic, or behavior by maintaining a list of
known "bad" items (such as IP addresses, email addresses, domains, or
specific keywords) and blocking any requests or interactions that match
these entries.
• While this method can help reduce specific types of attacks or prevent
access from known malicious sources, it's often less secure than "whitelist
validation" (where only known good items are allowed) because attackers
can sometimes find ways to bypass blacklists or use new, unlisted sources
to launch attacks.
• Examples: IP Address Blacklisting, Email Blacklisting, Keywords
Blacklisting
1.3 Input Validation
• WHITELIST VALIDATION: is a security technique in which only predefined,
trusted entities (such as IP addresses, users, email addresses, or inputs) are
allowed access or action, while everything else is rejected by default.
• This is considered a more secure approach compared to blacklist validation,
as it proactively allows only known good sources or inputs, thereby
minimizing the risk of malicious activity.
• In whitelist validation, the system explicitly defines what is "allowed" and
"safe," blocking anything that does not meet those criteria.
• Examples: IP Address Whtelisting, Email Whitelisting, Keywords
Whitelisting, URL Whitelisting
1.3 Input Validation
• The Defense-in-Depth Approach:
• An another approach to consider would be to validate input both as it
comes in and right before it's used.
• This may have some additional impact on the application's performance,
but it will provide a more thorough defense-in-depth security.
1.4 Attack Surface Reduction
• Like input validation, attack surface reduction is both an effective defense
against the known attacks of today, and a hedge against any new attacks
that you might face tomorrow-attacks that might not even exist in today's
world.
• The attack surface of your application is all of its code and functionality that
can be accessed by any untrusted user.
• Every time you add a new feature to your application, at the same time
you're adding a potential point of failure and a potential means for an
attacker to compromise your system.
• Attack surface reduction is a security strategy aimed at minimizing the
number of potential entry points or vulnerabilities that attackers can
exploit within a system, network, or application. The "attack surface" refers
to the sum of all the points where an attacker can attempt to gain
unauthorized access or exploit weaknesses. The goal of attack surface
reduction is to reduce the exposure to these attack vectors, thereby
lowering the likelihood of successful attacks.
1.4 Attack Surface Reduction
• The very first attack surface reduction principle that should be applied is
“the principle of the least privilege”
• It states that you should only provide a user with the permissions that
allow him to accomplish what he needs to do, and no more.
• For example, while an administrator on your web application might require
write-level access to the application's product catalog database in order to
add new items or change prices, a standard non-administrative user
certainly does not require this access and shouldn't have it.
• This can (and should) be enforced at the application level by performing
appropriate authorization checks.
• Another rule of thumb is that you should not only strive to minimize the
permissions that you grant your users, but also strive to minimize the
capabilities of the programming calls and objects that you yourself use
when you're writing the application.
• For example, If you're a .NET programmer and you have queries that you
intend to only pull data from a single table, you should use DataTable
instead of DataSet, because, DataTable objects are constrained to a single table
of data and consequently have a much lower attack surface.
 GOOGLE CLASSROOM CODE

tqixleq
https://classroom.google.com/c/NzI1NDc2NDg0MDM3?cjc=tqixleq
1.5 Classifying and prioritizing threats
• There is a need to prioritize and classify the threats to minimize the risk.
• STRIDE : It is a threat classification system originally designed by Microsoft
security engineers.
• STRIDE does not attempt to rank or prioritize vulnerabilities, instead the
purpose of STRIDE is only to classify vulnerabilities according to their
potential effects.
• STRIDE is an acronym, standing for:
• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege
• Spoofing vulnerabilities allow an attacker to claim to be someone they're
not, or in other words, to assume another user's identity.
• Tampering vulnerabilities let an attacker change data that should only be
readable to them (or in fact, not even readable to them). Ex. SQL injection
• Repudiation vulnerabilities let the user deny that they ever performed a
given action.
1.5 Classifying and prioritizing threats
• Information disclosure vulnerabilities allow an attacker to read data that
they're not supposed to have access to.
• Denial-of-service attacks are some of the oldest attacks against web
applications. Put simply, denial-of-service (or DoS) attacks attempt to knock
out a targeted application so that users can't access it any more. Another
form of the DoS is DDoS which is much more severe.
• Elevation of privilege, is generally considered to be the most serious type of
all of the STRIDE categories. Elevation of privilege (EoP) vulnerabilities
allow attackers to perform actions they shouldn't normally be able to do.
1.5 Classifying and prioritizing threats
• IIMF
• As a more simplified alternative to STRIDE, one can consider classifying
potential vulnerabilities according to the IIMF model: interception,
interruption, modification, and fabrication.
• Interception is equivalent to the STRIDE category of information disclosure.
• Interruption is equivalent to the STRIDE category of denial-of-service.
• Modification and fabrication are both subtypes of tampering: modification
vulnerabilities allow an attacker to change existing data, and fabrication
vulnerabilities allow an attacker to create his own forged data.
1.5 Classifying and prioritizing threats
• CIA
• A closely related concept to IIMF is CIA: the triad of confidentiality,
integrity, and availability.
• Where interruption, interception, modification, and fabrication are types of
threats, confidentiality, integrity, and availability are the aspects of the
system that we want to protect.
• In other words, CIA are the traits we want the system to have, and IIMF are
the ways attackers break CIA.
1.5 Classifying and prioritizing threats
• Common Weakness Enumeration (CWE)
• The Common Weakness Enumeration (or CWE) is a list of general types of
software vulnerabilities, such as:
• • SQL injection (CWE-89)
• • Buffer overflow (CWE-120)
• • Missing encryption of sensitive data (CWE-311)
• • Cross-site request forgery (CWE-352)
• • Use of a broken or risky cryptographic algorithm (CWE-327)
• • Integer overflow (CWE-190)
• The CWE list (maintained by the MITRE Corporation) is more specific than
the general concepts of STRIDE or IIMF, and is more akin to the OWASP Top
Ten list discussed.
1.5 Classifying and prioritizing threats
• DREAD
• Like STRIDE, DREAD is another system originally developed by Microsoft
security engineers during the "security push"-a special security-focused
development milestone phase-for Microsoft Visual Studio .NET
• STRIDE is meant to classify potential threats, DREAD is meant to rank them
or score them according to their potential risk.
• DREAD scores are composed of five separate subscores, one for each letter
of D-R-E-A-D:
• Damage potential
• Reproducibility (or Reliability)
• Exploitability
• Affected users
• Discoverability
• The damage potential component of the DREAD score is pretty
straightforward: If an attacker was able to pull off this attack, just how
badly would it hurt you? If it's just a minor nuisance attack, say maybe it
just slowed your site's response time by one-half of one percent, then the
damage potential for that attack would be ranked as the lowest score, one
out of ten.
1.5 Classifying and prioritizing threats
• But if it's an absolutely devastating attack, for example if an attacker could
extract all of the personal details and credit card numbers of all of your
application's users, then the damage potential would be ranked very high,
say nine or ten out of ten.
• The reproducibility (or reliability) score measures how consistently an
attacker would be able to exploit the vulnerability once he's found it. lf it
works every time without fail, that's a ten. If it only randomly works one
time out of 100 then the reproducibility score might be only one or two.
• Exploitability refers to the ease with which the attack can be executed: how
many virtual "hoops" would an attacker have to jump through to get his
attack to work? For an attack requiring only a "script kiddie" level of
sophistication, the exploitability score would be a ten. For an attack that
requires a successful social engineering exploit of an administrative user
within a five-minute timeframe of the time the attack was launched, the
exploitability score would be much lower.
• The affected users score is another pretty straightforward measure: the
more users that could be impacted by the attack, the higher the score.
1.5 Classifying and prioritizing threats
• The discoverability score-in other words, given that a vulnerability exists in
the application, how likely is it that an attacker could actually find it?
• obvious vulnerabilities like login credentials or database connection
strings left in HTML page code would score high, whereas something
more obscure, like an LDAP injection vulnerability on a web service
method parameter, would score low.
1.5 Classifying and prioritizing threats
• Common Vulnerability Scoring System CCVSS)
• CVSS is an open standard, originally created by a consortium of software
vendors and nonprofit security organizations, including:
• Carnegie Mellon University's Computer Emergency Response Team
Coordination Center (CERT/CC)
• Cisco
• U.S. Department of Homeland Security (DHS)/MITRE
• IBM Internet Security Systems
• Microsoft
• eBay
• Symantec
1.6 Mobile phone threats and vulnerabilities exploits
• Particular focus on wireless devices—including Internet of Things (IoT)—
and mobile devices (where it applies)
• The first step to formulating any security plan is to ask questions, such as
the following:
• What are you trying to protect? : Is it corporate data, intellectual property,
customer data, financial assets, or remote control of a physical device?
• Why are you trying to protect it? : Is protection mandated by a government
or industry agency, or is it an internal best practice?
• What is the value of the asset? Have the assets been quantified? Has the
cost of a data breach been estimated?
• What are you protecting it from? : Are the threats internal or external? Are
they aimed at data theft, device control, or system access? Are the threats
environmental or human in origin?
• What constraints prevent you from protecting the asset? Is broad access
required? Does the data change or move around?
1.6 Mobile phone threats and vulnerabilities exploits
• The answers to these basic questions will help you identify the assets you
must secure, as well as the priority and value of each individual asset. This
is vitally important.
• Security must be cost-effective.
1.6 Mobile phone threats and vulnerabilities exploits
• General Threat Categories:
• Outsider
• Insider
• Often known as Intruders : Who access the resources without permission.
• The core principle of information security remains same: C-I-A triad
• However, it has been expanded been expanded to cater to the specific
requirements of new technologies and business models. These expanded
principles of information security are as follows:
• Confidentiality
• Integrity
• Availability
• Accountability : Making users accountable for their actions
The key point is authentication. A user cannot be accountable if the
system has not authenticated them. Authentication on its own, however, is
of limited use because it simply verifies that the user is who they claim to
be and places no restrictions on access to resources.
• Nonrepudiation : Preventing the denial that an action has been taken
1.6 Mobile phone threats and vulnerabilities exploits
• Threats to Wireless and Mobile Devices
• Three categories:
• Data theft
• Device control
• System access
• Remember : virtually every threat that exists on wired networks also exists
on wireless and mobile networks. In addition to these threats, some threats
are specific to wireless and mobile or now have wireless and mobile
variants
1.6 Mobile phone threats and vulnerabilities exploits
• Data theft Threats :
• Often, hackers go after a target of opportunity rather than instigating a
targeted attack on a specific company.
• In such a case, they will look for personally identifiable information (PII),
which is information that can be used to identify, contact, or locate a single
person, or to identify an individual in context, with any business-related
data.
• The most common threats are:
• Sniffing (snooping) : In radio-based communication (wireless) the signals
can be easily intercepted through a process called sniffing or snooping.
• No physical access to the medium is needed.
• Remedy: Encryption
• Malicious applications (malware) : applications range from malware that
can be auto installed on phones to spyware that can copy emails, texts, and
contacts.
• There is also a significant privacy issue due to the ability to track the
location of a mobile device.
• Remedy: Strict restrictions on downloading apps
1.6 Mobile phone threats and vulnerabilities exploits
• Browser exploits : Specifically targeting mobile users, these exploits take
advantage of vulnerabilities on mobile web browsers.
• A big consideration for Bring Your Own Device (BYOD) environments
because unlike company-owned assets, on which updates can be mandated
and managed, personal devices can and often are several updates behind.
• Which means that simply by visiting an unsafe webpage, a user can trigger
a browser exploit that installs malware or performs other actions on their
device.
• Remedy: MDM – Mobile Device Management in BYOD environment.
• Wireless phishing : Phishing involves sending fake emails or Short
Message Service (SMS) messages to a target in an attempt to get the victim
to click a link that will take them to a fraudulent website.
• Phishing is more effective due to smart devices with small viewing screens,
which can make it difficult to notice some of the tell tale signs of phishing.
• Hackers can also take advantage of users who connect to rogue access
points.
1.6 Mobile phone threats and vulnerabilities exploits
• Lost or stolen devices: Not only do lost or stolen devices result in data loss
they also can result in unauthorized system access.
• The device is compromised, especially if it has remote access software
configured for access to the corporate network.
• Remedy: Timely notification and blocking or wiping the device are the best
options if it is lost or stolen.
• System or device takeover : With IoT, specifically with wireless controlled
IoT deives, attackers can block physical or remote access.
1.6 Mobile phone threats and vulnerabilities exploits
• Device Control threats : With control of the device, the hacker not only has
ongoing access to data but can also use the device to launch other attacks or
leverage the permissions on the device to gain access to higher-valued
targets such as internal servers.
• It occurs through a process of lateral movement across the network called
lily padding, or island hopping, in which the hacker “hops” from one device
to another, with each hop getting the hacker closer to the target
• Examples of device control threats include the following:
• Unauthorized and modified clients : clients—Users sometimes create
vulnerabilities when they try to modify policies or device configurations.
• This can open backdoors and other vulnerabilities.
• Examples of this include user hacks found on the Internet to alter a smart
device (referred to as jailbreaking) and opening a smartphone hotspot
(without security).
1.6 Mobile phone threats and vulnerabilities exploits
• Endpoint attacks : Several tools now exist that can attack wireless clients
directly.
• An automated tool called Metasploit, for example, can be used to probe Wi-
Fi clients for thousands of known vulnerabilities. Once exposed and
exploited, the Wi-Fi client can be controlled and/or monitored.
• Bluetooth Wi-Fi hacks : Traditionally, vulnerabilities in Bluetooth
protocols have enabled hackers to gain access to and control of mobile
devices.
• However, this is no longer as easy as it used to be because Bluetooth is now
switched off and set to non discovery mode by default.
• If a user changes this setting, however, hackers can easily take control of a
Bluetooth-enabled mobile device
• Near field communication and proximity hacking : One technology that
allows an ad hoc wireless connection between two devices that are within a
few feet of each other is near field communication (NFC).
• Unlike Bluetooth, the pairing process is automatic. Already used extensively
for social media and to exchange contact information, the future of NFC
includes the ability to auto pay via credit card at point-of-sale (PoS)
terminals and will likely become a prime target for hackers.
1.6 Mobile phone threats and vulnerabilities exploits
• System Access Threats : There are cases in which hackers are more
interested in breaking the network or disrupting network access for
political or financial gain or, in some cases, to exact revenge for a real or
perceived insult or injury. Examples of these types of system access threats
include the following:
• DoS attacks
• Evil twin access points : An access point can easily be set to the same SSID
(service set identifier) as a legitimate WLAN or hotspot, fooling
unsuspecting users into connecting.
• This is not a new problem, but there are new hacker tools that can listen to
clients to see what SSIDs they are looking for and then configure
themselves to look like one of those networks. The client will then connect
without the user having done a thing. Once connected, the client is subject
to a full host of network attacks.
1.6 Mobile phone threats and vulnerabilities exploits
• Rogue access points : Unauthorized or rogue access points have been a
problem for as long as Wi-Fi has been commercially available.
• Today, the appearance of rogue access points is usually due to poor site
planning, which results in wireless dead zones.
• Out of frustration, an employee may set up a rogue access point to gain
access to the network. But if a hacker gains entry to a building, they can
easily set one up as well.
• Unless regular site survey sweeps are conducted, rogue access points may
go unnoticed by IT for some time, resulting in a lingering vulnerability.
1.6 Mobile phone threats and vulnerabilities exploits
• Risk Mitigation:
• Mobile device screen locks and password protection
• Remote locks and data wipes for mobile devices : If a device is lost or
stolen, a remote lock can temporarily secure a device. If the device is not
recovered, a remote data wipe or swipe will prevent all future access to
business data and accounts stored on the phone.
• Mobile GPS location and tracking
• Stored data encryption—In most cases, device locks and data wipes are
sufficient to mitigate the risk of data theft, data loss, and data leakage. But
as an added security measure, executives and other employees with access
to sensitive information should encrypt data on their personal devices
1.6 Mobile phone threats and vulnerabilities exploits
• Mitigate risk of BYOD:
• Mobile Device Management (MDM) :
• MDM is a technology that has emerged to enable network security
administrators to manage mobile devices. MDM typically sends over the- air
signals to mobile devices to distribute applications and configuration
settings for all makes of mobile phones and other mobile devices.
• The intent is to provide a central point of control and policy from which to
enhance the functionality and efficiency of mobile communications while
reducing costs and risk.
• MDM architecture : two elements : Server element and Client element
• Server element is a central management system and a client element,
resides on the mobile device.
• MDM Server: The MDM server provides automatic identification and
configuration of any new mobile device that attempts to join the network
for the first time.
• it maintains a history of all configurations and updates sent to the devices
on the network and can send new updates over the air (OTA) when
required.
1.6 Mobile phone threats and vulnerabilities exploits
• The server can initiate MDM security features, which send the commands
OTA to the remote mobile device. E.g. remote locking, device wiping,
location tracking etc.
• The job of MDM is not just to keep mobile devices up to date. The
application typically provides other essential services such as remote
locking, location tracking, and wiping of the device in case of loss or theft.
• MDM provides a valuable management facility for administering and
securing mobile devices on large networks. MDM can be expensive for
smaller companies, but that capital expense can be avoided through the use
of a Software as a Service (SaaS) cloud based MDM solution.
1.6 Mobile phone threats and vulnerabilities exploits
• Mitigate risk of BYOD:
• Mobile Application Management (MAM) :
• MDM provides a method for configuration and policy management, but
what about application management and control?
• In MAM particular concern are applications of unknown origin or quality
residing on the employee’s device.
• After all, the employee is likely to download all sorts of recreational
applications, some of which open backdoors to the device. To mitigate this
risk, the following steps must be taken:
• Secure applications
• Secure network access
• Encryption
• MAM is responsible for administering and managing applications on mobile
devices.
• MAM software controls the provisioning and distribution of in-house
mobile applications and, in some cases, commercially available applications
through an enterprise application store.
• With MAM, the IT department can verify and authorize the download of in-
house and commercial applications from the central store. This goes a long
way toward establishing a secure application management system
1.7 Mobile device security models
• The major smartphone vendors—Google, Apple, and Microsoft—has
adopted an approach to improve security and lower risk for users.
Interestingly, these vendors’ approaches don’t significantly differ.
• All three are based in part on the two main concepts of controlling access to
applications (downloads) and compartmentalizing applications and their
resources once downloaded.
• Mobile device security models are :
• The Android security model
• The iOS security model
• The windows phone 8 security model
1.7 Mobile device security models
• The Android security model :
• 1. Linux Kernel Foundation: Android is built on the Linux kernel, which
provides a strong security foundation with features like user-based
permissions, process isolation, and inter-process control mechanisms.
• 2. Process Sandboxing: Each Android application runs in its own Dalvik
virtual machine (VM), isolated within its own Linux process, ensuring
robust application-level security.
• 3. Linux Security Features: The Linux kernel's multiuser capabilities
prevent unauthorized access between users, ensuring one user's files,
applications, or resources remain inaccessible to another.
• 4. Android Sandbox: Android enhances Linux's security features by creating
the "Android sandbox," which isolates applications and resources for added
security.
• 5. Kernel-Centric Security: While the Java and Dalvik VMs are secure,
Android relies on the Linux kernel—not the VMs—to enforce security,
removing unsecure kernel elements where necessary.
1.7 Mobile device security models
• The Android Sandbox:
• 1. Application Isolation: Android assigns a unique user ID to each
application, running it as a separate user process with its own permissions,
isolating files, resources, and memory.

• 2. Sandboxing: Applications are isolated within a sandbox, controlling inter-

process communications, resources, and memory, ensuring no leakage
between applications.

• 3. Crash Containment: A memory crash in one application is confined to

that application, preventing arbitrary code execution from affecting other
applications or the overall system security.

• 4. System-Wide Isolation: This isolation extends beyond applications to

include OS applications, libraries, frameworks, and the application runtime,
enhancing overall device security.
1.7 Mobile device security models
• File System Permissions:
• 1. Permission-Based Access Control: The Linux file system ensures that
users or applications cannot access files belonging to others without
explicit permission.

• 2. Application-Specific Permissions: In Android, each application runs as a

unique user with its own permissions.

• 3. File Isolation: Files created by one application are inaccessible to others

unless the developer explicitly grants permission.
1.7 Mobile device security models
• Android SDK Security Features:
• 1. Security Features : Android employs tools like ProPolice to prevent stack
overflows, protections against kernel address leaks and integer overflows,
and hardware-based "No-Execute" controls to block code execution on the
stack or heap.
• 2. Encryption Support : Android supports cryptographic APIs for secure
data encryption using algorithms such as AES, RSA, DSA, and SHA. Android
3.0 and later versions introduced full file-system encryption with AES-128
or AES-256 encryption.
• 3. Adiantum Encryption : To address the resource constraints of low-end
smartphones and IoT devices, Google developed Adiantum, a low-power
encryption system enabling secure full-file system encryption on devices
with limited memory and processing power.
1.7 Mobile device security models
• Android security model vulnerabilities:
• 1. Rooting and Unlocking Devices: Only the OS kernel and a few core
applications have root (super-user) permissions in Android's security
model.
• Rooting a device gives someone privileged root permissions, enabling them
to override the Android OS security and do anything on the device which
increases the device’s vulnerability to malware.
• Unfortunately, some versions of Android enable the user to change the boot
sequence through the boot loader, which enables them to upload an
alternative version of the OS or an application with root permissions.
• Another security concern with rooted Android devices is that Android
natively supports active content such as Flash, Java, JavaScript, and HTML5.
This can open attack routes for malware.
• Additionally, there are new features, such as Always on Listening and Auto
Content Update, which can be vulnerable to misuse because they can
dynamically enable or disable features, provide location information, or
record conversations.
1.7 Mobile device security models
• The Apple iOS security model :
• The Apple iOS is a slimmed-down version of Apple’s OS X, which is used in
the company’s line of Mac computers. OS X is actually a derivative of the
FreeBSD variant of UNIX code maintained by a large open source
community. Its security model is based on access control, application
security, encryption, and isolation.
• Walled Garden Security: Apple restricts app downloads to its App Store,
ensuring controlled access.
• Developer Verification: App creators must register, pay, and obtain a digital
certificate to sign and submit apps.
• Code Integrity: Digitally signed apps prevent tampering, maintaining
security after release.
• App Store Oversight: Apple reviews and approves all apps before granting
certificates and allowing distribution.
1.7 Mobile device security models
• The Apple iOS security model :
• Application Provenance: This approach doesn’t guarantee that apps in App
Store are safe, but hold app developers accountable for their work.
• Malicious actors can register with stolen identities to upload harmful
applications.
• Limitation:
• It works only on iOS devices that have not been jailbroken. If an owner
jailbreaks their device to download apps from any other source,
provenance model has been disabled, an iOS device is vulnerable to
malware attacks.
1.7 Mobile device security models
• The Apple iOS security model :
• iOS Sandbox: Each app runs in isolation, preventing access to other apps or
the OS kernel, enhancing security.
• Segregation of apps and system resources limits the risk of malware.
• iOS vs. Android Access Control: iOS allows apps free access to system
features, while Android requires user permission.
• Privacy Concerns: Apple's approach, though secure, has been criticized for
allowing apps to access sensitive data without user consent.
• Security Concerns: While Apple's sandboxing limits malware spread and
prevents kernel modifications, web-based attacks (e.g., via Safari) can still
compromise sensitive data like contacts, calendar, and login credentials.
1.7 Mobile device security models
• The Apple iOS security model :
• Encryption: Apple enhances security with full-device encryption, but since
a key is stored on the device for background processes, data could be
accessible to someone with physical access; to counter this, iOS uses
layered encryption, securing sensitive data like emails and messages –
double encrypted.
• Jailbreaking iOS: Jailbreaking in iOS is the process of removing Apple's
software restrictions, allowing users to gain root access to the operating
system and install unauthorized apps, modify system settings, and bypass
security features makes device vulnerable to the malwares.
1.7 Mobile device security models
• The Windows Phone8 Security:
• features that provide security and management control, mitigate data
leakage, and offer protection from malware. Microsoft has also integrated
security features such as BitLocker, Windows Defender, SmartScreen Filter,
and user access control into the security architecture for its mobile devices
• Platform Application Security: similar to Apple’s iOS strategy in the way
they both worked to protect applications through isolation
• Like Apple iOS, Windows Phone uses strict application provenance through
Windows store.
1.7 Mobile device security models
• The Windows Phone8 Security:
• Security features:
• Windows 8.1 implemented secure boot and encryption via Trusted
Platform Module, along with a sandbox model for app isolation.
• Security by Obscurity: Windows 8.1's limited market share (less than 2%)
made it less of a target for malware, offering some protection through
obscurity.