This document discusses security models for mobile platforms and detecting malware in the Google Play Store. It describes the security models of iOS and Android platforms, including sandboxing of apps, permissions, and code signing. It then covers different techniques for detecting malware in the Play Store, such as signature-based detection, behavior-based detection, permission analysis, and cloud-based scanning using services like Bouncer.

1. Mobile Platform Security
Models

2. List of Topics
• Introduction : Platforms and Attacks
• iOS Platform Security Models
• Android Platform Security Models
• Detecting Android Malware in Play Store

3. Introduction : Platform and
Attacks

4. Change takes time

5. Global Smartphone Market Share

6. Two different Attack Vectors
• Web Browsers
• Installed Applications
Both of these attack vectors are increasing in prevalence and
sophistication

7. Mobile Malware Attacks
• Unique to Phones:
• Premium SMS Messages
• Identify Location
• Record Phone Calls
• Log SMS
• Similar to desktops:
• Connects to botmasters
• Steals Data
• Phishing
• Malvertising

8. Kaspersky Security Bulletin
Overall statistics for 2017
• 4% of user computers were subjected to at least one Malware-class web
attack over the year.
• Kaspersky Lab solutions repelled 1 188 728 338 attacks launched from
online resources located all over the world.
• 199 455 606 unique URLs were recognized as malicious by web antivirus
components.
• Kaspersky Lab’s web antivirus detected 15 714 700 unique malicious
objects.
• 939 722 computers of unique users were targeted by encryptors.
• Kaspersky Lab solutions blocked attempts to launch malware capable of
stealing money via online banking on 1 126 701 devices

9. Typical Scenario
• Cybercriminals create an affiliate website and invite Internet users to
become their accomplices
• A unique modification of the malware and a landing page for
download is created for each accomplice
• Participants of the affiliate program trick Android users into installing
malicious application
• Infected device sends SMS messages to premium numbers, making
money for the cybercriminals
• Part of money is paid to the affiliate partners

10. Mobile Malware Examples
• DroidDream ( Android )
• Over 58 apps uploaded to Google Play Store
• Conducts Data Theft and sends credentials to the Attackers
• Ikee ( iOS )
• Worm Capabilites ( Targeted default ssh pwd )
• Worked only on Jailbroken Phones with ssh installed
• Zitmo ( Windows )
• Propagates via SMS, claims to install a security certificate
• Captures information from SMS, aims to defeat 2-factor Authentication
• Works with Zeus botnet, timed with user PC infection

11. Comparison between Platforms
• Operating Systems
• UNIX
• Windows
• Approval process for Applications
• Market: Vendor controlled / Open
• App signing: Vendor-issued / Self-signed
• User approval of permission
• Programming Language for Applications
• Managed Execution: Java, .NET
• Native Execution: Objective C

12. iOS Platform Security Model

13. Apple iOS Devices

14. iOS Application Development
• Apps developed in Objective C using Apple SDK
• Event-Handling model based on touch events
• Foundation and UIKit frameworks provide the security key services
used by all iOS Applications

15. iOS Platform
• Cocoa Touch: Foundation framework,
OO support for collections, file
management, network operations; UIKit
• Media layer: supports 2D and 3D
drawing, audio, video
• Core OS and Core Services: APIs for
files, network, etc includes SQLite,
POSIX threads, UNIX sockets
• Kernel: based on Mach kernel like Mac
OS X

16. iOS Security
• Device security
• Prevent unauthorized use of device
• Data security
• Protect data at rest; device may be lost
or stolen
• Network security
• Networking protocols and encryption of
data in transmission
• App security
• Secure platform foundation

17. App Security
• Runtime protection
• System resources, kernel shielded from user apps
• App “sandbox” prevents access to other app’s data
• Inter-app communication only through iOS APIs
• Code generation prevented
• Mandatory code signing
• All apps must be signed using Apple-issued certificate
• Application data protection
• Apps can leverage built-in hardware encryption

