In this article by Prashant Verma and Akshay Dikshit, author of the book Mobile Device Exploitation Cookbook we will cover the following topics:

Auditing Android apps using static analysis

Auditing Android apps using a dynamic analyzer

Using Drozer to find vulnerabilities in Android applications

Auditing iOS application using static analysis

Auditing iOS application using a dynamic analyzer

Examining iOS App Data storage and Keychain security vulnerabilities

Finding vulnerabilities in WAP-based mobile apps

Finding client-side injection

Insecure encryption in mobile apps

Discovering data leakage sources

Other application-based attacks in mobile devices

Launching intent injection in Android

(For more resources related to this topic, see here.)

Mobile applications such as web applications may have vulnerabilities. These vulnerabilities in most cases are the result of bad programming practices or insecure coding techniques, or may be because of purposefully injected bad code. For users and organizations, it is important to know how vulnerable their applications are. Should they fix the vulnerabilities or keep/stop using the applications?

To address this dilemma, mobile applications need to be audited with the goal of uncovering vulnerabilities. Mobile applications (Android, iOS, or other platforms) can be analyzed using static or dynamic techniques. Static analysis is conducted by employing certain text or string based searches across decompiled source code. Dynamic analysis is conducted at runtime and vulnerabilities are uncovered in simulated fashion. Dynamic analysis is difficult as compared to static analysis. In this article, we will employ both static and dynamic analysis to audit Android and iOS applications. We will also learn various other techniques to audit findings, including Drozer framework usage, WAP-based application audits, and typical mobile-specific vulnerability discovery.

Auditing Android apps using static analysis

Static analysis is the mostcommonly and easily applied analysis method in source code audits. Static by definition means something that is constant. Static analysis is conducted on the static code, that is, raw or decompiled source code or on the compiled (object) code, but the analysis is conducted without the runtime. In most cases, static analysis becomes code analysis via static string searches. A very common scenario is to figure out vulnerable or insecure code patterns and find the same in the entire application code.

Getting ready

For conducting static analysis of Android applications, we at least need one Android application and a static code scanner. Pick up any Android application of your choice and use any static analyzer tool of your choice.

In this recipe, we use Insecure Bank, which is a vulnerable Android application for Android security enthusiasts. We will also use ScriptDroid, which is a static analysis script. Both Insecure Bank and ScriptDroid are coded by Android security researcher, Dinesh Shetty.

How to do it...

Perform the following steps:

Download the latest version of the Insecure Bank application from GitHub. Decompress or unzip the .apk file and note the path of the unzipped application.

Create a ScriptDroid.bat file by using the following code:

@ECHO OFF 
  SET /P Filelocation=Please Enter Location: 
 
  mkdir %Filelocation%OUTPUT 
 
  :: Code to check for presence of Comments 
  grep -H -i -n -e "//" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_comment.txt" 
  type -H -i  "%Filelocation%*.java" |gawk "//*/,/*//" >>
  "%Filelocation%OUTPUTMultilineComments.txt" 
  grep -H -i -n -v "TODO" "%Filelocation%OUTPUTTemp_comment.txt" >> 
  "%Filelocation%OUTPUTSinglelineComments.txt"
  del %Filelocation%OUTPUTTemp_comment.txt 
 
  :: Code to check for insecure usage of SharedPreferences 
  grep -H -i -n -C2 -e "putString" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTverify_sharedpreferences.txt" 
  grep -H -i -n -C2 -e "MODE_PRIVATE" "%Filelocation%*.java" >> "%Filelocation%OUTPUTModeprivate.txt" 
  grep -H -i -n -C2 -e "MODE_WORLD_READABLE" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTWorldreadable.txt" 
  grep -H -i -n -C2 -e "MODE_WORLD_WRITEABLE" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTWorldwritable.txt" 
  grep -H -i -n -C2 -e "addPreferencesFromResource" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTverify_sharedpreferences.txt" 
 
  :: Code to check for possible TapJacking attack 
  grep -H -i -n -e filterTouchesWhenObscured="true" "%Filelocation%........reslayout*.xml" >>
  "%Filelocation%OUTPUTTemp_tapjacking.txt" 
  grep -H -i -n -e "<Button" "%Filelocation%........reslayout*.xml" >>
  "%Filelocation%OUTPUTtapjackings.txt"  
  grep -H -i -n -v filterTouchesWhenObscured="true" "%Filelocation%OUTPUTtapjackings.txt" >>
  "%Filelocation%OUTPUTTemp_tapjacking.txt" 
  del %Filelocation%OUTPUTTemp_tapjacking.txt 
 
  :: Code to check usage of external storage card for storing information 
  grep -H -i -n  -e "WRITE_EXTERNAL_STORAGE" "%Filelocation%........AndroidManifest.xml" >>
  "%Filelocation%OUTPUTSdcardStorage.txt"   
  grep -H -i -n  -e "getExternalStorageDirectory()" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTSdcardStorage.txt"
  grep -H -i -n  -e "sdcard" "%Filelocation%*.java" >> "%Filelocation%OUTPUTSdcardStorage.txt" 
 
  :: Code to check for possible scripting javscript injection 
  grep -H -i -n  -e "addJavascriptInterface()" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_probableXss.txt" 
  grep -H -i -n  -e "setJavaScriptEnabled(true)" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_probableXss.txt" 
  grep -H -i -n -v "import" "%Filelocation%OUTPUTTemp_probableXss.txt" >>
  "%Filelocation%OUTPUTprobableXss.txt" 
  del %Filelocation%OUTPUTTemp_probableXss.txt 
 
  :: Code to check for presence of possible weak algorithms 
  grep -H -i -n  -e "MD5" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_weakencryption.txt" 
  grep -H -i -n  -e "base64" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_weakencryption.txt" 
  grep -H -i -n  -e "des" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_weakencryption.txt" 
  grep -H -i -n  -v "import" "%Filelocation%OUTPUTTemp_weakencryption.txt" >>
  "%Filelocation%OUTPUTWeakencryption.txt" 
  del %Filelocation%OUTPUTTemp_weakencryption.txt 
 
  :: Code to check for weak transportation medium 
  grep -H -i -n -C3  "http://" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_overhttp.txt" 
  grep -H -i -n -C3 -e "HttpURLConnection" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_overhttp.txt" 
  grep -H -i -n -C3 -e "URLConnection" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_OtherUrlConnection.txt" 
  grep -H -i -n -C3 -e "URL" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_OtherUrlConnection.txt" 
  grep -H -i -n  -e "TrustAllSSLSocket-Factory" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTBypassSSLvalidations.txt" 
  grep -H -i -n -e "AllTrustSSLSocketFactory" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTBypassSSLvalidations.txt" 
  grep -H -i -n -e "NonValidatingSSLSocketFactory" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTBypassSSLvalidations.txt"  
  grep -H -i -n  -v "import" "%Filelocation%OUTPUTTemp_OtherUrlConnection.txt" >>
  "%Filelocation%OUTPUTOtherUrlConnections.txt" 
  del %Filelocation%OUTPUTTemp_OtherUrlConnection.txt 
  grep -H -i -n  -v "import" "%Filelocation%OUTPUTTemp_overhttp.txt" >> 
  "%Filelocation%OUTPUTUnencryptedTransport.txt" 
  del %Filelocation%OUTPUTTemp_overhttp.txt 
 
 
  :: Code to check for Autocomplete ON 
  grep -H -i -n -e "<Input" "%Filelocation%........reslayout*.xml" >>
  "%Filelocation%OUTPUTTemp_autocomp.txt"  
  grep -H -i -n -v "textNoSuggestions" "%Filelocation%OUTPUTTemp_autocomp.txt" >>
  "%Filelocation%OUTPUTAutocompleteOn.txt" 
  del %Filelocation%OUTPUTTemp_autocomp.txt 
 
 
  :: Code to presence of possible SQL Content 
  grep -H -i -n  -e "rawQuery" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "compileStatement" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "db" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "sqlite" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "database" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "insert" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n -e "delete" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "select" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n  -e "table" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n -e "cursor" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_sqlcontent.txt"  
  grep -H -i -n -v "import" "%Filelocation%OUTPUTTemp_sqlcontent.txt" >>
  "%Filelocation%OUTPUTSqlcontents.txt" 
  del %Filelocation%OUTPUTTemp_sqlcontent.txt 
 
  :: Code to check for Logging mechanism 
  grep -H -i -n  -F "Log." "%Filelocation%*.java" >> "%Filelocation%OUTPUTLogging.txt"  
 
  :: Code to check for Information in Toast messages 
  grep -H -i -n -e "Toast.makeText" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_Toast.txt"  
  grep -H -i -n -v "//" "%Filelocation%OUTPUTTemp_Toast.txt" >>
  "%Filelocation%OUTPUTToast_content.txt" 
  del %Filelocation%OUTPUTTemp_Toast.txt 
 
  :: Code to check for Debugging status 
  grep -H -i -n  -e "android:debuggable" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTDebuggingAllowed.txt"  
 
  :: Code to check for presence of Device Identifiers 
  grep -H -i -n  -e "uid|user-id|imei|deviceId|deviceSerialNumber|devicePrint|X-DSN|phone
  |mdn|did|IMSI|uuid" "%Filelocation%*.java" >> "%Filelocation%OUTPUTTemp_Identifiers.txt"  
  grep -H -i -n -v "//" "%Filelocation%OUTPUTTemp_Identifiers.txt" >>
  "%Filelocation%OUTPUTDevice_Identifier.txt" 
 del %Filelocation%OUTPUTTemp_Identifiers.txt 
 
  :: Code to check for presence of Location Info 
  grep -H -i -n  -e "getLastKnownLocation()|requestLocationUpdates()|getLatitude()|getLongitude()
  |LOCATION" "%Filelocation%*.java" >> "%Filelocation%OUTPUTLocationInfo.txt"  
 
  :: Code to check for possible Intent Injection 
  grep -H -i -n -C3 -e "Action.getIntent(" "%Filelocation%*.java" >>
  "%Filelocation%OUTPUTIntentValidation.txt"

