Monthly Archives: July 2016

How Serious is Username Enumeration

Looking through Twitter recently, I caught a very interesting stream that started with the following message:

There were quite a few replies, and a good discussion on the topic of the seriousness of username enumeration flaws. 140 characters is difficult to share a lot of thoughts, so I thought this would actually be a great post.

What is Username Enumeration?

Username Enumeration refers to the ability to determine not only if a username is valid within a specific application, but also to automate the process of identifying a multiple valid usernames. The most common example of username harvesting is on the application logon form. The culprit, the unsuccessful login error message. This happens because the application creators want to be helpful and let the user know what went wrong. When the message is not generic, for example “unsuccessful login”, it may indicate if the user exists or not. An example message would be “Username does not exist”. This is bad. A better response would be “Username or password are incorrect”. This is a much more generic answer and doesn’t give away whether or not the username is valid.

Where do we find Username Enumeration?

As I mentioned above, the login screen is one of the most common locations we find username harvesting. However, it is not the only place. Probably the two next biggest offenders are the Forgot Password screen and the User Registration screen. With all three of these screens, it is critical to realize that the display message is not the only way to detect username harvesting. In reality, it is any difference that comes back between an invalid and a valid user. This could be the error message, a status code that is different, timing attacks, or a myriad of other techniques. Don’t just think about the error message. That one is typically the easiest, but not the only method for identification. API calls may also be a source for username harvesting.

The Login Form

The login form is typically vulnerable through the error message. To help protect the login form, make sure that the application returns a generic error message for any error situation. A good example of this is “Your login attempt was unsuccessful. If you continue to have trouble, contact support.” This message is good for invalid username, invalid password, and even account lockout.

The Forgot Password Form

The forgot password screen is usually vulnerable due to poor forget password design. Most systems ask for the username/email address and if correct, do one of the following: 1) Ask for secret security questions, 2) Display a message that an email has been sent to the email address on record. Unfortunately, for an incorrect username, the system returns an error message that the username was not found. To correct this problem, it is possible to either ask for more than just the username (something that is private to the account), or just always display the “email has been sent” message. In this configuration, no matter what, the email is sent form is displayed.

The Registration Form

The registration screen is a bit more tricky because, in most situations, you need to be able to alert the user that their username is already in use. Unlike the other two scenarios, the error message can’t really be fixed. One option on a registration screen is to enable the use of a CAPTCHA to attempt preventing automation attacks. If implemented properly the attacker would be slowed down in their enumeration making things more difficult. It may not make it impossible, but the goal is to reduce the risk.

How is Username Enumeration Used?

There are a few ways that username enumeration becomes important to an attacker. First, it is a good technique to limit down the list of possible usernames to attempt password attacks on. One example on twitter gave the example of taking a list of 100 million usernames and reducing it to 100 thousand to perform actual password guessing on. In this scenario, the attackers are also attempting to take advantage of weak password complexity, or just bad password hygiene. Often times, they may take the top 3 or 4 common passwords and try those against all of the valid usernames to see if anyone is using them.

The second way that username enumeration is used is for social engineering attacks. Or, at least, more targeted social engineering attacks. If the attacker knows that the user has an account on a specific application, it can make phone calls and emails much more convincing and ultimately more successful. Limiting emails to 100,000 users rather than 100 million helps reduce the overhead and reduces the chances of getting detected.

Somewhat related to social engineering attacks, this information could also be used to target individuals based on moral values. Remember the Ashley Madison breach that happened a while back. Depending on what the username is in use, it may be possible to identify people that use a particular site and sort of out them, or blackmail them. Think of other sites people may not want to be public about visiting.

How Serious is it?

I bet you didn’t think we would ever get here. It is important to understand how the attackers may be using a vulnerability to start to determine how serious it really is. Unfortunately, there isn’t an easy answer that fits every application. As I mentioned above, with poor password hygiene, the risk would be raised if someone is using one of those top 4 passwords. It also depends on the type of system, the type of data collected, the functionality the application performs, etc. No systems are created or rated equally.

