Password Managers using Android Oreo’s Autofill API are Potentially Vulnerable to Data Leakage
Autofill is one of the biggest, and most publicized new features introduced with the release of Android 8.0 Oreo. Many different password managing apps, like LastPass, have already implemented this new API into their applications. And while it can prove to be quite the improvement over the previous Autofill implementations using Accessibility Services, there’s a potential security flaw to consider. Last month, a white paper was published to GitHub, documenting an inherent flaw in the Android Oreo Autofill API that could potentially lead to your password manager leaking more of your personal data than you gave it permission for. We’re going to do a quick rundown of the white paper written by Mark Murphy (better known as CommonsWare) and published on his GitHub page on August 8th, 2017.
Potential Data Leak Flaw in Android Oreo’s Autofill API
How does the flaw work?
The autofill implementation in Android Nougat (and lower versions), and browsers like Google Chrome, is something really simple. Usually, password management apps would use the Accessibility Services to scan the screen contents for a login box and recommend autofill data based on what it finds. While it worked, it could cause considerable lag.
On Android Oreo, this works a bit differently, as password apps are now officially supported with the Autofill API. Third party password applications do not require Accessibility Services anymore, as they can now fill the role of an autofill service, communicating with apps through the Autofill Framework. When the user focuses in a widget, the system will package some info about that widget/form and send it over to the autofill app. The application then returns relevant autofill data such as passwords, emails, credit cards, or any other kind of sensitive data. The Android system acts as an intermediary between the application storing the data and the one requesting for it.
However, malicious apps or malware can actually take advantage of the autofill feature to get more data for themselves. A malicious activity can request additional autofill data to be input with an invisible or hidden widget. While the user is agreeing to fill one of the visible widgets, like a login form or something similar, the invisible widget also gets additional data without you seeing it. This can be really dangerous if that leaked information is your password, address, or credit card details!
The screenshots above showcase a malicious test application taking advantage of this security flaw.
Google’s Answer to the Problem
According to CommonsWare, this security issue does not yet have a public solution posted by Google. However, we do know that Google is aware of the issue. CommonsWare states that Google engineers acknowledged that the issue exists in a private issue tracker report, but that it would be difficult (if not impossible) to actually patch it or roll out a fix.
But that doesn’t mean Autofill is completely unsafe to use, as Google is taking another approach to ensuring data safety. The company is pushing to have autofill services handle the issue on their end and as such, is trying to raise awareness for developers to improve their autofill providers and make them safer. What is being proposed exactly?
First of all, autofill providers should partition their data. Instead of keeping all autofill data into a single pool, developers should split up the user data stored in partitions. For example, an address/phone partition, a credit card partition, a password/username partition, etc. The autofill service should only hand back the data of one partition at a time based on the focused widget. This is one of the publicly available pages on Autofill apps protecting themselves from leaking data to invisible widgets.
There are also some other things developers of password managers should do, according to Google engineers. For example, the autofill provider should only hand back the data to the specific app that supplied it in the first place. This should be done by verifying the package name and the public signature of the application so that even a modified APK can’t access it. The other thing would be that autofill apps require authentication before actually providing the data, with that authentication activity informing the user what kind of data will be provided to the app requesting it. This advice actually has many mistakes, the most important one being that these bits of advice are not actually enforced by Google.
Keep in mind that many of the above proposals were taken from CommonsWare’s private issue tracker report, and not from any official Google documentation page. For a further, more technical breakdown of how apps that use the Autofill API can protect themselves from this kind of attack, we strongly recommend you read the full white paper by CommonsWare.
What apps are safe from this flaw?
We have reached out to the developers of 1Password, Enpass, and LastPass about this vulnerability, and have since confirmed that these 3 apps are secure.
As we can see in the statements above, 1Password requires authentication from the user before filling the data, also notifying them of what data will be filled in beforehand. This also helps with the silent filling issue, since an authentication popup will appear for each and every activity asking for autofill data.
Enpass will never reveal the whole keychain to the requesting app, whether malicious or genuine. Only the saved items matching the package name of the requesting app will be presented to the user. They also confirmed that they will have more measures in place following Google’s advice.
Furthermore, LastPass confirmed to us that, while they didn’t know about the issue prior to the Android Oreo release, their app does use data partitioning to protect users, along with other checks to make sure that LastPass only fills into the app associated with the entry.
While there should be absolutely no issues using these 3 applications, if you want to stay completely in the clear, you should disable autofill completely on your phone until you can confirm with your password manager developer that their app is safe from this line of attack. Luckily this can be done easily by going to Settings > System > Languages & input > Advanced and finding the “Autofill service” preference, tapping on it and selecting “None”.
As we said above, it’s not known whether Google can actually push out a fix for this, so using trusted apps or simply disabling the feature is the only way you can stay safe. If you want to read more on this issue and all the details associated with it, you should read up on the original white paper documenting it on GitHub.