How it works...

Go to the command prompt and navigate to the path where ScriptDroid is placed. Run the .bat file and it prompts you to input the path of the application for which you wish toperform static analysis. In our case we provide it with the path of the Insecure Bank application, precisely the path where Java files are stored. If everything worked correctly, the screen should look like the following:

auditing-mobile-applications-img-0

The script generates a folder by the name OUTPUT in the path where the Java files of the application are present. The OUTPUT folder contains multiple text files, each one corresponding to a particular vulnerability. The individual text files pinpoint the location of vulnerable code pertaining to the vulnerability under discussion.

The combination ofScriptDroid and Insecure Bank gives a very nice view of various Android vulnerabilities; usually the same is not possible with live apps.

Consider the following points, for instance:

Weakencryption.txt has listed down the instances of Base64 encoding used for passwords in the Insecure Bank application

Logging.txt contains the list of insecure log functions used in the application

SdcardStorage.txt contains the code snippet pertaining to the definitions related to data storage in SD Cards

Details like these from static analysis are eye-openers in letting us know of the vulnerabilities in our application, without even running the application.

There's more...

Thecurrent recipe used just ScriptDroid, but there are many other options available. You can either choose to write your own script or you may use one of the free orcommercial tools. A few commercial tools have pioneered the static analysis approach over the years via their dedicated focus.

Auditing Android apps a using a dynamic analyzer

Dynamic analysis isanother technique applied in source code audits. Dynamic analysis is conducted in runtime. The application is run or simulated and the flaws or vulnerabilities are discovered while the application is running.

Dynamic analysis can be tricky, especially in the case of mobile platforms. As opposed to static analysis, there are certain requirements in dynamic analysis, such as the analyzer environment needs to be runtime or a simulation of the real runtime.Dynamic analysis can be employed to find vulnerabilities in Android applications which aredifficult to find via static analysis. A static analysis may let you know a password is going to be stored, but dynamic analysis reads the memory and reveals the password stored in runtime. Dynamic analysis can be helpful in tampering data in transmission during runtime that is, tampering with the amount in a transaction request being sent to the payment gateway. Some Android applications employ obfuscation to prevent attackers reading the code; Dynamic analysis changes the whole game in such cases, by revealing the hardcoded data being sent out in requests, which is otherwise not readable in static analysis.

Getting ready

For conducting dynamic analysis of Android applications, we at least need one Android application and a dynamic code analyzer tool. Pick up any Android application of your choice and use any dynamic analyzer tool of your choice.

The dynamic analyzer tools can be classified under two categories:

The tools which run from computers and connect to an Android device or emulator (to conduct dynamic analysis)

The tools that can run on the Android device itself

For this recipe, we choose a tool belonging to the latter category.

How to do it...

Perform the following steps for conducting dynamic analysis:

Have an Android device with applications (to be analyzed dynamically) installed.

Go to the Play Store and download Andrubis. Andrubis is a tool from iSecLabs which runs on Android devices and conducts static, dynamic, and URL analysis on the installed applications. We will use it for dynamic analysis only in this recipe.

