PRESTONS is a fairly large law firm in Sydney. Their list of high-end clients is as long as it is impressive. During the latest financial crisis, PRESTON’s hasn’t been getting as much clients as budgeted for, so the company’s executives have been forced to make some cuts in order to turn a profit.
Jeremy is the desktop support guy for PRESTONS. He has been there for 5 years, and knows how to look after the company’s systems back to front. Jeremy was told recently by his boss, Max, that he will have to start having 1 day of un-paid leave a week. Jeremy isn’t the only one affected by this, but has he has just purchased a new moped to cruise around the city in, he fears he won’t be able to remake the payments. Both disgruntled and hurt by the fact the company he has worked in for so long has seemingly disregarded his years of hard work and contribution, Jeremy seeks revenge.
Max is the CIO of PRESTONS. He hasn’t worked there for too long but has found himself being the bearer of bad news for his small IT department. There is a bit of tension in the camp due to pay cuts, but it seems Jeremy is the one that just can’t accept it.
One day at lunch, Jeremy overheard Max talking to the CEO. Apparently Max was getting a pay-rise due to his fine work in cutting the IT budget in half and re-working the IT operations. This fired Jeremy up. Why is it he was getting shafted and his new boss is getting rewarded? Jeremy decides that Max will be the outlet for his payback.
One morning in the office, Jeremy pops his head up over the petition and yells out to Max…
“Hey boss, did we get paid early? The company has put money into my account; I didn’t think we got paid until Thursday?”
Slightly annoyed by Jeremy’s interruption, Max continues his email to a customer, calling out “Umm I don’t know… I’ll check in a minute”
Human predictability is just so… predictable.
Jeremy sits back and waits a few minutes, peeking up over the petition to look at Max’s screen… waiting for his bank’s website to pop up.
5 minutes later, Max has finished his email, takes a swig of coffee and fires up Firefox and logs into his bank.
The only thing Jeremy needs to know to pull of this attack is the local administrator login and password. As he is the desktop support guy, he knows what this is. Even if he did not know the local admin credentials, he could still pull off this attack (see the end of the post for more details)
Max opens up Firefox and logs in to his bank account. Jeremy can see the bank logo appear on Max’s screen from where he is sitting. This is how Jeremy knows it’s time to pull off the attack. As soon as Max has logged into the bank, his credentials are ready to be stolen. (Jeremy doesn’t have to sit there and watch Max’s screen, he can use other ways, he just needs to know that Max is logged into his bank at this time – or any other website Jeremy might want to steal)
Jeremy has downloaded a couple of small Windows tools which allow you to 1. Execute commands on a remote computer and 2. View and Dump a Windows process. Combining the two tools, Jeremy can find out what Process ID (PID) Firefox is using on Max’s computer. He then executes a command to dump firefox’s memory. (These tools can be found at the end)
So what has happened here is. When Max has logged into his bank. Firefox (or any browser for that matter) has temporarily cached his password for that session. This is stored in the browser’s memory until the entire process is closed (not just close the TAB) or the SIGN OUT link is used on the bank’s site. So when Jeremy dumps the memory from Max’s browser at the time Max is logged in, the password is captured in clear text!
Jeremy saves the memory dump to the Max’s C: drive and copies it back to his PC for analysis using Windows File Sharing with the UNC path (you can also dump the file directly to a share you have set up on your own PC so nothing is left on the victim’s machine).
He now has the memory dump on his PC, and he now has to sift through the data to find the bank login. You can use this method to find ANY password in cleartext that the victim is currently logged in to. Gmail, Facebook, Twitter etc. You just need to know ‘what’ to search for. Jeremy uses WInGrep to search through the file because it has good search functionality and can support large file sizes.
Jeremy started searching for the bank’s name. He found hundreds of entries. This will obviously take a while. He played around a little bit with searching for the banks name and ‘USERID=’ and ‘&PIN=’ and eventually…. how found it.
That is that! Jeremy knew name of the bank because 1. He saw the logo on his screen, but even if he didn’t – all Jeremy would have to do is casually ask Max one day what bank he uses, because he is thinking about swapping banks because his pay goes in a day late. Too easy really. And that is if your lazy. Searching through the dump file looking for ‘USERID’ you eventually find what you are looking for.
Jeremy cleans out Max’s account over a few days and can now afford to ride his pride and joy…
… Although Jeremy wasn’t the smartest hacker out there. It didn’t take Max long to figure out what happened. And the bank looking at what bank account his money vanished to…
Now this attack was very simple. All it does is illustrate how easy it can be for someone within a company with local admin rights to steal all of your credentials. This doesn’t just work for browsers, but any service which is running. What makes this more interesting is you don’t really need admin rights on the victim’s PC. You could get in early one morning, boot up their PC with a CD or USB containing the bootkit ‘kon boot’ http://www.piotrbania.com/all/kon-boot
Kon Boot bypasses local windows authentication. You boot it up, takes a few seconds, then the usual login screen appears. You can then remove the external media and nobody will realise. They will log in to the computer/network as normal. Thing is, everything that requires local authentication gets bypassed. So you can pull off the above attack even without local admin rights. You just have to have physical access to their PC.
There are obviously a wide array of attack methods to do things like this… keyloggers being the main one. But there is more possibility of your keylogger being detected. This method… pretty hard to detect if you aren’t actively looking for it.
In this example, Max was using a fully patched version of Windows 7 and fully patched version of Firefox. It isn’t a flaw with the application’s security because nothing was exploited. Legitimate tools were used in an illegitimate way.
It has been observed that some websites encrypt these session passwords, but if you want to test it yourself, dump your browser memory and do a search for one of your passwords. You will be scared at how many times it appears in cleartext.
Ways to avoid this happening to you:
The only real way to prevent this is to have proper access rules set up throughout the organisation. Don’t give employees access to perform tasks that they do not need to do their job. Even then, if you have locked down policies on your workstation, anybody can bypass local authentication on their own PC (to install nasty tools) and YOUR PC by using one of the many bootkits out there. Best thing to do? Make sure you lock down the BIOS so no external media can be booted off of without proper authentication. And again, if you have an IT Support guy in the company – he will need to know these for his daily duties, so all i can say is… keep your employees happy