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."
If a bad actor can get you to run their code on your computer, it's not your computer any more.
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"?.
WTF is security, how to ignore it and deliver your project https://www.facebook.com/nixcr...
Someone should charge them a convienence fee.
It once took me two weeks, to find a single comma missing. Thanks IE6!
Even worse, but solved more quickly: I accidentially typed a ` right before an i, resulting in a i with a dot that had one single more pixel. Even less, given the right font size. It was impossible to see. I had to do a unicode search by copying and pasting the character, to find what was weird about it.
Still not as insane as PHP though. I found, that if you make a few empty lines in the middle of some function code, and just wrote a random totally invalid word there, that the interpreter would still happily execute the function as if the word was not there.
Turns out PHP interprets everything it does not know as a string, which is equivalent to a function returning that string... And PHP also just ignores any functions' return value if it isn't assigned to anything. Making the string a valid statement equivalent to NOP. *facepalm*
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.
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.
Anons need not reply. Questions end with a question mark.
That's generally how bugs work
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.
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.
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.
The real "Libtards" are the Libertarians!
I reviewed the code, and I think I found the problem on line 1742:
It's always one line of code, or two, or one number, or two, etc.
Fucking shit. You want quality - stop infestation of IT by shitty smelly parasites hindu-chimps.
WebAssembly will make this kind of problems even worse, because the included third-party binary blobs will be even harder to audit, easier to exploit and more difficult to flag.
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.
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 test first and CI are difficult and boring and you have to learn it and make a habit just like versioning.
This is where the professionals come in. I personally have decided to stay in the web camp but move up the ladder in terms of responsibility and start exercising in the security and mission critical areas (ERP, Data Protection, etc.)
We suffer more in our imagination than in reality. - Seneca
A misplaced line of JavaScript, eh?
Is there any other kind?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
... that's what you must use, and you do not havr the freedom to quit, that's what you use.
Frankly, what we used before ... an internally developed language that looked like HTML tags, and was so cumbersome that even making functions was a hassle ... made PHP look like a godsend.
Also, my "team" was so incompetent, that when I suggested we should use functions to have a template library, instead of manually replacing snippets on ALL the web pages, the answer I got was "too complicated"!!
So ... yeah ... I ate that PHP and liked it too. :/
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.
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, and I don't think anyone would argue that it would be smarter for me to write this all from scratch.
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".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
So :
1. they outsourced part of their website
2. they never ever performed due diligence on the outsourced bits to check they are safe (because otherwise they would have insisted taking delivery of the files, and hosted them themselves, to avoid undeclared changes compromising the result of the audit). How hard it is to host a few js files?
3. they didn't even take delivery of the top-level js file to check it is safe, all they got delivered is an url to blindly call third party code they never checked and can be changed or compromised without notice
4. their own technical team probably washed their hands of the whole thing (not my code, not hosted on my servers)
5. the third party probably washed their hand on security (not supposed to be handling security-sensitive stuff even if the code runs in the same context in the browser)
6. the thing could leak like a sieve, all they worry about in $$$ because that's easy to trace to them
7. they feel the problem is they made the js call on the wrong page of their website (because once you own part of the website thanks to compromised js, you can't rewrite the payment links to an owned page?)
What an bunch of clueless guys. They are ripe to be compromised again with maybe a little more effort by baddies.
Yes and no. I've found out recently that a lot of startup companies will initially hire contract or young people to do the work as you say. This is to get a MVP out ASAP. After 2-3 years though, they end up having to hiring experienced professionals, or the company ends up dying out. This is due to the fact that young people, although they can code, most of them end up writing bad code.
Young coders tend to add code as they are told, to perform exactly what is asked of them. While this seems like a good thing for the company, its really a bad idea. Older coders will question the reason that the code is being added. Understanding the resulting goal is important to provide a better way to implement the solution that will help, not hinder, future development. I can't tell you the number of times that I received a user feature request, that was changed because we found a different solution that worked out better for system, and the workflow of the user.
Young coders tend to add features on top of other features. Doing this can be really bad. Continuing to add features will almost always cause code to be slower, because no one wants to understand the code they are not touching. I was once brought in to fix an API built in PHP, Rest API queries were taking anywhere between 40ms to 32s. i.e. A list of 10 items took over 10s to export in PHP.
Young coders tend to use massive frameworks (had a javascript app use over 13000+ npm modules). I have a love/hate relationship with frameworks. Its good in that it allows you to rapidly develop. Its bad in that its a lot easier to write poor performing code in it, where its harder to debug or profile, and if you have to do anything that is outside of the framework, good luck. I've found that most languages (that are mature) tend to not need frameworks or if they do, tend to be very lightweight.