Mobile Application Penetration Testing

@BGASecurity
BGA | MobilePentest
@BGASecurity
Mobile Application Penetration Testing
2014

@BGASecurity
BGA | MobilePentest
@BGASecurity
BGA Bilgi Güvenliği A.Ş
BGA Security Hakkında
BGA | MobilePentest
Siber güvenlik dünyasına yönelik, yenilikçi profesyonel
çözümleri ile katkıda bulunmak amacı ile 2008 yılında
kurulan BGA Bilgi Güvenliği A.Ş. stratejik siber güvenlik
danışmanlığı ve güvenlik eğitimleri konularında büyük
ölçekli çok sayıda kuruma hizmet vermektedir.
Gerçekleştirdiği vizyoner danışmanlık projeleri ve
nitelikli eğitimleri ile sektörde saygın bir yer kazanan
BGA Bilgi Güvenliği, kurulduğu günden bugüne kadar
alanında lider finans, enerji, telekom ve kamu
kuruluşları ile 1.000'den fazla eğitim ve danışmanlık
projelerine imza atmıştır.
ARGE
EĞİTİM
MSSP
PENTEST
SOME / SOC
SECOPS

@BGASecurity
BGA | MobilePentestBGA | MobilePentestIntroduction
• A major priority of the OWASP Mobile Security Project is to help standardize and disseminate mobile
application testing methodologies.
• The ideal mobile assessment combines dynamic analysis, static analysis, and forensic analysis to ensure
that the majority of the mobile application attack surface is covered.
• On some platforms, it may be necessary to have root user or elevated privileges in order to perform all
of the the required analysis on devices during testing.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestMobile Application Pentest
• Information Gathering - describes the steps and things to consider when you are in the early stage
reconnaissance and mapping phases of testing as well as determining the application’s magnitude of
effort and scoping.
• Static Analysis - Analyzing raw mobile source code, decompiled or disassembled code.
• Dynamic Analysis - executing an application either on the device itself or within a simulator/emulator
and interacting with the remote services with which the application communicates. This includes
assessing the application’s local interprocess communication surface, forensic analysis of the local
filesystem, and assessing remote service dependencies.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInformation Gathering
• Prerequisites of this phase may require specific operating systems, platform specific software
development kits (SDK’s), rooted or jailbroken devices, the ability to man-in-the-middle secure
communications (i.e. HTTPS) and bypass invalid certificate checks.
• Manually navigate through the running application to understand the basic functionality and workflow
of the application. This can be performed on a real device or within a simulator/emulator. For deeper
understanding of application functionality tester can proxy and sniff all network traffic from either a
physical mobile device or an emulator/simulator recording and logging traffic (if your proxy tool permits
logging, which most should).

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInformation Gathering – Cont.
• Identify the networking interfaces used by the application
• Determine what the application supports for access 3G, 4G, wifi and or others
• What networking protocols are in use?
Ø Are secure protocols used where needed?
Ø Can they be switched with insecure protocols?
• Does the application perform commerce transactions?
Ø Credit card transactions and/or stored payment information (certain industry regulations may be
required (i.e. PCI DSS)).
Ø In-app purchasing of goods or features
• Make note for future phases to determine does the application store payment information? How is
payment information secured?

@BGASecurity
• Monitor and identify the hardware components that the application may potentially interact with
Ø NFC
Ø Bluetooth
Ø GPS
Ø Camera
Ø Microphone
Ø Sensors
Ø USB
• Perform open source intelligence gathering (search engines, source code repositories, developer
forums, etc.) to identify source code or configuration information that may be exposed (i.e. 3rd party
components integrated within the application)
• What frameworks are in use?

@BGASecurity
• Identify if the application appears to interact with any other applications, services, or data such as:
Ø Telephony (SMS, phone)
Ø Contacts
Ø Auto correct / dictionary services
Ø Receiving data from apps and other on-device services
Ø Google Wallet
Ø iCloud
Ø Social networks (i.e. Facebook, Twitter, LinkedIn, Google+)
Ø Dropbox
Ø Evernote
Ø Email
Ø Etc.

@BGASecurity
• Can you determine anything about the server side application environment?
Ø Hosting provider (AWS, App Engine, Heroku, Rackspace, Azure, etc.)
Ø Development environment (Rails, Java, Django, ASP.NET, etc.)
Ø Does the application leverage Single Sign On or Authentication APIs (Google Apps, Facebook, iTunes, OAuth, etc.)
Ø Any other APIs in use
ü Payment gateways
ü SMS messaging
ü Social networks
ü Cloud file storage
ü Ad networks
• Perform a thorough crawl of exposed web resources and sift through the requests and responses to identify potentially
interesting data or behavior
Ø Leaking sensitive information (i.e. credentials) in the response
Ø Resources not exposed through the UI
Ø Error messages
Ø Cacheable information

@BGASecurity
BGA | MobilePentestBGA | MobilePentestStatic Analysis
• There are two primary ways static analysis will generally be performed on a mobile application:
Ø Analyzing source code obtained from development team (prefered)
Ø Using a compiled binary.
• Some level of static analysis should be performed for both dynamic and forensic analysis, as the
application’s code will almost always provide valuable information to the tester (i.e. logic, backend
targets, APIs, etc).
• In scenarios where the primary goal is to identify programmatic examples of security flaws, your best
bet is to review pure source code as opposed to reverse engineering compiled software.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestGetting Started
• If the source is not directly available, decompile or disassemble the application’s binary
Ø extract the application from the device
Ø follow the appropriate steps for your platform’s application reverse engineering
Ø some applications may also require decryption prior to reverse engineering (note: decryption and
code obfuscation are not the same thing)
• Review the permissions the application requests as well as the resources that it is authorized to access
(i.e. AndroidManifest.xml, iOS Entitlements or Windows Phone's WMAppManifest.xml)
• Are there any easy to identify misconfigurations within the application found within the configuration
files? Debugging flags set, world readable/writable permissions, etc.
• What frameworks are in use? Is the application built using a cross-platform framework?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestGetting Started
• Identify the libraries in use including both platform provided as well as third party. Perform a quick
review on the web to determine if these libraries:
Ø are up to date
Ø are free of vulnerabilities
Ø expose functionality that requires elevated privileges (access to location or contact data)
Ø native code
• Does the application check for rooted/jailbroken devices? How is this done? How can this be
circumvented? Is it as easy as changing the case of a file name or name of executable or path?
• Determine what types of objects are implemented to create the various views within the application.
This may significantly alter your test cases, as some views implement web browser functionality while
others are native UI controls only.
• Is all code expected to run within the platform’s standard runtime environment, or are some
files/libraries dynamically loaded or called outside of that environment at runtime?

@BGASecurity
BGA | MobilePentestBGA | MobilePentest
• Attempt to match up every permission that the application requests with an actual concrete
implementation of it within the application. Often, developers request more permission than they
actually need. Identify if the same functionality could be enabled with lesser privileges.
• Locate hard coded secrets within the application such as API keys, credentials, or proprietary business
logic.
• Identify every entry point for untrusted data entry and determine how it enforces access controls,
validates and sanitizes inbound data, and passes the data off to other interpreters
• From web service calls
• Receiving data from other apps and on-device services
• Inbound SMS messages
• Reading information from the filesystem
Getting Started

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthentication
• Locate the code which handles user authentication through the UI. Assess the possible methods of user
impersonation via vectors such as parameter tampering, replay attacks, and brute force attacks.
• Check if authentication is done online/offline. Sometimes authentication is done offline, so here you can
try SQLi to bypass authentication.
• Determine if the application utilizes information beyond username/password such as
Ø contextual information (i.e.- device identifiers, location)
Ø certificates
Ø tokens

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthentication
• Does the application utilize visual swipe or touch passwords vs. conventional usernames and
passwords?
Ø Assess the method of mapping the visual objects to an authentication string to determine if
adequate entropy exists
• Does the application implement functionality that permits inbound connections from other devices?
(i.e.- Wi-Fi Direct, Android Beam, network services)
Ø Does the application properly authenticate the remote user or peer prior to granting access to
device resources?
Ø How does the application handle excessive failed attempts at authentication?
Ø are failed attempts logged?
Ø what mechanisms exist to inform the user of a potential attack?
• Is there account lockout implemented for limited invalid login attempts?
Ø How many invalid attempts are allowed?
Ø Does application handles DOS performed using account lockout feature?
Ø How does it unlock the user account?

@BGASecurity
• Single Sign On, e.g.
Ø OAuth
Ø Facebook
Ø Google Apps
• SMS
v How is the sender authenticated?
Ø password
Ø header information
Ø Other mechanism?
v Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
Ø Can other applications access this data?
v What if attacker tampers OTP using gprs modem?
v Can application validate the tampered OTP?
Authentication

@BGASecurity
• USSD
Ø Does application use USSD/Flash messages to authenticate use?
v USSD based authentication is more reliable than SMS
• Push Notifications
Ø If the application consumes information via push notifications, how does the application verify the
identity of the sender?
Authentication

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthorization
• Review file permissions for files created at runtime
• Determine if it is possible to access functionality not intended for your role
Ø Identify if the application has role specific functionality within the mobile application
Ø Locate any potential flags or values that may be set on the client from any untrusted source that
can be a point of privilege elevation such as
ü databases
ü flat files
ü HTTP responses
Ø Find places within an application that were not anticipated being directly accessed without
following the application’s intended workflow

@BGASecurity
• Licensing
Ø Can licensing checks be defeated locally to obtain access to paid-for data resources? (i.e.- patching
a binary, modifying it at runtime, or by modifying a local configuration file)
Ø Does the code suggest that licensed content is served with a non-licensed app but restricted by UI
controls only?
Ø Are licensing checks performed properly by the server or platform licensing services?
Ø How does the application detect and respond to tampering?
ü Are alerts sent to and expected by the developer?
ü Does the application fail open or fail closed?
ü Does the application wipe its data?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestSession Management
• Ensure that sessions timeout locally as well as server side.
Ø Make sure Session Timeout is set to minimal value.
• Is sensitive information utilized within the application flushed from memory upon session expiration?
• No Session IDs should be passed in URL, ensure usage of POST method or hidden fields.
• Detect Session Fixation/Tampering on Server Side.
• Ensure Session tokens are randomized and are not guessable or in sequence.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestData Storage
• Encryption
Ø Are the algorithms used “best of breed” or do they contain known issues?
Ø How are keys derived from i.e. a password?
Ø Based on the algorithms and approaches used to encrypt data, do implementation issues exist that
degrade the effectiveness of encryption?
Ø How are keys managed and stored on the device? Can this reduce the complexity in breaking the
encryption?
• Identify if the application utilizes storage areas external to the “sandboxed” locations to store
unencrypted data such as:
Ø Places with limited access control granularity (SD card, tmp directories, etc.)
Ø Directories that may end up in backups or other undesired locations (iTunes backup, external storage,
etc.)
Ø Cloud storage services such as Dropbox, Google Drive, or S3

@BGASecurity
BGA | MobilePentestBGA | MobilePentestData Storage
• Does the application write sensitive information to the file system at any point, such as:
Ø Credentials
ü Username and/or password
ü API keys
ü Authentication tokens
Ø Payment information
Ø Patient data
Ø Signature files
• Is sensitive information written to data stores via platform exposed APIs such as contacts?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInformation Disclosure
• Logs
Ø Does the application log data? Is sensitive information accessible?
Ø How are the logs accessed, if so, and by which mechanism/functionality? Is log access protected?
Ø Can any of the logged information be considered a privacy violation?
Ø Is the device identifier sent that could be used to identify the user? (i.e.UDID in Apple devices)
Ø Does the application upload any log file to the server?
ü Is the log file extension validated before upload?
ü Is the content of the log file validated before upload? What if malicious code is embedded in log
file?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInformation Disclosure
• Caches
Ø Predictive text
Ø Location information
Ø Copy and paste
Ø Application snapshot
Ø Browser cache
Ø Non-standard cache locations (i.e the various SQLite databases that apps can create if they use HTML UI
components)
Ø Are HTTPS responses being cached?
• Exceptions
Ø Does sensitive data leak in crash logs?
Ø How does application handle data/logs outside its container?
• Third Party Libraries and APIs
Ø What permissions do they require?
Ø Do they access or transmit sensitive information?
• Review licensing requirements for any potential violations.
Ø Can their runtime behavior expose users to privacy issues and unauthorized tracking?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestWeb Application Issues
• XSS and HTML Injection
Ø Identify places where the application passes untrusted data into a web view or browser
Ø Determine if the application properly output encodes or sanitizes the data within the appropriate
context
• OS Command Injection (if the application utilizes a shell)
Ø Where the application permits usage of the shell, identify the entry points to manipulate or alter the
commands via user input or external untrusted data
Ø Determine if an attacker can inject arbitrary commands or manipulate the intended command in any
way
• CSRF
• SQL Injection
• Cookies
• HTML5
• XML Injection
• Check Cross Domain Policy

@BGASecurity
BGA | MobilePentestBGA | MobilePentestNetworking
• Are insecure protocols used to send or receive sensitive information? Examples- FTP, SNMP v1, SSH v1
• Are there any known issues with the specific libraries you are using to implement the protocol?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestTransport Layer Protection
• Does the application properly implement Certificate Pinning?
• Are certificates validated to determine if:
Ø The certificate has not expired
Ø The certificate was issued by a valid certificate authority
Ø The remote destination information matches the information within the certificate?
• Are certificates validated only by the operating system or also by the application that relies on it?
• Identify if code exist to alter the behavior for traffic transiting different interfaces (i.e.- 3G/4G comms
vs. Wi-Fi)? If so, is encryption applied universally across each of them

@BGASecurity
BGA | MobilePentestBGA | MobilePentestHelpful Search Strings and Regular Expressions
• DEBUG
• printStackTrace
• username/userID/password/passwd/pwd/
• key/encrypt/decrypt/MD5/MD4
• timeout/session.invalidate
• root/jailbreak
• test/demo/
• sqlconnection/sqlevents/sqldemo/sqlconn/sqltest
• account/URL/hostname/ipaddress
• proxy

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDynamic Analysis
• Application Types
• Establishing a Baseline
• Debugging
• Active Testing
• Local Testing
Ø Cryptography
Ø Web Applications
Ø Authentication
Ø Authorization
Ø File System Analysis
Ø Memory Analysis
• Remote Application/Service Testing
Ø Authentication
Ø Authorization
Ø Session Management
Ø Transport Layer Testing
Ø Server Side Attacks
Ø Server, Network & Application
Scanning

@BGASecurity
BGA | MobilePentestBGA | MobilePentestApplication Types
• Native Mobile Application: Native mobile applications can be installed on to the device. This type of
applications generally store most of their code on the device. Any information required can be requested to
the server using the HTTP/s protocol
• Web services for Mobile Application: Native mobile application that uses SOAP or REST based web services
to communicate between client and Server
• Mobile Browser Based Application: Web browser based applications can be accessed using device’s
browsers such as Safari or Chrome. Most of the commercial applications are nowadays specifically designed
and optimized for mobile browsers. These applications are no different than traditional web application and
all the web application vulnerabilities apply to these apps and these should be tested as traditional web
apps.
• Mobile Hybrid Applications: Applications can leverage web browser functionality within native applications,
blending the risks from both classes of applications.
In this phase, the mobile client, backend services, and host platform is analyzed/scanned in attempt to uncover
potential risks, vulnerabilities and threats. The use of an intercepting proxy tool as well as automated
vulnerability scanners are core to this phase. In many cases, you will also need some type of shell access to the
device.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestEstablishing a Baseline
• Generate File System Baseline Fingerprint (before app installation)
Ø Application interactions with the host file system must be reviewed and analyzed at various stages of
testing; starting with baseline capture. This may require a shell or GUI depending on platform and/or
preference.
• Install, Configure and Use the Application
Ø Manually inspect the file system to determine what files/databases were created, what and how data
is stored. Did the application store sensitive data unencrypted or trivially protected (i.e. encoded)?
Ø Generally, pay attention to credentials, payment information, or other highly sensitive information
being saved to the device. Also take a look at databases, log files, predictive text caches, and crash
logs.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDebugging
• Attach a debugger to an application to step through code execution and setting breakpoints at
interesting code within the application
• Monitor logged messages and notifications generated at runtime
• Observe interprocess communications between the target application and other applications and
services running on the mobile device.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestActive Testing
• Local Testing
• Exposed IPC interfaces
Ø Sniff
Ø Fuzz
Ø Bypass authorization checks
• Cryptography
Ø Brute force attacks against keys, pins, and hashes
Ø Attempt to reconstruct encrypted data through recovery of keys, hardcoded secrets, and any other
information exposed by the application

@BGASecurity
BGA | MobilePentestBGA | MobilePentestWeb Applications
• XSS and HTML Injection
Ø Is it possible to inject client side code (i.e. JavaScript) or HTML into the application to either modify
the inner working of the application or it's user interface?
• Command Injection (if the application utilizes a shell)
• CSRF
• SQL Injection
• Cookies
Ø Are cookies issued by a server secured by using the HTTP-only and Secure flag?
Ø Is there any sensitive information stored in the cookies?
• HTML5 Storage

@BGASecurity
BGA | MobilePentestBGA | MobilePentestWeb Applications
Authentication
• Assess the methods an application uses to authenticate peers
Ø NFC
Ø SMS
Ø Push notifications
Ø Across IPC channels (identify the calling application’s privileges and identity)
Authorization
• Instrument, patch, or interact with application at runtime to bypass methods intended to prevent
usage of privileged or premium features
• Determine if configuration or locally stored data can be manipulated in order to elevate a user’s
privileges
• Check the filesystem permissions for any files created at runtime

@BGASecurity
• Assess the application’s behavior throughout it’s lifecycle to determine if special functionality is triggered to
persist an application’s state when it enters different stages:
Ø Placed into the foreground
Ø Sent into the background
Ø Upon exiting the application
• Data storage in Cache
• Looking for artifacts left on device
• Unencrypted data storage on the device
• Encryption of data in backups
• Username/password, or app-specific unique device id stored on the device
• Application Permissions , Privileges and Access controls on the device
• Generally, pay attention to credentials, payment information, or other highly sensitive information being saved to
the device. Also take a look at log files, predictive text caches, and crash logs.
• Is sensitive information cached within the application’s UI back stack?
• Utilize forensic tools to determine if deleted data can be recovered from the filesystem as well as within
databases
File System Analysis

@BGASecurity
BGA | MobilePentestBGA | MobilePentestMemory Analysis
• Determine if sensitive information persists within memory after performing the following actions:
• Logging out of the application
• Transition between UI components
• Is it possible to obtain encryption keys, credentials, payment information and other sensitive
information by dumping device or application memory?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestRemote Application/Service Testing
Authentication
• What methods are available (3G, 4G, Wifi, etc)?
• What happens if the remote authentication service becomes unavailable?
• Assess strength of password requirements
• Test how account lockouts are implemented
• Analyze (monitor traffic) how each method performs authentication. Note target wifi as this is a common area where
authentication can be weak. Ensure authentication is robust and not based on trivial attributes (i.e. MDN, ESN, etc).
• Verify that authentication tokens are terminated after a user initiates a password reset
• Single Sign On (SSO)
• SMS Based
Ø One Time Passwords (OTP)
Ø Two Factor Authentication
• Push Notifications
• Licensing

@BGASecurity
BGA | MobilePentestBGA | MobilePentestRemote Application/Service Testing
Authentication
• What happens if the remote authorization handling service becomes unavailable?
• Test if direct access to backend resources is possible
• Access controls to server side resources not enforced
• Vertical and horizontal privilege escalation

@BGASecurity
• What happens if the remote authorization handling service becomes unavailable?
• Test if direct access to backend resources is possible
• Access controls to server side resources not enforced
• Vertical and horizontal privilege escalation

@BGASecurity
• Entropy analysis
• Device identifier related?
• Are session tokens refreshed between logouts?
• Lifetime and expiration
• Handling the session token on the device (stored, in memory, etc.)
• Privilege Escalation
• Ineffective Session Termination
• Session Fixation
• Pre-login/Login/Post-login Session checks
• Unique Session Generation

@BGASecurity
BGA | MobilePentestBGA | MobilePentestTransport Layer Testing
• Man-in-the-middle attacks
• Eavesdropping
• SSL checks (cypher strengths/weakness etc.)
• SSL Striping

@BGASecurity
BGA | MobilePentestBGA | MobilePentestServer Side Attacks
• Triggering unhandled exceptions
• Cross-Site Scripting
• SQL Injection
• XML Bombs
• Buffer overflow
• Unrestricted File Upload
• Open Redirect
• Cross Origin Resource Sharing

@BGASecurity
BGA | MobilePentestBGA | MobilePentestServer, Network & Application Scanning
Based on prior phases you should have 1 or more target servers (i.e. URLs) as candidates for automated
vulnerability scanning. Mobile applications often leverage existing web services/applications (i.e. hybrid
applications) which must be tested for security vulnerabilities.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestOWASP Mobile Top 10 Risks

@BGASecurity
BGA | MobilePentestBGA | MobilePentestWeak Server Side Controls

@BGASecurity
BGA | MobilePentestBGA | MobilePentestExample Scenarios

@BGASecurity
BGA | MobilePentestBGA | MobilePentestBusiness Logic Testing
• 4.11.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)
• 4.11.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)
• 4.11.3 Test Integrity Checks (OTG-BUSLOGIC-003)
• 4.11.4 Test for Process Timing (OTG-BUSLOGIC-004)
• 4.11.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)
• 4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)
• 4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)
• 4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)
• 4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthentication Testing
• 4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
• 4.5.2 Testing for default credentials (OTG-AUTHN-002)
• 4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)
• 4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)
• 4.5.5 Test remember password functionality (OTG-AUTHN-005)
• 4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)
• 4.5.7 Testing for Weak password policy (OTG-AUTHN-007)
• 4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)
• 4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)
• 4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthorization Testing
• 4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-001)
• 4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-002)
• 4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-003)
• 4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-004)

