22 replies to this topic

[Ohm]

By simply changing the type of an input field from password to text (AKA a normal form field), it will reveal any password currently in that field. How is this so dangerous? How many people have your web browser remember passwords for you? Anyone with physical access to your computer not only has access to your accounts, but also has trivial access to your passwords. This means they can access your accounts at their leisure, as well as any other accounts you use with that password.

It's always been known that this was insecure, but I didn't realize just how insecure it was. There are some systems that are woefully insecure, like KDE's KWallet, which has no mechanism to tell which program is requesting a password. Once you open the wallet and decrypt with your master password, a simple dcop command from the command line can get any and all password. But these web browser password databases are supposed to be a little more secure, right?

Anyway, here's the javascript. Just put this in your address bar on a site with password fields.

javascript:var els = document.getElementsByTagName('input');for(var x = 0; x < els.length; x++){if(els[x].type.toLowerCase()=='password'){var test = els[x].type = 'text';}}

var els = document.getElementsByTagName('input');
  for(var x = 0; x < els.length; x++) {
    if(els[x].type.toLowerCase() == 'password' ) {
      var test = els[x].type = 'text';
    }
  }

Here's the article it comes from.

http://blogs.techrepublic.com.com/security/?p=2156

And here's a tinyurl you can use in a pinch. I made it easy to remember.

http://tinyurl.com/passpwn

Happy passpwning!

[Ohm]

Doesn't seem to work on IE. Works on Firefox and Chrome though. Maybe the MS people actually thought of this?

[~Total_Blackout~]

Wow! This is some good "magic trick" material!

[~Total_Blackout~]

javascript: alert(document.getElementById('Passwd').value);

Worked on IE.

http://www.devilsworkshop.org/javascript-to-unmask-password-on-web-pages/

[Ohm]

FYI, hit Ctrl-C on a dialog box like made by alert() to copy its contents into the clipboard. You can be in and out in no time with that.

[chaostic]

javascript:(function(){
   var s,F,j,f,i;
   s = "";
   F = document.forms;
   for(j=0; j<F.length; ++j) {
      f = F[j];
      for (i=0; i<f.length; ++i) {
         if (f[i].type.toLowerCase() == "password") s += f[i].value + "\n";
      }
   }
   if (s) alert("Passwords in forms on this page:\n\n" + s);
   else alert("There are no passwords in forms on this page.");
})
();

~
Edit: Fixed /n to \n

Edited by chaostic, 15 August 2009 - 12:32 PM.

[chown]

In Firefox you can just go Tools->Options->Security->Saved Passwords->Show Passwords (Unless the user has set a master password). I demonstrated something like this a while back where I combined this attack with XSS to acquire passwords remotely.

In my opinion I think the password field needs to be redesigned to display only a place-holder for the password, much like the windows VPN login dialog. Having the actual value set and readable serves no purpose at all. Things like client-side Javascript validation could be implemented differently, for example a regex 'filter' property could be added.

Edit: Nice one chaostic - but you've got your slashes backwards. Also, screenshot attached.

Attached Files

•  VPNLoginDialog.png   76.76K   3 downloads

Edited by chown, 15 August 2009 - 12:02 PM.

[Ohm]

You don't have to go that far. Just make the field write-only and prevent people from changing it to a normal text field. Additionally, display 8 dots or asterisks for saved passwords so it also doesn't give away the length of your password.

Out of the 3 browsers I tested, IE is the only one that got this at least partly right. You couldn't change it to a text field, but as someone posted here, you could still read the value and report it in another way.

Of course, the best way to avoid this is to not save your passwords. Use a password manager program for that.

[Phail_Saph]

Cool post but to put some perspective here just in case...all of this is very well known whether its the javascript hack or the one post about using the browser's setting/options to view the passwords.

But I didn't post just to be an ass...it seems that it might be beneficial to note what actual is happening during the password manager process for the major browsers since this relates to how to solve the problem. All the passwords are stored and encrypted properly whether stored in SQL-Lite as in Chrome or in the Registry for Explorer. What's happening is that the password is being pulled from their encrypted location, decrypted, and placed into(not 'onto' since they are inside variables for the grammatically correct) the Password Form on the webpage. Your password during this process was never in any jeopardy of being 'hacked.' The encryption for the password on your machine is generally greater then that of it when it is transmitted to the other location on the web. That is, it is less secure when transmitted across the web since you generally are hashing it rather then using a more advanced form of encryption that your OS typically employes.

The stars you usually see are placed as part of the HTML standard for Password Forms but the variable for the password is always plaintext at your location. When they get transmitted to the other location, the one you are requesting access, they are of course hashed or encrypted in some form to avoid a man-in-the-middle attack. At this point the 'automated' process here is doing exactly the same thing you would do simply inputting information into the form which is stored into the variables of the Password Form.