18. iOS Sandbox
• Limit app’s access to files,
preferences, network, other
resources
• Each app has own sandbox
directory
• Limits consequences of
attacks
• Same privileges for each
app

19. File Encryption
• The content of a file is encrypted with a per-file key, which is wrapped with
a class key and stored in a file’s metadata, which is in turn encrypted with
the file system key.
• When a file is opened, its metadata is decrypted with the file system key, revealing
the wrapped per-file key anda notation on which class protects it
• The per-file key is unwrapped with the class key, then supplied to the hardware AES
engine, decrypting the file as it is read from flash memory
• The metadata of all files is encrypted with a random key. Since it’s stored
on the device, used only for quick erased on demand.

20. Masque Attack
• iOS app installed using enterprise/adhoc provisioning could replace
genuine app installed through the App Store, if both apps have same
bundle identifier
• This vulnerability existed because iOS didn't enforce matching
certificates for apps with the same bundle identifier

21. Android Platform Security
Models

22. Platform Outline
• Linux kernel, browser, SQL-lite database
• Software for secure network communication
• Open SSL, Bouncy Castle crypto API and Java library
• C language infrastructure
• Java platform for running applications
• Also: video stuff, Bluetooth, vibrate phone, etc.

23. Android Architecture

24. Google Play Store
• Self-signed apps
• App permissions granted on user installation
• Open market
• Bad applications may show up on market
• Shifts focus from remote exploit to privilege escalation

25. Security Features
• Isolation
• Multi-user Linux operating system
• Each application normally runs as a
different user
• Battery life
• Developers must conserve power
• Applications store state so they can
be stopped (to save power) and
restarted – helps with DoS
• Communication between
applications
• May share same Linux user ID
• Access files from each other
• May share same Linux process and
Dalvik VM
• Communicate through application
framework
• “Intents,” based on Binder,
discussed in a few slides

26. Application Development Concepts
• Activity – one-user task
• Example: scroll through your inbox
• Email client comprises many activities
• Service – Java daemon that runs in
background
• Example: application that streams an
mp3 in background
• Activity
• User click on inbox entry fires an intent
to the viewer activity, which then
allows user to view that email
• Content provider
• Store and share data using a relational
database interface
• Broadcast receiver
• “mailboxes” for messages from other
applications
• Intents – asynchronous messaging
system
• Fire an intent to switch from one
activity to another
• Example: email app has inbox,
compose activity, viewer

27. Exploit Prevention
• 100 libraries + 500 million lines new code
• Open source -> public review, no obscurity
• Goals
• Prevent remote attacks, privilege escalation
• Secure drivers, media codecs, new and custom features
• Overflow prevention
• ProPolice stack protection
• First on the ARM architecture
• Some heap overflow protections
• Chunk consolidation in DL malloc (from OpenBSD)

28. Application Sandbox
• Each application runs with its UID in its own Dalvik virtual machine
• Provides CPU protection, memory protection
• Authenticated communication protection using Unix domain sockets
• Only ping, zygote (spawn another process) run as root
• Applications announces permission requirement
• Create a whitelist model – user grants access
• But don’t want to ask user often – all questions asked as install time
• Inter-component communication reference monitor checks permissions

29. Layers of Security
• Each application executes as its own user identity
• Android middleware has reference monitor that mediates the
establishment of inter-component communication (ICC)

30. Java Sandbox
Four complementary mechanisms
• Class loader
• Separate namespaces for separate class loaders
• Associates protection domain with each class
• Verifier and JVM run-time tests
• NO unchecked casts or other type errors, NO array overflow
• Preserves private, protected visibility levels
• Security Manager
• Called by library functions to decide if request is allowed
• Uses protection domain associated with code, user policy

31. Comparison: iOS vs Android
• App approval process
• Android apps from open app store
• iOS vendor-controlled store of vetted apps
• Application permissions
• Android permission based on install-time manifest
• All iOS apps have same set of “sandbox” privileges
• App programming language
• Android apps written in Java; no buffer overflow…
• iOS apps written in Objective-C

