One Misplaced Line of JavaScript Caused the Ticketmaster Breach (itwire.com) 44
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."
Re: Rules of computer safety (Score:4, Insightful)
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.
Re: (Score:3)
It's very hard to be sure that things play together when more than one content provider is involved
But it works fine, see? Besides it's not MY code that broke things. And I'll be gone long before *I* have to support it, so no harm, no foul, no problem.
I'd write some documentation, but I won't and you won't understand it anyway and will just rewrite the entire things from scratch so I won't.
This Problem is Much Bigger Than Most People Know (Score:5, Insightful)
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"?.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
You get what you pay for.
That's true for developers, too. Companies only want young developers because they're cheaper and eager to be overworked. With that comes lack of experience and a tendency to jump on hip, flavor of the month frameworks because the tried and true stuff is so boring and old-fashioned.
Re: (Score:1)
What do you expect? We allow corporations to disclaim all responsibility for breaches and the price they pay if there is a breach is usually insignificant compared with the actual damage that's been done.
The end result is that there's no particular reason why they would care as it's not something that affects their paycheck. If something does go wrong, the managers get golden parachutes and the underlings get pink slips.
Re: (Score:3, Insightful)
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 th
Re: This Problem is Much Bigger Than Most People K (Score:1)
Ubuntu and Debian use signed packages, and they are curated much like the Apple store. Node doesn't use signed packages, but it doesn't matter anyway because anyone can upload anything. It's actually a really nice system in terms of ease of use, but there is malware all over up there.
Web Dev Hipster here: Amen brother! (Score:2)
While I plead guilty of being a mix of old school geek and ISO Certified JS Toolkit hipster, I second the notion of security being handled way to lax in the web agency camp.
However this is more often a problem of skill and awareness and not so much the toolkit. Security is always a tradeoff between usability and it has to be considered day in and day out. Most people don't have an opinion of this because they are rarely forced to take responsibility for mission critical code. Security and due diligence like
Re: (Score:2)
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 think it's more pragmatic than that. No one wants to reinvent the wheel, presumably when someone else has done it better. I think that's almost always a good thing, because the standard third party packages for performing most of these things is far safer than what the average developer would write. I think if someone's boss saw them rewriting something that was available as a standard, widely used NPM package they'd get an earful for wasting time.
I'm working on a small flask application right now,
Re: (Score:1)
Thing is, it's always just one line of code. Very rarely is a security bug something big and prevalent throughout the code. It's a forgotten bounds check, or a miss-sized integer. You can say "just one line of code allowed _______" for almost the entire set of security bugs that have occurred for the last decade.
more than one line (Score:4, Funny)
Don't give me the "it's only one line" bullshit because sites use condensed javascript files that only have one line! It's like saying someone was killed by an speeding piece of steel after being hit by a bus. Sure, it's technically correct and completely misleading.
Re: (Score:2)
It's like saying "a 30 mph piece of steel" It's focusing on one metric (speed/LOC) that while it feeds into the important result (momentum/?) while ignoring the multiplier (mass/includes).
Re: (Score:2)
The description makes it sound like this was just a one-line “src” link to a script on Inbenta’s server.
But then, I’d argue that pulling web content from third-party sites is problematic in its own right - even though it’s an almost ubiquitous practice nowadays. Your web site is basically serving out content and instructions, which you have absolutely no control over or visibility into, to your site visitors. It’s bad enough when it’s ad network stuff... but this wa
Summary (Score:3)
As far as I can tell:
inBenta was hacked, and the problem was worse than it should have been because the Ticketmaster website pulled javascript from inBenta on their payment processing site.
Third-party, included content on the web (Score:2)
Re: (Score:2)
Misplaced line of JavaScript (Score:5, Funny)
A misplaced line of JavaScript, eh?
Is there any other kind?
Inbenta? WTF (Score:3)
Did they run any kind of sanity check on the name? Like going into a pub and asking a few of the people there what they thought?
Among the myriad meanings of bent are:
* homosexual e.g. "He's bent, he's bent, his arse is up for rent _insert_name_of_opposing_player_here ".
* corrupt e.g. "There ain't nuffink lower than a bent copper and no mistake, lummee if it ain't so and strike a light, me old china".