1549738 - Lockwise / Doyensec / Auto-Lock Insecure Design and Departure From Best Practices

Status: RESOLVED INCOMPLETE

(Lockwise Graveyard :: Security, defect)

Description

[Luca Carettoni]

Vulnerability Class: Insecure Design
Component: mozilla.lockbox.support.AutoLockSupport

Description

Lockwise implements a feature named “auto-lock” to reduce the window of opportunity for an attacker with physical access to the device, when PIN/Fingerprint is setup. After a predetermined amount of time (customizable in the application’s settings), Lockwise locks down access to credentials.

According to the design documentation provided by Mozilla, the user has the ability to set an auto lock time, which will be started in any of the following cases:

• When Lockwise goes to background
• When Lockwise is terminated
• When the phone is locked, while Lockwise is unlocked

The current implementation relies on a check performed when a new activity is started, in order to compare the current timestamp with the expected auto-lock time.

This issue summarizes four auto-lock insecure design decisions that we believe are affecting Lockwise’s overall security posture:

A) This feature is not triggered when the application is in foreground. While this was clearly a design choice, Doyensec would suggest to reconsider this decision. Mobile phone screen locks may have a longer timeout, hence the password manager auto-lock feature may be able to mitigate risks introduced by insecure phone settings. Please note that Lockwise’s iOS does enforce a timeout in foreground.

B) The application is not immediately locked when the user closes it. As a result, there is a window of opportunity for an attacker between the application’s shutdown and auto-lock/device-lock (whichever triggers first). During our audit, we have performed a comparison of auto-lock features among popular password managers and Lockwise is the only application that does not lock credentials once the app is closed.

C) When the application is locked after a timeout (via auto-lock), a device reboot unlocks the application for a short period of time (approx. 10 to 60 seconds depending on the device). This is the result of the current implementation that relies on a broadcast receiver for the android.intent.action.BOOT_COMPLETED intent before locking the secure storage. Since the operating system does not guarantee a broadcast of such intent immediately after phone reboot and unlock, there is a small (yet significant) window of opportunity for an attacker. While the maintainers are aware of this issue (see #568), we believe that the threat model did not consider:

• Local malicious applications, exploiting a privilege escalation bug. A previously installed application could exploit a local sandbox bypass and access the stored data in the window of opportunity between phone reboot/unlock and Lockwise BootReceiver execution;
• Devices with unlocked bootloader. In this situation, physical access to the device can be leveraged to bypass the pin. As a result, an attacker can boot the device and quickly switch to Lockwise (which will be in an unlocked state). Doyensec has tested this scenario on different devices.

D) As mentioned, the current implementation relies on a timestamp check performed during activity load. That means that the application is actually in the unlock state, unless the user opens the application (or triggers the auto-fill activity). Malicious processes can take advantage of this implementation strategy to obtain a reference of the unlocked database connection string.

Reproduction Steps

All insecure design decisions and departure from best practices can be verified using simple operations:

For (A), setup a phone with a long device screen-lock timeout. Then, leave the Lockwise application in foreground and verify that the application will not lock itself.

For (B), setup Lockwise with auto-lock in 5 minutes. Close the application and immediately re-open it to verify that the application is still in an un-locked state.

For (C), setup Lockwise with auto-lock in 1 minute. Wait and verify that the application is in fact locked. Reboot the device and immediately open Lockwise after unlocking the device.

For (D), source review review (or debugging using breakpoints) can be used to verify the current implementation strategy. See mozilla.lockbox.support.AutoLockSupport#autoLockTimeElapsed

Impact

Under specific circumstances, all design decisions and departures from best practices discussed in this finding might be leveraged to disclose stored credentials.

Remediation

Based on our comparison with other Android password managers, we would recommend to reconsider the current auto-lock design and implementation. In particular, we would recommend to:

• Enforce auto-lock for both foreground and background activities
• Ensure that Lockwise is always locked at startup
• Ensure that the lock state is changed without requiring user interactions (e.g. using a background service)

Resources

• Firefox Lockbox Documentation, “Locking/Unlocking” https://lockbox.firefox.com/architecture/lock-unlock.html
• 1Password, “How to set 1Password to lock automatically” https://support.1password.com/auto-lock/
• Dashlane, “Dashlane logs out all the time, can I change that?” https://support.dashlane.com/hc/en-us/articles/202699351-Dashlane-logs-out-all-the-time-can-I-change-that-

Comment 1

[Frederik Braun [:freddy]]

Going for sec-moderate. Would be nice if we get those things fixed specifically where Lockwise deviates from standards met by all other password managers.

Matt, I know this is a bit of a mixed bag for a single Bugzilla issue, but can I ask you to get this into the team's discussion and let us know which work items you'll queue up here?

Comment 2

[Frederik Braun [:freddy]]

Ok, during triage we came to the following conclusion:
Issue A, locking when timeout occurs while app is foreground: is indeed a design consideration that is unlikely to be fixed.
Issue B,C,D: The solution might be around locking when app is force-quit. But will need a bit of further consideration.

Comment 3

[David Lawrence [:dkl]]

Removing employee no longer with company from CC list of private bugs.

Comment 4

[BMO Automation]

Lockwise deprecated 12/13/2021. Closing bug as INCOMPLETE