Open the Andrubis application on your Android device. It displays the applications installed on the Android device and analyzes these applications.

How it works...

Open the analysis of the application of your interest. Andrubis computes an overall malice score (out of 10) for the applications and gives the color icon in front of its main screen to reflect the vulnerable application. We selected anorange coloredapplication to make more sense with this recipe. This is how the application summary and score is shown in Andrubis:

auditing-mobile-applications-img-1

Let us navigate to the Dynamic Analysis tab and check the results:

auditing-mobile-applications-img-2

The results are interesting for this application. Notice that all the files going to be written by the application under dynamic analysis are listed down. In our case, one preferences.xml is located.

Though the fact that the application is going to create a preferences file could have been found in static analysis as well, additionally, dynamic analysis confirmed that such a file is indeed created. It also confirms that the code snippet found in static analysis about the creation of a preferences file is not a dormant code but a file that is going to be created. Further, go ahead and read the created file and find any sensitive data present there. Who knows, luck may strike and give you a key to hidden treasure.

Notice that the first screen has a hyperlink, View full report in browser. Tap on it and notice that the detailed dynamic analysis is presented for your further analysis. This also lets you understand what the tool tried and what response it got. This is shown in the following screenshot:

auditing-mobile-applications-img-3

There's more...

The current recipe used a dynamic analyzer belonging to the latter category. There are many other tools available in the former category. Since this is an Android platform, many of them are open source tools.

DroidBox can be tried for dynamic analysis. It looks for file operations (read/write), network data traffic, SMS, permissions, broadcast receivers, and so on, among other checks.Hooker is another tool that can intercept and modify API calls initiated from the application. This is veryuseful indynamic analysis. Try hooking and tampering with data in API calls.

Using Drozer to find vulnerabilities in Android applications

Drozer is a mobile security audit and attack framework, maintained by MWR InfoSecurity. It is a must-have tool in the tester's armory. Drozer (Android installed application) interacts with other Android applications via IPC (Inter Process Communication). It allows fingerprinting of application package-related information, its attack surface, and attempts to exploit those. Drozer is an attack framework and advanced level exploits can be conducted from it. We use Drozer to find vulnerabilities in our applications.

Getting ready

Install Drozer by downloading it from https://www.mwrinfosecurity.com/products/drozer/ and follow the installation instructions mentioned in the user guide.

Install Drozer console agent and start a session as mentioned in the User Guide.

If your installation is correct, you should get Drozer command prompt (dz>).

You should also have a few vulnerable applications as well to analyze. Here we chose OWASP GoatDroid application.

How to do it...

Every pentest starts with fingerprinting. Let us useDrozer for the same. The Drozer User Guide is very helpful for referring to the commands. The following command can be used to obtain information about anAndroid application package:

run app.package.info -a <package name>

We used the same to extract the information from the GoatDroid application and found the following results:

auditing-mobile-applications-img-4

Notice that apart from the general information about the application, User Permissions are also listed by Drozer.

Further, let us analyze the attack surface. Drozer's attack surface lists the exposed activities, broadcast receivers, content providers, and services. The in-genuinely exposed ones may be a critical security risk and may provide you access to privileged content.

Drozer has the following command to analyze the attack surface:

run app.package.attacksurface <package name>

We used the same to obtain the attack surface of the Herd Financial application of GoatDroid and the results can be seen in the following screenshot. Notice that one Activity and one Content Provider are exposed.

We chose to attack the content provider to obtain the data stored locally. We used the followingDrozer command to analyze the content provider of the same application:

run app.provider.info -a <package name>

This gave us the details of the exposed content provider, which we used in another Drozer command:

run scanner.provider.finduris -a <package name>

We could successfully query the content providers. Lastly, we would be interested in stealing the data stored by this content provider. This is possible via another Drozer command:

run app.provider.query content://<content provider details>/

The entire sequence of events is shown in the following screenshot:

auditing-mobile-applications-img-5

How it works...

ADB is used to establish a connection between Drozer Python server (present on computer) and Drozer agent (.apk file installed in emulator or Android device). Drozer console is initialized to run the various commands we saw. Drozer agent utilizes theAndroid OS feature of IPC to take over the role of the target application and run the various commands as the original application.

There's more...

Drozer not only allows users to obtain the attack surface and steal data via content providers or launch intent injection attacks, but it is way beyond that. It can be used to fuzz the application, cause local injection attacks by providing a way to inject payloads.

Drozer can also be used to run various in-built exploits and can be utilized to attack Android applications via custom-developed exploits. Further, it can also run in Infrastructure mode, allowing remote connections and remote attacks.

Auditing iOS application using static analysis

Static analysis in source code reviews is an easier technique, and employing static string searches makes it convenient to use.Static analysis is conducted on the raw or decompiled source code or on the compiled (object) code, but the analysis is conducted outside of runtime. Usually, static analysis figures out vulnerable or insecure code patterns.

Getting ready

For conducting static analysis of iOS applications, we need at least one iOS application and a static code scanner.

Pick up any iOS application of your choice and use any static analyzer tool of your choice. We will use iOS-ScriptDroid, which is a static analysis script, developed by Android security researcher, Dinesh Shetty.

How to do it...

Keep the decompressed iOS application filed and note the path of the folder containing the .m files.

Create an iOS-ScriptDroid.bat file by using the following code:

ECHO Running ScriptDriod ... 
  @ECHO OFF 
  SET /P Filelocation=Please Enter Location: 
  :: SET Filelocation=Location of the folder containing all the .m files eg: C:sourcecodeproject
  iOSxyz 
 
  mkdir %Filelocation%OUTPUT 
 
 
  :: Code to check for Sensitive Information storage in Phone memory 
  grep -H -i -n -C2 -e "NSFile" "%Filelocation%*.m" >> "%Filelocation%OUTPUTphonememory.txt" 
  grep -H -i -n -e  "writeToFile " "%Filelocation%*.m" >> "%Filelocation%OUTPUTphonememory.txt" 
 
  :: Code to check for possible Buffer overflow 
  grep -H -i -n  -e "strcat(|strcpy(|strncat(|strncpy(|sprintf(|vsprintf(|gets("
  "%Filelocation%*.m" >> "%Filelocation%OUTPUTBufferOverflow.txt" 
 
 
  :: Code to check for usage of URL Schemes 
  grep -H -i -n  -C2 "openUrl|handleOpenURL" "%Filelocation%*.m" >>
  "%Filelocation%OUTPUTURLSchemes.txt" 
 
 
  :: Code to check for possible scripting javscript injection 
  grep -H -i -n  -e "webview" "%Filelocation%*.m" >> "%Filelocation%OUTPUTprobableXss.txt" 
 
 
  :: Code to check for presence of possible weak algorithms 
  grep -H -i -n  -e "MD5" "%Filelocation%*.m" >> "%Filelocation%OUTPUTtweakencryption.txt" 
  grep -H -i -n  -e "base64" "%Filelocation%*.m" >> "%Filelocation%OUTPUTtweakencryption.txt" 
  grep -H -i -n  -e "des" "%Filelocation%*.m" >> "%Filelocation%OUTPUTtweakencryption.txt" 
  grep -H -i -n -v "//" "%Filelocation%OUTPUTtweakencryption.txt" >>
  "%Filelocation%OUTPUTweakencryption.txt" 
  del %Filelocation%OUTPUTtweakencryption.txt 
 
  :: Code to check for weak transportation medium 
  grep -H -i -n -e  "http://" "%Filelocation%*.m" >> "%Filelocation%OUTPUToverhttp.txt" 
  grep -H -i -n  -e "NSURL" "%Filelocation%*.m" >> "%Filelocation%OUTPUTOtherUrlConnection.txt" 
  grep -H -i -n  -e "URL" "%Filelocation%*.m" >> "%Filelocation%OUTPUTOtherUrlConnection.txt" 
  grep -H -i -n  -e "writeToUrl" "%Filelocation%*.m" >> "%Filelocation%OUTPUTOtherUrlConnection.txt" 
  grep -H -i -n  -e "NSURLConnection" "%Filelocation%*.m" >>
  "%Filelocation%OUTPUTOtherUrlConnection.txt" 
  grep -H -i -n -C2 "CFStream" "%Filelocation%*.m" >> "%Filelocation%OUTPUTOtherUrlConnection.txt" 
  grep -H -i -n  -C2 "NSStreamin" "%Filelocation%*.m" >> "%Filelocation%OUTPUTOtherUrlConnection.txt" 
 
  grep -H -i -n -e "setAllowsAnyHTTPSCertificate|kCFStreamSSLAllowsExpiredRoots
  |kCFStreamSSLAllowsExpiredCertificates" "%Filelocation%*.m" >>
  "%Filelocation%OUTPUTBypassSSLvalidations.txt"  
  grep -H -i -n -e "kCFStreamSSLAllowsAnyRoot|continueWithoutCredentialForAuthenticationChallenge"
  "%Filelocation%*.m" >> "%Filelocation%OUTPUTBypassSSLvalidations.txt" 
  ::to add check for "didFailWithError" 
 
  :: Code to presence of possible SQL Content 
  grep -H -i -F  -e "db" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F  -e "sqlite" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F  -e "database" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F  -e "insert" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F -e "delete" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F  -e "select" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F  -e "table" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F -e "cursor" "%Filelocation%*.m" >> "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F -e "sqlite3_prepare" "%Filelocation%OUTPUTsqlcontent.txt" >>
  "%Filelocation%OUTPUTsqlcontent.txt"  
  grep -H -i -F -e "sqlite3_compile" "%Filelocation%OUTPUTsqlcontent.txt" >>
  "%Filelocation%OUTPUTsqlcontent.txt"  
 
  :: Code to check for presence of keychain usage source code
  grep -H -i -n  -e "kSecASttr|SFHFKkey" "%Filelocation%*.m" >>
  "%Filelocation%OUTPUTLocationInfo.txt"  
 
  :: Code to check for Logging mechanism 
  grep -H -i -n  -F "NSLog" "%Filelocation%*.m" >> "%Filelocation%OUTPUTLogging.txt"  
  grep -H -i -n  -F "XLog" "%Filelocation%*.m" >> "%Filelocation%OUTPUTLogging.txt"  
  grep -H -i -n  -F "ZNLog" "%Filelocation%*.m" >> "%Filelocation%OUTPUTLogging.txt"  
 
 
  :: Code to check for presence of password in source code 
  grep -H -i -n  -e "password|pwd" "%Filelocation%*.m" >> "%Filelocation%OUTPUTpassword.txt"  
 
  :: Code to check for Debugging status 
  grep -H -i -n  -e "#ifdef DEBUG" "%Filelocation%*.m" >> "%Filelocation%OUTPUTDebuggingAllowed.txt"  
 
  :: Code to check for presence of Device Identifiers  ===need to work more on this 
  grep -H -i -n  -e "uid|user-id|imei|deviceId|deviceSerialNumber|devicePrint|X-DSN|phone
  |mdn|did|IMSI|uuid" "%Filelocation%*.m" >> "%Filelocation%OUTPUTTemp_Identifiers.txt"  
  grep -H -i -n -v "//" "%Filelocation%OUTPUTTemp_Identifiers.txt" >>
   "%Filelocation%OUTPUTDevice_Identifier.txt" 
  del %Filelocation%OUTPUTTemp_Identifiers.txt 
 
 
  :: Code to check for presence of Location Info 
  grep -H -i -n  -e "CLLocationManager|startUpdatingLocation|locationManager|didUpdateToLocation
  |CLLocationDegrees|CLLocation|CLLocationDistance|startMonitoringSignificantLocationChanges"
  "%Filelocation%*.m" >> "%Filelocation%OUTPUTLocationInfo.txt"  
 
  :: Code to check for presence of Comments 
  grep -H -i -n -e "//" "%Filelocation%*.m" >> "%Filelocation%OUTPUTTemp_comment.txt" 
  type -H -i  "%Filelocation%*.m" |gawk "//*/,/*//" >> "%Filelocation%OUTPUTMultilineComments.txt" 
  grep -H -i -n -v "TODO" "%Filelocation%OUTPUTTemp_comment.txt" >>
  "%Filelocation%OUTPUTSinglelineComments.txt" 
  del %Filelocation%OUTPUTTemp_comment.txt

How it works...

Go to the command prompt and navigate to the path where iOS-ScriptDroid is placed. Run the batch file and it prompts you to input the path of the application for which you wish to perform static analysis.

In our case, we arbitrarily chose an application and inputted the path of the implementation (.m) files.

The script generates a folder by the name OUTPUT in the path where the .m files of the application are present. The OUTPUT folder contains multiple text files, each one corresponding to a particular vulnerability. The individual text files pinpoint the location of vulnerable code pertaining to the vulnerability under discussion.

The iOS-ScriptDroid gives first hand info of various iOS applications vulnerabilities present in the current applications.

For instance, here are a few of them which are specific to the iOS platform.

