# A Multi-Tier Security Analysis of Official Car Management Apps for Android
## 5 Low-Level Static Analysis
### Signer Cert., APKiD, Network Security  
Each APK is signed by the developer using a specific cryptographic hash function, say, SHA-1, and APK signature scheme version, say, v3. As observed from the second column of Table 5, seven apps indicate a different hash algorithm (SHA256) than the one actually used (SHA-1) to sign the app. Precisely, the algorithm in parenthesis indicates the hash algorithm declared in the manifest file, while the actual algorithm used is shown at the left. On top of this, five more apps, i.e., 12 in total, have used SHA-1. Nevertheless, NIST deprecated the use of SHA-1 and suppressed its use for digital signatures in 2011 and 2013, respectively, [60]. If the app has been signed with the use of SHA-1 (or MD5), collisions may be possible. This means that apps signed with the corresponding weak algorithm are prone to attacks, including hijacking the app with phony updates or granting permissions to a malicious app. For example, the attacker may be able to repackage the app after including malicious code in it. Then, given that the signature validates, they could phish users to install the repacked app instead of the legitimate one.  
Another vulnerability, which is rooted in improper signature usage, is known as \"Janus\" (CVE-2017-13156) [61]. Namely, Janus can be exploited if the v1 signature scheme (JAR signing) is used along with Android v5.0 (API 21) to v7.0 (API 25). Specifically, Janus leverages on the possibility of adding extra bytes to APK and DEX files, without affecting the signature. As shown in Table 5, all but one (30) of the examined apps are vulnerable to Janus, namely they were signed under scheme v1 and support Android v6.  
As presented in the forth column of Table 5, network security analysis pinpointed three high severity vulnerabilities. The first and more serious, namely \"insecure base configuration to permit clear text traffic to all domains\", means that the app is configured to possibly allow unencrypted network communications. The second, is similar to the previous one; the difference is that the scope of domains is narrower. The last vulnerability, titled \"Domain is configured to trust user installed certificates\" may allow an assailant to successfully exercise a man-in-the-middle (MitM) attack and decrypt the network traffic. It is to be noted that this triplet of issues refer to the network security configuration xml file an app may designate through a special entry <application android:networkSecurityConfig=\"> in its manifest file under the <application> tag [62]. Seven apps were found to be susceptible to the first vulnerability, while the rest two apply to a single (different) app.  
The Android app identifier (APKiD) [63] offers information about how an APK was built. Precisely, APKiD is used by a plethora of static analysis tools to identify packers, i.e., agents created by packing engines used to protect the software, protectors, obfuscations, etc. From them, the most interesting one is packers [64], originally made to safeguard the intellectual property of apps. However, nowadays, Android packers like Baidu, Bangcle, Ijiami, and others are used extensively by malware coders given that reverse engineering tools are typically unable to unpack and inspect concealed payloads within packed apps. As seen in Table 5, only one app was found to leverage packing mechanisms.