@BGASecurity
BGA | MobilePentestBGA | MobilePentestSession Management Testing
• 4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)
• 4.7.2 Testing for Cookies attributes (OTG-SESS-002)
• 4.7.3 Testing for Session Fixation (OTG-SESS-003)
• 4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)
• 4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)
• 4.7.6 Testing for logout functionality (OTG-SESS-006)
• 4.7.7 Test Session Timeout (OTG-SESS-007)
• 4.7.8 Testing for Session puzzling (OTG-SESS-008)

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInsecure Data Storage

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Specific Best Practices:
• Never store credentials on the phone file system. Force the user to authenticate using a standard web
or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts
are set at the bare minimum to meet the user experience requirements.
• Where storage or caching of information is necessary consider using a standard iOS encryption library
such as CommonCrypto. However, for particularly sensitive apps, consider using whitebox cryptography
solutions that avoid the leakage of binary signatures found within common encryption libraries.
• If the data is small, using the provided apple keychain API is recommended but, once a phone is
jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce
on the devices PIN, which as stated above is trivial in some cases.
• For databases consider using SQLcipher for Sqlite data encryption

@BGASecurity
• For items stored in the keychain leverage the most secure API designation,
kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile
devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.
• For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely
be used (see NSData Class Reference for protection options).
• Avoid using NSUserDefaults to store sensitive pieces of information as it stores data in plist files.
• Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.
• Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive
information assets.
• Consider providing an additional layer of encryption beyond any default encryption mechanisms
provided by the operating system.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Specific Best Practices:
• For local storage the enterprise android device administration API can be used to force encryption to
local file-stores using “setStorageEncryption”
• For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few
options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
• Ensure any shared preferences properties are NOT MODE_WORLD_READABLE unless explicitly required
for information sharing between apps.
• Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive
information assets.
• Consider providing an additional layer of encryption beyond any default encryption mechanisms
provided by the operating system.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestIOS Simulator

