Get A Quote

More MobSF – Mobile Application Penetration Testing #3

  • Home
  • More MobSF – Mobile Application Penetration Testing #3
More MobSF – Mobile Application Penetration Testing #3
  • 03 November, 2023
  • No Comments

Welcome back for Part 3 of our series on Mobile Application Penetration Testing. If you haven’t read Part 1 or Part 2, go ahead and take a look. In this post we will go over some more of the MobSF output. I promise you that we will eventually get to real testing, but as I said, this will be a long running series. At the end of the day, a lot of what we will cover in the MobSF posts is what makes Android mobile application penetration testing different that web application testing.

Signer Certificate

The next section we see in the output is the Signer Certificate section. What’s all in this section?

  1. Signature Versioning:
    • The APK uses v2 and v3 signatures, but not v1. APK Signature Scheme v2 (and v3) offers stronger protection against unauthorized alterations to the APK file.
  2. Certificate Details:
    • The issuer is identified with Google, Inc. based in Mountain View.
    • The certificate was valid from December 2, 2008, to December 19, 2036. The extended validity period is common for root and certain intermediate certificates.
  3. Hash Algorithms:
    • MD5: MD5 is considered insecure due to its vulnerability to collision attacks.
    • SHA-1, SHA-256, and SHA-512: These are cryptographic hash functions. SHA-256 and SHA-512 are considered secure and are widely used for digital signatures.
  4. PublicKey Algorithm:
    • RSA with a key size of 1024 bits. Generally, RSA with a key size of 2048 bits or more is recommended for modern security practices. However, the APK might be using 1024 bits for compatibility reasons or due to the age of the certificate.
  5. Issues Detected:
    • The primary concern raised by the tool is that the APK is signed with MD5, highlighting its known vulnerability to collision attacks.

Given that this APK is from a major developer like Google, the presence of MD5 is unexpected in modern app distributions. However, remember that certificates, especially root or intermediate ones, might have been generated a while ago when MD5 was still in use. The key question is how the APK uses these signatures. If the app relies solely on MD5 for its security, then there’s a significant concern. However, if MD5 is just one of several signatures (as the presence of SHA-1, SHA-256, and SHA-512 suggests), and the app’s security doesn’t depend solely on MD5, then the risk might be mitigated.

In practical terms, any malicious actor attempting to exploit the MD5 vulnerability would also need to bypass the SHA-256 and SHA-512 signatures, which are still considered secure. This stuff is interesting and all, but you aren’t going to get any bug bounties from what you see here. All apps should be signed, if they aren’t, that could be an issue for a penetration test report.

Permissions

The next section may be a little more spicy – permissions

The permissions section for Android applications provides a list of all the permissions that the application requests. Each permission is associated with a specific capability that the app might need to function correctly or to provide certain features to the user. Let’s break down the provided permissions:

  1. android.permission.ACCESS_AD_ID and android.permission.ACCESS_ADSERVICES_ATTRIBUTION:
  2. android.permission.ACCESS_COARSE_LOCATION:
    • Status: Dangerous
    • Description: This permission allows an application to access approximate location data, typically derived from sources like the mobile network database. It gives a rough idea about the device’s location, which could be used for features like local weather, regional ads, etc. Given its “dangerous” label, apps need explicit user consent at runtime to access this data.
  3. android.permission.ACCESS_FINE_LOCATION:
    • Status: Dangerous
    • Description: This permission allows an application to access precise location data, using sources like the Global Positioning System (GPS). It provides exact geolocation data which can be used for map-based apps, location tracking, etc. This is a “dangerous” permission, requiring user consent at runtime.
  4. android.permission.ACCESS_NETWORK_STATE:
    • Status: Normal
    • Description: This is a standard permission that allows apps to view the status of network connections, such as whether Wi-Fi is enabled or if the device is connected to a mobile network. It’s used to check connectivity before making network requests or to change behavior based on connection type.
  5. android.permission.ACCESS_WIFI_STATE:
    • Status: Normal
    • Description: This permission lets the app view information regarding the Wi-Fi networks, like whether Wi-Fi is enabled, the name of the connected network, etc. It doesn’t grant access to connect/disconnect from Wi-Fi networks, just to view the current state.
  6. android.permission.CAMERA:
    • Status: Dangerous
    • Description: With this permission, apps can access the device’s camera to capture photos or videos. It might be used for features like image uploading, video calls, scanning QR codes, etc. Being a “dangerous” permission, user consent is required at runtime.
  7. android.permission.FOREGROUND_SERVICE:
    • Status: Normal
    • Description: This permission is required for apps that want to use the startForeground method, ensuring the app can run a foreground service. Foreground services are tasks that the user is actively aware of and shouldn’t be killed by the Android system, like playing music or a navigation app giving directions.
  8. android.permission.FOREGROUND_SERVICE_CAMERA and android.permission.FOREGROUND_SERVICE_DATA_SYNC:
    • Status: Unknown
    • Description: FOREGROUND_SERVICE_CAMERA allows a regular application to use Service.startForeground with the type “camera” and FOREGROUND_SERVICE_DATA_SYNC allows a regular application to use Service.startForeground with the type “dataSync”.

When analyzing permissions, it’s essential to consider:

  • The type of app and its core functionality.
  • Whether the app genuinely requires the permission to operate.
  • If the permissions fit the app’s described purpose and functionality.

In other words, one app’s dangerous functionality is another app’s normal functionality.

Android API

The next and final section we will cover today is the Android API section. Again, this section isn’t likely to give us any specific vulnerabilities, but it will be indicative of certain behaviors or functionalities of the application.

In a normal application, this section will always be very long. There are some things to note like file IO, network IO, crypto, etc. This is invaluable for a quick assessment, but for a thorough security review, it should be combined with other analyses like static code review, dynamic analysis, and network traffic inspection.

That’s All For Today’s Mobile Application Penetration Testing

I know this all seems kind of dry, but a strong foundation will help us find the high impact bugs that other testers miss because they lack this knowledge. Stay tuned for Part 4 of our Mobile Application Penetration Testing series, and as always, Let’s Make the Bad Guys Salty!

Tags: