An Example in .NET
Most languages are susceptible to this attack to one degree or another. A list of other languages and there susceptibility is listed at the end of this document. We have chosen .NET because the default method is widely used and is more susceptible to this attack than most other languages that we have checked. Here is an example code in .NET that grabs a random number:
private static int GetDice(int min, int max)
{
Random rand = new Random();
return rand.Next(min, max + 1);
}
This code takes a min and max values that specify the range to return for the random number. For instance a call to GetDice(1,6) would return a standard 6-sided die roll. The fact that this is very simple to code and to read coupled with the fact that MSDN[2] does not seem to stress the dangers of using this method is probably why you see this done so much. We will go into more details as to why this is dangerous next.
Now lets modify the GetDice method to allow it to pick random characters in an array that holds letters a-z. It will pick 8 characters to add to a string to generate a random password.
private static string GetRandomPassword()
{
StringBuilder password = new StringBuilder();
char[] lCase = new char[] { ‘a’, ‘b’, ‘c’, ‘d’, ‘e’, ‘f’, ‘g’, ‘h’, ‘i’, ‘j’, ‘k’, ‘l’, ‘m’, ‘n’, ‘o’, ‘p’, ‘q’, ‘r’, ’s’, ‘t’, ‘u’, ‘v’, ‘w’, ‘x’, ‘y’, ‘z’, };
int lCaseIndex = 0;
Random rand = new Random();
for(int cnt = 0; cnt < 8; cnt++ ) {
lCaseIndex = rand.Next(0, lCase.Length - 1);
password.Append(lCase[lCaseIndex]);
}
password.Append(0);
return password.ToString();
}
Now we will create a basic Web Application that has a login box. With a login box we will include a Forgot Password link that will reset the users password to a randomly generated password and email that password to the user. The Forgot Password link is called http://localhost/ForgotPassword.aspx and it takes one argument userid.
The Vulnerability
The problem comes from the call to initialize a new Random object. This line:
Random rand = new Random();
Implicitly calls:
Random rand = new Random(Environment.TickCount());
Where Environment.TickCount()[3] returns the number of milliseconds elapsed since the system startup. The problem is simple. If you call this random function in quick succession (in the same millisecond) you will get the EXACT same random value. This is because our application initializes every time before picking the next random number. This is very common in a web application because each time you connect the web server will likely create a new thread.
So how hard is it to call this function in the same millisecond? Its not too hard at all. A modern computer on a decent network can easily get out hundreds of requests in a millisecond. For our attack all we need is two.
In a localhost experiment Neohapsis sent 67,000 requests to a server with a random password generation routine similar to the one in our example. We only received 208 unique responses from the server. That is approximately 322 duplicate passwords. Again, that is under a rather ideal situation, you probably will not have that many duplicates in a real world scenario.
The Exploit
This is how the exploit would work. The attacker has an account on the target system with a valid email that they can check. Then the attacker locates a victims ID they want to target for the attack. The attacker needs to perform the following to successfully exploit this vulnerability:
1. Send two simultaneous (or close to it) web requests to the target system. One request with the attacks ID and one with the victims ID. Example: http://localhost/ForgotPassword.aspx?userid=attackerid and http://localhost/ForgotPassword.aspx?userid=victimid
2. That will reset both of their passwords and send both accounts an email. The attacker checks their email and users their generated password on the victims account.
3. If that fails, repeat.
Now that could be tedious, especially with a system that randomizes with microseconds instead of milliseconds like .NET does. However, luckily for the attacker, this is not very hard to automate. It is not only trivial to write a script to send out two simultaneous requests but also to have it check the mail and attempt to login.
This attack can potentially take several hours to execute and generate a LOT of email during that time. Won’t the users see hundreds of emails informing them that there password was reset? Sure, but by that time the attacker is already in and if the system was the mail system then the attacker can simply delete those messages. The truth of the matter is that the damage is already done and the only way to stop the attacker from breaking in is to fix the underlying code.
Posted by Mike Murray
Posted by Craig Smith
Posted by Mike Murray