@BGASecurity
BGA | MobilePentestBGA | MobilePentestInsufficient Transport Layer Protection

@BGASecurity
• Assume that the network layer is not secure and is susceptible to eavesdropping.
• Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other
sensitive data to a backend API or web service.
• Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an
application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.
• Use strong, industry standard cipher suites with appropriate key lengths.
• Use certificates signed by a trusted CA provider.
• Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
• Always require SSL chain verification.
• Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
• Alert users through the UI if the mobile app detects an invalid certificate.
• Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).
• If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future
vulnerabilities are discovered in the SSL implementation, the encrytped data will provide a secondary defense against
confidentiality violation.
General Best Practices:

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Specific Best Practices
• Ensure that certificates are valid and fail closed.
• When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates.
In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher
strength.
• After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid
certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
• Consider using certificate pinning by doing the following: export your certificate, include it in your app
bundle, and anchor it to your trust object. Using the NSURL method
connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Specific Best Practices
• Remove all code after the development cycle that may allow the application to accept all certificates
such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or
SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.
• If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly
implemented so that server certificate is correctly checked.

@BGASecurity
Lack of Certificate Inspection
The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a
secure channel. However, the mobile app fails to inspect the certificate offered by the server and the
mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual
authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-
in-the-middle attacks through a SSL proxy
Weak Handshake Negotiation
The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection
handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak
encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel
between the mobile app and the endpoint;
Privacy Information Leakage
The mobile app transmits personally identifiable information to an endpoint via non-secure channels
instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app
and the endpoint.
Android Specific Best Practices

@BGASecurity
BGA | MobilePentestBGA | MobilePentestBest Practices

@BGASecurity
BGA | MobilePentestBGA | MobilePentestUnintended Data Leakage

@BGASecurity
BGA | MobilePentestBGA | MobilePentestHow Do I Prevent Unintended Data Leakage?
It is important to threat model your OS, platforms, and frameworks, to see how they handle the following
types of features:
• URL Caching (Both request and response)
• Keyboard Press Caching
• Copy/Paste buffer Caching
• Application backgrounding
• Logging
• HTML5 data storage
• Browser cookie objects
• Analytics data sent to 3rd parties

@BGASecurity
BGA | MobilePentestBGA | MobilePentestPoor Authorization And Authentication

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Poor Authorization and Authentication?
Avoid the following Insecure Mobile Application Authentication Design Patterns:
• If you are porting a web application to its mobile equivalent, authentication requirements of mobile
applications should match that of the web application component. Therefore, it should not be possible
to authenticate with less authentication factors than the web browser.
• Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data
locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation
or modification of the binary. If there is a compelling business requirement for offline authentication,
see M10 for additional guidance on preventing binary attacks against the mobile app.
• Where possible, ensure that all authentication requests are performed server-side. Upon successful
authentication, application data will be loaded onto the mobile device. This will ensure that application
data will only be available after successful authentication.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Poor Authorization and Authentication?
Avoid the following Insecure Mobile Application Authentication Design Patterns:
• If client-side storage of data is required, the data will need to be encrypted using an encryption key that
is securely derived from the user’s login credentials. This will ensure that the stored application data will
only be accessible upon successfully entering the correct credentials. There are additional risks that the
data will be decrypted via binary attacks. See M10 for additional guidance on preventing binary attacks
that lead to local data theft.
• Persistent authentication (Remember Me) functionality implemented within mobile applications should
never store a user’s password on the device.
• Ideally, mobile applications should utilize a device-specific authentication token that can be revoked
within the mobile application by the user. This will ensure that the app can mitigate unauthorized access
from a stolen/lost device.
• Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-
location.
• Persistent authentication within mobile applications should be implemented as opt-in and not be
enabled by default.
• If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.

@BGASecurity
• Developers assume that only authenticated users will be able to generate a service request that the
mobile app submits to its backend for processing. During the processing of the request, the server code
does not verify that the incoming request is associated with a known user. Hence, adversaries submit
service requests to the back-end service and anonymously execute functionality that affects legitimate
users of the solution.
• Developers assume that only authorized users will be able to see the existance of a particular function
on their mobile app. Hence, they expect that only legitimately authorized users will be able to issue the
request for the service from their mobile device. Backend code that processes the request does not
bother to verify that the identity associated with the request is entitled to execute the service. Hence,
adversaries are able to perform remote administrative functionality using fairly low-privilege user
accounts.
• Due to usability requirements, mobile apps allow for passwords that are 4 digits long. Server code
correctly stores a hashed version of the password. However, due to the severely short length of the
password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables.
If the password file (or data store) on the server is compromised, an adversary will be able to quickly
deduce users' passwords.
The following scenarios showcase weak authentication or
authorization controls in mobile apps:

@BGASecurity
BGA | MobilePentestBGA | MobilePentestBroken Cryptography

@BGASecurity
BGA | MobilePentestBGA | MobilePentestReliance Upon Built-In Code Encryption Processes
By default, iOS applications are protected (in theory) from reverse engineering via code encryption. The iOS
security model requires that apps be encrypted and signed by trustworthy sources in order to execute in
non-jailbroken environments. Upon start-up, the iOS app loader will decrypt the app in memory and
proceed to execute the code after its signature has been verified by iOS. This feature, in theory, prevents an
attacker from conducting binary attacks against an iOS mobile app.
Using freely available tools like ClutchMod or GBD, an adversary will download the encrypted app onto
their jailbroken device and take a snapshot of the decrypted app once the iOS loader loads it into memory
and decrypts it (just before the loader kicks off execution). Once the adversary takes the snapshot and
stores it on disk, the adversary can use tools like IDA Pro or Hopper to easily perform static / dynamic
analysis of the app and conduct further binary attacks.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestClutch

