keepass2android
keepass2android copied to clipboard
PhilippC
AutoSpill vulnerability in Keepass2Android
Checks
- [X] I have read the FAQ section, searched the open issues, and still think this is a new bug.
Describe the bug you encountered:
A recent presentation at Black Hat discusses a new vulnerability that affects password managers on Android when using WebView autofill. This vulnerability reportedly also affects Keepass2Android. More details can be found in the article below:
Vulns in Android WebView, Password Managers Can Leak User Credentials https://www.darkreading.com/cyberattacks-data-breaches/android-vulnerability-leaks-credentials-from-password-managers-
Describe what you expected to happen:
No response
What version of Keepass2Android are you using?
1.09e-r7
Which version of Android are you on?
13
Very concerning.
My understanding is that for this to happen you need a malicious app installed on the user's device that runs in the background and detects the presence of the WebView component displaying the login form. The malicious app then triggers WebView to display a fake login page that overlays the legitimate login form. This fake page perfectly mimics the look and feel of the legitimate login form, including the logo, branding, and text fields. Due to the overlay, the password manager, not being aware of the fake overlay, automatically fills in the credentials on the fake login page displayed within WebView.
I'm not a developer, but it looks to me this is an Android bug and the Android should prevent it from happening.
While it's correct that this is mainly an Android issue, there are mitigations that can be taken by app developers to address the issue on the password manager side. The folks at 1password apparently already have a fix planned for this issue.
I'm not a developer either, so I don't know how easy or complex it would be to implement something similar here (if at all possible). Hopefully someone more knowledgeable can shed some light on the issue.
I have today received the paper by the authors publishing this attack and will investigate it.
A possible secure workaround would also be helpful (perhaps simply deactivating the autofill service) if I could continue to use the app for the time being, albeit with a loss of convenience.
The paper does not provide enough information IMO. I asked the authors for their apk (in source code or binary) to demonstrate the issue, but haven't received it for 2 weeks. Does anybody know if their app to test the exploit is available anywhere?
I don't think the paper is even publicly available yet, let alone the apks used for testing. The only first-hand resource I can find online as of now is the presentation on the Black Hat site. What's interesting is that 1password does have enough information to come up with a solution (as per multiple statements). Maybe the researchers have more information to share?
Also, if you are able, would it be possible to share the paper? I'd love to take a look at the findings.
I have requested the paper on https://www.researchgate.net/publication/370223676_AutoSpill_Credential_Leakage_from_Mobile_Password_Managers. I'm sure they will share with you as well. And maybe it helps if you ask for the testing app as well?
Arstechnica published an article https://arstechnica.com/security/2023/12/how-worried-should-we-be-about-the-autospill-credential-leak-in-android-password-managers/ which also provides a Google Drive link to the original paper.
I also have not seen the proof from the original authors, however, some other vendor published a testing tool here https://github.com/heylogin/android_autospill_tester
Maybe this can be used to implement mechanisms (such as detecting two password fields) which would avoid or at at least reduce probability for "AutoSpill".
@strauss115 thanks a lot for sharing that testing tool! I installed it and it does show that it is possible that KP2A will fill the username field of the host app with credentials for the website which is not good. However, this only happens after the app clearly warns about Asset verification link failure. This was not mentioned by the paper's authors, so I'm not 100% sure if that tester does exactly what they were doing, but it's certainly a good starting point.
I also don't find a way of inserting credentials stored for the app into the webview inputs.
If anybody of you can find others vulnerabilities, please let me know here. (Might depend on Android version etc.)
Arstechnica published an article https://arstechnica.com/security/2023/12/how-worried-should-we-be-about-the-autospill-credential-leak-in-android-password-managers/ which also provides a Google Drive link to the original paper.
I've seen and read this article, but completely missed the Google Drive link in there. Thanks for pointing it out.
I also have not seen the proof from the original authors, however, some other vendor published a testing tool here https://github.com/heylogin/android_autospill_tester
Nice! Hopefully this'll help investigate this further.
I got the same behaviour as you described @PhilippC on Android 13. The attack vector (i.e. scenario "more serious" called "S" where credentials intended for the hosted webpage "HW" should be inaccessible to the hosting app "HA") is the same. But you are right, it seems that the authors used a more sophistacated approach (which might depend on the Android version as they just tested it up to Android 12).
One difference I found is that it seems the authors managed to create an Autofill Request where "WebDomain" is everywhere "null" which I guess would bypass the Asset verification mechanism. The footnote says they created one RootView with two NativeViews and one WebView for that - that's different compared to the Autospill tester.
Only mitigation (if it is really necessary) IMO at the moment would be to disallow auto filling of more than one password field i.e. if there are more than one password fields Keepass2Android would not autofill any password. But I am not sure if it is really a good idea - it would break the "password retype" use-case.
Just one thing I encountered - when confirming the Asset verification (not consenting to a permanent exception) I only got the warning once. Even after a complete restart. Only after clearing Keepass2Android's app data I got the warning again. Did I miss something here?
We could reach out to 1password to see if they can offer some insights into how they are tackling things. I suspect @strauss115 is right about mitigation, though. 1password, and the other products have a mutual interest in fixing this, so I don't see any harm in asking to see if they have any thoughts - worst case, we get a "no thanks".
@PhilippC Let me see if I can get in touch with someone at 1password and get some contact information. Give me a few days to track this down.
Is there any further development or perspective on this matter? I would also appreciate a temporary workaround.
I still don't know how to reproduce. @CiaoAnkit, you are the author of that paper, can you please comment here to help us reproduce the vulnerability you reported?
I have two questions in this context:
- Could it be helpful to involve someone like c't, for example, to get the necessary information to understand the vulnerability exactly? c't reported on this here (https://www.heise.de/news/Black-Hat-Europe-2023-Neuer-Angriff-AutoSpill-auf-Android-Passwortmanager-9569772.html).
- Can you currently assess whether it would be a safe temporary solution to deactivate certain app settings (e.g. "AutoFill service" for password access, "AutoFill" for the keyboard, ...)?
I still don't know how to reproduce. @CiaoAnkit, you are the author of that paper, can you please comment here to help us reproduce the vulnerability you reported?
Hi, all the details (causes/remedies) about AutoSpill is mentioned in our paper "https://dl.acm.org/doi/abs/10.1145/3577923.3583658." Moreover, I can share a PoC video demo for more clarity (please send me an email or tell me your email).
thanks for getting back @CiaoAnkit! I guess that is the paper you shared on Research Gate, right? I wasn't able to reproduce it from there, but maybe the demo video helps! Can you share it here or by mail to [email protected]? I'm sure you have created a demo app to test this. If you could share this, it would be even better!
thanks for getting back @CiaoAnkit! I guess that is the paper you shared on Research Gate, right? I wasn't able to reproduce it from there, but maybe the demo video helps! Can you share it here or by mail to [email protected]? I'm sure you have created a demo app to test this. If you could share this, it would be even better!
Yes, that paper was my local copy. Sent you the video demo and some comments via email. Thanks.
Hi, after one month I ask again: Are there any new insights, developments, plans, perspectives, recommendations...?
unfortunately the video did not help me to reproduce the issue. Unless there is an app demonstrating the exploit, I don't know how to continue here.
What a pity! And now what? Since the problem arose, I've only been able to use the app in a very rudimentary way. Very occasionally to look up access data, which I hope is not critical.
What I would have liked to have seen and what has not been commented on so far, for whatever reason, is:
- What workarounds are there that still allow the app to be used safely, albeit with restrictions?
- Are there any new assessments of the risk of this problem?
I am also wondering:
- How have the other affected app providers dealt with the issue and is there not possibly a chance for direct or indirect exchange or cooperation to come to a reasonably satisfactory solution in this matter after all?
- Don't the people who discovered the security problem have a proposed solution?
For me, it is not a solution to simply ignore what I see as an unresolved problem.
Does this vulnerability affect other passwords in the database from entries which were not selected by the user for autofill?
I've been reading up on this as new developments occur, and came across this (source):
This is a well-known attack called an AutoSpill exploit(new window). In 2023, many password managers were confirmed to have been compromised using this exact exploit, including 1Password, LastPass, Enpass, Keeper, and Keepass2Android. It’s a vulnerability that many password managers simply didn’t have a rigorous enough autofill policy to combat.
But it’s actually incredibly easy to avoid. All you need to do is turn on manual autofill.
Your password manager will always run background checks, examining the domain and verifying that no phishing elements are present. But using manual autofill creates an extra layer of security because it gives you a chance to check that you’re on the right website.
As far as I am aware, manual autofill is the default for Keepass2Android. This would mean that this issue is mitigated by default, assuming the quoted above and my assumption are correct. @PhilippC What's your take?