Slashdot Mirror
One Misplaced Line of JavaScript Caused the Ticketmaster Breach (itwire.com)
An anonymous reader quotes ITWire:
Well-known British security researcher Kevin Beaumont says the breach of the British operations of American multinational ticket sales and distribution company Ticketmaster, that has led to the possible leak of tens of thousands of credit card details, was caused by the incorrect placement of a single line of code... Beaumont said Inbenta was providing a chat bot for website developers "by providing a single line of HTML which calls a JavaScript from Inbenta's Web server...."
He pointed out that while Inbenta had provided Ticketmaster a customised JavaScript one-liner, the ticketing company had placed this chatbot code on its payment processing website without informing Inbenta it had done so. "This means that Inbenta's webserver was placed in the middle of all Ticketmaster credit card transactions, with the ability to execute JavaScript code in customer browsers," Beaumont said. This code had been altered by some malicious person back in February and the problems began at that point, he said.
Beaumont warns businesses to be cautious with third-party JavaScript code in sensitive processes. "Check your supply chain. Because attackers are."
And he also highlights how anti-virus tools started flagging the the script months before Ticketmaster announced the breach. "I can see the Javascript file being uploaded to a variety of threat intelligence tools from April through just before the breach announcement, so clearly somebody was looking into it."
He pointed out that while Inbenta had provided Ticketmaster a customised JavaScript one-liner, the ticketing company had placed this chatbot code on its payment processing website without informing Inbenta it had done so. "This means that Inbenta's webserver was placed in the middle of all Ticketmaster credit card transactions, with the ability to execute JavaScript code in customer browsers," Beaumont said. This code had been altered by some malicious person back in February and the problems began at that point, he said.
Beaumont warns businesses to be cautious with third-party JavaScript code in sensitive processes. "Check your supply chain. Because attackers are."
And he also highlights how anti-virus tools started flagging the the script months before Ticketmaster announced the breach. "I can see the Javascript file being uploaded to a variety of threat intelligence tools from April through just before the breach announcement, so clearly somebody was looking into it."
In recent years it has become common practice to use GitHub or other code sharing sites to pull in reams of third party dependencies for whatever flavor-of-the-month JavaScript framework that young coders want to use because it's trendy or because they saw an awesome demo at a conference somewhere. I guarantee that not one in one hundred of these kids has any clue what sort of dependencies of dependencies are being automatically pulled from the public repositories and being injected auto magically into their code running on top of one of these JavaScript frameworks and frankly many of them wouldn't care even if they did. They plan to be gone in 3 years or less and on to their next gig and whatever framework has come along since then to be the newest craze. Meanwhile the security oversights remain for years or maybe decades after they're gone, silently waiting for the exploit that must surely come. It would not surprise me at all to learn that nation state backed hacking groups are embedding advanced persistent threats into these public JavaScript frameworks or any of their thousands of dependencies. I predict that we haven't heard the last of these kinds of breaches because the JavaScript code slingers out there, who might have learned to code in a boot camp, haven't yet been taught a harsh lesson in security that they will remember in their bones. Some of them even show outright contempt for security or those who suggest it, although most of them are simply indifferent. They grew up with Facebook after all and their attitude tends towards, "Meh, privacy is dead, who cares"?.
You get what you pay for. Business people see no difference in software quality, they only judge user-interface decisions and responsiveness. With no regulation, no one will care about reliability or source code quality, and development will continue its decline from earlier days that considered using formal verification and cared about fault-tolerance.
And the dangers of third party content on web pages. It's very hard to be sure that things play together when more than one content provider is involved.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Everyone likes to shit over JavaScript and its developers but frankly its blindsided elitism. The problem is endemic to package management and computing in general. As if anyone has line-by-line verified anything they've pulled in via nuget, apt-get or whatever package manager you'd care to mention. And even if you were to try, would you actually catch something really underhanded?
All we have for any of this at the end of the day is blind trust. I think all of computing to some extent is faith-based that the next link in the chain was built competently and without malicious intent.
There's no easy solution to this and there never will be. The open source community seems content to place their faith in a panopticon of other eyes (and always other eyes, I've seemed to notice) finding these flaws. Mostly it works, other than the odd catastrophic failure when it doesn't. The only other choice appears an authority that can vet packages and give a stamp of approval, though getting financial support for it would likely be impossible.