Taint analysis for Android Java code

Document/0x05c-Reverse-Engineering-and-Tampering.md

@@ -1272,6 +1272,86 @@
 
 To conclude, learning symbolic execution might look a bit intimidating at first, as it requires deep understanding and extensive practice. However, the effort is justified considering the valuable time it can save in contrast to analyzing complex disassembled instructions manually. Typically you'd use hybrid techniques, as in the above example, where we performed manual analysis of the disassembled code to provide the correct criteria to the symbolic execution engine. Please refer to the iOS chapter for more examples on Angr usage.
 
+### Taint Analysis
+
+Taint analysis is an information flow analysis technique. It involves tracking the flow of sensitive information within a program. For example, determining the usage of geolocation information collected in an Android app - whether it is being sent to 3rd party domains or not.
+
+In taint analysis, the information is defined to flow from source to sink. Source is from where a sensitive information originates, while a sink is where the information is eventually used. For instance in an Android app `getDeviceId()` and `sendTextMessage()` function calls are used. Using taint analysis we can determine whether the device ID from `getDeviceId()` is being sent out as a text message or not, using `sendTextMessage()`. For taint analysis,  `getDeviceId()` is the source and `sendTextMessage()` is the sink, and we determine if there is a direct path between the source and sink. If there is a direct path, then such a flow is called a **leak**.
+
+Often with big applications information flow analysis performed manually is very time consuming, and can be inaccurate. Taint analysis provides an excellent alternative to automate such analysis. Taint analysis can be performed both statically and dynamically, with each approach having its own pros and cons. Discussing these pros and cons is beyond the scope of this section.
+
+There are multiple tools which perform taint analysis on native code, like [Triton](https://github.com/jonathansalwan/Triton "Triton"), [bincat](https://github.com/airbus-seclab/bincat "bincat"). In this section we will focus on Android Java code, and use [FlowDroid](https://github.com/secure-software-engineering/FlowDroid "FlowDroid") to perform the taint analysis. Apart from FlowDroid, [GDA](https://github.com/charles2gan/GDA-android-reversing-Tool/wiki/GDA-Static-Taint-Analysis "GDA") also supports taint analysis for Android apps.
+
+FlowDroid is an open-source tool, built on top of [soot](https://github.com/soot-oss/soot "soot") - a framework for analyzing and transforming Java and Android applications. FlowDroid performs a fully context, object and flow-sensitive taint analysis, while accommodating the additional complexity of Android application's lifecycle and UI widgets in the analysis.
+
+FlowDroid tool can be used either as a standalone command line tool or as a library. The former mostly used to perform a quick analysis, while later for performing complex analysis. We will use command line tool and perform taint analysis on [InsecureShop v1.0]( https://github.com/hax0rgb/InsecureShop/releases/tag/v1.0 "InsecureShop") application.
+
+In InsecureShop app, it accepts username and password as input, and stores them into the app's shared preferences. For taint analysis, we are interested in how this stored username and password are used. For our analysis, username and password is the sensitive information, while reading from shared preferences will be the source. Sink for this analysis can be multiple operations - sending info over the network, sending info out in an Intent, storing info in an external file etc. For simplicity, let us only consider the scenario where an `Intent` is sent with username and password included as extra parameters to the `Intent`.
+
+To use FlowDroid, firstly, we need to provide an input list of possible sources and sinks to evaluate for. In our case, reading from shared preferences will be the source, while adding parameters to an `Intent` as sink. The config file will look as following (and named as source_sink.txt):
+
+```Jimple
+<android.content.SharedPreferences: java.lang.String getString(java.lang.String, java.lang.String)> -> _SOURCE_
+
+<android.content.Intent: android.content.Intent putExtra(java.lang.String,java.lang.CharSequence)> -> _SINK_
+<android.content.Intent: android.content.Intent putExtra(java.lang.String,char)> -> _SINK_
+<android.content.Intent: android.content.Intent putExtra(java.lang.String,java.lang.String)> -> _SINK_
+```
+
+To invoke FlowDroid via command line, following command can be used:
+
+```shell
+java -jar soot-infoflow-cmd/target/soot-infoflow-cmd-jar-with-dependencies.jar \
+    -a InsecureShop.apk \
+    -p Android/Sdk/platforms \
+    -s source_sink.txt
+```
+
+The output from the above command is following:
+
+```
+...
+
+[main] INFO soot.jimple.infoflow.android.SetupApplication$InPlaceInfoflow - The sink virtualinvoke r2.<android.content.Intent: android.content.Intent putExtra(java.lang.String,java.lang.String)>("password", $r5) in method <com.insecureshop.AboutUsActivity: void onSendData(android.view.View)> was called with values from the following sources:
+
+[main] INFO soot.jimple.infoflow.android.SetupApplication$InPlaceInfoflow - - $r1 = interfaceinvoke $r2.<android.content.SharedPreferences: java.lang.String getString(java.lang.String,java.lang.String)>("password", "") in method <com.insecureshop.util.Prefs: java.lang.String getPassword()>
+
+...
+
+[main] INFO soot.jimple.infoflow.android.SetupApplication$InPlaceInfoflow - The sink virtualinvoke r2.<android.content.Intent: android.content.Intent putExtra(java.lang.String,java.lang.String)>("username", $r4) in method <com.insecureshop.AboutUsActivity: void onSendData(android.view.View)> was called with values from the following sources:
+
+[main] INFO soot.jimple.infoflow.android.SetupApplication$InPlaceInfoflow - - $r1 = interfaceinvoke $r2.<android.content.SharedPreferences: java.lang.String getString(java.lang.String,java.lang.String)>("username", "") in method <com.insecureshop.util.Prefs: java.lang.String getUsername()>
+
+...
+
+[main] INFO soot.jimple.infoflow.android.SetupApplication - Found 2 leaks
+```
+
+The output indicates there are 2 leaks in the application, with one each corresponding to the username and password.
+
+The above output uses [jimple intermediate representation](https://www.sable.mcgill.ca/soot/doc/soot/jimple/Jimple.html "Jimple") to show the sources and sinks. Jimple representation contains enough information to locate the sources and sinks in the actual application. Since, InsecureShop app is an open source app, we can look for the source code corresponding to above findings, and shown below:
+
+```java
+// file: AboutActivity.kt
+
+fun onSendData(view: View) {
+        val userName = Prefs.username!!
+        val password = Prefs.password!!
+
+        val intent = Intent("com.insecureshop.action.BROADCAST")
+        intent.putExtra("username", userName)
+        intent.putExtra("password", password)
+        sendBroadcast(intent)
+
+        textView.text = "InsecureShop is an intentionally designed vulnerable android app built in Kotlin."
+
+    }
+```
+
+FlowDroid is a versatile tool, and can also be used for generating call graphs. This is demonstrated in this [blog post](https://medium.com/geekculture/generating-call-graphs-in-android-using-flowdroid-pointsto-analysis-7b2e296e6697 "FlowDroid call graphs") by Navid Salehnamadi.
+
+To summarize, taint analysis is an information flow analysis approach. For Android Java code, FlowDroid can be used for performing taint analysis. Taint analysis is especially helpful in automating data flow analysis in big complex applications. With applications having complex flows, the accuracy of such tools may vary, thus it is upto the human reviewer to strike a balance between time consumed for manual analysis and accuracy.
+
 ## Tampering and Runtime Instrumentation
 
 First, we'll look at some simple ways to modify and instrument mobile apps. _Tampering_ means making patches or runtime changes to the app to affect its behavior. For example, you may want to deactivate SSL pinning or binary protections that hinder the testing process. _Runtime Instrumentation_ encompasses adding hooks and runtime patches to observe the app's behavior. In mobile application security however, the term loosely refers to all kinds of runtime manipulation, including overriding methods to change behavior.