@BGASecurity
BGA | MobilePentestBGA | MobilePentestClass-dump
This is a command-line utility for examining the Objective-C runtime information stored in Mach-O files. It
generates declarations for the classes, categories and protocols. This is the same information provided by
using ‘otool -ov’, but presented as normal Objective-C declarations, so it is much more compact and
readable.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestPoor Key Management Processes
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct
encryption algorithm, but implementing their own protocol for employing it. Some examples of problems
here include:
• Including the keys in the same attacker-readable directory as the encrypted content;
• Making the keys otherwise available to the attacker;
• Avoid the use of hardcoded keys within your binary; and
• Keys may be intercepted via binary attacks. See M10 for more information on preventing binary attacks.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestCreation and Use of Custom Encryption Protocols
• There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your
own encryption algorithms or protocols.
• Always use modern algorithms that are accepted as strong by the security community, and whenever
possible leverage the state of the art encryption APIs within your mobile platform. Binary attacks may
result in adversary identifying the common libraries you have used along with any hardcoded keys in the
binary. In cases of very high security requirements around encryption, you should strongly consider the
use of whitebox cryptography. See M10 for more information on preventing binary attacks that could
lead to the exploitation of common libraries.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestCreation and Use of Custom Encryption Protocols
Many cryptographic algorithms and protocols should not be used because they have been shown to have
significant weaknesses or are otherwise insufficient for modern security requirements. These include:
• RC2
• MD4
• MD5
• SHA1

