How worried should we be about the “AutoSpill” credential leak in Android password managers?

This newly discovered vulnerability is real, but it’s more nuanced than that.

By now, you’ve probably heard about a vulnerability named AutoSpill, which can leak credentials from any of the seven leading password managers for Android. The threat it poses is real, but it’s also more limited and easier to contain than much of the coverage to date has recognized.

This FAQ dives into the many nuances that make AutoSpill hard for most people (yours truly included) to understand. This post wouldn’t have been possible without invaluable assistance from Alesandro Ortiz, a researcher who discovered a similar Android vulnerability in 2020.

Q: What is AutoSpill?

A: While much of the press coverage of AutoSpill has described it as an attack, it’s more helpful to view it as a set of unsafe behaviors that can occur inside the Android operating system when a credential stored in a password manager is autofilled into an app installed on the device. This unsafe behavior exposes the credentials being autofilled to the third-party app, which can be just about any kind of app as long as it accepts credentials for logging the user into an account.

Password managers affected in one way or another include 1Password, LastPass, Enpass, Keepass2Android, and Keeper. Other password managers may also be affected since the researchers who identified AutoSpill limited their query to only seven titles. Both Google Smart Lock and Dashlane are vulnerable to a similar attack involving JavaScript injection that are discussed later.)

AutoSpill was identified by researchers Ankit Gangwal, Shubham Singh, and Abhijeet Srivastava of the International Institute of Information Technology at Hyderabad in India. They presented their findings last week at the Black Hat security conference in London.

Q: If the third-party app allows or requires a user to log into an account, why is it a problem for the password to be autofilled from a password manager?

A: It’s only a problem in certain scenarios. One is when the third-party app allows users to log in to one account using credentials for a different account. For instance, hundreds of apps and sites use a standard known as OAuth to offer users the convenience of logging in to their accounts by using the credentials for their accounts on sites such as Google, Facebook, or Apple. A chief selling point of these arrangements, known as access delegation, is that the third-party app or service never sees the credentials. AutoSpill has the potential to violate this fundamental guarantee.

Another way a malicious app could exploit AutoSpill would be by loading WebView content from a site of a bank or another service the user has an account with. When the malicious app loads the login page of the trusted site, the user will be prompted to select credentials. If the user approves the autofill prompt, the credentials will be populated not only into the WebView portion of the malicious app but also the app’s native view (more about the difference between WebView and native view properties in a moment). And depending on the password manager in use, this flow may occur without warning.

It’s hard to envision a realistic pretense the malicious app could use to trick a user into logging in to a third-party account not managed by the app developer, and the AutoSpill researchers didn’t offer any. One possibility might be a malicious version of an app that transfers song playlists from one music service to another. Legitimate apps, such as FreeYourMusic or Soundiiz, provide a valuable service by analyzing a playlist stored in the account of one service, such as Apple Music, and then creating an identical playlist for an account on a different service, such as Tidal. To work as desired, these apps require the credentials of both accounts.

Another way a malicious app might exploit AutoSpill is by injecting JavaScript into the WebView content that copies the credentials and sends them to the attacker. These types of attacks have been previously known and work in settings that go well beyond those presented by AutoSpill.

What hasn’t been clear from some of the coverage of AutoSpill is that it poses a threat only in these limited scenarios, and even then, it exposes only a single login credential, specifically the one being autofilled. AutoSpill doesn’t pose a threat when a password manager autofills a password for an account managed by the developer or service responsible for the third-party app—for instance, when autofilling Gmail credentials into Google’s official Gmail app, or Facebook credentials into Facebook’s official Android app.

Q: How, and in what scenarios, does the exposure of these passwords pose a threat?

A: As already indicated, the biggest threat stems from the possibility that someone could develop a third-party app that intentionally exploits the unsafe behavior. While there are no known instances of apps exploiting the AutoSpill behaviors, Android apps that use JavaScript injection to steal passwords are a semi-routine occurrence. It wouldn’t be surprising to see apps target this newly discovered attack surface as well.

