Back

Targeting RSA Emergency Access Tokencodes for Fun and Profit

SecurID Emergency Access Tokencodes

A few months ago, one of my RSA soft token was on the fritz. It refused to work, and I was not able to remote into the client’s network to do an internal project for them. In fiddling with the RSA self-service console, and playing around with the troubleshooting section, I came across this feature called the Emergency Access Tokencode.

Hmmm I wonder what that is?

The Emergency Access Tokencode (EAT), is a backup code that is randomly generated on the RSA server that works for a set period, typically a week or so. Awesome, I didn’t need my soft token anymore, and I’m on the client network legitimately.

A few weeks later I was on an internal assessment for a PCI internal pen test. The CDE was isolated from the user and server networks via a Jump Host that used, you guessed it, RSA SecureID tokens for a second form of authentication. This is how I used the self-service console to get a legitimate token to bypass the 2FA.

RSA Self-Service Consoles have the option to integrate with LDAP for authentication. I have seen this commonly implemented, despite the potential pitfalls. After compromising a user’s account who had access to the CDE, I was able to log into the RSA console using their Active Directory username and password.

Once inside the console, navigate to the troubleshooting page.

And select the option, “Token is temporarily unavailable or misplaced”

At this point, an Emergency Access Tokencode was issued that was valid for a week.

In this instance, the user was not using a pin with the token, which allowed for direct access. However, this is not always the case though. In instances where there is a pin set, a work around is possible. Within the RSA console, there is a Change PIN field.

Normally a change pin field wouldn’t be particularly interesting, however there are a couple abnormalities to it.

  • The PIN is a finite length
  • The PIN is all numbers
  • The change PIN field is not governed by the standard lockout policy

What does this add up to?

This field is in most instances bruteforceable, and you’re basically guaranteed to get the PIN. The longer the PIN, the more time it takes to brute force. However, if human nature holds true, most of the time users will make a pin that is the minimum length of 4 or 6 character, both of which can be brute forced in a few minutes.

Using Burp Suite’s Intruder Attack, with the Battering ram attack type, we can discover what the current PIN is without changing it.

By sorting attack responses for length, we can find the anomaly, which is from a different error.

Now that we have our backup token and PIN we can now log into any SecureID protected system.

In instances where the Self-Service Console is not integrated into LDAP, and we also were not able to retrieved the saved password from a browser, we still have a one more card to play before we need to move onto social engineering.

Going back to the login page we can see a “Troubleshoot SecureID token” link.

If we follow the link we find a input for a username.

Now, fortunately to avoid a username enumeration vulnerability, RSA returns a question for every username enter, regardless if it is valid.

By default there are three Security Questions, so if you can’t discover the name of their sixth grade teacher, perhaps you can find the name of their maternal grandmother’s first name.

However, with some clever research, we can sometimes find the answer to the user’s security question. If we get the question correct we are then brought to this familiar page.

Where, we can again be issued an Emergency Access Tokencode.

One problem that I have consistently run into, is discovering RSA servers, as they do not seem to register an SPN, nor are they consistently registered in DNS. However, they do often run on the default port of 7004, of which very little else run on as well.

… and Shodan seems to agree.

Additionally, RSA consoles have the default title “Self-Service Console – Home”, which is also searchable.

Placing the RSA console outside the security boundary they are attempting to harden has always been a risky idea. Exposing it to the internet wasn’t a good idea before, it’s an even worse one now.

So about that two factor VPN…

Back

Application Self Protection – A New Addition to the OWASP Top 10

OWASP has just released their release candidate of the Top 10 most critical web application security risks. While no major changes were included, i.e. Injection is still number one in the list, they added two new ones:

  1. A7 – Insufficient Attack Protection
  2. A10 – Under protected APIs

This blog discusses the first.

A7 – Insufficient Attack Protection

OWASP stated the reason for the addition as being:

For years, we’ve considered adding insufficient defenses against automated attacks. Based on the data call, we see that the majority of applications and APIs lack basic capabilities to detect, prevent, and respond to both manual and automated attacks. Application and API owners also need to be able to deploy patches quickly to protect against attacks.

An application must protect itself against attacks not just from invalid input, but also involved detecting and blocking attempts to exploit the security vulnerabilities. The application must try to detect and prevent them, log these attempts and respond to them.

What are some examples of attacks that should be handled?

  • Brute force attacks to guess user credentials
  • Flooding user’s email accounts using email forms in the application
  • Attempting to determined valid credit card numbers from stolen cards
  • Denial of service by flooding the application with many requests
  • XSS or SQL Injection attacks by automated tools

A more complete list can here found here but the ways in which they are handled are all very similar.

Prevention

The first step is to prevent these types of attacks.

Consider using some built-in steps for preventing attacks to the application. This includes:

  • Remove or limit the values of the data accessed using the application; can it be changed, masked or removed?
  • Create use (abuse) cases that simulate automated web attacks.
  • Identify and restrict automated attacks by identifying automation techniques to determine is the requests are being made by a human or by an automated tool.
  • Make sure the user is authenticated and authorized to use the application.
  • Consider using CAPTCHA when high value functions are being performed.
  • Set limits on how many transaction can be performed over a specified time; consider doing this by user or groups of users, devices or IP address.
  • Consider the use of web application firewalls that detect these types of attacks. Another alternative is using OWASP AppSensor or similar; it is built into the application to detect these types of attacks.
  • Build conditions into your terms and conditions; require the user not to use automated tools when using the application.

Other items to consider to use include:

  • Networks firewalls
  • Load balancers
  • Anti-DDoS systems
  • Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
  • Data Loss Prevention

Detection

An application must determine if activity is an attack or just suspicious.  The response must be appropriate based on which of these is true.

  • Could the user have made a mistake when entering the data?
  • Is the process being followed for the application or is the user trying to jump past steps in the process?
  • Does the user need a special tool or knowledge?

If any two of the above items are true, then it is most likely an attack and not suspicious activity.

Is it possible that the requests are coming in at a very high rate? A typical user may make one request every couple of seconds, whereas a tool such as Burp Suite Pro or WebInspect may make many more requests per second. The application should also detect these types of attack or attempts to find vulnerabilities in the application.

Response

The application can handle detected attacks or even the suspicion of attacks in a variety of ways.

The first should be a warning to the user. This will deter a normal user that their activities are being monitored. It would also warn a malicious user that certain events are being monitored, though it will probably not deter the latter person.

The application could, based on further activity after the warning, either logout the user or lockout the user. If a logout is performed, automated tools can be programed to automatically re-authenticate the user. If lockout is chosen, then all activity will stop.

In any of the above cases, a legitimate user may end up calling the help desk, so the application must log this type of activity and notify the application’s administrators. The log must be reviewed to determine if the response was appropriate.

Choosing which action to perform would depend on the sensitivity of the data within the application. A public website must be more forgiving to prevent overreaction to suspicious activities; whereas an application with highly sensitive data must respond quickly to suspicious activity.

Conclusion

The OWASP Top 10 2017 A7 – Insufficient Attack Protection requires the application to prevent, detect, and respond to attacks. This could affect other regulations such as PCI, which base their standards on the OWASP Top 10.

References