So I am looking to put some money into a local credit union in my area. I have heard great feedback from existing customers and it is a community organization so I wanted to take a look into their services. I went to the website not really expecting much by way of technology, after all this is a credit union, basically promoting itself with technology of yesterday such as telephone account assistance for balances and such. Anyway they do have an online solution for the more modern customer. The following is why I am not currently a customer of this institution: I click the link for the web banking aspect and I am immediately concerned as I am no longer at the credit union site. OK so they use a 3rd party for this service, it should be hosted on their own network, but whatever right. The only field for entry on this page is a login text box. Of course for my own security and that of others using this site I am forced to run a simple test on the login mechanism. I enter a name, "John." Here is where it gets ugly..... I failed the login, expected, however the poor coding of the application actually filled in the exact number of remaining characters required for the field with zeros! So now I know that I need exactly 6 characters for a valid login on this screen. How about "John12".. well of course that worked...and now I am on the next screen, which was a security question, I assume that this was their attempt to tout a "dual authentication" process. Anyway, I was not able to guess the correct answer in the 3 tries I was given and I actually locked "John12"s account. Sorry about that, and of course it again informed me that I had done so, and that an email was being sent to my address with instructions on how to reset my password. So...if I were to use a proxy tool to stop the submit/response to take a look at what was going on there, would I be able to bypass this logic using some boolean logic of my own? Possibly...but the point is that even without exploring this any further, this site clearly demonstrated a complete lack of not only security implementation but a complete lack of security as a concept. I will not be a customer of this financial institution, however I may call them on Monday to solicit a web application vulnerability assessment. They are placing their customers at great risk. See what I mean, these vulnerabilities are EVERYWHERE!
1 comment:
So in further exploring this site...I was able to read the raw javascript code used and understand the logic they deploy to deal with this login mechanism.
Below is a sample of the login process and we can see that I was wrong in my initial assumption that the login ID must be 6 characters. It must be a MINIMUM of 6 not exactly 6 characters. Thanks to the developer, I don't even have to understand the code to learn this, it is stated in the comments...a big "no no" for production code, don't tell me anything about the app, YOU need to know what is going on, not me..!
function validateLogonId(inLogonId, inVLogonId) {
var nl = newLine();
if( inLogonId != inVLogonId) {
alert(nl + "New Logon ID and Verify Logon ID do not match.");
return false;
}
return verifyLogonIdContents(inLogonId);
}
function verifyLogonIdContents(inLogonId) {
var nl = newLine();
var nLogonIdLen = inLogonId.length;
// must contain at least 6 or more characters
if( nLogonIdLen < 6 ) {
alert(nl + "Logon ID must contain at least 6 characters.");
return false;
}
var ch;
for( var i=0; i < nLogonIdLen; ++i ) {
ch = inLogonId.substring(i,i+1);
if(( ch >= 'a' && ch <= 'z' )
|| ( ch >= 'A' && ch <= 'Z' )
|| ( ch >= '0' && ch <= '9' )
|| ( ch == '@' )
|| ( ch == '.' )
|| ( ch == '-' )
|| ( ch == '_' )) {
; // valid character, do nothing
}
else {
alert(nl + "Logon ID may only contain letters, numbers, " +
nl + "periods, dashes(-), underscores(_)," +
nl + "and the @ symbol.");
return false;
}
}
// appears to be properly formatted
return true;
}
Here is a sample of the field filler I mentioned and the blank field error condition:
if (curForm.LOGNID.value == "") {
alert(nl + "The Logon ID field is a required entry.");
curForm.LOGNID.focus();
return false;
}
if (curForm.LOGNID.value.length<6){
var logonid = "000000" + curForm.LOGNID.value
var newlogonid = logonid.substring(logonid.length-6, logonid.length);
curForm.LOGNID.value=newlogonid;
}
inProgress = 1;
return true;
Again if I were to break the submit process using a proxy, would I be able to alter this logic and say (in english) "if you enter a blank(no characters) as a username", the condition is true and allow a null login? Yes, that would work however due tothefact that there is not a null entry, by nature of it's denial, I would assume that if there is a second for of authentication here, I would also need to break on that and force a true statement no matter what the input. This process depends on the presence of data sanitization, if there is none, we can perform this level of attack successfully.
Post a Comment