SECURITY: Man-in-the-Browser attacks

Not really, the post linked to is a prime example of misleading scaremongering.

Things can be done but there is no reason to believe that the P2P tools whose inner workings can be readily examined do those things.

That I could if I was someone else go and mug stevio and steal their money is true but that is not sufficient reason to ban me. Yet that is the nature of the claim being made in the linked post: crooks can do x so we must treat everyone as a crook. Like me, the tools should be judged based on what they actually do not what a different criminal tool might do.

So, here's a tale of a real man in browser risk issue at a well known bank caused by the bank not following good security practices and making false claims that they were reducing customer fraud risk when they were actually increasing it.

Some years ago HSBC in Hong Kong was having trouble with personal info about prominent customers being taken via guessing login details and published to embarrass them. To deal with this they introduced a secure key system that generated a code you had to use to log in. That worked.

Some years later in the UK HSBC's First Direct was looking to reduce fraud risk and they decided to adopt roughly that system. They could assert that if the code had been entered the customer must have carried out the transaction. Great for them, they had transferred the man in browser fraud risk from them to their customer. Unfortunately for them that was noticed. A year or so later they introduced a modified system similar to the one other UK banks with key cards had already been using for years. Instead of allowing any transaction after login with the code, new codes linked to the details of a specific transaction would also be needed. Now a man in browser attacker couldn't just go and transfer money to their account because the code details wouldn't match their account details. And the customers and bank then both got the claimed fraud risk reduction.

Like FD the P2P platforms need to design systems that are secure in the face of man in browser attacks. Those attacks are not likely to come from the tools here that can be technically reviewed. Instead unreviewable tools with concealed working are more likely. Remembering bank account details and seeking external confirmation of any change, perhaps with a built in delay, is one such approach. Another one will probably be introduced by UK banks later this year, having the destination bank tell the transferring customer and their bank the name on the destination account. That can then be compared to the expected name and investigated if necessary.

Perhaps you didn't read any of the scholarly articles by real experts that I linked. My brief initial comments above were derived from them, not my own opinions.

I am no expert in internet software [just a basic understanding], but my 15-years systems analysis and software development experience in the data processing environment at least taught me this:-

Ad-hoc introduction and testing on the fly of software, with no formal or secure storage and change-management procedures, on live mission-critical systems is a recipe for disaster, all the more so if - god forbid - unsophisticated users are given the access privileges to do the same. [In the P2P case, they already have the access privileges - it's their own accounts they're running this stuff on!]

I freely admit that my intervention was a bit dramatic. Being invited to run such software on my own mission-critical system awakened the old mainframe programmer in me, and data disasters of days of yore. Sorry if I spoilt your lunch....

It was intended to ascertain:-

a) is everyone asleep at the wheel? [apparently not. Good]
b) does everyone understand what's going on at the moment? [apparently there is some confusion]
c) even if nothing critical is occurring at the moment, does everyone fully understand the scope of the problem domain, and how, by inadvertence or inattention, a critical situation could yet arise? [some constructive comments have already indicated it's a valid question that needs addressing]
d) What is "the plan" to minimise risk?

"Shoot the messenger" is not a recognised response to computer security questions.

They told me nothing new because I was already familiar with the issues and that is why I recognised your use of them for what it was. That an issue is possible does not mean that the issue is happening. The things you linked to and my posts in response have described things that really can happen but that does not mean that they are happening in the specific tools being considered. That someone could write a tool to steal from you if a P2P site isn't sufficiently secure does not mean that the actual tool does that.

As you may be aware, a USB storage stick or any other USB type can be programmed to act as a keyboard and install attacks on any computer it is plugged in to. Have you and your workplace followed some security services and blocked all USB ports with glue to protect your and your work systems? Or alternatively has a judgement been made that for most systems and employees such an attack is unlikely and only implemented such protective measures in those higher risk areas? This one is a route that may have been used to help steal money from a central bank and to destroy nuclear enrichment equipment. So the risk is there and has been exploited... but is it being exploited in your own devices and how are you protecting yourself from it?

Or more in the P2P context, are P2P companies ensuring that their employees who have access to financial systems at work know that unexpected delivery of a USB device or just seeing one on the floor at their office might be part of an attempt to steal money from the P2P firm?

That apparent minimal experience with such things as open source software that can be modified by anyone perhaps partly explains your discomfort with a normal situation where development is much less structured and not centrally controlled. It's just a different way of doing things being used in a different environment.

