Card-stealing code that pwned British Airways, Ticketmaster pops up on more sites via hacked JS A Javascript library hosted by Feedify and used by e-commerce websites globally has been repeatedly infected this week to potentially siphon off countless victims' bank card details to crooks. The library code is typically embedded into retail webpages by site administrators and developers to add a means for shoppers to leave …
It is phenomenal that we live in a world where it is perfectly normal for people to just dump some other company's code, being served from some other company's servers, right into the most sensitive bits of their own property without a second though. External code should be considered a a security vulnerability, whether or not it is being served "securely".
Put Commercial-Interests ahead of everything else esp... Security!
The rush to 'digital everything' at this time = extinction level event!
We should be retrenching and doing more things Offline anti-cloud!
We need a decade focused solely on security. Meantime - Unplug!
That's it! We can now see the implosion of the place on which the markets are now dependent. The cost of security against the market forces that make it un-affordable inevitably means universal catastrophic collapse. {Insert post-apocalyptic movie clips here.}
The only downside to that is duplicating the works of others. It turned out I duplicated quite a chunk of "The Art of Computer Programming" [Donald Knuth] in the process. {Shrug} However, I damned well knew why my code worked and how to prevent many computational, logical and security blunders. Then again, StackExchange didn't exist back then.
{I've looked at StackExchange. No. That's not the way to do things. It's as ethically challenging as a security engineer using Script-Kiddie tools.]
other company's code, being served from some other company's servers
Good grief! For some reason it didn't click that the idiots are actually running it off someone else's server - I'd always imagined that the 3rd party code had been downloaded, checked and installed. I thought that updates would be downloaded and checked before installation. But no...
Unbelievable!!
"For some reason it didn't click that the idiots are actually running it off someone else's server..."
Get yourself uBlock or some other similar technology that displays a counter of blocked requests. This shit is rife. Even this page for commenting on this thread has at least six separate domains serving content into it, about half of those apparently for "analytics".
But they're blocked, natch.
Running uBlock, or similar, seems like good idea. The problem is that many eCommerce sites have scripts running from so many locations, you can't tell which ones are irrelevant crap, and which are necessary for the purchase to proceed. So you end up inching through the purchase, playing guess the script, enabling each one in turn. All the time hoping that your purchase doesn't disappear with the next page reload, or end up debiting your credit card twice.
Online retail sites need to get it through to their thick heads that I have never, ever, found the need to relay news of my online purchases to some social media account. And I am not interested in being tracked by anyone while I am on a page entering my credit card details. For any reason.
At the point of purchase that is all I want to do; purchase. The only people involved in that exchange should be me, the website I'm on, and the relevant bank. That is all.
I'd always imagined that the 3rd party code had been downloaded, checked and installed.
Even if it was being run off their servers, can you imagine the conversation?
developer, running into the room: We need to update foo.js to version 3.4.7.1.8.
sysadmin: Have you checked that it's got no security issues?
developer: Marketing want us to have the flibble text flashing and the new version of foo reinstates the blink tag. They want it live half an hour ago because they've already got the adverts running.
sysadmin: I really think we should test this...
developer: No time, just put it live!
Sadly too many web "devs" are far too wedded to JS.
Made worse by managers wanting lots of JS produced GUI bells and whistles irrelevant blinginess on sites
It would be good if anything that took payments was JS free, and all just server side code (and from originating site only, no iframes etc.) involved (then at least the single point of failure only affects that one site)
It would also remove the abomination of verified by visa which teaches users to accept really bad security practices.
That's because the vast majority of developers are security-ignorant morons who think their ability to wire together lego-brick-style frameworks and libraries somehow makes them gods. Throw in a bit of ignorant management yelling "faster faster!" as if people will die otherwise and you've got a recipe for iced snafu-cake.
* External code should be considered a a security vulnerability, whether or not it is being served "securely". *
I work for an exchange. Let's just say that the lead IT people don't even know how to spell "security', let alone paying the slightest attention to any of the basics. Glad I'm not the CISO, as far as I can tell she's only there to take the blame when the inevitable happens.
"So you end up inching through the purchase, playing guess the script, enabling each one in turn. "
'Guess the Script' is a fun game. You learn a lot about how webpages are structured, how some third parties include fourth-party scripts that in turn have fifth-party code...
But yeah, it's frustrating sometimes. A lot of the time I just go "no, 27 cat Pictures that will Make me Smile Is not worth this bother" and close the tab.
"...a textbook demonstration of why sensitive pages on websites – particular[ly] payment pages – should not carry any third-party code."
I just got a chuckle and cringe imagining how abominable it would be if any payment page ever, ever sourced a separate advertising service.
Yeah, and this is why if you're concerned about security, or even functionality, you don't link to dynamic third-party libraries. Third party libraries that you don't have locally are subject to change.
Did people not pay attention two years ago, when removing 'left-pad' crashed Node?
https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
I wouldn't call it 'lazy' but it does need to be risk managed and not just done as a matter of course.
Linking to very large libraries from standard sources (e.g. jsquery) can ensure that the library is cached between sites and so the browser doesn't need to download it each time store in a separate cache for each site.
Also some third party scripts are designed to require dynamic loading from the host site for functionality based up the IP or query string etc.
I used to be super conscious about the risks and security of third party hosted code but that didn't mean our sites didn't have any, Gower the risks were assessed. It definitely didn't mean we were lazy.
No, considering you thought about it I'd go with "misguided", "easily swayed" and "apathetic".
It's a third party you don't control. The risks are not yours to control. However secure your stuff may be it's ultimately pointless if you allow a third party to run their own code.
"It's a third party you don't control. The risks are not yours to control. "
So I guess you don't use any cloud services, hosted email, hosted web servers, third party maintained alarm systems? You don't allow any updates to software unless you have all the source code and have read and evaluated it all thoroughly? Every AV update (hourly) you check thoroughly for issues, including data transmitted and every script change? Every application you install you insist on full access to the source code and you read and work out exactly what it does to ensure there is no issue?
Anytime there is a windows update or a new Kernel lands, you thoroughly check the source code?
Plenty of Open Source software has had security issues or bugs that have run for many years without being spotted, btw.
Pretty much every IT person in the world is having to trust a third party and their code on a daily basis, it's a managed risk.
Therefore everyone who states that running third party code of any kind is too great a risk, I presume your organisations are run on a self built OS, using custom hardware chips designed and built in house with all custom software in every device including every switch and gateway?
My comment above got a bit mangled - when I said "I used to be super conscious about the risks and security", I don't mean I stopped getting concerned, it's just I'm not in that area any more - I still would be super conscious about it if I was back in that arena. However my point is with everything as long as you understand the risks thoroughly and evaluate them then you can make a conscious decision on it. If your site uses hosted popular library and you are not processing any forms, are not a major site and are not in certain sectors then running from the official hosts over https may be considered an acceptable risk, far less of a risk than running you site over http by default in the first place (as many on these forums have advocated whenever the drive to https everywhere is mentioned). Sometimes people wish to do small amounts of e-commerce so they rely on third parties to provide the functionality on their site, or analytics to see if their site actually works reasonably or something to provide AB testing. all reasonable use cases some may feel?
If you just slap third party code on because stack exchange has told you it is cool or so you have a super cool visitor counter then you are open for trouble.
Indeed - to prevent CPU security problems, we should follow in James Newman's footsteps and build our own out of transistors.
Sure, if you can write web page code you're obviously capable of writing everything else, obviously.
Come on, comparing kernel updates to javascript web apps is literally childish. Go tell Torvalds that his code is a wretched hive of scum and villainy, while you're at it.
Let's not confuse the issue, shall we ? We're talking about a humongous security hole that is without any control or oversight.
OSes have their issues, web hosting as well, but they are much more scrutinized than web apps and it is the total lack of oversight that is the problem.
And how do you enforce this ?
Make it policy, and the first time someone does it in violation of policy you publicly discipline them with a demotion and pay/bonus cut. Second time, you fire the guilty person on the spot. If you're hacked because of it, you give their name to the ICO. People need to learn that this is serious, and if that means learning the hard way that's their problem, not yours.
That will probably mean a lot of programmers get the brunt of the punishment for "following orders".
If it's company policy then giving such orders would be an infringement.
It would be up to the top management, preferably the board, to lay down policy; the costs of this are going to end up as sufficient to have board level visibility. It's then up to the board to ensure that the blame arrives in the right place or, failing that, the employment tribunal.
Thing is; they give those orders verbally, not in writing (they arent quite THAT dumb).
When asked to do something insanely dangerous many years ago; I informed them it wasnt safe; when they insisted - I asked for the instruction in writing.
I was sent home and docked a days pay; but when it came to the disciplinary hearing; it was "for reading trash science fiction novels during my lunch break".
Since then, I dont bother asking for it in writing; I just quit on the spot.
EXAMPLE (I swear to God this is word for word real)
Asked to work in a dry well all day, rewiring a control panel.
Q/ Can I have a working gas meter please (Every meter in the shop was NFU)
A/ Just hold your breath.
BYE!!!
Dont ask the name of the company, I have been calling them "Bodgeit & Scarper" for so long, I cannot remember - they went bust a year later anyway.
There are times that the only correct thing to do is not follow those orders.There are some things, especially around security and constitutionality, that I simply won't do and the people above me were quite aware of what those limits were. I used to be the lead person explaining what I understood those issues to be in our own in-house classes and was respected for that. Sorry, my conscience is not something I check at the door whenever I report for duty.
"That will probably mean a lot of programmers get the brunt of the punishment for "following orders". "
Then they should learn that "I was just following orders" is neither a defense nor an excuse.
If you are a professional (and I'd hope a dev would be) then part of your responsibility is not just saying no to problematic requests, but explaining why.
I'm not going to this because it's a bad idea, versus it's illegal, versus it's treason*. And yes, I've had to carefully explain those cases at least once to people who REALLY should have known better.
Most of the time you can deal with these sort of situations by saying "I'm not sure, this sounds illegal/treasonous/suicidal. Can you please put this request in writing, acknowledging that you will take any and all responsibility if this blows up". Faced with having to own their decisions, often manglement will back down. Or go talk to Legal, and realise what a fuckup they avoided.
If you want to build things, act like a fucking engineer. That involves a lot of saying "no, you have to do it the right way" to people who aren't focused on making things work as best as possible, but for a cheaply as possible.
* that manager did have the decency to thank me later with a bottle of scotch
Web Developer's actions are typical of the Bruce Lee quote:
"“Use only that which works, and take it from any place you can find it.”
While Security Professionals go by the Joseph Stalin quote:
"I trust no one, not even myself"
Good, Cheap, Fast. Good can be such a chameleon.
And there you hit the nail on the head. So many sites are constructed that if you block third and forth party libraries the site doesn't run. I came across a site that needed about 50 odd outside bits to actually display anything and another 30 odd if you wanted to buy something. Of those 80 odd third/forth party sites 85% of them were advertising/marketing and tracking.
Useless marketing bling is vital for e-commerce sites: It makes the marketers (who obviously have special powers in an e-commerce site) feel all warm and tingly. So don't expect it to go away anytime soon, and for any reason. After all, even if some credit cards get stolen, what's the big deal? It's not their credit cards after all, and in a week the customers will have forgotten and will be back anyway.
Or do you really think that British Airways and Ticketmaster are in risk of bankruptcy due to their payment system having been compromised?... No, they're doing fine, they just emit the standard "Your security is important to us" magic formula and everything is automatically forgiven.
"do you really think that British Airways and Ticketmaster are in risk of bankruptcy due to their payment system having been compromised?"
No but I do expect them to have to provide proper compensation to customers. I also expect the relevant data protection regulators to make it clear that fines for repeat offenders will rise rapidly, even if businesses do self-report quickly.
I expect them to have to spend sufficient money for compensation and fines for the board to have to be concerned and even put it into annual reports. If that doesn't happen this time round I expect that when financial regulators get back from lunch they'll require them to do it.
While this fiasco is unlikely to change all these websites from using 3rd party code on their website, i guess a lot of them will be removing the Feedify hosted code from them. Seems as Feedify really have an underlying issue with security of their servers, that they are unable or unwilling to fix which is allowing hackers to keep altering their code. And unfortunately for them a Google search for Feedify, the second article that shows up is about how their servers were hacked, so the future doesn't look rosy for them.
Most people seem to be missing the point of these recent hacks. It is not important that the tool was Magecart, the language was JavaScript and the infected code was imported from a third party.
The server was compromised. The bad guys either exploited some as yet undisclosed weakness elsewhere on the server or did an inside job.
Because of people in charge that keep spouting such phrases as "Infrastructure Free" are then in charge of all things digital. Agile gets thrown around a lot so little testing is done and when questions of security are mentioned you get branded "Difficult" and "You're being a blocker".
Oh well. When the world and its dog insist on everything being in "the cloud" and wanting to do everything on the cheap by lifting others code officially or unofficially. And then using said code from someone else's server that you have no control over, then this is bound to happen.
Yes, I'm not so stuck in the past that I can't see the benefits of the cloud, but I also don't want ALL our data there where I then lose control over it. I don't want my SQL databases given to a 3rd party company to manage who then refuse to allow me direct access to the said SQL database. Forcing me to use the cloud based app we've purchased from a totally different company just to be able to access fields and tables in said database.
What am I trying to say? That digital everything isn't great but unfortunately certain directors get away with spouting bullshit to others that don't understand so believe in said bullshit. Who then pay said director thousands to make their bullshit happen. When said director knows it can never happen because "I just made it up. I never thought they'd believe me". So now has to get "something" live before legging it and doing the same at another company.
I've lost my point again. Which is simply, management wanting everything done on the cheap and paying their staff as little as they can until they can outsource them. Then wondering why shit like this happens and just spouting "Lessons have been learned" when they haven't and it just happens over and over again.
Is that the cost of potentially having to reimburse potentially hundreds of thousands of customers whose card details may have been compromised, needs to be weighed against the utterly trivial cost of implementing a simple customer feedback form on your website yourself.
I know that Not Invented Here syndrome is a widely understood and frowned upon phenomenon, but this case certainly illustrates where the limits of reuse need to be debated. Code hosted on third party servers looks like a very fine place to start drawing that line for commerce websites. For payment services, the liabilities are well defined, but that really should be the only third party service you allow when you're taking payments.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020
