Bypassing app lock in Ente Auth
20 Nov 2024A couple of months ago I discovered three issues that allow one to bypass app lock in Ente Auth. The issues I found aren’t technically interesting and don’t really deserve a blog post, but since Ente appears to be hesitant to notify their users about them, off we go.
Disclaimer: I’m one of the authors of Aegis Authenticator.
Some background: Aegis’ implementation of automatic lock has a somewhat annoying side effect that makes the app vanish from the recent apps screen in Android. A user recently commented that Ente Auth does not have this issue and suggested that we take some inspiration from them. I decided to take a look, but instead found myself drafting an email to security@ente.io after 10 minutes of playing around with the app.
The issues
These issues were discovered in Ente Auth 3.1.3 for Android, but may be present on other platforms as well. I used the app without signing into an Ente account.
We’re not going to dive into Ente Auth’s code to find the cause of these issues, because I don’t think it would make for interesting reading in this blog post. As you’ll realize while watching the demonstration videos below, the fact that app lock can be bypassed in this fashion tells us that it was implemented as essentially a glorified “if” statement rather than actually requiring the configured credential to decrypt the secrets used to generate OTP’s.
The security of this app lock implementation relies on the absence of bugs in the UI logic. In this case, there are three.
1. Bypassing app lock after the app was automatically locked from the app lock settings screen:
2. Downgrade from password app lock to device credential based app lock by entering the device PIN:
3. Bypassing device credential based app lock entirely:
The second and third video contain a brief flash of blackness, because Android blocks screen recording of the device credential prompt. The touch indicators give a hint of what I’m doing. In video 2 I’m entering the device PIN (not the password configured in Ente) and in video 3 I simply dismiss the prompt.
Timeline
The first two issues were fixed in 18 days. The third one was fixed in 76 days. Here’s the timeline:
2024-09-04 Report submitted via email.
2024-09-05 Ente responds: Thank you for bringing these issues to our attention. We’ll be fixing these problems in the next update.
2024-09-22 I notice that Ente Auth 4.0.0 was released which silently fixes the first two issues. I send an email where I:
- Point out that device credential based app lock can still be bypassed.
- Express that I was a little surprised to see that there’s no announcement urging users to update.
- Mention that I would have appreciated a brief mention crediting me for reporting these issues.
2024-09-25 - 2024-09-26 Some back and forth emails: The dev team is looking into the remaining issue. They explain that they currently don’t have “a credit system” for issues. I clarify that I’m not looking for a monetary reward. They don’t respond to my comment about not announcing the issue to their users.
2024-11-17 I send an email reminding them about this issue and that a little over 2 weeks are left until the 90 day mark. I also share a draft of the blog post I plan to publish on the 3rd of December.
2024-11-19 Ente Auth 4.1.0 is released with a fix for the third issue. It looks like 4.1.0 was released as a pre-release on GitHub on the 5th of November, but it had not been rolled out through all channels (such as Google Play) yet.
2024-11-20 Vishnu from Ente reaches out via email. To summarize:
- “The GitHub release did not get promoted due to human error, so the release did not get pushed to some of our distribution channels. We’ve now appointed a release manager to reduce the possibility of such errors.”
- The changelogs on GitHub have been updated to mention the security issues:
- The help articles have been updated to explain how app lock works in Ente Auth.
2024-11-20 Since all issues have been fixed, this blog post was published earlier than the 90 day mark.