With a heavy push for native mobile apps in the last 10 years, there has been a large corresponding growth in the mobile appsec space. With the OWASP Mobile Top 10, which was initially released in 2014 and updated in 2016, many organizations have a framework to use to properly secure their APIs and mobile devices.
Like web applications, testing mobile applications is more than just running a DAST or VA scan of your APIs. Mobile applications are still susceptible to many of the same application flaws but also introduce another vector of exposure – data residency. For example, mobile builds may contain sensitive API keys, encryption keys, or secrets that shouldn’t be publicly shared. We have even seen developers forgetting to remove logging statements from production builds, which logs every single request and response, including sensitive data. Given that mobile devices are inherently more susceptible to being misplaced, lost, or stolen, data residency for mobile applications creates a high security risk for organizations and users.
Other data residency issues we typically find is through the normal use of mobile applications. Storing of customer data should be done securely and only on an as-needed-basis. Google has the Keystore and Apple the Keychain, which can be leveraged to securely store sensitive information (e.g., authentication tokens) on the device’s file system. This can be particularly bad when data is stored in public storage (e.g., /sdcard on Android) or on a device that is rooted or jailbroken since the app folders can be easily accessed. So, queue up another research endeavor.
Enter – Bell Smart Home (fka. AlarmForce) Note: We responsibly disclosed the below issues to Bell and gave several extensions to give them a chance to implement fixes. After offering us a bug bounty reward, Bell gave us the rigmarole without fully remediating all the issues.
Test Environment:
Android Smart Home App: v4.20.2
If you have read some of our other blog posts, we tend to wander off and research everyday household apps. Which is how Bell’s “Smart Home” Android app came on our radar.
Now, this one came as a little bit of a shock, considering it is a security app. Lo and behold, we found cleartext tokens (SeamlessLoginToken and TwoFactorId) stored in a Shared Preferences file within the app container. These are long-lived tokens that are used retrieve a temporary session token, which is then used in subsequent requests to interact with the Bell APIs. So, if these two tokens fall into the wrong hands, they can be used to get a refreshed session token and hijack a user’s account on the Smart Home app.
We also found two related session management issues:
- On Android, when a user logs out, a request isn’t even sent to the API to terminate the user’s session (oops). The app now sends a request, but the tokens are not invalidated.
- When a user resets their password, their SeamlessLoginToken is not terminated, so it can be used to retrieve a new SessionToken. Bell has since addressed this issue.
DISCLOSURE TIMELINE:
Bell does not have a bug bounty program or a method to disclose vulnerabilities responsibly; however, our findings were reported as per industry best practices:
- February 9, 2022: Provided details of our findings to Bell’s Security team.
- May 5, 2022: Bell requested an extension and offered a potential bug bounty reward. A 30-day extension was provided.
- May 13, 2022: Bell indicated remediation may take longer than 30 days but are willing to offer a bug bounty reward in exchange for an NDA.
- May 24, 2022: Bell requested additional time to provide an NDA.
- June 16, 2022: Proack requested an update.
- July 14, 2022: Bell requested additional time. Proack provided final deadline of July 18th, 2022.
- July 27, 2022: Proack observed that some of the vulnerabilities that were disclosed have been addressed
- July 29, 2022: Public disclosure.