BufferOverflow.txt contains the usage of harmful functions when missing buffer limits such as strcat, strcpy, and so on are found in the application.

URL Schemes, if implemented in an insecure manner, may result in access related vulnerabilities. Usage of URL schemes is listed in URLSchemes.txt. These are sefuuseful vulnerabilitydetails to know iniOS applications via static analysis.

There's more...

The current recipe used just iOS-ScriptDroid but there are many other options available. You can either choose to write your own script or you may use one of the free or commercial tools available. A few commercial tools have pioneered the static analysis approach over the years via their dedicated focus.

Auditing iOS application using a dynamic analyzer

Dynamic analysis is theruntime analysis of the application. The application is run or simulated to discover the flaws during runtime. Dynamic analysis can be tricky, especially in the case of mobile platforms.

Dynamic analysis is helpful in tampering data in transmission during runtime, for example, tampering with the amount in a transaction request being sent to a payment gateway. In applications that use custom encryption to prevent attackers reading the data, dynamic analysis is useful in revealing the encrypted data, which can be reverse-engineered.

Note that since iOS applications cannot be decompiled to the full extent, dynamic analysis becomes even more important in finding the sensitive data which could have been hardcoded.

Getting ready

For conducting dynamic analysis of iOS applications, we need at least one iOS application and a dynamic code analyzer tool. Pick up any iOS application of your choice and use any dynamic analyzer tool of your choice.

In this recipe, let us use the open source tool Snoop-it. We will use an iOS app that locks files which can only be opened using PIN, pattern, and a secret question and answer to unlock and view the file.

Let us see if we can analyze this app and find a security flaw in it using Snoop-it. Please note that Snoop-it only works on jailbroken devices.

To install Snoop-it on your iDevice, visit https://code.google.com/p/snoop-it/wiki/GettingStarted?tm=6.

We have downloaded Locker Lite from the App Store onto our device, for analysis.

How to do it...

Perform the following steps to conductdynamic analysis oniOS applications:

Open the Snoop-it app by tapping on its icon.

Navigate to Settings. Here you will see the URL through which the interface can be accessed from your machine:

Please note the URL, for we will be using it soon. We have disabled authentication for our ease.

Now, on the iDevice, tap on Applications | Select App Store Apps and select the Locker app:

Press the home button, and open the Locker app. Note that on entering the wrong PIN, we do not get further access:

Making sure the workstation and iDevice are on the same network, open the previously noted URL in any browser. This is how the interface will look:

Click on the Objective-C Classes link under Analysis in the left-hand panel:

Now, click on SM_LoginManagerController. Class information gets loaded in the panel to the right of it.

Navigate down until you see -(void) unlockWasSuccessful and click on the radio button preceding it:
This method has now been selected.

Next, click on the Setup and invoke button on the top-right of the panel. In the window that appears, click on the Invoke Method button at the bottom:

As soon as we click on thebutton, we notice that the authentication has been bypassed, and we can view ourlocked file successfully.

How it works...

Snoop-it loads all classes that are in the app, and indicates the ones that are currently operational with a green color. Since we want to bypass the current login screen, and load directly into the main page, we look for UIViewController. Inside UIViewController, we see SM_LoginManagerController, which could contain methods relevant to authentication. On observing the class, we see various methods such as numberLoginSucceed, patternLoginSucceed, and many others. The app calls the unlockWasSuccessful method when a PIN code is entered successfully. So, when we invoke this method from our machine and the function is called directly, the app loads the main page successfully.

There's more...

The current recipe used just onedynamic analyzer but other options and tools can also be employed. There are many challenges in doingdynamic analysis of iOS applications. You may like to use multiple tools and not just rely on one to overcome the challenges.

Examining iOS App Data storage and Keychain security vulnerabilities

Keychain iniOS is an encrypted SQLite database that uses a 128-bit AES algorithm to hold identities and passwords. On any iOS device, theKeychain SQLite database is used to store user credentials such as usernames, passwords, encryption keys, certificates, and so on. Developers use this service API to instruct the operating system to store sensitive data securely, rather than using a less secure alternative storage mechanism such as a property list file or a configuration file. In this recipe we will be analyzing Keychain dump to discover stored credentials.

Getting ready

Please follow the given steps to prepare for Keychain dump analysis:

Jailbreak the iPhone or iPad.

Ensure the SSH server is running on the device (default after jailbreak).

Download the Keychain_dumper binary from https://github.com/ptoomey3/Keychain-Dumper

Connect the iPhone and the computer to the same Wi-Fi network.

On the computer, run SSH into the iPhone by typing the iPhone IP address, username as root, and password as alpine.

How to do it...

Follow these steps toexamine security vulnerabilities in iOS:

Copy keychain_dumper into the iPhone or iPad by issuing the following command:
```
scp root@<device ip>:keychain_dumper private/var/tmp
```

Alternatively, Windows WinSCP can be used to do the same:

Once the binary has been copied, ensure the keychain-2.db has read access:
```
chmod +r /private/var/Keychains/keychain-2.db
```
This is shown in the following screenshot:

Give executable right to binary:

chmod 777 /private/var/tmp/keychain_dumper

Now, we simply run keychain_dumper:
```
/private/var/tmp/keychain_dumper
```

This command will dump all keychain information, which will contain all the generic and Internet passwords stored in the keychain:

How it works...

Keychain in an iOS device is used to securely store sensitive information such as credentials, such as usernames, passwords, authentication tokens for different applications, and so on, along with connectivity (Wi-Fi/VPN) credentials and so on. It is located on iOS devices as an encrypted SQLite database file located at /private/var/Keychains/keychain-2.db.

Insecurity arises when application developers use this feature of the operating system to store credentials rather than storing it themselves in NSUserDefaults, .plist files, and so on. To provide users the ease of not having to log in every time and hence saving the credentials in the device itself, the keychain information for every app is stored outside of its sandbox.

There's more...

This analysis can also be performed for specific apps dynamically, using tools such as Snoop-it. Follow the steps to hook Snoop-it to the target app, click on Keychain Values, and analyze the attributes to see its values reveal in the Keychain. More will be discussed in further recipes.

Finding vulnerabilities in WAP-based mobile apps

WAP-based mobile applications are mobile applications or websites that run on mobile browsers. Most organizations create a lightweight version of their complex websites to be able to run easily and appropriately in mobile browsers. For example, a hypothetical company called ABCXYZ may have their main website at www.abcxyz.com, while their mobile website takes the form m.abcxyz.com. Note that the mobile website (or WAP apps) are separate from their installable application form, such as .apk on Android.

