Abstract
Nowadays mobile phones are widely used to enforce multi-factor authentication (MFA) either by receiving a code through SMS or, even better, using a dedicated application as an authenticator. Those applications have to be correctly secured because the final step of authentication will rely on them.
During a penetration engagement, our client was using the HID ActivID Mobile Soft Token in order to enable 2FA on their VPN servers. With the agreement of the client, we performed a security review of the ActivID Soft Token on both Android and iOS platforms. RandoriSec found a few vulnerabilities on the HID ActivID Mobile Soft Token earlier this year. We’ve choose to “responsible disclose” these 0day vulnerabilities directly to the vendor HID in April 2020.
Both mobile applications (Android and iOS) are vulnerable. Hence they are not complying with the OWASP Mobile Application Security Verification Standard. Here is a description of each one with its related MSTG-ID:
- The iOS app does not remove Secure Code (virtual token) from views when moved to the background (MSTG-STORAGE‑9)
- The Android app allows to take screenshots of the token (MSTG-STORAGE‑9)
- The iOS app does not prevent an attacker to tamper with executable files and critical data within their own sandbox (MSTG-RESILIENCE-3)
- The Security Code (the virtual token) generated is, by design, automatically copied to the general pasteboard and this feature cannot be disabled. So, it’s available to other apps including malware/spyware installed on the device or injected in the mobile processes (MSTG-PLATFORM-2).
- The iOS app does not prevent an attacker to use reverse engineering tools and frameworks on the device (MSTG-RESILIENCE-4).
These issues won’t be fixed as the ActivID product is EOL since April 2020 but HID recommends to move from ActivID to HID Approve which don’t suffer from these issues.
Product
The following HID ActivID Mobile Soft Tokens were reviewed:
- HID ActivID iOS Mobile Soft Token Version: 4.2.2.2
- HID ActivID Android Mobile Soft Token Version: 4.3.0.4035
1. Auto-Generated Screenshots for Sensitive Information (MSTG-STORAGE-9)
Description
The iOS app does not remove the Secure Code (virtual token) from views when moved to the background. As a reminder when the application goes into the background, a screenshot is taken. This feature can pose a security risk because screenshots are written to local storage, where they can be recovered by a rogue application.
Proof of Concept
In this example, we can see that backgrounding the application results in a screenshot of the front view of the app. This screenshot contains the last Secure Code.
Recommendation
A static image (e.g: HID logo) should replace the screenshot to avoid the leak of the Secure Code by a malware/spyware.
References
2. Taking Screenshots for Sensitive Information (MSTG-STORAGE-9)
Description
The Android app allows a user to take a screenshot of the Secure Code (virtual token). A malicious application installed on the device can use this flaw in order to retrieve the Secure Code of the user.
Proof of Concept
Here is a screenshot of the Secure Code:
Recommendation
To protect the Secure Code from being recorded by other apps, FLAG_SECURE should be used on any views containing sensitive data.
References
- https://github.com/OWASP/owasp-mstg/blob/0afa8787c36d6a46d5928dbd1ae7b4a155cf5dd9/Document/0x05d-Testing-Data-Storage.md#finding-sensitive-information-in-auto-generated-screenshots-mstg-storage-9
- https://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/
3. Application Source Code Integrity Checks (MSTG-RESILIENCE-3)
Description
The iOS app does not detect, and does not respond to, tampering with executable files and critical data within their own sandbox.
Proof of Concept
The iOS app implements a jailbreak detection:
But it does not check the integrity of the binary or the process so it’s quite easy to patch them to bypass the final branch of the check to avoid exiting the process when a jailbroken device is detected.
Graph view of the final branch of the check:
If the device is detected as jailbroken the app branches on the right part: an error message is shown and the app exits. If not, it branches on the left part and the Splash screen is called.
Here the binary is patched by replacing:
b.ne sub_100006538+272
by:
beq sub_100006538+272
This screenshot, showing Cydia in background, proves that the app is running on a jailbroken device.
Recommendation
It is recommended to implement an internal run-time check that determines whether the signatures still match at run time.
References
4. Security Code automatically copied to the clipboard (MSTG-PLATFORM-2)
Description
The Security Code (virtual token) generated is, by design, automatically copied to the general pasteboard and this feature cannot be disabled. So, it is available to other apps including malware/spyware installed on the device or injected in the mobile processes.
Proof of Concept
The following screenshot shows that Safari app is getting the Security Code by accessing the pasteboard:
Note: the same behavior was observed on the Android app.
Recommendation
If possible, we recommend to not copy the Security Code to the clipboard. If this feature is really needed, we recommend implementing a way to disable this feature globally for a client.
References
N/A
5. Reverse engineering tools detection (MSTG-RESILIENCE-4)
Description
The iOS app does not detect, and does not respond to, the presence of widely used reverse engineering tools and frameworks on the device.
Proof of Concept
The following screenshot shows that Frida has been injected to ActivID app process:
Then the methods whose name begin with DisplayOTP have been instrumented to display their inputs and outputs:
Recommendation
The app should detect that Frida is installed on the device and should detect and avoid process hooking.
References
Conclusion
ActivID product is EOL so these issues won’t be fixed. But HID recommends to move from ActivID to HID Approve which don’t suffer from these issues (it worths mentioning that we didn’t checked that yet). Finally we would like to thank Jeremy Tomlin from HID for the good communication regarding the disclosure process and add that he can be contacted (Jeremy Tomlin at hidglobal dot com) regarding your HID solutions and mitigations.