Another client side: mobile app security through the eyes of an attacker

[Man]

Hello! Today I want to talk about the security of mobile applications from the attacker's side.

Mobile applications actively use data, which means they need proper protection. Therefore, over the past few years, the number of projects related to the analysis of their security has grown significantly. The interest of companies in the security of mobile applications can also be seen in the bug bounty market. For example, on BI.ZONE Bug Bounty, mobile applications are included in 19 public programs.

Let's take a closer look at what vulnerabilities are found in mobile applications

This text is based on my speech at VolgaCTF.

Example of vulnerability​

Further we will talk specifically about Android, since it is more accessible for security research.

Client-side vulnerabilities are less critical than server-side ones, since they affect a specific user, not a service. But there is one key feature that makes vulnerabilities in mobile clients a tasty morsel for attackers. Unlike web applications, they directly interact with the device's operating system, which means they have much more capabilities.

Mobile applications can interact directly:

• with the device's file system,
• OS via system calls,
• sh shell,
• camera, microphone, gyroscope and other peripheral devices,
• other applications on the device.

Let's experiment and see what we can do on the device using RCE. To emulate the presence of RCE on the device, I used AndroRAT and the Android Studio device emulator.

The capabilities of Interpreter AndroRAT out of the box are already amazing.

With RCE on the device we get access to the following data:

• Information about the device.
  
  
• Information about the IP and MAC address of the device.
  
  
• Camera (due to the emulator's features, it was not possible to connect to it).
• History of messages, incoming and outgoing calls.
  
  
• Device location.
  
  
• Information about the SIM card and provider.
  
  
• Microphone.
  
  
• Clipboard.
  
  

Often, applications have access to the SD card, where many interesting things can be stored: from application cache to user photos.

There is nothing stopping an attacker from uploading their own utilities and then using them for post-exploitation and persistence. For demonstration purposes, I compiled and uploaded my own version of the URL, and used it to access the resource from the internal network.

In the same way, an attacker can compile and download to the device:

• utilities for reconnaissance and network scanning,
• utilities for proxying traffic through the device,
• Malware: miners, botnet backends, etc.

Not every RCE will give you so many options. It all depends on the flexible mechanism of setting permission in Android or specifying property in iOS. Thanks to this, you can specify what the application should have access to and what it should not.

With a strict policy, you can reduce the impact of RCE to approximately zero, limiting the application's access as much as possible, up to interaction over the network. But in this case, the application will be cut down in functions, which is not always convenient.

For example, the Habra app on Android doesn’t request that many permissions.

When a theoretical RCE is detected, the maximum we can do is write and execute arbitrary files in the application directory (regardless of permissions), and interact with the device network. That's all.

But if you look at how many permissions a given Telegram requests, one screenshot won’t be enough to fit everything.

And Telegram is no exception. According to statistics from Cybernews, it is easy to see that 3 out of 4 applications request access to external data storage, and every third one requests access to the microphone and camera. Applications often request rights that they do not need. This is due to the fact that some developers ask to give extended rights to the application by default. So the exception is rather the Habra application with a relatively small set of rights.

The impact of vulnerabilities does exist, but it depends on the type of vulnerability, as well as the permissions set for the application. But on average, the criticality in mobile applications will be higher than that of client-side vulnerabilities in web applications.

Vulnerability classification​

There are several opinions on how to classify vulnerabilities in mobile applications. Let's consider these.

By the vector of exploitation

• 0-click. To exploit the vulnerability, no action is required from the user, be it any interaction or installation of additional applications. It is enough to send the user a message with a payload, which will be processed by the application without additional interaction from the person.
  
  
• 1-click. To operate, the user must perform one action: follow a link, open an attachment, etc.
  
  
• Malware app: Exploitation requires the user to install a malicious application that exploits an interprocess communication vulnerability in another application.
  
  
• MITM: To be exploited, the attacker must have implemented a man-in-the-middle attack and be able to control network traffic.
  
  
• Physical access: Physical access to the device is required to exploit the vulnerability.

The first three types have a real vector for mass exploitation, so they can be considered the most critical. For such vulnerabilities, in most cases, you can get a bounty in bug bounty programs that have mobile applications.

The last two, while seemingly harmless, can still pose serious risks. No one wants to see a notice about a charge on their bank account after briefly leaving their phone in the office kitchen or connecting to public Wi-Fi.

Injections
An injection is a vulnerability in which an attacker introduces malicious data into an application to change its behavior, bypass protection, or execute unwanted commands.

Unlike web applications, where CSS, HTML and JS can be embedded in the client-side, here the list is much wider.

In some places the mobile application uses WebView, which is essentially an internal browser, so we can find the same client-side vulnerabilities in it as in the web application.

To allow XSS, it is enough to enable javascript support in WebView. In my experience, it is enabled in 99 cases out of 100. When was the last time you saw a web page without JS?

 webView.getSettings().setJavaScriptEnabled(true);

It's not enough to just escape user input: it's just like a web app.

One of the interesting features: in some cases, developers can implement a javascript interface that will allow calling java code from javascript and thus get the ability to interact with the OS.

So, you can write a simple interface where the getDeviceInfo and getBatteryLevel functions will be implemented:

 public class WebAppInterface { private Context mContext;
private LocationManager locationManager; private LocationListener locationListener;
public WebAppInterface(Context context) { mContext = context;
locationManager = (LocationManager) mContext.getSystemService(Context.LOCATION_SERVICE);
}
@JavascriptInterface
public String getDeviceInfo() {
return "Device: " + Build.MODEL + ", OS Version: " + Build.VERSION.RELEASE;
}
@JavascriptInterface
public String getBatteryLevel() {
BatteryManager batteryManager = (BatteryManager) mContext.getSystemService(Context.BATTERY_SERVICE);
int batteryLevel = batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY);
return "Battery Level: " + batteryLevel + "%";
}

Then connect it to WebView:

 webView.addJavascriptInterface(new WebAppInterface(this), "os");

In this case we will be able to use these functions from javascript, which is especially interesting when there is XSS.

Any code implemented by the developer, which may also contain vulnerabilities, can be executed in this way.

SQLi
Mobile applications may be vulnerable to SQL injections due to the use of SQLite for data storage and improper filtering of user input.

Example of vulnerable code:

 public void search(View view) { 
 EditText srchtxt = (EditText) findViewById(R.id.ivi1search); 
 try { 
 Cursor cr = this.mDB.rawQuery("SELECT * FROM sqliuser WHERE user
= '" + srchtxt.getText().toString() + "'", null);

The impact of SQLi is significantly less than that of a server-side vulnerability, but it can still be noticeable.

This injection can be used to steal user personal data, spoof data, bypass local verification, or cause denial of service to the application client by corrupting or deleting data.

Path traversal
The application interacts directly with the device's file system, so path traversal allows reading and rewriting arbitrary files that the application has permission to access.

By default, a regular user cannot view the contents of the application directory and, as a result, access the data stored there without root rights. So, if we have found path traversal, which allows reading any files on behalf of the application, this is already a fairly serious vulnerability.

Example of vulnerable code:

 public String readFileContent(String fileName) throws IOException { 
String BASEDIR = getFilesDir().getAbsolutePath(); 
File file = new File(BASEDIR + "/notes/"+ fileName); 
StringBuilder content = new StringBuilder(); 
 
try (BufferedReader reader = new BufferedReader(new
FileReader(file))) { 
String line; 
while ((line = reader.readLine()) != null) { 
content.append(line).append(System.lineSeparator());
} 
} 
return content.toString().trim(); 
}

However, the criticality increases significantly if it is path traversal when writing a file, as it can directly lead to RCE on the device. To do this, it is enough to overwrite one of the libraries used by the application with your own, which will contain the necessary code.

If you're interested in how this is used in real life, I recommend checking out the Hackerone report on RCE in Evernote's Android client.

Insecure deserialization
Most Android apps are developed using Java/Kotlin, and if input data is not properly validated, unsafe deserialization of data can occur.

Example of vulnerable code:

private void deserialize(InputStream inputStream) throws IOException,
ClassNotFoundException { 
ObjectInputStream ois = new ObjectInputStream(inputStream); 
MyObject obj = (MyObject) ois.readObject(); 
TextView outputTextView = findViewById(R.id.deserOutput);
outputTextView.setText(obj.toString()); 
}

In this case, a potential attacker will be able to influence the serialized object, change its property or method implementation, as in the example:

private static void Exploit() throws IOException { 
MyObject hackedObject = new MyObject("OriginalName") { 
@Override 
public String toString() { 
return "hacked " + UUID.randomUUID().toString(); 
} 
}; 
ObjectOutputStream oos = new ObjectOutputStream(new
FileOutputStream("/tmp/exploit.bin")); 
oos.writeObject(hackedObject); 
oos.close(); 
}

In the example, I changed the toString implementation to return a randomly generated value of "hacked + UID".

Although in this way it is possible to inject any other code and get its remote execution on the device.

A more detailed analysis of the vulnerability is beyond the scope of this article. For a deeper understanding, I recommend reading what serialization is in java, as well as how the tool for generating payloads using the ysoserial gadget chain is structured.

Code Execution
Standard code execution vulnerabilities are also possible.

Example of vulnerable code:

private String executeCommand(String command) { try {
Process process = Runtime.getRuntime().exec(command);
...

This is rare, as the modern SDK contains enough options to completely eliminate the use of exec.

Inter-process communications (IPC)
Android has many built-in features for inter-app communication. On the one hand, this gives developers greater flexibility when building an app architecture, but on the other hand, it significantly increases the attack surface for attackers.

Explaining all the IPC mechanisms is not the main topic of this article, so I will only talk about the main entities that are used to exploit IPC vulnerabilities:

• An Intent is an interprocess communication mechanism in Android that allows application components such as an Activity, Service, or BroadcastReceiver to communicate with each other or with other applications.
• Broadcast receivers are an Android component that allow applications to respond to system broadcasts, such as events like receiving an SMS or changing network status.

You can initiate broadcast messages using the am utility:

am broadcast -n com.test.package/.NotificationReceiver -a package.newnotification --es "text" "YOU HAVE BEEN HACKED"

• A content provider is a component for managing access to structured application data, such as databases or files within an application directory.
• Deeplinks are schemes that allow applications to open specific actions through link handling, for example an application can be launched through a link like myapp://open?param=value.

This category is difficult to break down into subgroups like injections, so I'll give a few examples of IPC-related vulnerabilities.

Exported content provider
One of the most common vulnerabilities in Android applications is incorrectly configured access rights to application entities. As an example, I will give Content Provider.

When a Content Provider is marked as exported, it becomes accessible to other applications. This means that external applications can query and modify the data unless proper access control is in place.

In my case, the ISP provided access to the application database, so I wrote a proof of concept (POC) of the application that would contact the ISP and retrieve passwords from the user's database.

An example of a function that implements a call to a third-party content provider:

public static List<Map<String, String>> getPassword(Context context) {
    Uri parse = Uri.parse("content://com.test.app.contentprovider/pwds");
    ArrayList arrayList = new ArrayList();
    Cursor query = context.getContentResolver().query(parse, null, null, null, null);
    if (query != null && query.moveToFirst()) {
        do {
            try {
                HashMap hashMap = new HashMap();
                String string = query.getString(query.getColumnIndex("pwd"));
                hashMap.put("name", query.getString(query.getColumnIndex("name")));
                hashMap.put("pwd", string);
                arrayList.add(hashMap);
            } finally {
                query.close();
            }
        } while (query.moveToNext());
    }
    return arrayList;
}

While searching for similar cases in the bug bounty, I came across a report in the Nextcloud program. True, here the data was obtained using the drozer software, but the meaning is about the same.

Local auth bypass via deeplink
Deeplink is used to handle an action in the application when a certain type of link is followed. Often, this action is the launch of an application activity. In some cases, deeplink handling misses application security checks, such as local user authorization checks.

The vulnerable application implemented PIN code authorization:

protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 if (!isPinCodeVerified()) {
 Intent intent = new Intent(this, PinCodeActivity.class); 
 startActivity(intent); finish();
 } else {
 setContentView(R.layout.activity_main); 
 } 
}

However, the application allowed access to other activities via a link, in particular viewing the user's profile.

<activity android:name=".ProfileActivity"> 
 <intent-filter> 
 <action android:name="android.intent.action.VIEW" /> 
 <category android:name="android.intent.category.DEFAULT" /> 
 <category android:name="android.intent.category.BROWSABLE" /> 
 <data android:scheme="https" android:host="www.example.com" android:path="/profile" /> 
 </intent-filter> 
</activity>

Moreover, in .ProfileActivity they forgot to implement the isPinCodeVerified() check. To bypass local authorization, it is enough to open the link `https://host[.]com/account` in the browser.

Or run the application via deeplink using the am utility:

am start –n com.package.example –d "https://host.com/account”

Information leak via URL-scheme
Another vulnerability is related to URL schemes - when an application transmits sensitive information in cleartext using a URL scheme.

The problem is that any application can register to handle any URL scheme. We can write our own application that will handle the required URL scheme, for example testapp://createtask:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.evil.app">
<application
 android:allowBackup="true"
 ... 
 >
 <activity android:name=".MailtoAppActivity"> 
 <intent-filter> 
 <action android:name="android.intent.action.VIEW" /> 
 <category android:name="android.intent.category.DEFAULT" /> 
 <category android:name="android.intent.category.BROWSABLE" /> 
 <data android:scheme="testapp" android:host="createtask" /> 
 </intent-filter> 
 </activity>

And it will allow interception of data when accessing the URL scheme from the original application.

So, on Hackerone I came across an account takeover in the Shopify app using this vulnerability. You can read the details in the report itself.

Binary vulns
Mobile applications under the hood may use native libraries, often written in C/C++ languages, which are not memory safe.

This opens the door to vulnerabilities such as:

• Buffer Overflow Integer Overflow.
• Use-After-Free.
• Double-free.

So fans of the pwn category should definitely appreciate it.

A few articles are unlikely to be enough to fully dive into this category, so I'll give examples of discovered in-the-wild vulnerabilities:

• How a double-free bug in WhatsApp turns to RCE.
• Instagram_RCE: Code Execution Vulnerability in Instagram App for Android and iOS.

Getting Started​

Reading about vulnerabilities, large attack surface and other features, someone might decide that it is difficult to start researching mobiles. I think that the main thing here is to start. Therefore, I have collected what can help at the start.

To get basic knowledge and study the theory, it is worth looking at OWASP and their MASTG and MASVS. I would also recommend paying attention to the free course from Mobile hacking lab. On GitHub you can find collections of resources with task analyses, bug bounty reports and other content that can help in learning (AST, one more repo).

After gaining basic knowledge, it is time to move on to practice.

The first thing you need for mobile app security testing is a device. It is much more convenient to view apps on a physical device, but you can start checking Android apps with an Android emulator, which is not the case with iOS.

From experience I can advise:

• Genymotion is a lightweight and fast emulator that is more than enough for testing an application.
• Android studio is a full-fledged development and debugging environment. The built-in emulator is only a small part of its capabilities, so this software is much heavier and requires more computing resources. It will do if you want to write a POC for a vulnerability with a malware app vector.

If you plan to use a physical device, you will first need to root it and enable Android Debug Bridge through the developer settings.

When working with mobile applications, it is worth paying attention to these utilities:

• JADX is an Android app (APK) decompilation tool that converts Dalvik/ART (DEX) bytecode back into readable Java source code and allows you to examine app structures.
• Frida is a dynamic analysis and debugging tool that allows you to intercept and modify code execution in real time on devices.
• Objection is a Frida-based framework that simplifies the process of bypassing mobile app security.
• AM (activity manager) is an Android command for managing activities and other application components. It allows you to start, stop, and interact with applications through the command line on the device.
• ADB (Android debug bridge) is a command utility that allows you to interact with your Android device from your computer, performing debugging, installing applications, managing the file system, and executing commands in the terminal.
• MobSF is an opensource (SAST/DAST) vulnerability scanner for mobile applications. It is unlikely to find anything serious, but it can highlight bottlenecks.

After stocking up on the starting tools and device, let's go get our hands dirty. All sorts of labs and CrackMe will help with this:

• Frida Labs.
• SecureNote.
• OWASP CrackMe.

Bug bounty programs will help you try your hand at real applications. You can hone your skills on the BI.ZONE Bug Bounty platform, because there are enough public programs there, the scope of which includes mobile applications.

Researching mobile app security opens up career opportunities and helps businesses create quality, reliable products. Hopefully, this article will help some readers pay attention to the mobile app industry and give impetus to research in this area.

Author: Sergey Arefyev, specialist of the application security analysis department.

Source