32. Detecting Malware in Play Store

33. Detecting Malware in Play Store
• Signature based Malware Detection
• Specification based Malware detection
• Behaviour based Malware Detection
• Application Permission Analysis
• Cloud based Malware Detection

34. Signature Based Malware Detection
• Signature-based detection works by scanning the contents of computer files
and cross-referencing their contents with the “code signatures” belonging to
known viruses.
• A library of known code signatures is updated and refreshed constantly by
the store.
• If a viral signature is detected, the software acts to block application from
causing any damage.
• Clearly there will always be new and emerging viruses with their own
unique code signatures.
• Hence the library is updated frequently to detect application with malware

35. Specification Based Malware Detection
• Specification based detection makes use of certain rule set of what is considered as
normal in order to decide the maliciousness of the program violating the
predefined rule set.
• Thus programs violating the rule set are considered as malicious program. In
specification-based malware detection, where a detection algorithm that addresses
the deficiency of pattern-matching was developed.
• This algorithm incorporates instruction semantics to detect malware instances.
• The approach is highly resilience to common obfuscation techniques. It used
template T to describe the malicious behaviours of a malware, which are sequence
of instructions represented by variables and symbolic constants. The limitation of
this approach is that the attribute of a program cannot be accurately specified.
• Specification-based detection is the derivate of anomaly based detection.

36. Behaviour based Malware Detection
• The behaviour-based malware detection system is composed of several
applications, which together provide the resources and mechanisms
needed to detect malware on the Android platform.
• Each program has its own specific functionality and purpose in the
system and th e combination of all of them creates the Behavior-
Based malware detection system.
• The Android data mining scripts and applications mentioned in are the
responsible for collecting data from Android applications, and the
script running on the server will be the responsible for parsing and
storing all collected data.

37. Behaviour based Malware Detection
• The methods of analysis of the behavior-based malware detection
system can be divided into two main groups:
• Static Analysis
• Static Analysis is responsible for analysing Android source code in order to
look for malicious code patterns or signatures.
• This form of analysis will decompress, disassemble and search for patterns in
the APK files.
• The method is fast and does not generate a high processing load.

38. Behaviour based Malware Detection
• Dynamic Analysis
• Dynamic Analysis analyses the behaviour of Android applications by
monitoring system calls with the Strace tool.
• All input traces generated by the Android smartphone user will be collected
using the data collector application well as the crowd sourcing and data
collector script.
• In Dynamic Analysis the user will install, execute and generate input data for
the Android applications in order to obtain an application behaviour output log
file.

39. Application Permission Analysis
• Applications run in a sandbox environment however they need
permissions to access certain data.
• At the time of installation, Android platform asks the user to grant or
deny permission for the application based on the activities the
application can perform.
• The Kirin security service interacts with Android Application installer
and it also interacts with collection Kirin Security rules.
• Rules represent the malicious patterns and it is compared with
configuration of the installed application.

40. Application Permission Analysis
The study proposes five steps to identify dangerous configurations
1. Check the phone’s assets
2. What are the functional requirements
3. Analyse asset security goals and threats
4. Specify security requirements
5. Analyse security mechanism limitations

41. Cloud Based Malware Detection
• Google Play applications are scanned for malware.
• Google uses a service named Bouncer to automatically scan applications on
the Google Play Store for malware.
• As soon as an application is uploaded, Bouncer checks it and compares it to
other known malware, Trojans, and spyware.
• Every application is run in a simulated environment to see if it will behave
maliciously on an actual device.
• The applications behaviour is compared to the behaviour of previous
malicious apps to look for red flags.
• New developer accounts are particularly scrutinized – this is to prevent
repeat offenders from creating new accounts.

42. Cloud Based Malware Detection
• Google Play can remotely uninstall applications: If you’ve installed an
app that is later found to be malicious, Google has the ability to
remotely uninstall this application from your phone when it’s pulled
from Google Play.
• Google announced an exciting security feature called the "application
verification service" to protect against harmful Android applications.