The 'hack' here is that the stars are created when you set the Object document.forms to password and 'unstarred' when you set it to text so by changing the attribute from password to text you are now displaying the real text, which is already decrypted in memory(this is another hack when you don't have immediate direct access to a target machine). So your passwords are secure its the Password Form standard in HTML which needs to be changed. This goes for saved or real-time passwords.

You probably noticed that the password input box is perpetually in plaintext and it also allows you to send what's in the box so that you can log in...but it will be sent encrypted since transmission encryption is a different process. This just highlights that the variable is always plaintext and that the stars are to prevent physically nearby people from seeing it- nothing more. Basically this 'hack' is an "after the fact" key logger; still a cool hack though.

What this means is that you can't "solve" this exploit directly. It's built into the Password Form standard and is in common usage. The only way to stop this is to use a third party solution which someone mentioned Windows Remote Desktop as an example (it basically displays a graphic to appear 'user friendly' pretty neat actually) or change the standard (unlikely).

I could see the major browsers implement their own third-party solution as a marketing angle for their browsers. There would be no reason why they couldn't implement a third party solution to this, but it would slow things down from the users perspective. Since this is the current competitive field, being the fastest broswer, I don't see them doing this, not to mention it falsely makes the user think that the browser is protecting them and the companies don't want the customer to associate them with security or lack thereof in this age of daily exploit discovery.

[Freed.Info]

That's stupid. I didn't know that the variable is saved in plaintext. I guess that makes sense though because it is simply a container from your keyboard to the screen. I guess they assumed that you are in control of your machine so that they don't have to encrypt transmission between your keyboard and your own browser...lol.

It's not just for saved passwords but anything you type in there and then run the code it will display...I guess you mentioned it but I just wanted to say it again since this means that anyone who walks away from their computer for a moment, even if not completely inputted can scoot over to the machine and get a large portion of the password and then set the attribute back so the the victim would never know. This is a good reminder that physical security is the base of any security pyramid.

[chaostic]

Some places use an encrypted cookie or something like that, and make the password box display a mix of stars and the last four of the password. The stars are plaintext asterisks.

Bank of America does this.

So it is possible to avoid this problem in normal html.

[Phail_Saph]

Some places use an encrypted cookie or something like that, and make the password box display a mix of stars and the last four of the password. The stars are plaintext asterisks.

Bank of America does this.

So it is possible to avoid this problem in normal html.

That's interesting...I didn't know bank of America does that...I'm probably misunderstanding you but do you realize that that setup is by far even less secure? The fact that it displays anything of the 'real' password has just increased the chances of someone breaking it, literally, exponentially. Even if they were bogus numbers all they are doing is using a substition which is in essence what the star is anyway. BTW...Both my bank and college are vulnerable to this trick.

I have come across authentication programs that use 'tags.' Is that what you are talking about with the cookie? If you have more information on what they do please post.Also, it isn't hard to do what they are doing...all they are doing is turning on and off the password and text attribute of the Object for the Password Field; however, the variable containing the typed in password is plaintext. The 'stars' are just a 'graphic' to prevent people from literally looking over your shoulder and seeing the password. Like I said in my last post, just experiment and see...you can turn the attribute on and off at will while in the browser.

Also I didn't mean that HTML is flawed and prevents you from coming up with a solution...HTML with Javascript/VBScript/or any other powerful web scripting language can make HTML jump through hoops...the 'flaw' if it is a flaw (at some point plaintext must be transmitted to the point where it will be encrypted that's why key loggers even though simple are so pernicious) is that an Input field box (I don't know the 'official' designation for this in HTML but I think we all know what I mean) can be toggled to either show or obfuscate the inputted text. My point about third party solution was that you would have to come up with your own inputing program/solution to bring the encryption of the input 'closer' to the keyboard but there will always be a hack here since at some point plaintext is inputed. The point about changing the standard was so that an exclusive password/secure input box would be developed whereby the text is actually never placed onto the page but immediately encrypted and stored in a buffer in memory waiting to be transmitted to the external site, but since the current method of input is so widespread I thought that that would be very unlikely. I also wanted to explain that you are not cracking the password or anything too; the secure fetching and decrypting process had already occured and deposited the decrypted info in the the Object of the Password Field.

Edited by Phail_Saph, 16 August 2009 - 05:57 PM.

[chaostic]

Some places use an encrypted cookie or something like that, and make the password box display a mix of stars and the last four of the password. The stars are plaintext asterisks.

Bank of America does this.

So it is possible to avoid this problem in normal html.

That's interesting...I didn't know bank of America does that...I'm probably misunderstanding you but do you realize that that setup is by far even less secure? The fact that it displays anything of the 'real' password has just increased the chances of someone breaking it, literally, exponentially. Even if they were bogus numbers all they are doing is using a substition which is in essence what the star is anyway. BTW...Both my bank and college are vulnerable to this trick.

I have come across authentication programs that use 'tags.' Is that what you are talking about with the cookie? If you have more information on what they do please post.Also, it isn't hard to do what they are doing...all they are doing is turning on and off the password and text attribute of the Object for the Password Field; however, the variable containing the typed in password is plaintext. The 'stars' are just a 'graphic' to prevent people from literally looking over your shoulder and seeing the password. Like I said in my last post, just experiment and see...you can turn the attribute on and off at will while in the browser.

Also I didn't mean that HTML is flawed and prevents you from coming up with a solution...HTML with Javascript/VBScript/or any other powerful web scripting language can make HTML jump through hoops...the 'flaw' if it is a flaw (at some point plaintext must be transmitted to the point where it will be encrypted that's why key loggers even though simple are so pernicious) is that an Input field box (I don't know the 'official' designation for this in HTML but I think we all know what I mean) can be toggled to either show or obfuscate the inputted text. My point about third party solution was that you would have to come up with your own inputing program/solution to bring the encryption of the input 'closer' to the keyboard but there will always be a hack here since at some point plaintext is inputed. The point about changing the standard was so that an exclusive password/secure input box would be developed whereby the text is actually never placed onto the page but immediately encrypted and stored in a buffer in memory waiting to be transmitted to the external site, but since the current method of input is so widespread I thought that that would be very unlikely. I also wanted to explain that you are not cracking the password or anything too; the secure fetching and decrypting process had already occured and deposited the decrypted info in the the Object of the Password Field.

The box is plaintext, not password object. The site uses javascript to live write the page, and fills in the plaintext box with the saved "olb_signin_prefill_multi" (or "olb_signin_prefill_multi_secure") information, the first 4 digits of the passcode + 6 asterisks. This prefill information is saved in a cookie, with a hash and date of last input. All you need to do to know the users passcode (Really, just a user name, you still need to recognize a picture and put in a password on a second page) is copy all the boa cookies to another computer. But by using the hash in a cookie instead of relying on the browser to store the password, you do prevent displaying what it is to someone using that javascript trick. On a locked down computer, it would make it harder to find out.

[Phail_Saph]

I mentioned Google Chrome uses SQLite to store and encrypt the passwords and that in doing so the passwords are fundamentally safe since it is very difficult to break the encryption.

However, the fact that there is no master password to access Google Chrome so that different users have a different database for their passwords, password protected, means that any unauthorized access call to the database is valid. This means that whether you are Chrome or an unauthorized program you can access the database.

I came across this program...ChromePasswordDecrytpor...that is being advertised as "decrypting" the password SQLite database of Chrome. It works and gives you access to your username, password, and website for your saved passwords. What makes this a good tool for a hacker to have is that Chrome doesn't remove the database when you uninstall Chrome.

But, the only problem I have is that it doesn't decrypt your passwords...a little propaganda to generate interest I guess. All it is doing is making API calls to SQLite which ANYONE can make. That's why this program and a few others out there are super small. The only thing taking up space are the libraries to generate the windows for the program!

It is a valid exploit though since Google in their stupidity here didn't make Chrome and SQLite authenticate one another.

[Colonel Panic]

Phail_Saph, please stop posting your stuff in orange. It makes the text really hard to read.

[Ohm]

Any in-browser database is compromised if only for reasons like this. It doesn't matter if it's encrypted on disk or not, or if it has a master password, only that the browser willingly gives out and exposes your passwords to attackers. You have to remember that most things like this are broken in the protocol, not the encryption. This is the weakness with password safes too. The password safe is secure from any attacks you can throw at it (assuming the crypto is solid). Such a system is only going to be defeated by using a keylogger to grab the master password, grab the password from the clipboard (as many allow you to copy passwords to the clipboard), a network sniffer, or a third party compromise. However, password safes require a manual step. A simple XSS attack isn't going to do it, for example. You can still be fooled, but it's harder to fool a person than a program (at least a person savvy enough to use a password safe).

[Colonel Panic]

Phail_Saph, please stop posting your stuff in orange. It makes the text really hard to read.

Actually, it looks OK in the dark grey/green theme, but in the regular blue/white one it's a strain on the eyes.

[Davie]

what the fuck?
you would have thought firefox or anyother browser apart from IE would have stopped shit like this.
Microsoft's suppost to be an asshole of a company, yet they have better security for this stuff.
dont make sense in my opinion

[biosphear]

what the fuck?
you would have thought firefox or anyother browser apart from IE would have stopped shit like this.
Microsoft's suppost to be an asshole of a company, yet they have better security for this stuff.
dont make sense in my opinion

Don't you hate it when MS wins. I don't In fact I wish they would win in this game all the time. Of course if they did I would not have as much work as I do.

[chown]

[...] yet they have better security for this stuff.

What makes you think that?