In the scenario above for the login screen guessing the top 4 passwords, let’s not forget that it is possible to try all 100 million usernames from our list. Sure, it is helpful to reduce it down to only valid usernames, but the attack is still possible without the username enumeration flaw. In the ideal setup, the application would have some form of detection system in place that might detect all of the unsuccessful login attempts, but that is the ideal. It is not common enough to see that type of detection implemented in many applications. Without that detection, and a little crafty rate limiting by an attacker, the difference between 100 million attempts and 100,000 attempts is really just time.

As we all know, social engineering attacks are the latest and greatest. Any help we provide attackers in that arena is a step backwards for us. This could lead to a bigger problem and that is why we need to understand the issues we are trying to solve.

Should we fix it?

If we had all the time and resources in the world, the answer would be an easy “yes”. Unfortunately, we don’t have that. This really comes down to your organization’s risk assessments and priorities. I always like to provide the recommendation to resolve the issue, as it makes for a better application overall. Depending on your situation, the fix may not be straight forward or easy. You may have other higher priority items that need to be worked on. Remember, for the password attack, it is really a combination of a weak password issue as well. It is not just username harvesting on its own.

Take the opportunity to review how you are auditing and logging these types of events within your application. In some cases we may see logging occurring, but then there is no auditing of those logs. Detection and response is critical in helping reduce the risk of these types of flaws.

Continuing Forward

Username enumeration is a risk to any application. It is up to the organization to understand their business to determine how big or small that risk is. This isn’t something that should just be ignored, but it also doesn’t mean it is something that is a critical finding. Don’t just write the finding off. Use that as an opportunity to discuss the functionality, understand how it works, and determine the best course of action for the organization and the users.

Username enumeration is typically fairly simple to test for and should be worked into the QA testing cycle. Take the time to discuss with the architects, developers, business analysts, and the testers how the organization can test for this and reduce the risk.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Should Password Change Invalidate All Access Tokens?

Passwords are a part of our every day life. It is no wonder they are under such scrutiny, with many breaches focusing on them. We all know how to manage our passwords, or at least we should by now. We know that we should change our passwords every once in a while, especially if we believe they may have been a part of a recent breach. What about those access tokens?

Access tokens are typically used by your mobile devices to access your account without the need for you to enter in your username and password every time. In some situations, you may have to create an app password for your mobile device if you are using 2-factor authentication. This is because most applications still don’t support the 2-factor model. Instead, you create an application password and use that with your application.

Depending on your system, the management of these app passwords or tokens can vary quite a bit. In this post, I want to focus on how the ideal solution may work. First, the access tokens and the user’s password should not be related in any way. The closest they come to any relation is that they both provide authentication to the same application. This purpose here is that the compromise of one, does not compromise the other. While getting access to an access token may give me access to the account, it should not give me access to the password. If you are thinking that the access to the account means I could change the password, let me stop you right there. A good system would require the current password to be able to change the password. So this should be prohibited.

In the same vein, getting access to the account password should not lead to the compromise of the account’s access tokens. In a good system, there should be a way to manage these tokens, but that management should not include the ability to view existing tokens. Instead, that functionality is used to revoke an access token. In the instance of an application password (2-factor), you may also have the ability to create a new application password. This would still not give access to the existing password or token values.

So the question posed, or implied: If you change your account password, should that invalidate your devices?

If there is truly no relationship between the two items, and one doesn’t effect the other, then there may not be a reason to invalidate everything for every password change. As a good friend likes to always say, “what is the problem we are trying to solve?” So what is the problem? Let’s look at a few scenarios:

User just wanted to change their password

It is not unusual for a user to want to change their password. They may have even forgotten it. In this case, if the password and access tokens are unrelated, I don’t see a big risk around the access tokens that may have been created for other devices. The password should be completely separate from the access tokens and the change should have no impact to the mobile devices.

User’s password was leaked in a recent breach

This scenario is very similar to the one above. However, if an account has been compromised, it makes sense to review the devices that have been granted access and remove any that should not be there. The account compromise should not lead to the compromise of the access tokens already generated, but may enable the creation, or addition, of access tokens for new devices.