Even without a malicious third-party app, AutoSpill is still problematic. The exposure is a violation of fundamental best practices and of assurances provided by Android Autofill, the OS component that acts as an intermediary between password managers and third-party apps installed on a device. Exposure of the credentials to the third-party app, even when it’s not malicious, runs the risk that they might be logged somewhere and eventually accessed by a malicious party. (A Google representative disagreed, writing in an email “By definition, when a user autofills anything into an app, the information from the password manager is transferred to the app. There’s no violation of any ‘fundamental best practice.’”

Q: Is there a security patch available?

A: The researchers who identified AutoSpill say that Google and the maker of each affected password manager are equally responsible for the vulnerability. So far, Google has not indicated that it will change the behavior of the Android autofill engine. Some makers of password managers—among them 1Password and Dashlane—say they have either issued fixes or plan to do so. Others have indicated that they have no such plans.

Q: So what are Android users to do?

A: Whatever you do, don’t stop using a password manager if it means reverting to less secure practices, such as reusing credentials or storing them in plain text files. Based on the limitations of the threat, a move like that would introduce more, not less, risk.

The most constructive defense is to be highly selective in choosing which apps get installed. This practice has long made sense for users of any platform but has historically taken on even greater importance for those using Android, given the chronic inability of Google to keep malicious apps out of Google Play. Users should be doubly suspicious of any app that requires passwords for important accounts not actively managed or provided by the app developer. Manually copying credentials from a password manager and pasting them into an app will prevent AutoSpill attacks that don’t use JavaScript injection. This approach comes with its own risks, since it saves passwords to the OS clipboard, a rich attack surface that has been targeted previously.

Aside from that, Android users should stay abreast of any security guidance issued by either Google or the developer of their chosen password manager. So far, none of these players has published advisories related to AutoSpill and how it affects users in specific use cases.

Q: What’s the root cause of AutoSpill?

A: The answer is complicated and in dispute, with Google suggesting it’s the result of password manager developers failing to follow practices laid out here and password manager developers saying the vulnerability is the fault of Android design decisions. The researchers who identified AutoSpill, meanwhile, say the vulnerability is the result of the interplay among three components: the password manager, the app that received the autofilled credentials, and the autofill engine in Android, which acts as an intermediary between the two.

To expand a little more, developers often use an Android component known as WebView to display web content inside their apps. WebView allows an app to behave as a special-purpose browser that renders only the functions needed to provide the service at hand. Some of the functions are supplied from an online site through WebView, while other functions are supplied natively by the app.

AutoSpill stems from the misalignment that exists among the password manager, the third-party app, and Android autofill engine about whether functions supplied by WebView or the native app should be responsible for securely populating the credentials during the autofill process. As a result, the credentials are handled by both.

In a paper the researchers published ahead of their Black Hat presentation, they made two observations and went on to explain how they lead to “confusion” among the password manager, app, and Android Autofill component:

(1) Android always processes and renders NativeView data to autofill service. For an autofill request triggered from a WebView, AssistStructure should only contain data related to WebView. The unwanted presence of NativeView data creates confusion for the autofill service, which wants to autofill all the related fields for user’s convenience.
(2) Autofill service traverses the entire AssistStructure—as an obligation—to identify all the input fields that are related to the autofill triggering field. A blind traversal of AssistStructure without keeping a track of the parent view’s WebDomain leads to identification of incorrect target input fields.

Based on these findings, we argue that both the Android system and [password managers] are equally responsible for credential AutoSpill from [the Web content hosted online to the third-party app.]

The paper, available here, provides a more technical explanation of the root causes.

Q: What are affected parties saying about AutoSpill?

A: Google:

WebView is used in a variety of ways by Android developers, which include hosting login pages for their own services in their apps. This issue is related to how password managers leverage the autofill APIs when interacting with WebViews. We recommend third-party password managers be sensitive as to where passwords are being inputted, and we have WebView best practices that we recommend all password managers implement. Android provides password managers with the required context to distinguish between native views and WebViews, as well as whether the WebView being loaded is not related to the hosting app. For example, when using the Google Password Manager for autofill on Android, users are warned if they are entering a password for a domain Google determines may not be owned by the hosting app, and the password is only filled in on the proper field. Google implements server-side protections for logins via WebView.

Users should always be mindful of the security of the apps they are using and ensure they use password managers that implement security best practices. Users should also leverage the security protections that Android provides by default, such as Google Play Protect on devices with Google Play Services.

1Password Chief Product Officer Steve Won:

tt would be great for Google to implement changes in Android to provide more specific filling pathways. To continue to enhance our security in the meantime, 1Password will rewrite the filling logic to prevent native fields from being filled with credentials intended for Android Webview.

Candidly, there are simpler and more effective ways for attackers to steal credentials than what’s described here. This attack vector requires a pretty significant hoop to jump through, which is installing an untrusted, malformed app.

The scenario here requires that:

1. A user installs a malformed/malicious application
   1. This application will have had to either:
      1. Bypass Google Play’s malware scanners
      2. Be side-loaded by the user
2. The user then choose to share credentials with that malformed application

LastPass Director of Threat Intelligence, Mitigation, and Escalation Alex Cox:

Listing image: Getty Images

55 Comments