@BGASecurity
BGA | MobilePentestBGA | MobilePentestClient Side Injection

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Client Side Injection?
Data on the Device:
SQL Injection: SQLite (many phones default data storing mechanism) can be subject to injection just like
in web applications. The threat of being able to see data using this type of injection is risky when your
application houses several different users, paid-for/unlockable content, etc.
Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains
to reading files that might be yours to view inside the application directory.
The Mobile Users Session:
JavaScript Injection (XSS, Etc): The mobile browser is subject to JavaScript injection as well. Usually the
mobile browser has access to the mobile applications cookie, which can lead to session theft.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Client Side Injection?
The Application Interfaces or Functions:
Several application interfaces or language functions can accept data and can be fuzzed to make
applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms
being managed code, there have been several that have been used as a “userland” exploit in an exploit
chain aimed at rooting or jailbreaking devices.
Binary Code Itself:
Mobile malware or other malicious apps may perform a binary attack against the presentation layer
(HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app's executable. These
code injections are executed either by the mobile app's framework or the binary itself at run-time.

@BGASecurity
• SQLite Injection: When designing queries for SQLite be sure that user supplied data is being passed to a
parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user
supplied data will be inserted by a “%@” instead of a proper parameterized query specifier of “?”.
• JavaScript Injection (XSS, etc): Ensure that all UIWebView calls do not execute without proper input validation.
Apply filters for dangerous JavaScript characters if possible, using a whitelist over blacklist character policy before
rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your
application.
• Local File Inclusion: Use input validation for NSFileManager calls.
• XML Injection: use libXML2 over NSXMLParser
• Format String Injection: Several Objective C methods are vulnerable to format string attacks:
• NSLog, [NSString stringWithFormat:], [NSString initWithFormat:], [NSMutableString appendFormat:], [NSAlert
informativeTextWithFormat:], [NSPredicate predicateWithFormat:], [NSException format:], NSRunAlertPanel.
• Do not let sources outside of your control, such as user data and messages from other applications or web
services, control any part of your format strings.
• Classic C Attacks: Objective C is a superset of C, avoid using old C functions vulnerable to injection such as: strcat,
strcpy, strncat, strncpy, sprint, vsprintf, gets, etc.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Specific Best Practices:
• SQL Injection: When dealing with dynamic queries or Content-Providers ensure you are using
parameterized queries.
• JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews (usually
the default).
• Local File Inclusion: Verify that File System Access is disabled for any WebViews
(webview.getSettings().setAllowFileAccess(false);).
• Intent Injection/Fuzzing: Verify actions and data are validated via an Intent Filter for all Activities.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestSecurity Decisions Via Untrusted Inputs

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Specific Examples:
• Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not
contain an argument containing the BundleID of the source application.
• Instead use the openURL:sourceApplication:annotation method and validation the
sourceApplication argument against a white-list of trusted applications
• Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all
third party apps on the device.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestImproper Session Handling

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Improper Session Handling?
• Failure to Invalidate Sessions on the Backend
• Many developers invalidate sessions on the mobile app and not on the server side, leaving a major
window of opportunity for attackers who are using HTTP manipulation tools. Ensure that all session
invalidation events are executed on the server side and not just on the mobile app.
• Lack of Adequate Timeout Protection
• Any mobile app you create must have adequate timeout protection on the backend components.
This helps prevent malicious potential for an unauthorized user to gain access to an existing session
and assume the role of that user.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable To Improper Session Handling?
• Failure to Properly Rotate Cookies
• Authentication state changes include events like:
• Switching from an anonymous user to a logged in user
• Switching from any logged in user to another logged in user
• Switching from a regular user to a privileged user
• Timeouts
• Insecure Token Creation
• In addition to properly invalidating tokens (on the server side) during key application events, it's
also crucial that the tokens themselves are generated properly. Just as with encryption algorithms,
developers should use well-established and industry-standard methods of created tokens. They
should be sufficiently long, complex, and pseudo-random so as to be resistant to
guessing/anticipation attacks.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestLack Of Binary Protections

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAm I Vulnerable to Lack of Binary Protections?
If you answer yes to any of these questions, you are vulnerable to a binary attack:
• Can someone code-decrypt this app (iPhone specific) using an automated tool like ClutchMod or manually
using GDB?
• Can someone reverse engineer this app (Android specific) using an automated tool like dex2jar?
• Can someone use an automated tool like Hopper or IDA Pro to easily visualize the control-flow and
pseudo-code of this app?
• Can someone modify the app’s presentation layer (HTML/JS/CSS) of this app within the phone and
execute modified JavaScript?
• Can someone modify the app’s binary executable using a hex editor to get it to bypass a security control?

@BGASecurity
BGA | MobilePentestBGA | MobilePentestHow Do I Prevent Lack of Binary Protections?
• Jailbreak Detection Controls;
• Checksum Controls;
• Certificate Pinning Controls;
• Debugger Detection Controls.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDisabling Code Encryption (iOS) with Clutch

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Root Detection
• Check for test-keys
Ø Check to see if build.prop includes the line ro.build.tags=test-keys indicating a developer build or unofficial ROM
Ø Check for OTA certificates
• Check to see if the file /etc/security/otacerts.zip exists
• Check for several known rooted apk's
Ø com.noshufou.android.su
Ø com.thirdparty.superuser
Ø eu.chainfire.supersu
Ø com.koushikdutta.superuser
• Check for SU binaries
Ø /system/bin/su
Ø /system/xbin/su
Ø /sbin/su
Ø /system/su
Ø /system/bin/.ext/.su
• Attempt SU command directly
• Attempt the to run the command su and check the id of the current user, if it returns 0 then the su success!

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Security
• Drozer
• Andbug
• Introspy
• dex2jar
• apktool

@BGASecurity
• AndroidManifest.xml - This is probably by far the most important source of information. From a security point of
view, it contains information about the various components used in an application and lists the conditions in which
they can be launched. It also displays information about the permissions that the application uses. It is highly
recommend to go through Google’s documentation on the manifest file. assets - This is used to store raw assets file.
The files stored here as compiled as is into the apk file.
• res - Used to store resources such as images, layout files, and string values.
• META-INF - Contains important information about the signature and the person who signed the application.
• classes.dex - This is where the compiled application code lies. To decompile an app, you need to convert the dex file
to a jar file which can then be read by a java decompiler
Android Security

@BGASecurity
it is also possible to modify the code of an apk file after decompiling and then recompile it to deploy to a
device. However, once the application code is modified, it loses its integrity and hence needs to be resigned
with a new public/private key pair.
Android Security

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Security

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAndroid Components

@BGASecurity
BGA | MobilePentestBGA | MobilePentestActivites

@BGASecurity
BGA | MobilePentestBGA | MobilePentestServices

@BGASecurity
BGA | MobilePentestBGA | MobilePentestBroadcast Receivers

@BGASecurity
BGA | MobilePentestBGA | MobilePentestContent Providers

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDecoded

@BGASecurity
BGA | MobilePentestBGA | MobilePentestPostlogin

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDrozer

@BGASecurity
• The first step in assessing Sieve is to find it on the Android device. Apps installed on an Android device are uniquely
identified by their ‘package name’. We can use the `app.package.list` command to find the identifier for the app:
run app.package.list -f Insecure
• We can ask drozer to provide some basic information about the package using the `app.package.info` command:
run app.package.info -a com.android.insecurebankv2
• We will only consider vulnerabilities exposed through Android’s built-in mechanism for Inter-Process Communication
(IPC). These vulnerabilities typically result in the leakage of sensitive data to other apps installed on the same device.
We can ask drozer to report on Sieve’s attack surface:
run app.package.attacksurface com.android.insecurebankv2
• We can drill deeper into this attack surface by using some more specific commands.
run app.activity.info -a com.android.insecurebankv2
• Launching Activities
run app.activity.start --component com.android.insecurebankv2 com.android.insecurebankv2.PostLogin
Using drozer for Security Assessment

@BGASecurity
run
app.activity.start --
component
com.android.insecureb
ankv2
com.android.insecureb
ankv2.PostLogin
Using drozer for Security Assessment

@BGASecurity
ShadowOS
ShadowOS

@BGASecurity
BGA | MobilePentestBGA | MobilePentestShadowOS

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Setting Up a Mobile Pentesting Platform
• Jailbreaking your device
• www.jailbreak-me.info
• www.jailbreaktools.com
• Setting up a mobile auditing platform
• OpenSSH
• BigBoss Recommended tools
• MobileTerminal
• class-dump-z
• Clutch

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Getting Class Information of iOS Apps
1 - Clutch
2 - Class-dump

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Getting Class Information of iOS Apps

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Understanding the Objective-C Runtime
• Objective-C runtime
Ø Objective-C is a runtime oriented language.
Ø A runtime language is a language that decides what to implement in a function and other decisions
during the runtime of the applications.
Ø Is Objective-C a runtime language ? NO.
Ø It is a runtime oriented language, which means that whenever it is possible, it defers decisions from
compile and link time to the time when the code in the application is actually being executed.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Runtime Analysis Using Cycript
• Cycript is a javascript interpreter which also understands Objective-C syntax, meaning we can write either
Objective-C or javascript or even both in a particular command. It can also hook into a running process
and help us to modify a lot of the things in the application during runtime. As far as its application to iOS
application is concerned, here are some of the advantages of using Cycript.
Ø We can hook into a running process and find the names of all classes being used, i.e the view
controllers, the internal and third party libraries being used and even the name of the Application
delegate.
Ø For a particular class, i.e View Controller, App delegate or any other class, we can also find the
names of all the methods being used.
Ø We can also find the names of all the instance variable and their values at any particular time during
the runtime of an application.
Ø We can modify the values of the instance variable during runtime.
Ø We can perform Method Swizzling, i.e replace the code of a particular method with some other
implementation.
Ø We can call any method in the application during runtime without it being in the actual code of the
application .

@BGASecurity
BGA | MobilePentestBGA | MobilePentestFinding methods for a particular class

@BGASecurity
http://iphonedevwiki.net/index.php/Cycript_Tricks
Finding methods for a particular class

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Analyzing Security of iOS Applications Using Snoop-it
• Features
• Monitoring
• File system access (print data protection classes)
• Keychain access
• HTTP(S) connections (NSURLConnection)
• Access to sensitive API (address book, photos
etc.)
• Debug outputs (NSLog)
• Tracing App internals (objc_msgSend)
Analysis/Manipulation
• Fake hardware identifier (UDID, Wireless MAC,
etc.)
• Fake location/GPS data
• Explore and force display of available
ViewController
• List custom URL schemes
• List available Objective-C classes, objects and
methods
• Invoke arbitrary methods at runtime
• Bypass basic jailbreak detection mechanisms

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Analyzing Security of iOS Applications Using Snoop-it

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – iOS Filesystem and Forensics

@BGASecurity
BGA | MobilePentestBGA | MobilePentestSQLite Database
• find . -name *.db
• SQLiteBrowser

@BGASecurity
BGA | MobilePentestBGA | MobilePentestSQLite Database

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Analyzing Network Traffic Over HTTP/HTTPS
• In case you want to analyze the traffic
for a device over SSL, there are plenty
of ways to do that as well using a
combination of Arpspoof and SSLStrip.
• Using TCPDump
• tcpdump -i en0 -s 0 -w candan.pcap

@BGASecurity
BGA | MobilePentestBGA | MobilePentestUsing Burpsuite over HTTP

@BGASecurity
BGA | MobilePentestBGA | MobilePentestUsing Burpsuite over HTTPS

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAnalyzing Keychain read-write using Snoop-it

@BGASecurity
BGA | MobilePentestBGA | MobilePentestDumping Keychain data using Keychain Dumper
• https://github.com/ptoomey3/Keychain-Dumper
• ./keychain_dumper

@BGASecurity
iOS Application Security – Booting a Custom Ramdisk Using Sogeti Data
Protection Tools
• A bootrom exploit allows us to bypass the bootrom signature checks on the Low level bootloader and
hence boot the device using a custom ramdisk.
• Such an exploit could also allow the user to run unsigned code and hence create an untethered
jailbreak.
• A bootrom exploit once found cannot be fixed by Apple by releasing a new iOS version but can only be
fixed by a new hardware release.
• There is no bootrom exploit discovered from A5 device or later. The bootrom exploit we will be using in
this article will only work on A4 devices.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Jailbreak Detection and Evasion
Most of the jailbreak softwares install Cydia on the device after jailbreaking. Hence just a simple check for
the file path of Cydia can determine whether the device is jailbroken or not.
NSString *filePath = @"/Applications/Cydia.app";
if ([[NSFileManager defaultManager] fileExistsAtPath:filePath])
{
//Device is jailbroken
}

@BGASecurity
Not all devices that are jailbreaked have Cydia installed on them. In fact, most hackers can just change the
location of the Cydia App
+(BOOL)isJailbroken{
if ([[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]){
return YES;
}else if([[NSFileManager defaultManager] fileExistsAtPath:@"/Library/MobileSubstrate/MobileSubstrate.dylib"]){
return YES;
}else if([[NSFileManager defaultManager] fileExistsAtPath:@"/bin/bash"]){
return YES;
}else if([[NSFileManager defaultManager] fileExistsAtPath:@"/usr/sbin/sshd"]){
return YES;
}else if([[NSFileManager defaultManager] fileExistsAtPath:@"/etc/apt"]){
return YES;
}
return NO;
}
iOS Application Security – Jailbreak Detection and Evasion

@BGASecurity
A good way to check for it would be to see if we can modify a file in some other location outside the
application bundle.
NSError *error;
NSString *stringToBeWritten = @"This is a test.";
[stringToBeWritten writeToFile:@"/private/jailbreak.txt" atomically:YES
encoding:NSUTF8StringEncoding error:&error];
if(error==nil){
//Device is jailbroken
return YES;
} else {
//Device is not jailbroken
[[NSFileManager defaultManager] removeItemAtPath:@"/private/jailbreak.txt" error:nil];
}
iOS Application Security – Jailbreak Detection and Evasion

@BGASecurity
iOS Application Security – Secure Coding Practices for iOS
Development
• Local Data Storage
• Important data like Passwords, Session ID’s etc should never be stored locally on the device.
• NSUserDefaults should never be used to store confidential information like passwords,
authentication tokens etc.
• Plist files should also be never used to store confidential information like passwords etc because
they can also be fetched very easily from inside the application bundle even on a non-jailbroken
device.
• Core Data files are also stored as unencrypted database files in your application bundle.The Core
Data framework internally uses Sql queries to store its data and hence all the files are stored as
.db files. One can easily copy these files to their computer and use a tool like sqlite3 to examine all
the content in these database files.

@BGASecurity
• Encrypt important files before saving them locally.
• Encrypt SQlite files by using SQLCipher.
• Add checks to prevent Runtime Analysis
Development

@BGASecurity
• TextFields that have inputs as passwords should be used with Secure option.
• Clear the Pasteboard once the application enters background.
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[UIPasteboard generalPasteboard].items = nil;
}
• The input to the URL scheme should also be validated.
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
//Validate input from the url
return YES;
}
• A developer should make sure that the content he loads into the UIWebview is not malicious
Development

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Insecure or Broken Cryptography

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Attacking URL Schemes
dvia://no_matter/call_number/?phone=candan
dvia

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security - Attacking URL Schemes

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Sensitive Information in Memory
OS applications may store sensitive information like passwords, session IDs etc in the memory of the
application without releasing them. In some cases, releasing these variables may not be an option. For e.g,
it might be required for the application to send an authentication token with every request and hence there
has to be a reference to it in the memory somewhere.
Even though these variables might be encrypted when stored locally in the application, these variables will
be in their unencryped format while the application is running. Hence, analyzing the contents of the
memory is an important thing while pentesting an iOS application. If there are some important properties
or instance variables that are not required, they should be released from the memory.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestiOS Application Security – Sensitive Information in Memory

