Why user scripts are a bad thing July 4, 2007
Posted by a1291762 in : heritage , add a commentSo Heritage uses a substitution cipher to protect the password. I thought they used a hard-coded substitution key… perhaps they did originally (back when I first looked at the code) but they don’t any more. Of course, since my current method of defeating the onscreen keyboard relies on having access to the JavaScript engine I hadn’t noticed this (the variable has the same name, just a different value). Not counting user scripts (and JS engine exploits) that probably makes the Heritage system as secure as it’s reasonable to make it.
It seems there was a big hole found in Greasemonkey where it let remote sites take hijack the Greasemonkey bits to do bad things. They re-architected it to prevent this from happening but I don’t think Creammonkey/Trixie/Konqmonkey did this. Mind you, these systems were always more basic than Greasemonkey so perhaps it’s not as issue there. What I don’t seem to see though is any sort of protection for web sites from user scripts. These extensions are punching a hole through a security barrier and allowing arbitrary code to run. However, how do you know that the user really installed the script and that a trojan didn’t just put it there or modify the file on disk?!?!?
An example of the evil things that could be done by an evil user script:
1) redirect from the login page to http://myevilsite/username/password and go through the server logs to pick up usernames and passwords.
2) override the values the user entered when registering a new BPAY/inter-bank payee (so that all future payments go to Mr. Evil instead of the intended recipient).
My auntie has a little black box on her keyring. When she wants to login to her bank’s website she presses a button and a number is printed on the box. This number lets her login. How does it work? The basic idea is to take a lump of material that decays in a predictive way (ie. something radioactive) and cut it in half. The first half sits in the black box, providing the number to the user while the second half feeds numbers to the server. This is essentially the same as a one time pad though because you’re using a key both parties know but that nobody else knows (and that is useless within a short period of time).
Using this would mean that stealing the password is useless but it doesn’t stop the other bad things a user script can do. I suppose at this point you have to just kind of assume that user scripts won’t do evil things.
Since I’m talking about security, let me rant about key length. A 3-digit briefcase lock has 10^3 (1000) combinations. A 3-character, alphanumeric, case-insensitive password has 36^3 (46656) combinations. Add in caps and you get 62^3 (238232) combinations. Adding in the punctuation keys on my keyboard gives 92^3 (778688) combinations. Notice the exponential trend here? My minimum length Heritage password gives me only 36^5 (60466176) combinations instead of the 92^5 (6590815232) I’d get if they let me use all the keys. That’s a whopping 109 times the combinations an attacker would need to check to brute force my password!
An interesting phone call… July 2, 2007
Posted by a1291762 in : heritage , add a commentI had an interesting phone call this afternoon. It seems that Heritage has taken notice of my little hack. I spoke with a guy called John (who’s the General Manager of Technology) who asked me politely to take down the links so I have removed them.
There were a few reasons for the request, the most significant being that using my hack could remove the protection offered to you under the EFT Code of Conduct. The point is that the onscreen keyboard prevents keyloggers from recording your password and by allowing you to enter your password using your keyboard you could expose your password to a keylogger. If your account is compromised as a result then you might not be covered by the EFT Code of Conduct because you were (at least partially) responsible for the compromise by bypassing the “security” provided by the onscreen keyboard.
If you know what security is and understand what the implications of bypassing the keyboard are, drop me a line and I’ll send you the script. However, if you’re not sure if your computer is secure or has been compromised just stick with the onscreen keyboard.
Heritage updates keyboard May 28, 2007
Posted by a1291762 in : heritage, programs , add a commentHeritage has updated their online banking login keyboard. It took me about 30 minutes to update my script. The new keyboard apparently supports uppercase letters now but I can’t see how you’re supposed to access the shift/capslock functions that are used. For now, my script still takes your input and makes it uppercase but it’s ready to support mixed case as soon as I can see a way to change my password to use mixed case.
Get it here. I’ve archived the old version over here in case you want to see what changed.
As before, this has been tested in Safari 2.0.4/Creammonkey 0.7, Firefox 1.5.x/Greasemonkey 0.6.5.x and IE (XPSP2)/Trixie 0.2.3. As before, I wish someone would make a Konqmonkey. I don’t have IE 7 installed at home and I’m not at all interested in installing extra crap on a system that’s meant for games. I do have IE 7 at work so I might get around to checking this out there.
Update 30 May 2007
It looks like someone is making a konqmonkey. Trouble is that’s for KDE 4 but the original version is for KDE 3 so I’ve got that running now. It needs some work though. The 0.1.1 download link was broken and the 0.1 version doesn’t do metadata so I’ll need to put that in. Luckily I do Qt programming for a living so getting it going should be a snap.
Update 31 May 2007
In case any of the other links die, here’s konqtest.kdevelop-0.1.tar.gz. Apply konqmonkey.patch. I had to change the automake version to 1.9 for SuSE 9.3. Run automake –version to see what version you have. I then ran configure -prefix /opt/kde3 because that’s where KDE lives on SuSE 9.3. Finally, I’ve updated heritage_remove_keyboard.user.js to work in Konqueror. Place it in ~/.kde/share/apps/konqueror/userscripts (you’ll have to create that directory).
Update 2 July 2007
As a result on an interesting phone call the links have been removed.
Just can't stop hacking my bank August 23, 2006
Posted by a1291762 in : heritage, programs , add a commentSo writing a javascriptlet and converting it to a Greasemonkey script wasn’t enough. I finally installed Creammonkey and ported the script to it. Just for completeness, I also ported it to Trixie.
Observations:
- Greasemonkey loads the script in a separate context, before the page loads
- Creammonkey loads the script in the same context, after the page loads
- Trixie loads the script in the same context, before the page loads
That’s 3 different behaviours for the three tools (which are supposed to be compatible with each other). On top of that is the browser incompatibilities. Cross-browser scripting sucks :(
I’ve used some crappy (but apparently working) browser detection code to enable all three versions to live in the same script. I’ve tested that this works in Safari 2.0.4/Creammonkey 0.7, Firefox 1.5.x/Greasemonkey 0.6.5.x and IE (XPSP2)/Trixie 0.2.3.
Now all I need is for someone to make a Konqmonkey…
Update 2 July 2007
As a result on an interesting phone call the links have been removed.
Hacking my Bank (revisited) June 5, 2006
Posted by a1291762 in : heritage, programs , add a commentI found a way to bypass the onscreen keyboard at my online bank. However both the AJAX and PHP versions I came up with had problems. The AJAX one doesn’t work from a web server. The PHP one works nicely on my Linux machine at work but it seems that PHP on Mac OS X can’t open SSL connections, so it doesn’t work at home. Both solutions also fail to handle the “pay anyone” keyboard, which comes up when you try to do a “pay anyone” operation. I went and looked at my solution again and came up with this javascriptlet. Save that link as a bookmark and then open it when you get an on-screen keyboard (it works with both the login and “pay anyone” keyboards).
Update 10 July 2006
While I was sleeping, most browsers stopped supporting javasciptlets. Luckily, there’s Greasemonkey for Firefox. I’ve adapted the javascript to run in this environment. Once you’ve installed Greasemonkey, click on Heritage Keyboard Killer and install it.
Similar environments exist for Safari (Creammonkey) and IE (Trixie) but I haven’t tested the code with them. Unfortunately, my primary browser at work (Konqueror) doesn’t do Greasemonkey or javascriptlets. I might just move back to Firefox.
Update 2 July 2007
As a result on an interesting phone call the links have been removed.
Hacking my Bank May 10, 2006
Posted by a1291762 in : heritage, programs , 1 comment so farSome time ago, Virgin Money put a crappy on-screen keyboard on their login page. The idea is that you have to click with the mouse and you can’t type with the keyboard. There’s some obfuscation done to try and ensure that malware can’t sniff your password. It’s very user-hostile but I don’t use their online banking much though so it wasn’t a big deal.
However, I recently opened a Heritage account (to escape newly-introduced fees at my old bank). They not only have a keyboard on their login page, it moves! Their solution is extremely user-hostile and downright annoying for me since I’ll be using it frequently. I know enough about this sort of thing to know that they’re just using JS to obfuscate the password. I think it’s time to do something about it.
My first attempt can be found here (Note: It won’t work from there, see below).
This simple hack took me about 30 minutes, mostly because I had no idea what I was using and I had to google extensively for hints about what JS functions to use and how they worked.
There’s a downside though. The AJAX request means that it is not possible to run this from a web server. It works in Safari if I open it as a local page (ie. file:///) though. The problem is the cross-domain scripting security feature. The whole point of this feature is to prevent people from doing exactly what I want to do, dynamically modify someone else’s page. I think that’s a bogus argument because you can use a server side scripting language to do that now. The URL bar will always let you know where you are so there’s no surprises (unless you’re an idiot). Basically, it looks like you can’t use JS to fetch a file from a domain other than the one you’ve loaded. This includes things like finding out the HTML in an IFRAME or FRAMESET. There are various hacks for getting around this but none that work when you don’t control the “other” machine. A simple workaround would be to use PHP instead of AJAX to request the obfuscation tokens. My webhost doesn’t support PHP (it’s a free ISP-supplied account) so I won’t be able to put a working solution based on PHP online (then again, the current solution doesn’t work online either). The machines I use frequently run a web server with PHP support so it’s something I’ll probably do anyway because Safari doesn’t let you click a link to file:/// from a http:// page :(
Update 23 May 2006
Here’s the PHP version. It won’t directly work either because my web host doesn’t support PHP. However, you can copy it somewhere that does support PHP and it’ll work.
Update 2 July 2007
As a result on an interesting phone call the links have been removed.