Roboform Vulnerability

[Vittoria Pretlow]

Thisfeature enables you to send additional notifications to the website owners or admins after the vulnerability is submitted. The total number of additional notification is limited to 10, and to 1 in 24 hours.

A recent discovery by cybersecurity researchers has exposed a critical flaw in older versions of RoboForm, specifically up to version 7.9.14, which allowed them to predict and crack a 20-character password tied to a crypto wallet. This revelation highlights the inherent dangers of using outdated password managers and underscores the necessity for robust, random algorithms in password generation. The incident serves as a stark reminder of the importance of continuous software updates and user vigilance in maintaining cybersecurity. What other implications does this flaw have for both individual users and larger organizations?

In a striking example of cybersecurity challenges, researchers cracked a 20-character RoboForm-generated password to access a crypto wallet containing 43.6 BTC. They faced significant obstacles, such as the wallet owner's inability to recall the password generation date and multiple failed attempts.

Utilizing advanced encryption techniques and analytical prowess, researchers identified patterns within the RoboForm password generation process. The breakthrough came when they discovered the correct password, generated without special characters, on May 15, 2013.

This incident underscores the necessity of robust encryption techniques and highlights potential weaknesses in password managers like RoboForm. The successful recovery not only reclaimed substantial crypto assets but also revealed critical insights into managing digital security effectively.

Researchers identified a notable flaw in RoboForm's password generator that made it possible to predict passwords based on the date and time of generation. This RoboForm vulnerability stemmed from a weakness in the pseudo-random number generator used in older versions of the software, specifically until version 7.9.14.

The flaw allowed attackers to exploit password predictability, greatly reducing the effort required to crack generated passwords. Researchers demonstrated this by successfully recovering a 20-character password to a cryptocurrency wallet. Siber Systems addressed the issue in 2015 by enhancing the randomness of the password generation process in subsequent versions.

This password vulnerability highlights the inherent risks in relying on outdated or flawed password generation methods. Effective password management demands continuous scrutiny and updates to guarantee the reliability and security of generated passwords.

Addressing ongoing security concerns, users should be wary of lingering vulnerabilities in outdated password management software. Despite security updates, many individuals may still use passwords generated by older versions of RoboForm, leaving them exposed to password vulnerabilities. Siber Systems fixed the flaw in 2015, but without notifying users to regenerate passwords, the risk persists.

Most people don't change passwords unless prompted, exacerbating the issue. This situation underscores the importance of continuous monitoring and proactive security updates. Users must make sure they're using the latest software versions to mitigate risks.

Additionally, cybersecurity experts recommend periodic password changes and adopting multi-factor authentication to enhance security. This proactive approach is essential for safeguarding sensitive information against evolving threats.

However, it is often no longer mentioned that the autofill function should be disabled or be set to fill only upon user request. Rather, this feature is more often described as a useful feature to ensure a convenient and "secure" login. Yes, it is convenient, but for loss of security.

If a user uses the default configuration or follows the password manager's recommendation, it is possible to steal the saved login credentials from 11 of the 16 tested browsers and password managers in one mouse click. So the database/password on the website doesn't have to be leaked, and the attacker still gets your data - all in readable and unencrypted form (in plaintext).

From a security point of view, this feature can be used to verify that users are not on a phishing site. If they were on it, the data would not be automatically filled in. Users might notice unusual behaviour and could check what domain they are currently on.

In addition to "verifying" the phishing site, this is more of a convenience login feature, as the user does not have to click anywhere and has everything pre-filled. However, pre-filled data is a problem because all data is in a readable form (plaintext) and can be accessed with javascript.

In these browsers, the data is filled in automatically at first view, but this is not true. The data in the form is not really filled in. It is only filled in when the user interacts with the website.

The user interaction must be of type isTrusted (=> triggered by the user) with an event such as a keystroke or mouse click. Mouseover, mousemove and similarly "simpler" events do not perform full autofill. If the content of the input is displayed without prior user interaction with the website, only a empty value will be displayed.

So the attacker must somehow trick the user into clicking somewhere on the website. In the role of the attacker, I would probably display a notification or cookie dialog. Both types of elements are displayed quite frequently on the sites, so the victim will not suspect suspicious activity.

The goal is not for the victim to click somewhere exactly, but for a click to be made. Displaying an element that makes browsing the site uncomfortable, and which requires interacting with the site to remove, is, in my opinion, a very effective way to get the required click from the user.

XSS is the most common web vulnerability. If a web page has this type of vulnerability, it is possible to inject javascript code into the page. The injected code will then perform an action defined by the attacker, such as stealing login credentials.

There are several ways to steal user login credentials using XSS. Someone could think of capturing the values entered to the login form or changing form action value (=address where the data will be sent). Then I have a few questions:

I'm not a fan of complicated interactions from the victim. If I want more than 2 normal mouse clicks from a user, I'm requesting too much and I'm thinking of a different solution. Among other things, if I ask the user to log in again (re-enter credentials), at that point it's primarily based on social engineering.

My approach would be to abuse the autofill feature that password managers have. If I know about the XSS vulnerability, I will use javascript to create a new login form that will be completely hidden to the user. The password manager will detect the presence of this form and will auto-fill the data into it. So the goal would be to take advantage of a misconfiguration in the password manager in use.

As part of the analysis, I focused on the most used browsers and password managers. For password managers, only browser extensions were tested and everything was verified in the desktop-only version (especially Google Chrome). So on mobile phones the behaviour may be completely different.

Mozilla Firefox and Internet Explorer fill in passwords automatically. Google Chrome and "chromium-based" browsers (with the exception of Brave) only fill in passwords when you interact with the site. In total, it is possible to get the password within one mouse click for 6 browsers.As for password managers, 3 of them have autofill enabled by default. With the Keeper password manager, the user confirms the dialog before using the stored credentials for the first time. The user is asked if he want to enable autofill for a specific domain. It's worrying that the YES option is highlighted. Once the dialog is confirmed, the user is not asked again in the future and the data is filled in completely automatically.

With autofill password managers, the data is filled in without interaction with the site, i.e. completely automatically and without user assistance. If I count Keeper and the currently vulnerable KeePassXC-Browser, it is possible to get the stored password for 5 password managers in one click.The behaviour of the autofill depends on the password manager you are using. For a user using only Brave browser for their passwords, the autofill would not happen. If the user had Brave only as a browser, and was using, for example, LastPass as their primary password manager, at that point the behavior of the browser is affected by the password manager. So, if the LastPass manager is installed, the Brave browser would also automatically fill in the data.

In case of an attack, the most important information is how the password manager behaves when the form is displayed on another URL, and also on the subdomain. Name, input ID or other attributes can be changed by the attacker when creating a new form.

There may be users who want to switch from a browser-based password manager to another, but with the same behaviour. That is, when using a different password manager, the data will be automatically filled in as they have been used to. So they decide to enable this feature in the settings.

Of the remaining password managers, it is not possible to set up autofill for 1Password, Brave or Safari. For the other Bitwarden, KeePassXC-Browser and Roboform it is possible. If this feature is only enabled (no other changes), none of the managers require additional action from the user - the data is filled in completely automatically.

3a8082e126