Since mobile websites run on browsers, it is very logical to say that most of the vulnerabilities applicable to web applications are applicable to WAP apps as well. However, there are caveats to this. Exploitability and risk ratings may not be the same. Moreover, not all attacks may be directly applied or conducted.

Getting ready

For this recipe, make sure to be ready with the following set of tools (in the case of Android):

WinSCP

Putty

Rooted Android mobile

SSH proxy application installed on Android phone

Let us see the common WAP application vulnerabilities. While discussing these, we will limit ourselves to mobilebrowsers only:

Browser cache: Android browsers store cache in two different parts—content cache and component cache. Content cache may contain basic frontend components such as HTML, CSS, or JavaScript. Component cache contains sensitive data like the details to be populated once content cache is loaded. You have to locate the browser cache folder and find sensitive data in it.

Browser memory: Browser memory refers to the location used by browsers to store the data. Memory is usually long-term storage, while cache is short-term. Browse through the browser memory space for various files such as .db, .xml, .txt, and so on. Check all these files for the presence of sensitive data.

Browser history: Browser history contains the list of the URLs browsed by the user. These URLs in GET request format contain parameters. Again, our goal is to locate a URL with sensitive data for our WAP application.

Cookies: Cookies are mechanisms for websites to keep track of user sessions. Cookies are stored locally in devices. Following are the security concerns with respect to cookie usage:
- Sometimes a cookie contains sensitive information
- Cookie attributes, if weak, may make the application security weak
- Cookie stealing may lead to a session hijack

How to do it...

Browser Cache: Let's look at the steps that need to be followed with browser cache:

Android browser cache can be found at this location: /data/data/com.android.browser/cache/webviewcache/.

You can use either ADB to pull the data from webviewcache, or use WinSCP/Putty and connect to SSH application in rooted Android phones.

Either way, you will land up at the webviewcache folder and find arbitrarily named files. Refer to the highlighted section in the following screenshot:

Rename the extension of arbitrarily named files to .jpg and you will be able to view the cache in screenshot format. Search through all files for sensitive data pertaining to the WAP app you are searching for.

Browser Memory: Like an Android application, browser also has a memory space under the /data/data folder by the name com.android.browser (default browser). Here is how a typical browser memory space looks:

auditing-mobile-applications-img-19

Make sure you traverse through all the folders to get the useful sensitive data in the context of the WAP application you are looking for.

Browser history

Go to browser, locate options, navigate to History, and find the URLs present there.

Cookies The files containing cookie values can be found at /data/data/com.android.browser/databases/webview.db.

These DB files can be opened with the SQLite Browser tool and cookies can be obtained.

There's more...

Apart from the primary vulnerabilities described here mainly concerned with browser usage, all otherweb application vulnerabilities which are related to or exploited from or within a browser are applicable and need to be tested:

Cross-site scripting, a result of a browser executing unsanitized harmful scripts reflected by the servers is very valid for WAP applications.

The autocomplete attribute not turned to off may result in sensitive data remembered by the browser for returning users. This again is a source of data leakage.

Browser thumbnails and image buffer are other sources to look for data.

Above all, all the vulnerabilities in web applications, which may not relate to browser usage, apply. These include OWASP Top 10 vulnerabilities such as SQL injection attacks, broken authentication and session management, and so on. Business logic validation is another important check to bypass. All these are possible by setting a proxy to the browser and playing around with the mobile traffic.

The discussion of this recipe has been around Android, but all the discussion is fully applicable to an iOS platform when testing WAP applications. Approach, steps to test, and the locations would vary, but all vulnerabilities still apply. You may want to try out iExplorer and plist editor tools when working with an iPhone or iPad.

Finding client-side injection

Client-side injection is a new dimension to the mobile threat landscape. Client side injection (also known as local injection) is a result of the injection of malicious payloads to local storage to reveal data not by the usual workflow of the mobile application. If 'or'1'='1 is injected in a mobile application on search parameter, where the search functionality is built to search in the local SQLite DB file, this results in revealing all data stored in the corresponding table of SQLite DB; client side SQL injection is successful.

Notice that the payload did not to go the database on the server side (which possibly can be Oracle or MSSQL) but it did go to the local database (SQLite) in the mobile. Since the injection point and injectable target are local (that is, mobile), the attack is called a client side injection.

Getting ready

To get ready to find client side injection, have a few mobile applications ready to be audited and have a bunch of tools used in many other recipes throughout this book.

Note that client side injection is not easy to find on account of the complexities involved; many a time you will have to fine-tune your approach as per the successful first signs.

How to do it...

The prerequisite to the existence of client side injection vulnerability in mobile apps is the presence of a local storage and an application feature which queries the local storage. For the convenience of the first discussion, let us learn client side SQL injection, which is fairly easy to learn as users know very well SQL Injection in web apps.

Let us take the case of a mobile banking application which stores the branch details in a local SQLite database. The application provides a search feature to users wishing to search a branch. Now, if a person types in the city as Mumbai, the city parameter is populated with the value Mumbai and the same is dynamically added to the SQLite query. The query builds and retrieves the branch list for Mumbai city. (Usually, purely local features are provided for faster user experience and network bandwidth conservation.)

Now if a user is able to inject harmful payloads into the city parameter, such as a wildcard character or a SQLite payload to the drop table, and the payloads execute revealing all the details (in the case of a wildcard) or the payload drops the table from the DB (in the case of a drop table payload) then you have successfully exploited client side SQL injection.

Another type of client side injection, presented in OWASP Mobile TOP 10 release, is local cross-site scripting (XSS). Refer to slide number 22 of the original OWASP PowerPoint presentation here: http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks. They referred to it as Garden Variety XSS and presented a code snippet, wherein SMS text was accepted locally and printed at UI. If a script was inputted in SMS text, it would result in local XSS (JavaScript Injection).

There's more...

In a similar fashion, HTML Injection is also possible. If an HTML file contained in the application local storage can be compromised to contain malicious code and the application has a feature which loads or executes this HTML file, HTML injection is possible locally.

A variant of the same may result in Local File Inclusion (LFI) attacks.

If data is stored in the form of XML files in the mobile, local XML Injection can also be attempted.

There could be morevariants of these attacks possible. Finding client-side injection is quite difficult and time consuming. It may need to employ both static and dynamic analysis approaches. Most scanners also do not support discovery of Client Side Injection.

