Lack of Binary Protections

Loo Chia Feng G1301352LSunil Paudel G1400834AAbdul Rachman G1400808FWang Bo G1301325H

Table of ContentsIntroduction.................................................................................................................................................3

Attack Tree...................................................................................................................................................3

Directly steal original code:......................................................................................................................5

Analyze and reverse engineer a compiled mobile application code downloaded from store..................5

Code modification/injection.....................................................................................................................6

Cryptographic key replacement...........................................................................................................6

Method swizzling..................................................................................................................................6

Rogue application.................................................................................................................................6

Presentation layer modification using JavaScript.................................................................................6

Mitigation.....................................................................................................................................................7

Reverse Engineering.................................................................................................................................7

Cryptographic key Replacement...............................................................................................................7

Method Swizzling:....................................................................................................................................7

Rogue Application....................................................................................................................................7

Presentation Layer modification using JavaScript....................................................................................7

Demo of Reverse Engineering......................................................................................................................8

Conclusion....................................................................................................................................................9

Bibliography...............................................................................................................................................10

IntroductionWe live in a mobile powered world, where nearly 7 billion mobile devices are expected to be in use by the end of 2014 and 108 billion mobile downloads are anticipated by 2017. Businesses that are most efficiently adapting to today’s “App Economy” are the most successful at deepening customer engagement and driving new revenues in this changing world. (Arxan Research, 2014)

However, where business opportunities abound, opportunities for attackers abound as well. Unlike web applications, mobile software is uniquely exposed to binary risks, since application must be released to public. Attackers can directly download the application and access, compromise, and exploit binary code. For example, analyze or reverse-engineer sensitive code, modify code to change application behavior, or inject malicious code.

Traditional application security practices are alone no longer sufficient to protect mobile assets from new binary vulnerabilities, since even “flawless code” can be reversed, modified, repackaged and distributed. (Arxan Research, 2013) To prevent hacking attacks on code binaries requires new security practices, binary protections.

This document will define the possible hacking attacks on the code binaries and develop mitigating strategies to deal with the possible attack scenarios.

Attack TreeAttack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes. (Schneier, Schneier on Security, 1999)

An attack tree (Schneier, Attack trees, 1999) is constructed by following:

Define the goal of the attack. Check all the possibilities to achieve that goal. Break down the possibilities in the tree diagram hierarchically. Specify the possibilities of the path that can be followed.

The main objective of our attack tree as shown in Figure 1 is to show attackers attempting alteration and obtaining of binary code. The three different possible approaches are:

Directly steal original code Analyze and reverse engineer a mobile app downloaded from store or backup to SD card using

APKoptic or Astro File Manager Code modification/injection

Figure 1: Attack tree of binary theft protection

Directly steal original code:It can be achieved through bribery, threatening/blackmailing or hacking into the source code versioning server.

Analyze and reverse engineer a mobile app downloaded from store or backup to SD card using APKoptic or Astro File ManagerIt can be achieved by reverse engineering using various tools which can be downloaded from the internet free of cost. The below are the steps that can be followed for reverse engineering:

1. Install the application in the device2. Bypass the jailbreak or root detection

The developer who develops the app like mobile banking may not want his app to run in jail broken or rooted devices. They might have special logic embedded in the app to detect if the device is jail broken/rooted or not. This logic has to be bypassed if we want to do reverse engineering by the use of tools such as xCon. (IBM, 2014)

3. Reverse engineering o For IOS:

If we feed the mobile app into Reverse Engineering Tool, an error is thrown saying: "The file is encrypted. The disassembly of it will likely be useless. Do you want to continue?"So first of all we have to bypass this security of apple and decrypt the content. The same can be achieved by using the tool clutch. (IBM, 2014)Clutch takes the decrypted snapshot from memory and writes it to the disk. Once we get that snapshot, we can feed into the tool (IDA PRO) and we can get the decrypted code.

o For Android:The android app can be reverse engineered in two different ways:

DisassemblingTransform binary Dalvik byte code (Dex) into smali (assembly code) source code using the tool such as apktool.

Decompile Dex Jar Java (Tools used: Dex2jar, JDGUI) Dex Java (Tools used : Androguard)

4. After getting the source code, we can modify the codes for our own benefits such as:o Redirect original code methods to call other malicious codeo Modify the GUI layero Replace cryptographic keyo Change the security control flows

5. Then recompile the code back and sign the application

Code modification/injection