@BGASecurity
function tryPrintIvars(a){ var x={}; for(i in *a){ try{ x[i] = (*a)[i]; }
catch(e){} } return x; }
iOS Application Security – Sensitive Information in Memory

@BGASecurity
BGA | MobilePentestBGA | MobilePentestMobile Application Coding Guidelines
• Authentication and Password Management
• Code Obfuscation
• Communication Security
• Data Storage and Protection
• Paywall Controls
• Server Controls
• Session Management
• Use of 3rd Party Libraries/Code
• Mobile Application Provisioning/Distribution/Testing

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthentication and Password Management
This is a set of controls used to verify the identity of a user, or other entity, interacting with the software,
and also to ensure that applications handle the management of passwords in a secure fashion.
• Instances where the mobile application requires a user to create a password or PIN (say for offline
access), the application should never use a PIN but enforce a password which follows a strong password
policy.
• Mobile devices may offer the possibility of using password patterns which are never to be utilized in
place of passwords as sufficient entropy cannot be ensured and they are easily vulnerable to smudge-
attacks.
• Mobile devices may also offer the possibility of using biometric input to perform authentication which
should never be used due to issues with false positives/negatives, among others.
• Wipe/clear memory locations holding passwords directly after their hashes are calculated.
• Based on risk assessment of the mobile application, consider utilizing two-factor authentication.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestAuthentication and Password Management
• For device authentication, avoid solely using any device-provided identifier (like UID or MAC address) to identify the
device, but rather leverage identifiers specific to the application as well as the device (which ideally would not be
reversible). For instance, create an app-unique “device-factor” during the application install or registration (such as
a hashed value which is based off of a combination of the length of the application package file itself, as well as the
current date/time, the version of the OS which is in use, and a randomly generated number). In this manner the
device could be identified (as no two devices should ever generate the same “device-factor” based on these inputs)
without revealing anything sensitive. This app-unique device-factor can be used with user authentication to create
a session or used as part of an encryption key.
• In scenarios where offline access to data is needed, add an intentional X second delay to the password entry
process after each unsuccessful entry attempt (2 is reasonable, also consider a value which doubles after each
incorrect attempt).
• In scenarios where offline access to data is needed, perform an account/application lockout and/or application data
wipe after X number of invalid password attempts (10 for example).
• When utilizing a hashing algorithm, use only a NIST approved standard such as SHA-2 or an algorithm/library.
• Salt passwords on the server-side, whenever possible. The length of the salt should at least be equal to, if not
bigger than the length of the message digest value that the hashing algorithm will generate.

@BGASecurity
• Salts should be sufficiently random (usually requiring them to be stored) or may be generated by pulling
constant and unique values off of the system (by using the MAC address of the host for example or a
device-factor; see 3.1.2.g.). Highly randomized salts should be obtained via the use of a Cryptographically
Secure Pseudorandom Number Generator (CSPRNG). When generating seed values for salt generation on
mobile devices, ensure the use of fairly unpredictable values (for example, by using the x,y,z magnetometer
and/or temperature values) and store the salt within space available to the application.
• Provide feedback to users on the strength of passwords during their creation.
• Based on a risk evaluation, consider adding context information (such as IP location, etc…) during
authentication processes in order to perform Login Anomaly Detection.
• Instead of passwords, use industry standard authorization tokens (which expire as frequently as
practicable) which can be securely stored on the device (as per the OAuth model) and which are time
bounded to the specific service, as well as revocable (if possible server side).
• Integrate a CAPTCHA solution whenever doing so would improve functionality/security without
inconveniencing the user experience too greatly (such as during new user registrations, posting of user
comments, online polls, “contact us” email submission pages, etc…).
• Ensure that separate users utilize different salts.
Authentication and Password Management

@BGASecurity
BGA | MobilePentestBGA | MobilePentestCode Obfuscation
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and the time
required to attack the application.
• Abstract sensitive software within static C libraries.
• Obfuscate all sensitive application code where feasible by running an automated code obfuscation
program using either 3rd party commercial software or open source solutions.
• For applications containing sensitive data, implement anti-debugging techniques (e.g. prevent a debugger
from attaching to the process; android:debuggable=”false”).
• Ensure logging is disabled as logs may be interrogated other applications with readlogs permissions (e.g.
on Android system logs are readable by any other application prior to being rebooted).
• So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above,
Android 4.0 and above), Address Space Layout Randomization (ASLR) should be taken advantage of to hide
executable code which could be used to remotely exploit the application and hinder the dumping of
application’s memory.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestCommunication Security
This is a set of controls to help ensure the software handles the sending and receiving of information in a secure manner.
• Assume the provider network layer is insecure. Modern network layer attacks can decrypt provider network
encryption, and there is no guarantee a Wi-Fi network (if in-use by the mobile device) will be appropriately encrypted.
• Ensure the application actually and properly validates (by checking the expiration date, issuer, subject, etc…) the
server’s SSL certificate (instead of checking to see if a certificate is simply present and/or just checking if the hash of
the certificate matches). To note, there are third party libraries to assist in this; search on “certificate pinning”.
• The application should only communicate with and accept data from authorized domain names/systems. It is
permissible to allow application updates which will modify the list of authorized systems and/or for authorized
systems to obtain a token from an authentication server, present a token to the client which the client will accept.
• To protect against attacks which utilize software such as SSLStrip, implement controls to detect if the connection is not
HTTPS with every request when it is known that the connection should be HTTPS (e.g. use JavaScript, Strict Transport
Security HTTP Header, disable all HTTP traffic).
• The UI should make it as easy as possible for the user to find out if a certificate is valid (so the user is not totally reliant
upon the application properly validating any certificates).
• When using SSL/TLS, use certificates signed by trusted Certificate Authority (CA) providers.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestData Storage and Protection
This is a set of controls to help ensure the software handles the storing and handling of information in a
secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen
which should be taken into consideration here.
• Only collect and disclose data which is required for business use of the application. Identify in the design
phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each
data type.
• Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal
data, location, error logs, etc.). Process, store and use data according to its classification
• Store sensitive data on the server instead of the client-end device, whenever possible. Assume any data
written to device can be recovered.
• Beyond the time required by the application, don’t store sensitive information on the device (e.g.
GPS/tracking).
• Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted.
• Encrypt sensitive data when storing or caching it to non-volatile memory (using a NIST approved
encryption standard such as AES-256, 3DES, or Skipjack).