Another dimension to Client Side Injection is the impact, which is judged to be low in most cases. There is a strong counter argument to this vulnerability. If the entire local storage can be obtained easily in Android, then why do we need to conduct Client Side Injection? I agree to this argument in most cases, as the entire SQLite or XML file from the phone can be stolen, why spend time searching a variable that accepts a wildcard to reveal the data from the SQLite or XML file?

However, you should still look out for this vulnerability, as HTML injection or LFI kind of attacks have malware-corrupted file insertion possibility and hence the impactful attack. Also, there are platforms such as iOS where sometimes, stealing the local storage is very difficult. In such cases, client side injection may come in handy.

Insecure encryption in mobile apps

Encryption is one of the misused terms in information security. Some people confuse it with hashing, while others may implement encoding and call itencryption. symmetric key and asymmetric key are two types of encryption schemes.

Mobile applications implement encryption to protect sensitive data in storage and in transit. While doing audits, your goal should be to uncover weak encryption implementation or the so-called encoding or other weaker forms, which are implemented in places where a proper encryption should have been implemented. Try to circumvent the encryption implemented in the mobile application under audit.

Getting ready

Be ready with a fewmobile applications and tools such as ADB and other file and memory readers, decompiler and decoding tools, and so on.

How to do it...

There are multiple types of faulty implementation ofencryption in mobile applications. There are different ways to discover each of them:

Encoding (instead of encryption): Many a time, mobile app developers simply implement Base64 or URL encoding in applications (an example of security by obscurity).
Such encoding can be discovered by simply doing static analysis. You can use the script discussed in the first recipe of this article for finding out such encoding algorithms.

Dynamic analysis will help you obtain the locally stored data in encoded format. Decoders for these known encoding algorithms are available freely. Using any of those, you will be able to uncover the original value. Thus, such implementation is not a substitute for encryption.

Serialization (instead of encryption): Another variation of faulty implementation is serialization. Serialization is the process of conversion of data objects to byte stream. The reverse process, deserialization, is also very simple and the original data can be obtained easily.
Static Analysis may help reveal implementations using serialization.

Obfuscation (instead of encryption): Obfuscation also suffers from similar problems and the obfuscated values can be deobfuscated.

Hashing (instead of encryption): Hashing is a one-way process using a standard complex algorithm. These one-way hashes suffer from a major problem in that they can be replayed (without needing to recover the original data). Also, rainbow tables can be used to crack the hashes.

Like other techniques described previously, hashing usage in mobile applications can also be discovered via static analysis. Dynamic analysis may additionally be employed to reveal the one-way hashes stored locally.

How it works...

To understand the insecure encryption in mobile applications, let us take a live case, which we observed.

An example of weak custom implementation

While testing a live mobile banking application, me and my colleagues came across a scenario where a userid and mpin combination was sent by a custom encoding logic. The encoding logic here was based on a predefined character by character replacement by another character, as per an in-built mapping. For example:

2 is replaced by 4

0 is replaced by 3

3 is replaced by 2

7 is replaced by =

a is replaced by R

A is replaced by N

As you can notice, there is no logic to the replacement. Until you uncover or decipher the whole in-built mapping, you won't succeed. A simple technique is to supply all possible characters one-by-one and watch out for the response. Let's input userid and PIN as 222222 and 2222 and notice the converted userid and PIN are 444444 and 4444 respectively, as per the mapping above. Go ahead and keep changing the inputs, you will create a full mapping as is used in the application.

Now steal the user's encoded data and apply the created mapping, thereby uncovering the original data. This whole approach is nicely described in the article mentioned under the See also section of this recipe.

This is a custom example of faulty implementation pertaining to encryption. Such kinds of faults are often difficult to find in static analysis, especially in the case of difficult to reverse apps such as iOS applications. The possibility of automateddynamic analysis discovering this is also difficult. Manual testing and analysis stands, along with dynamic or automated analysis, a better chance of uncovering such customimplementations.

There's more...

Finally, I would share another application we came across. This one used proper encryption. The encryption algorithm was a well known secure algorithm and the key was strong. Still, the whole encryption process can be reversed.

The application had two mistakes; we combined both of them to break the encryption:

The application code had the standard encryption algorithm in the APK bundle. Not even obfuscation was used to protect the names at least. We used the simple process of APK to DEX to JAR conversion to uncover the algorithm details.

The application had stored the strong encryption key in the local XML file under the /data/data folder of the Android device. We used adb to read this xml file and hence obtained the encryption key.

According to Kerckhoff's principle, the security of a cryptosystem should depend solely on the secrecy of the key and the private randomizer. This is how all encryption algorithms are implemented. The key is the secret, not the algorithm.

In our scenario, we could obtain the key and know the name of the encryption algorithm. This is enough to break the strong encryption implementation.

Discovering data leakage sources

Data leakage risk worries organizations across the globe and people have been implementing solutions to prevent data leakage. In the case of mobile applications, first we have to think what could be the sources or channels for data leakage possibility. Once this is clear, devise or adopt a technique to uncover each of them.

Getting ready

As in other recipes, here also you need bunch of applications (to be analyzed), an Android device or emulator, ADB, DEX to JAR converter, Java decompilers, Winrar, or Winzip.

How to do it...

To identify the data leakage sources, list down all possible sources you can think of for the mobile application under audit. In general, all mobile applications have the following channels of potential data leakage:

Files stored locally

Client side source code

Mobile device logs

Web caches

Console messages

Keystrokes

Sensitive data sent over HTTP

How it works...

The next step is to uncover the data leakage vulnerability at these potential channels. Let us see the six previously identified common channels:

Files stored locally: By this time, readers are very familiar with this. The data is stored locally in files like shared preferences, xml files, SQLite DB, and other files.
In Android, these are located inside the application folder under /data/data directory and can be read using tools such as ADB.

In iOS, tools such as iExplorer or SSH can be used to read the application folder.

Client side source code: Mobile application source code is present locally in the mobile device itself. The source code in applications has been hardcoding data, and a common mistake is hardcoding sensitive data (either knowingly or unknowingly).
From the field, we came across an application which had hardcoded the connection key to the connected PoS terminal. Hardcoded formulas to calculate a certain figure, which should have ideally been present in the server-side code, was found in the mobile app. Database instance names and credentials are also a possibility where the mobile app directly connects to a server datastore.

In Android, the source code is quite easy to decompile via a two-step process—APK to DEX and DEX to JAR conversion.

In iOS, the source code of header files can be decompiled up to a certain level using tools such as classdump-z or otool.

Once the raw source code is available, a static string search can be employed to discover sensitive data in the code.

