Thursday, June 6, 2013

tneb - js vulnerability



This morning, I stumbled upon this link via FirstPost. It got me thinking how vulnerable sites are and how we, as the users are at risk. A few months ago, I happened to find out a similar vulnerability in TNEB's online payment portal.

Disclaimer: I am not a hacker and I don't go around snooping HTTP requests. I don't spend my time trying to break firewalls. All I do is, I look around. I observe how people build sites. I make a mental note of what I would do if I were asked to build the same site. That is all I do. More than anything, I am bored and these are the things that keeps my boat afloat. ;-)

Anyways, here are my findings.

- Easy access to the script which validates user login. Right click + view source + look for login_validate.js. I don't see any reason for NOT minifying resources. Markups, I can understand. But .js and .css can be minified right?

- On submit, if you look at the form closely, you’ll find that the password is encrypted before its been sent over the wire.You'll see the increase in the no. of characters.

- Pretty naïve way to encrypt the password. Very old school.

/* 
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */ 
// I don't know what the heck this comment means. 
 function encryptPassword(){
    var password = new String(document.getElementById("password").value);
    var length = password.length;
    var encyPassword = new String("");
    for(var i=0;i<length;i++){
        // add 74 to char code
 var temp = parseInt(password.charCodeAt(i))+74; 
        // pad zero of the no. of digits is < 4 which is true for almost all keyboard characters
 encyPassword = encyPassword + pad(temp,4); 
  
    }
    //<input id="password" type="password" name="j_password"></input>
   // set it back so that user will see a visible change in password field in the UI.
 document.getElementById("password").value = encyPassword;
    return password;
}
function pad(num, size) {
    var s = num+"";
    while (s.length < size) 
 s = "0" + s;
    return s;
}
 

- Even worse, sending the password as a plain text in the post request. Although, the HTTPS secures the communication to an extent, leaving the encryption logic open makes it kind of moot.


- This piece of code works for most of the passwords. And it took under 10 mins. A professional hacker might even crack this just by taking a look. 

function decrypt(password)
{
 var pwdArr = password.split("0");
 var c = "";
 for(var i=1;i<pwdArr.length;i++)
 {
  var code = pwdArr[i] - 74;
  var n = String.fromCharCode(code);
  c= c+n;
 }
 alert(c);
}

What do you think? I would love to hear from you guys?
Happy Coding :)
~ cheers.!

2 comments:

  1. Well, correct me if I am wrong. I am failing to see a security vulnerability here. I agree that the developers should have minified & obfuscated JavaScript in order to hide the encryption logic. But leaving them as it is, does not leads to cracking passwords.

    For instance, the data transfer happens over https, so the hacker much decrypt that information first and then only he can apply the decryption logic that you described, right?

    I would say, TNEB is relatively more secure than the other n number of websites out there, because at least TNEB 'encrypts' passwords but most of other site just transmit raw passwords over the internet (some of them do it over just http). :)

    ReplyDelete
  2. Thanks for bringing this up Veera. :)
    I thought people might be able to get the actual POST data if the site is accessed via proxy and with the encryption logic left open, I thought that it might be a loop hole. Yeah, lots of "IFs" and "BUTs" + the chances of our own people intercepting web traffic is very minimal to zero.

    Correct me if I'm wrong.

    I just want to know what others thought about this. :)

    ~ cheers.!

    ReplyDelete