@BGASecurity
• Use the PBKDF2 function to generate strong keys for encryption algorithms while ensuring high entropy as much as possible. The
number of iterations should be set as high as may be tolerated for the environment (with a minimum of 1000 iterations) while
maintaining acceptable performance.
• Sensitive data (such as encryption keys, passwords, credit card #’s, etc…) should stay in RAM for as little time as possible.
• Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys should be generated real time for
encryption/decryption as needed and discarded each time.
• So long as the architecture(s) that the application is being developed for supports it (iOS 4.3 and above, Android 4.0 and above),
Address Space Layout Randomization (ASLR) should be taken advantage of to limit the impact of attacks such as buffer overflows.
• Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their cryptographic mechanisms.
• Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs.
• Never store any passwords in clear text within the native application itself nor on the browser (e.g. save password feature on the
browser).
• When displaying sensitive information (such as full account numbers), ensure that the sensitive information is cleared from memory
(such as from the webView) when no longer needed/displayed.
• Do not store sensitive information in the form of typical strings. Instead use character arrays or NSMutableString (iOS specific) and
clear their contents after they are no longer needed. This is because strings are typically immutable on mobile devices and reside
within memory even when assigned (pointed to) a new value.
Data Storage and Protection

@BGASecurity
• Do not store sensitive data on external storage like SD cards if it can be avoided.
• Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data
shows phone is outside Europe, car key not usable unless within 100m of car etc...).
• Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an
identifier, use a randomly generated number instead.
• Make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss.
• Use a time based (expiry) type of control which will wipe sensitive data from the mobile device once the application has not
communicated with its servers for a given period of time.
• Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of inactivity).
• Avoid cached application snapshots in iOS: iOS can capture and store screen captures and store them as images when an application
suspends. To avoid any sensitive data getting captured, use one or both of the following options: 1. Use the ‘willEnterBackground’
callback, to hide all the sensitive data. 2. Configure the application in the info.plist file to terminate the app when pushed to
background (only use if multitasking is disabled).
• Prevent applications from being moved and/or run from external storage such as via SD cards.
• When handling sensitive data which does not need to be presented to users (e.g. account numbers), instead of using the actual value
itself, use a token which maps to the actual value on the server-side. This will prevent exposure of sensitive information.
Data Storage and Protection

@BGASecurity
BGA | MobilePentestBGA | MobilePentestPaywall Controls
This is a set of practices to ensure the application properly enforces access controls related to resources
which require payment in order to access (such as access to premium content, access to additional
functionality, access to improved support, etc…).
• Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a
trusted server backend – with user consent) and make them securely available to the end-user for
monitoring.
• Warn users and obtain consent for any cost implications for application behavior.
• Secure account/pricing/billing/item information as it relates to users. If client has made any purchases
via the application for instance, we should ensure that what they bought, the size of purchase, the
quantity of the purchase, etc… should all be treated as sensitive information.
• Use a white-list model by default for paid-for resource addressing.
• Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g.
significant change in location occurs, user-language changes, etc...

@BGASecurity
BGA | MobilePentestBGA | MobilePentestServer Controls
This is a set of practices to ensure the server side program which interfaces with the mobile application is
properly safeguarded. These controls would also apply in cases where the mobile application may be
integrating with vended solutions hosted outside of the typical network.
• Ensure that the backend system(s) are running with a hardened configuration with the latest security
patches applied to the OS, Web Server and other application components.
• Ensure adequate logs are retained on the backend in order to detect and respond to incidents and
perform forensics (within the limits of data protection law).
• Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the
risk from DoS type of attacks.
• Carry out a specific check of your code for any sensitive data unintentionally transferred between the
mobile application and the back-end servers, and other external interfaces (e.g. is location or other
information included transmissions?).
• Ensure the server rejects all unencrypted requests which it knows should always arrive encrypted.

@BGASecurity
This is a set of controls to help ensure mobile applications handle sessions in a secure manner.
• Perform a check at the start of each activity/screen to see if the user is in a logged in state and if not,
switch to the login state.
• When an application’s session is timed out, the application should discard and clear all memory
associated with the user data, and any master keys used to decrypt the data.
• Session tokens should be revocable (particularly on the server side).
• Use lower timeout values to invalidate expired sessions (in contrast to the typical timeout values on
traditional (non-mobile) applications).

@BGASecurity
BGA | MobilePentestBGA | MobilePentestUse of 3rd Party Libraries/Code
This is a set of practices to ensure the application integrates securely with code produced from outside
parties.
• Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g.
making sure they come from a reliable source, will continue to be supported, contain no backdoors)
and ensure that adequate internal approval is obtained to use the code/library.
• Track all third party frameworks/API’s used in the mobile application for security patches and perform
upgrades as they are released.
• Pay particular attention to validating all data received from and sent to non-trusted third party apps
(e.g. ad network software) before incorporating their use into an application.

@BGASecurity
BGA | MobilePentestBGA | MobilePentestMobile Application Provisioning/Distribution/Testing
This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that
there are mechanisms to report new security issues if they are found, and also that the software has been
designed to accept patches in order to address potential security issues.
• Design & distribute applications to allow updates for security patches.
• Provide & advertise feedback channels for users to report security problems with applications (such as a
MobileAppSecurity@ntrs.com email address).
• Ensure that older versions of applications which contain security issues and are no longer supported are
removed from app-stores/app-repositories.
• Periodically test all backend services (Web Services/REST) which interact with a mobile application as well
as the application itself for vulnerabilities using enterprise approved automatic or manual testing tools
(including internal code reviews).

@BGASecurity
BGA | MobilePentestBGA | MobilePentestMobile Application Provisioning/Distribution/Testing
• This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities,
that there are mechanisms to report new security issues if they are found, and also that the software
has been designed to accept patches in order to address potential security issues.
• Design & distribute applications to allow updates for security patches.
• Provide & advertise feedback channels for users to report security problems with applications (such as a
MobileAppSecurity@ntrs.com email address).
• Ensure that older versions of applications which contain security issues and are no longer supported are
removed from app-stores/app-repositories.
• Periodically test all backend services (Web Services/REST) which interact with a mobile application as
well as the application itself for vulnerabilities using enterprise approved automatic or manual testing
tools (including internal code reviews).

@BGASecurity
BGA | MobilePentestBGA | MobilePentestReferences
• http://highaltitudehacks.com/index.html
• https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
• http://www.cycript.org/
• http://iphonedevwiki.net/index.php/Cycript_Tricks

@BGASecurity
BGA | MobilePentest
@BGASecurity
- Thanks -
bgasecurity.com | @bgasecurity

Mobile Application Penetration Testing

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Mobile Application Penetration Testing

Similar to Mobile Application Penetration Testing (20)

More from BGA Cyber Security

More from BGA Cyber Security (20)

Recently uploaded

Recently uploaded (20)

Mobile Application Penetration Testing