Mobile device logs: All devices create local logs to store crash and other information, which can be used to debug or analyze a security violation. A poor coding may put sensitive data in local logs and hence data can be leaked from here as well.
Android ADB command adb logcat can be used to read the logs on Android devices. If you use the same ADB command for the Vulnerable Bank application, you will notice the user credentials in the logs as shown in the following screenshot:

Web caches: Web caches may also contain the sensitive data related to web components used in mobile apps. We discussed how to discover this in the WAP recipe in this article previously.

Console messages: Console messages are used by developers to print messages to the console while application development and debugging is in progress. Console messages, if not turned off while launching the application (GO LIVE), may be another source of data leakage. Console messages can be checked by running the application in debug mode.

Keystrokes: Certain mobile platforms have been known to cache key strokes. A malware or key stroke logger may take advantage and steal a user's key strokes, hence making it another data leakage source. Malware analysis needs to be performed to uncover embedded or pre-shipped malware or keystroke loggers with the application. Dynamic analysis also helps.

Sensitive data sent over HTTP: Applications either send sensitive data over HTTP or use a weak implementation of SSL. In either case, sensitive data leakage is possible.

Usage of HTTP can be found via static analysis to search for HTTP strings. Dynamic analysis to capture the packets at runtime also reveals whether traffic is over HTTP or HTTPS.

There are various SSL-related weak implementation and downgrade attacks, which make data vulnerable to sniffing and hence data leakage.

There's more...

Data leakage sources can be vast and listing all of them does not seem possible. Sometimes there are applications or platform-specific data leakage sources, which may call for a different kind of analysis.

Intent injection can be used to fire intents to access privileged contents. Such intents may steal protected data such as the personal information of all the patients in a hospital (under HIPPA compliance).

iOS screenshot backgrounding issues, where iOS applications store screenshots with populated user input data, on the iPhone or iPAD when the application enters background. Imagine such screenshots containing a user's credit card details, CCV, expiry date, and so on, are found in an application under PCI-DSS compliance.

Malwares give a totally different angle to data leakage. Note that data leakage is a very big risk organizations are tackling today. It is not just financial loss; losses may be intangible, such as reputation damage, or compliance or regulatory violations. Hence, it makes it very important to identify the maximum possible data leakage sources in the application and rectify the potential leakages.

Other application-based attacks in mobile devices

When we talk about application-based attacks, OWASP TOP 10 risks are the very first things that strike. OWASP (www.owasp.org) has a dedicated project to mobile security, which releases Mobile Top 10.

OWASP gathers data from industry experts and ranks the top 10 risks every three years. It is a very good knowledge base for mobile application security. Here is the latest Mobile Top 10 released in the year 2014:

M1: Weak Server Side Controls

M2: Insecure Data Storage

M3: Insufficient Transport Layer Protection

M4: Unintended Data Leakage

M5: Poor Authorization and Authentication

M6: Broken Cryptography

M7: Client Side Injection

M8: Security Decisions via Untrusted Inputs

M9: Improper Session Handling

M10: Lack of Binary Protections

Getting ready

Have a few applications ready to be analyzed, use the same set of tools we have been discussing till now.

How to do it...

In this recipe, we restrict ourselves to other application attacks. The attacks which we have not covered till now in this book are:

M1: Weak Server Side Controls

M5: Poor Authorization and Authentication

M8: Security Decisions via Untrusted Inputs

M9: Improper Session Handling

How it works...

Currently, let us discuss client-side or mobile-side issues for M5, M8, and M9.

M5: Poor Authorization and Authentication

A few common scenarios which can be attacked are:

Authentication implemented at device level (for example, PIN stored locally)

Authentication bound on poor parameters (such as UDID or IMEI numbers)

Authorization parameter responsible for access to protected application menus is stored locally

These can be attacked by reading data using ADB, decompiling the applications, and conducting static analysis on the same or by doing dynamic analysis on the outgoing traffic.

M8: Security Decisions via Untrusted Inputs

This one talks about IPC. IPC entry points forapplications to communicate to one other, such as Intents in Android or URL schemes in iOS, are vulnerable. If the origination source is not validated, the application can be attacked.

Malicious intents can be fired to bypass authorization or steal data. Let us discuss this in further detail in the next recipe.

URL schemes are a way for applications to specify the launch of certain components. For example, the mailto scheme in iOS is used to create a new e-mail. If theapplications fail to specify the acceptable sources, any malicious application will be able to send a mailto scheme to the victim application and create new e-mails.

M9: Improper Session Handling

From a purely mobile device perspective, session tokens stored in .db files or oauth tokens, or strings granting access stored in weakly protected files, are vulnerable. These can be obtained by reading the local data folder using ADB.

Launching intent injection in Android

Android uses intents to request action from another application component. A common communication is passing Intent to start a service. We will exploit this fact via an intent injection attack.

An intent injection attack works by injecting intent into the application component to perform a task that is usually not allowed by the application workflow. For example, if the Android application has a login activity which, post successful authentication, allows you access to protected data via another activity. Now if an attacker can invoke the internal activity to access protected data by passing an Intent, it would be an Intent Injection attack.

Getting ready

Install Drozer by downloading it from https://www.mwrinfosecurity.com/products/drozer/ and following the installation instructions mentioned in the User Guide.

Install Drozer Console Agent and start a session as mentioned in the User Guide.

If your installation is correct, you should get a Drozer command prompt (dz>).

How to do it...

You should also have a few vulnerable applications to analyze. Here we chose the OWASP GoatDroid application:

Start the OWASP GoatDroid Fourgoats application in emulator.

Browse the application to develop understanding. Note that you are required to authenticate by providing a username and password, and post-authentication you can access profile and other pages. Here is the pre-login screen you get:

Let us now use Drozer to analyze the activities of the Fourgoats application. The following Drozer command is helpful:
```
run app.activity.info -a <package name>
```
Drozer detects four activities with null permission. Out of these four, ViewCheckin and ViewProfile are post-login activities.

Use Drozer to access these two activities directly, via the following command:
```
run app.activity.start --component <package name> <activity name>
```

We chose to access ViewProfile activity and the entire sequence of activities is shown in the following screenshot:

Drozer performs some actions and the protected user profile opens up in the emulator, as shown here:

How it works...

Drozer passed an Intent in the background to invoke the post-login activity ViewProfile. This resulted in ViewProfile activity performing an action resulting in display of profile screen. This way, an intent injection attack can be performed using Drozer framework.

There's more...

Android usesintents also forstarting a service or delivering a broadcast. Intent injection attacks can be performed on services and broadcast receivers. A Drozer framework can also be used to launch attacks on the app components. Attackers may write their own attack scripts or use different frameworks to launch this attack.