Title:

Subdomain Password Leakage in Avast Password Manager

Report ID

SIK-2016-036

Summary:

• Vendor: AVAST Software
• Product: Avast Passwords
• Affected Version: 1.4.1
• Severity: Low
• Short summary:
  When the user stores credentials for a domain “foo.com”, these credentials will not only be filled into websites loaded from “foo.com”, but also for any subdomain “bar.foo.com”.

Details:

When the user stores credentials for a domain “foo.com”, these credentials will not only be filled into websites loaded from “foo.com”, but also for any subdomain “bar.foo.com”. This approach implicitly assumes that all subdomains of a particular domain are trusted to receive the credentials stored for the parent domain. In the case of free hosting services, for example, this might not be the case. If the user has stored credentials for administering his subdomain “my.provider.com” through an administrative interface hosted on “provider.com”, he might not trust the subdomain “attacker.provider.com” registered by another person. If the password manager automatically fills the credentials into the untrusted subdomain, they can silently be leaked when the user is tricked into visiting the untrusted subdomain, provided that his password manger is unlocked at that time.

Individual entries from the password database can be leaked if the user visits an untrusted subdomain of a parent domain for which he has stored credentials. The attack is possible remotely, provided that the attacker is able to set up such an untrusted subdomain. Note that DNS spoofing might be sufficient in many cases to create a rogue subdomain, the domain might not even need to actually exist.

Workaround

Disable automatic filling. When your password database contains credentials for a specific domain, make sure to not visit an unknown subdomain or subdomain of unknown trustworthiness of that parent domain for which the credentials are stored.

Suggested Mitigation

The password manager should not automatically fill credentials into login prompts at websites that are hosted on different subdomain. We acknowledge that there might be usability reasons for such a less-strict URI mapping, but the user should at least be warned and have a chance to prevent his credentials from being entered into untrusted subdomains.

Timeline

• 2016-11-21 Vulnerability Reported
• 2017-02-15 Still working on a solution
• 2017-05-18 Vulnerability Fixed