By contrast I have both relatively classic experience doing things like designing and writing accounting and payroll systems and with major open source development in ubiquitous systems that we all here use and that are key to a substantial part of the internet. One of those has been very widely attacked with browser exploits because it's so prominent and the other also has to be secure in an environment where any attacker can go in and use a custom written version of client software including their attack because like any one else they have the source code and can change it if they like. It's also one of the most attacked parts of internet infrastructure. The design reviews for security issues in what I work with have to take such issues into account, and do. All changes to the core software release get hundreds of automated tests before check in plus thousands later and often also additional change-specific and security-specific quality assurance testing. Yet beyond that, any user can change and build their own versions and household name firms both do that and publish their modified versions that anyone can use. It's not the classic data processing environment but it's also not wrong, just different and with a far broader ecosystem around it that has to be considered.

The things that worry you here are part of the normal web ecosystem. The clients - the browsers - not only can be modified, they are specifically designed to facilitate modification including by tweaks by uncontrolled third parties and end users. By design it's a very chaotic environment where the development is highly diffuse even though the core products are very extensively tested.

That has the potential for trouble. Consider a place where I would sometimes make changes with a few minutes or less of notice and if I screwed up internet providers would get calls from their customers saying the internet is down even though it was just one highly used place. Those real time changes were typically in response to ongoing attacks or major performance issues related to high growth or unexpected load that required urgent action to resolve harm that was already happening. Taking days or weeks for a more traditional process wasn't acceptable because that would have prolonged the disruption. More recently I told a household name firm to shut down one of their systems for a while as a necessary part of fixing an outage caused by some of their design and settings mistakes.

You probably don't know it but major places like Facebook normally make thousands of changes to their live software every day. They have processes in place to do some rapid testing and to rapidly roll back changes as well as to deal with issues. So for example they have monitoring software looking at their database servers that will go in and automatically terminate troublesome queries or block accounts used by an application until the application can be corrected. It's very much a case of deliberately organised chaotic development that's comprehensively different from what will still be used today in core banking systems.


It's a well recognised one though in this case the messenger was exaggerating the problem and those reacting to the message including me have explained how.

I'm not unfamiliar with delivering such messages. In one case it led to the person I'd delivered the message to literally running out of their office to take action. I'd shown him a log proving that the system operators of the university mainframe had granted me system manager access one day after he asked me to do something to get escalated privileges in the system he was security manager for. The log showed a request for the system to tell me either his or the normal system manager's password and illustrated how I could have obtained every password and any data on the system. The request didn't happen because an incorrect instruction caused the job to be automatically ended shortly after the access was granted and before I'd be told the password. To get that access the job sent to the mainframe operators a request to mount one of a specific range of magnetic tapes then sent a message to their console saying "Archive restore job, please run".

You mentioned data disasters. It happens that in the thing I work with I've been the lead internal promoter of changes that have made recovery from potential data loss easier, faster and less likely to be needed, with more of this to come. Done by educating the relevant people about real world failures and recovery and how those are and could be dealt with, then designing in improved resilience. That has greatly reduced the number and severity of issues seen. We do still from time to time see situations where we can't find out what was done in detail because the person who did it is not available any more, whether in custody or not permitted on the premises any more. Systems can be protected against that - off site storage of tested backups, say - but they can be quite tough for the businesses involved. One of them was "lucky" to get back only a couple of weeks of data due to insufficient protection against a malicious employee, and that only because the employee missed deleting the logs used to get it. I think the business survived that one.

You're not wrong about the potential for issues, just perhaps not paying enough attention to whether the specific tools actually have those attacks and how P2P sites can have robustness against threats they have to live with designed in to their systems so they can survive attacks from compromised client programs and customer accounts without undue pain.

You can guess what you like.

I prefer to think, based on my coding experience, and the possibilities that you've not even thought of.

For those who do use the script, either manually copy and paste the code or disable the auto update so that the code can not be maliciously changed by the original author at a later date.

Companies do spend millions for advantages though. High speed low latency connections to stock exchanges to get trades in that fraction of a second faster are all the rage. Companies like Bloomberg charge for financial data based on speed, accuracy and analysis, precisely the opposite of your post.

No client side script which has no connectivity elements can be providing special permissions. It only has the data the website it presenting anyway, possibly showing it in a different way or highlighting elements relevant to you etc.

Im not advocating that all scripts are safe, or even that this one is, I could think of a VERY dangerous tweak to this one or if similar was used on other sites, but that is why you should only ever install any software on a computer from a trusted source or that you have reviewed the code yourself (or by a trusted third party).

Finally, there is relatively little a site can do to prevent scripts like this. Something like trusteer could be used, but the costs are significant and I've heard of issues with similar products.