Title:

Broken Secure Communication Implementation in Avast Password Manager

Report ID

SIK-2016-037

Summary:

• Vendor: AVAST Software
• Product: Avast Passwords
• Affected Version: 1.4.1
• Severity: Low
• Short summary:
  The Avast password manager communicates with the backend using insecure http connections. For securing the communication, the provides its own cryptographic protocol. This protocol, however, contains serious weaknesses that allow an attacker to decrypt the transmitted data.

Details:

The transmitted data consists of the AES-encrypted ciphertext concatenated with an HMAC for integrity protection. The same key is used for the encryption and the MAC which is generally considered bad style. We are not aware of any interactions between AES and HMAC/SHA-1, but the risk can be reduced by using one key only for one purpose.
The key is derived from the current time, which is obtained through a call to Systen.currentTimeMillis(). Consequently, an attacker who knows the time at which the key was generated with a millisecond-granularity is able to construct the same key. This allows a purely passive attacker (eavesdropper) to not only decrypt all transmitted data, but a man-in-the-middle attacker can forge the MAC to inject spurious client requests and server responses. Since MACs are based on symmetric crypto, there is no secret that only the server can know, and if the key is not secure exchanged between the client and the server, a man-in-the-middle attacker can forge messages without being detectable. The time at which the key was derived can be approximated from the time at which the request was seen on the network or from the http protocol headers. The attacker only needs to try one key per possible millisecond at which the key derivation has happened. This effort is negligible. Even if the attacker is unsure about the time frame of a complete second (which is already a very weak attacker model), how would only need to try 1,000 keys.

Weak cryptography for client/server communication allows the attacker to decrypt all data exchanged between the client and the server. This includes the user’s credentials for his Avast account. The attacker can then use this data to log into the Avast website or another instance of the password manager. Furthermore, a man-in-the-middle attacker can also spoof requests from the client to the server and responses sent back by the server.
Additional investigations are required to check whether the ability to decrypt and forge data is sufficient to complete the activation of a rogue instance of the password manager. Since the attacker already has the user’s credentials for his Avast account through the decryption vulnerability, one would need to further investigate the protocol used for activating new devices. We assume that, given the complete breakdown of protocol security, the respective requests and responses can be faked or at least replayed once a successful activation for some other device has been observed. If this is indeed the case, the attacker can obtain a complete copy of the user’s password database.

Workaround

Do not use the synchronization feature. Do not log into your Avast account using the password manager.

Suggested Mitigation

When exchanging security-sensitive information between an app and the backend, known and tested standards such as TLS should be applied instead of custom-built (and likely faulty) cryptographic solutions. Use https connections for all requests that contain credentials, password database entries, or any other kind of data that must be protected from eavesdropping and/or tampering.
 

Timeline

• 2016-11-21 Vulnerability Reported
• 2016-12-05 Vulnerability Fixed