Predictable Session IDs

Session IDs allow a user to maintain an authenticated session with a service without having to re-enter a password for each Web page access. A server maps the session ID to a user's profile. The tricky part is that session IDs should not be predictable. Cookies and URL authenticators are popular mechanisms to implement session IDs.

Description of the Problem

Many sites have easily predictable authenticators. For instance, highschoolalumni.com used ID numbers and email addresses inside cookies to authenticate users. This information is publicly available in the alumni database so anyone cause use it to create a valid authenticator for whichever user they like.

More subtly, authenticators often contain keys which function as session identifiers. These session IDs are used so that a user can navigate the Web pages of a system without having to repeatedly re-enter their password. If these authenticators are not cryptographically random, they can often be guessed by an adversary and used to guess the next valid session identifier and thus have access to the information of another user. In the case of FatBrain.com, the system used sequential session IDs. As a result, an adversary could gain access to the account management system for an arbitrary user. This allowed the adversary to then break into the book purchasing part of the system.

What follows is a detailed description of the FatBrain attack. An interrogative adversary would have been able to obtain the personal information of any customer, knowing only the victim's email address and approximate last login time. An adversary could obtain addresses, partial credit card information, order status and email addresses of any user who has recently visited the "My account" area of fatbrain.com. An adversary can also change the customer's contact email adress. The following example demonstrates how this could have been done.

  1. The victim visits http://www.fatbrain.com/ and logs into the "My Account" section. The victim ends up at a URL such as:
    https://www1.fatbrain.com/Asp/actmgmt/HelpAccount.asp?t=0&p1=victim@mit.edu&p2=50000
  2. Within a few days after the victim has accessed the "My Account" section, the adversary legitimately logs in under his/her username. The resulting URL might be: https://www1.fatbrain.com/Asp/actmgmt/HelpAccount.asp?t=0&p1=badguy@mit.edu&p2=50030
  3. The adversary changes the request URL, replacing the "p1" value with the victim's email address. The adversary tries several sequence numbers working backwords from the current "p2" number. Because the "p2" authenticator is just a sequence number and the Fatbrain site appears to get only one new login per second, the adversary can quickly locate the victim's "p2" value by decrementing p2.
  4. The adversary can now view all the personal information of the user and change shipping addresses and email addresses.

In reality, an adversary would probably call the victim, pretending to be part of Fatbrain customer service. The adversary mgiht ask the victim to check the status of an order. A reasonable but fake explanation might be, "Someone ordered $500 in cookbooks with your name. Could you login to the "My Account" section to verify this?" Then the adversary can mount the attack.

The attack is more serious than it appears because the adversary can use the previously mentioned vulnerability to obtain a customer's password.

  1. After exploiting vulnerability #1, the adversary proceeds to change the email address of the victim to an address controlled by the adversary. After several hours, the new address becomes active.
  2. The adversary visits
    https://www1.fatbrain.com/Asp/Actmgmt/Passwords.asp?p1-&t=1
    and types in the adversary's email address.
  3. Fatbrain emails the victim's password to the adversary.
  4. The adversary now has control of the victim's account and purchasing ability.

Although Fatbrain customer service manually applies this change of address, it completes within 24 hours. The old email address is not notified of the change.

Fatbrain responded to us quickly and courteously by randomizing the session IDs. As such, we feel comfortable discussing this now fixed vulnerability.

Workarounds or fixes

First of all, sites should not use sequential numbers as session IDs. Cryptographically random numbers would work better. To prevent the second vulnerability, mail should be sent to the old email address when it is changed. This will warn the legitimate user of the attempted email address change.

Sites who have suffered this type of problem


[Home]   [Publications]   [Cookie encyclopedia]   [Mailing list]   [FAQ]   [Contact us]

[Blue Ribbon Campaign icon]
Join the Blue Ribbon Online Free Speech Campaign!