Cryptographic key replacementApplications use cryptographic key to encrypt/decrypt sensitive data. Attackers may replace the cryptographic key in order to decrypt and steal the sensitive data. Attackers may perform dataflow analysis of an application in order to identify a particular key in use.

Method swizzlingMethod swizzling is a technique to replace or extend methods in classes that you don’t own. The attacker can take an advantage of this method to call his malicious code.

Rogue applicationRogue application is a malicious application which shares the same execution environment and memory resources as a target application. By the use of rogue application, the binary code of the target app can be modified.

Presentation layer modification using JavaScriptPresentation layer can be modified using the JavaScript to inject the malicious code and modify the binary code.

Mitigation(Carter) Review the risks to integrity and confidentiality of mobile apps from binary-level attacks and suggest few solutions to code modification and injections via the various methods below.

Reverse EngineeringThe below steps can be incorporated to prevent the app from reverse engineering:

Remove unused program symbols (which usually convey sensitive information) from the application binaries.

Use the tool like ProGuard which shrinks, optimizes, and obfuscates the code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is the smaller sized .apk which is difficult to do reverse engineering.

Change the easy to understand program symbol names to irrelevant names. Encrypt the part or whole of the application when not in use and when stored in disk. Also

encrypt the data within the application. Use some special logic that can sense the use of debuggers and take appropriate action. Use checksum to see if any cod has been tampered.

Jail Break/Root Detection Detect the existence of Cydia; Cydia is an IOS app required to install app in jail broken devices Detect the existence of the path /private/var/stash This is the folder created on jail broken devices Detect non-sandboxed behavior

Cryptographic key Replacement Use dynamic keys all the time. Otherwise, the application's complier will store hardcoded keys in

their raw form within the final binary. An attacker will be able to find any such key looking at the associated method calls.

If in case hardcoded key is to be used, theno Damage the static keyo Repair the key just before the key is requiredo While using the repaired key, perform the checksum to check that the key is not

tamperedo After the use of the key, destroy it again

Method Swizzling: If the application is intentionally performing the swizzle, an adversary will exploit this design

decision and swizzle this particular method as it will be a reliable entry point into the application. Avoid using the swizzling method.

Use of special logic that can identify the change in the code and that can take appropriate action.

Rogue Application Use of checksum to find out if the code has been tampered Avoid using swizzling whenever possible

Presentation Layer modification using JavaScript Perform the checksum. Compare the checksum of the files at build time to the values found at

runtime. Perform additional checksum to check if the first checksum has been tampered. Make sure that both the checksums don't have a unique binary signature.

Demo of Reverse EngineeringUsing the apktool, we decompiled the android apk file into snail files. For the testing purpose, we changed the icon of the android app (iMilk) and recompiled back.

Steps:

1. Install the original apk in virtual android device Command: adb install iMilk\ Free.apk

2. Transform the binary Dalvik byte code to smali file (it converts the apk file into the folder) Command: apktool d iMilk\ Free.apk

3. Modify the codes 4. Rebuild the smali file back to apk

Command: apktool b iMilk\ Free iMilk_modified.apk5. Generate the private key using keytool

Command: keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

This example prompts you for passwords for the keystore and key, and to provide the Distinguished Name fields for your key. It then generates the keystore as a file called my-release-key.keystore. The keystore contains a single key, valid for 10000 days. The alias is a name that you will use later when signing your app.

6. Sign your app with your private key using jarsigner: Command: jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-

key.keystore iMilk_modified.apk alias_name

ConclusionIn conclusion, all software is made up of machine-readable code. In fact, code is what makes every program function the way it does. The code defines the software and the decisions it will make. Attacker can locate potential software code vulnerabilities and apply reverse engineering to search for patterns in the code to perform hidden functionalities.

To build the binary theft protection, we examine on the conceivable methodologies for an attacker to endeavor alteration to the binary code by utilizing a within profundity examination of an attack tree conceptual diagram to break down the security of systems and subsystems. Furthermore, each subsystem is mitigated to explain on the necessary counter-measures.

BibliographyArxan Research. (2013). State of Security in the App Economy. Arxan Research.

Arxan Research. (2014). Securing Mobile Applications in the Wild with Application Hardening and Run-Time Protection. Arxan Research.

Carter, J. (n.d.). Threats to Mobile Apps in the Wild. Arxan.

Schneier, B. (1999). Attack trees. Dr. Dobb’s journal, 21-29.

Schneier, B. (1999). Schneier on Security. Retrieved September 23, 2014, from Schneier on Security: Attack Tree: https://www.schneier.com/paper-attacktrees-ddj-ft.html