Guessing the PIN Code
The attacker tries to create a co-browsing connection with the agent. To do this, the attacker hopes to guess a PIN (the security number the collaboration server uses to make the connection between the visitor and the agent - by default, a six-digit number). If the attacker types the PIN before the visitor does, the collaboration server will create the co-browsing connection between the attacker and the agent.
There are a number of ways the attacker might learn the PIN:
By guessing - that is, by repeatedly connecting to the collaboration server using different PINs, until a number used by the attacker matches one used by the collaboration server.
By intercepting the PIN when it is transmitted via telephone. This can be done in various ways, for example by hacking a phone or by listening-in to the conversation.
By intercepting the PIN when it is transmitted over the network, i.e., after the visitor has typed it.
How we Prevent Attackers from Guessing the PIN
If you want to prevent any possibility of attack, you can configure the length and format of the PIN to suit your needs. For example, you can set it to include five digits, or three letters and two digits, or a mixture of eight letters and digits.
Note: In all use cases in which unblu was used to date, including e-banking and online consulting, we have not observed any way an attacker could capitalize on an attack. We recommend you use a PIN format which requires some effort to guess, but is still easy to type for visitors.
Note: The odds of correctly guessing a six-digit PIN (only numbers, no letters) is 10 to the sixth power, which equals one in one million. Given that letters are also permitted, the odds against anyone guessing the PIN run into many millions to one against such an event happening.
unblu takes the steps below to guard against such attacks:
The PINs are created using an established and trusted random-number generator, so they are as difficult to guess as possible.
Dynamic PIN generation: Once a PIN is used to make a connection, the number is discarded. An attacker cannot re-use a PIN after the visitor has used it.
The session ID of the visitor's session is independent of the PIN. If the attacker learns the PIN, they cannot use it to guess the session ID.
Once the session is established, an attacker cannot use the PIN to gain access to it.
Once a PIN is used, it is blocked for some time.
There is a limit on the number of PINs that can be blocked at one time, which means there is always a large pool of possible PINs available.
Possible Effects of a Successful Attack
If an attacker successfully guesses the PIN, the consequences are limited because of the way that unblu works. Here are the possible outcomes:
The legitimate visitor fails to initiate co-browsing, as the PIN is already used.
The agent sees the attacker's browser content. This does not represent a security risk in itself, as the attacker could just as well (and more easily) get to this point by simply initiating a regular co-browsing session.
The attacker has a co-browsing session, but cannot do anything other than that permitted during a regular browsing session. Co-browsing does not provide more access to the visitor than during normal browsing sessions.
As the agent and the visitor are still communicating via telephone, the most likely outcome is that the visitor reports that something went wrong. The agent will then re-initiate the co- browsing session. This will end the co-browsing session of the attacker. Even if the agent continues the co-browsing session for some time, this does not present a security risk.
At no point does the attacker gain access to the legitimate visitor's browser content or online account.
Caution: For some setups, guessing the PIN may introduce special security considerations. However, due to the architecture of the unblu co-browsing solution, the attacker can never access the content of the legitimate visitor, and they can never execute commands as the legitimate visitor. The only possible risk is that the agent puts some privileged information into the attacker‘s browser - which is unlikely for a number of reasons:
The agent does not have any reason for doing so.
In high-security environments, you may prefer to configure the collaboration server in such a way that agents cannot interact with the visitor's screen. In this case, it is impossible that the attacker profits from co-browsing.
We recommend that you block the agent's access to sensitive elements, such as login and password fields, and functions that execute payments. This usually happens as part of the general security precautions. See Embedded Co-Browsing - Masking And Hiding Webpage Elements.
Again, it is usually part of the standard security precautions that agents do not have access to the visitor's passwords, and are trained to be very careful when helping their visitors with log-in problems.
Can Guessing the PIN succeed in a Cloud Setup?
This type of attack is blocked in a cloud setup in the same way as in an on premises setup. However, an attacker has more access points in a cloud setup, and you cannot take as many security precautions as on your own server environment (such as blocking access from certain countries or setting alarms when login attempts fail frequently).
Related Topics
Compromising the Agent Session
Eavesdropping on the Visitor Session
- deploycloud
- deployonprem