User’s device was lost or stolen

Something no one wants to think about, their device getting lost or stolen. In this case, the specific device’s access token has probably been compromised. This shouldn’t lead to a compromise of the user’s actual password. Like the above example, there should be a way for the user to log into their account and revoke access to that specific device, or worst case, all devices.

Should we, or shouldn’t we?

I don’t think there is an exact answer here. I think if done right, the two pieces are separate and stand alone. What happens to one, shouldn’t have an effect on the other. Unfortunately, that is not how things work in the real world. If you are a developer or architect designing these systems, take the time to consider these questions. Understand how your applications work, how the authentication pieces fit together, and how that will all tie together for the user experience. It may make sense to reset everything every time. On the flip side, it shouldn’t have to if designed properly. Remember the question: “What are we trying to solve?”

Application security is moving at a rapid pace, and it is great to see these types of topics coming up. As we start to raise more questions, we start to have more discussions. Share your feedback with us about this topic. Are there concerns that should be raised? Are there risks that should be considered? Share your thoughts with out on Twitter (@developsec).

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Application Security and Responsibility

Who is responsible for application security within your organization? While this is something I don’t hear asked very often, when I look around the implied answer is the security team. This isn’t just limited to application security either. Look at network security. Who, in your organization, is responsible for network security? From my experience, the answer is still the security group. But is that how it should be? Is there a better way?

Security has spent a lot of effort to take and accept all of this responsibility. How often have you heard that security is the gate keeper to any production releases? Security has to test your application first. Security has to approve any vulnerabilities that may get accepted. Security has to ….

I won’t argue that the security group has a lot of responsibility when it comes to application security. However, they shouldn’t have all of it, or even a majority of it. If we take a step back for a moment, lets think about how applications are created. Applications are created by application teams which consist of app owners, business analysts, developers, testers, project managers, and business units. Yet, when there is a security risk with the application it is typically the security group under fire. The security group typically doesn’t have any ability to write or fix the application, and they shouldn’t. There is a separation, but are you sure you know where it is?

I have done a few presentations recently where I focus on getting application teams involved in security. I think it is important for organizations to think about this topic because for too long we have tried to separate the duties at the wrong spot.

The first thing I like to point out is that the application development teams are smart, really smart. They are creating complex business functions that drive most organizations. We need to harness this knowledge rather than trying to augment it with other people. You might find this surprising, but most application security tools have GUIs that anyone on your app dev teams can use with little experience. Yet, most organizations I have been into have the security group running the security tools (such as Veracode, Checkmarx, WhiteHat, Contrast, etc). This is an extra layer that just decreases the efficiency of the process.

By getting the right resources involved with some of these tools and tasks, it not only gets security closer to the source, but it also frees up the security team for other activities. Moving security into the development process increases efficiency. Rather than waiting on a scan by the security team, the app team can run the scans and get the results more quickly. Even better, they can build it into their integration process and most likely automate much of the work. This changes the security team to be reserved for the more complex security issues. It also makes the security team more scalable when they do not have to just manage tools.

I know what you are thinking.. But the application team doesn’t understand security. I will give it to you, in may organizations this is very true. But why? Here we have identified what the problem really is. Currently, security tries to throw tools at the issue and manage those tools. But the real problem is that we are not focusing on maturing the application teams. We attempt to separate security from the development lifecycle. I did a podcast on discussing current application security training for development teams.

Listen to the podcast on AppSec Training

Everyone has a responsibility for application security, but we need to put a bigger focus on the application teams and getting them involved. We cannot continue to just hurl statements about getting these teams involved over the fence. We say to implement security into the SDLC, but rarely are we defining these items. We say to educate the developers, but typically just provide offensive security testing training, 1-2 days a year. We are not taking the time to identify how they work, how their processes flow, etc. to determine how to address the problem.

Take a look at your program and really understand it. What are you currently doing? Who is performing what roles? What resources do you have and are you using them effectively? What type of training are you providing and is it effective regarding your goals?

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Originally posted at https://www.jardinesoftware.com