Overview
Today we’re going to unpack vulnerabilities one of our researchers discovered in Kaspersky’s web portal – my.kaspersky.com. It was discovered on February 5, 2018. Kaspersky was notified on the same day and the vulnerability has since been patched.
Before being patched, the vulnerability boiled down to three key issues:
• Broken authentication and session management
• Failure to invalidate sessions
• Poor server-side validation on password changes
Combined, these issues meant the application:
• Permitted automated attacks such as brute force or credential stuffing, where the attacker has a list of valid usernames and passwords.
• Permitted default, weak, or well-known passwords, such as “Password1” or “admin/admin“.
• Used weak or ineffective credential recovery and forgotten-password processes, such as “knowledge-based answers” which cannot be made safe.
• Had missing or ineffective multi-factor authentication.
• Exposed Session IDs in the URL (e.g., URL rewriting).
• Did not rotate Session IDs after successful login.
• Did not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) weren’t properly invalidated during logout or a period of inactivity.
Impact
These vulnerabilities meant the app could be exploited in three different scenarios, either to target users directly or as a means to verify credentials for future attacks:
Scenario 1: Credential stuffing, or the use of lists of known passwords, is a common attack method. As the application did not implement automated threat or credential stuffing protections, the application could be used as a ‘password oracle’ to determine the validity of credentials.
Scenario 2: Most authentication attacks occur due to the repeated use of the same passwords. Although it was once considered best practice to enforce password rotation and complexity requirements, these are now viewed as encouraging users to reuse weak passwords. Organizations are recommended to stop these practices, as per NIST 800-63, and implement multi-factor authentication.
Scenario 3: As application session timeouts weren’t set properly, a user on a public computer could accidentally close the browser rather than logging out. An attacker could then use the same browser later, and the original user session would still be authenticated.
Reproduction
Below, are the steps our analyst took to reproduce the vulnerability on the failure to invalidate sessions on password change:
Step 1: Create an account on https://my.kaspersky.com/
Step 2: Login on a normal Chrome browser window
Step 3: Install the Kaspersky mobile APK on android mobile and login with the same email id
Step 4: Login with same id in a Chrome incognito window (we now have three logged in sessions with same email id)
Step 5: Change the password in any browser session
Step 6: Refresh the application in mobile – there is no forced logout and we’re still able to make purchases with the account logged in with the old password
Step 7: Delete the account from the incognito window session – accounts can still be deleted even though the password was changed earlier
Remediation
In our initial notification to Kaspersky, we recommended several ways in which the vulnerabilities could be patched:
1. Implement multi-factor authentication where possible in order to prevent automated credential-stuffing, brute force, and stolen credential re-use attacks.
2. Stop deployment with default credentials, particularly for admin users.
3. Implement weak-password checks, such as testing passwords against a list of the 10000 most common passwords.
4. Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines for modern, evidence-based password policies.
5. Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
6. Limit or delay failed login attempts. Log all failures and alert administrators when potential credential stuffing, brute force, or other attacks are detected.
7. Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL. They should be securely stored and invalidated after logout, idle, and absolute timeouts.
Note: While some elements of this report are currently in dispute, LMNTRIX stands by its research methodology. Our researchers discovered and produced the issues outlined above on February 5, 2018, and immediately reported them. We have since been coordinating with the subject of the research to reproduce the results, however have been unable to do so since February 10, 2018, and therefore believe the issues have been resolved.
On 2018-03-04