Ticketmaster tells customer it's not at fault for site's Magecart malware pwnage Ticketmaster is telling its customers that it wasn't to blame for the infection of its site by a strain of the Magecart cred-stealing malware – despite embedding third-party Javascript into its payments page. In a letter to Reg reader Mark, lawyers for the controversy-struck event ticket sales website said that Ticketmaster " …
I've lost track of the number of times I've had to bash heads together over this kind of thing.
Its usually some sales or marketing drone think that adding a <Insert retarded social network here> link to the website will magically add a tone of traffic.
This tends to result in emails like this :
F.F.S. people if its an even vaguely secure area no script that you have not copied locally and validated does what you think it does goes in, is this so hard to understand.
I don't like making excuses for myself but dyslexia sucks and tools like Grammarly can only do so much!
Hamish, relax. I would like to offer you this video as a comment. It explains my views in a far nicer way (with a nice surprise at the end) than I would be able to express them myself.
Cheers.
I would like to offer you this video as a comment.
Thank you very much for that I haven't seen that one before and it made me smile.
NoScript detected a potential Cross-Site Scripting attack
from https://sync.rtk.io to https://ads.avocet.io.
Suspicious data:
(URL) https://ads.avocet.io/getuid?url=//x.bidswitch.net/sync?dsp_id=59&user_id={{UUID}}&ssp=rtkio&bsw_param=9edf2f91-6c5c-4248-b768-ca7d39a0076e
"Punctuation has a purpose, use it."
Up to a point...
Punctuation (or lack of) has been what several legal cases have hinged upon - especially commas.
It isn't helped by the issue that fullstops or commas can be smudged in reproduction (faxing) or disappear entirely.
That's why lawyers don't use it and why their sentences may seem overly wordy when a bit of punctuation might make them shorter. It's all about avoiding (or causing) ambiguity.
Simpler version: If interpretation of a sentence changes depending on punctuation, then the sentence needs revision. (Let's eat, Grandma/Let's eat Grandma)
FWIW this is one of the reasons why English is regarded as such a difficult language and why engineering cockups happen so regularly compared to engineering in other languages.
"...if its an even vaguely secure area no script that you have not copied locally and validated does what you think it does goes in, is this so hard to understand."
I'm not understanding how that matters. If the script links in external references the script can be benign when tested but not necessarily in the future.
Still relevant after all these years: Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
I'm waiting for the Google Analytics site to get whacked, if just by a resource-consuming coding error.
I'm not understanding how that matters. If the script links in external references the script can be benign when tested but not necessarily in the future.
If the script has any ability to load remote code in after deployment it fails the can I put this in a secure area test.
If you want analytics of your payment tunnel, use an after the event log analysis tool.
There are plenty that can have this data uploaded to the cloud to give the morons managment pretty graphs that they won't understand to look at.
Your law #1 does that apply to microcode inside your CPU too? Damn shame that is hidden from you to do your own audit eh?
You are right that it is impossible to audit everything but when you are not even attempting to defend against proven attack vectors you have failed at security.
Having script's that load untrusted 3rd party code on secure pages is at this point the equivalent of leaving the keys in the front door and wondering why you lost all of your stuff.
"No, it's more like taking front door off the hinges and setting it aside."
No it isn't. It's like giving your keys to a cleaning company to clean your premises.
IF you trust the cleaning company, and you believe the risk that a criminal will not join their company with a fake reference, and you believe that there isn't much risk that the cleaner will not let a stranger into your house, and you believe that the cleaner will not be mugged and your keys stolen then you are happy to do that.
Therefore many people take that risk with a cleaning company but they might not give them keys to the cash room in the finance office.
There is the opportunity to use specified hosted scripts if you understand the risks and have decided that they are acceptable. However using a link to an online library with no from some new startup is probably to be avoided, I would suggest.
"No it isn't. It's like giving your keys to a cleaning company to clean your premises."
Except that you have a contract with a cleaning company and liability statements and both of you have liabilty insurance cover.
You seldom, if ever have such contracts with 3rd party script providers and there's almost always explicit disclaimers of liability associated with them (ie, "you're on your own") - I do wonder what insurers will make of this when someone decides to get legal on the company whose website served up the links (My suspicion is "your insurance cover is void, we won't be covering your legal fees")
I would like to point out that if the workstation is company owned, then It's not your computer to begin with, and you are being allowed to use it to perform company functions.
At least that's the arguement that we respond with when people are whining about their workstations because we won't let them install Jumboautohackme.exe on their workstation because they like the pretty pretty colors it puts on the screen.
(Disclaimer: I'm one of the domain admins for [RedactedCo], and I've had to actually use that argument regarding why we don't make world+dog local admins on their workstations to vendors and sundry.
Have a look at the TSB login page. Offsite resources include:
we-stats.com
clicktale.net
online-metrix.net
tiqcdn.com
facebook.net (!)
This is on a bank login page FFS! How many trackers do you need??
At least they've removed the references to internal test servers that were present when they had their big meltdown earlier this year...
@Clanger9
Have a look at the TSB login page. Offsite resources include:
That got me interested. Just looked at the Lloyds login page:
we-stats.com
tiqcn.com
webtrendslive.com
All now blocked by ABP of course.
And looking at the Network info from Webdeveloper in Firefox there are a lot of curious bits - cross-site scripting blocked to other subdomains? XML parsing errors? Some very curious "Firefox can't establish a connection to the server at wss://127.0.0.1:5900/"
And am I the only one who is suspicious of GET requests that have a parameter of 500 bytes of hex?
"Firefox can't establish a connection to the server at wss://127.0.0.1:5900/"
IIRC there was an article here a while back that may explain this: part of tests to see if your computer/whatever looks like it has been compromised (VNC in this case.)
Can't find it now but a web search on that URL looks like it might explain more...
I think you bring up a good point.
Someone builds a web page for a site and then includes a bunch of JS modules that call outside the organization... like calls to FB, Google, etc ... or they see a neat widget and its easier / faster to just implement it with no thought to security.
That said. Many sites, including this one... call google,analytics and google tag services.
Why? Surely El Reg can do their own site analytics...
I have to ask why EL Reg does this along with every other major site.
And people wonder why Google will always have better analytics and indexing than their competition.
Now if only someone in Congress or the EU who deals with anti-trust lawsuits gets a clue ...
I'd post this anon, but FFS, this should be common sense. Yet no reporter ever writes about this. *cough* *cough* (FREE CLUE HERE EL REG!)
>Someone builds a web page for a site and then includes a bunch of JS modules that call outside the organization...
Rant incoming. Only a f**king millennial "developer" (admittedly often enabled by older management) thinks its a good idea for a nightly build to pull in random shit off the internet. Of course they are going to do it at runtime too. Rant over.
True.
But if you look more closely, it looks like their lawyers are positioning themselves using GDPR article 82(3):
"A controller or processor shall be exempt from liability under paragraph 2 if it proves that it is not in any way responsible for the event giving rise to the damage."
And in doing so, lay the grounds for a potential counter claim to their processors, if that falls through:
"... [controllers] shall be entitled to claim back from the other controllers or processors involved in the same processing that part of the compensation corresponding to their part of responsibility for the damage"
But "not in any way responsible" is not true in this case. The third party script is also unlikely to define itself as a data controller. If it was deemed by Ticketmaster to be a data controller then they would have had to do the risk analysis and the consultation with them to ensure their duties as a data controller. They would also have to notify the customers of their use of this third party data controller and gain data transfer agreements under one of the exceptions in GDPR.
It could all get a bit messy if they go down the GDPR route.
@AC
"It could all get a bit messy if they go down the GDPR route."
Absolutely it could, it could end with TM being fined for sharing privileged information with unauthorised third parties. TM have stuck themselves into a choice of:
1. It was us, sorry guv, QC issue on adding scripts.
2. It was them, we sent them everyone's information and they unsurprisingly stole it, but we sent it, don't worry.
Actually, 2 breaks PCI and PII rules too, never mind GDPR. TM have managed the insecure trifecta; the trilogy of swillogy; the trio of wankio.
Does it get messy?
My understanding is that Tickemaster remain the data controller for their customers regardless of who they assign as processors.
It's possible for the data controller to be prosecuted OR the data controller and the processor to be prosecuted (from https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/):
* If you are a processor, the GDPR places specific legal obligations on you; for example, you are required to maintain records of personal data and processing activities. You will have legal liability if you are responsible for a breach.
* However, if you are a controller, you are not relieved of your obligations where a processor is involved – the GDPR places further obligations on you to ensure your contracts with processors comply with the GDPR.
"It's the sort of attempted weaselling that'd likely to get them into top tier fines."
That depends on who their friends are.
You and I might think that weaselling is a good reason to slap them harder, but weaselling is primarily a method for the Old Boys' Club to find a way of not slapping each other - and one of the problems with the UK civil service is that the Old Boys' Club still rules.
If Ticketmaster included scripts on their website, then they are fully responsible to their users for the action of these scripts. Even if they didn't turn the scripts malicious. The only way they would be off the hook would be if they are "not in any way responsible". So just a little bit responsible would be enough.
Sure, if Ticketmaster has to pay out damages, then they are absolutely entitled to recover their money from the creator or distributor of the malware. But that's their problem, not the problem of people visiting Ticketmaster's website.
it is difficult to see how Ticketmaster could say it is not responsible for the breach while keeping a straight face.
===
THIS from a Co that takes the face value of any ticket as a starting point then doubles / trebles down on that, has had PLENTY of experience in keeping at least ONE of their faces straight .....................
THIS from a Co that takes the face value of any ticket as a starting point then doubles / trebles down on that, has had PLENTY of experience in keeping at least ONE of their faces straight .....................
And there's the problem of a company that holds an effective monopoly on pretty much any and all event ticket sales these days (except for, *maybe* stage performances from your local ballet school).
There's a reason we refer to them as "Ticketbastard".
he should have to demonstrate this by publicly eating some of it.
(which - at least metaphorically - happened in the wonderful "LifeLock" case: CEO boasted their system protected customers against identity theft, with the result described by the story title "LifeLock CEO's Identity Stolen 13 Times")
There are many things to embrace and admire about technological developments in the previous few decades.
Javascript is regrettably not one of them.
What happened to the good old days of server-side rendering ?
Since when have the cool kids (front-end devs) been allowed to rule the roost and be allowed to bloat websites with thousands of lines of javascript that do nothing more than outsource the work the server should be doing ?
Sure, maybe if you're doing stuff that needs to be "live", for example streaming share prices, Javascript might be a perfectly acceptable solution to the problem.
But stuff like payment pages on websites ? That should be good old-fashioned server-side.
Reminds me of the old saying "if all you have is a hammer, everything looks like a nail" ... perhaps we could adapt that for the 21st century "if all you have is Javascript, everything you code looks like a use for it".
I would hardly call front-end devs "the cool kids", nowadays they are just devs, nothing cool about it.
Also the idea that client-side javascript is some form of easy way of doing exactly the same as server side javascript is ridiculous. Sure there is laziness (efficiencies) in using libraries that could utilise server-side coding but I would love to see your conversation with your dev team or agency for a significant modern ecommerce website where you stipulated no client side code can be used but the results must be easy to use, have a great user experience and the sort of modern functionality that consumer require. I doubt there would be an agency who would take on the brief and you dev team would resign.
For better or worse, client side code and client side libraries are here to stay in modern web dev for any significantly sized modern website with interactivity and e-commerce. However that doesn't stop devs & marketing having decent training about the security implications of their decisions and making sure that useful risk assessments are done.
"That way there's a job opening that someone like me could fill"
Err. you're a web dev who doesn't want to use client side scripting? No wonder you're looking for a job.
Much better to have loading screens than ajax, far better to refresh the page on every action, who needs a client side validation when you can just reload the page after the mistake has been made and the form submitted, hell we don't need no automatic address fillers when we can just get people to type in their full address or submit the whole page to look it up, wow iframes are still great.
Client side scripting has its place, but to use some of your examples, I could do without intelligent forms. I don't need someone to store my address on my computer in a format that only works with their site. I can use one of the many browser add-ons for automatic filling of forms should I get tired of entering my address. I also don't need overactive warnings every time I already know that, that tell me that my phone number is not a valid number because I haven't finished typing it yet or that a person can't live at an address where the country says "please select". This kind of thing could be done with HTML5 form things that allow simple conditions to be sent to the browser, without requiring as much attention to client-side parsers and incidentally annoying me less.
" I don't need someone to store my address on my computer in a format that only works with their site. I can use one of the many browser add-ons for automatic filling of forms should I get tired of entering my address"
They don't store your address, they use you postcode and house number to automatically show your address so it 1) makes for filling quicker and easier 2) keeps data sane within your end DB. Your automatic form filler needs to work specifically with 'my' site. Having been faced with trying to do an address cleanse on a database that had manual form fields was a complete PITA and cost a lot of money.
Not many people complain about house number/postcode lookup if done properly and I find filling in individual address fields awkward.
" I also don't need overactive warnings every time I already know that, that tell me that my phone number is not a valid number because I haven't finished typing it yet or that a person can't live at an address where the country says "please select"."
You're just describing a poorly written system. Any dev can do horrible UX with front end or back end code. However do you truly love a form that has to completely reloads the page to validate your input with the red warning then a scroll to the invalid entry which you resubmit only to find there is another invalid entry etc?
Most* people want to be told as soon as they leave or go to leave the field - once again if done properly!
"person can't live at an address where the country says "please select""
Once again see the note about things being done badly.
A good example is comparison insurance sites. If you use them, compare them to 5 years ago. They had page after page after page of information that needed filling with constant blockers because the page was incorrectly filled in. Nowadays some of them have brilliant use of client-side scripting to ensure valid input immediately, only ask relevant questions to your application, allow real time adjustments to quotes, have data being returned on the fly etc.
We don't want to go back to a world of Flash because that was the only way to get client side interactivity.
Even this site - Isn't it much nicer now the up/down selectors are client side rather than having to submit the page when you clicked on them?
*Yes most - I've done extensive user testing on sites before now to identify the key things that visitors wanted from an ecommerce site and gained extensive stats about what worked and what didn't. One of the biggest battles I had was removing the stupid 'retype your email address' box that everyone was using at the time - you almost never see that any more.
I may be describing a badly written system, and I'll gladly stipulate that you can write a bad system in any language or paradigm you like. However, I still think this is an adequate argument against some, but only some, javascript use. The reason I say this is how many extremely terrible client-side form handlers there are. If they all worked really well, that would be nice, but it doesn't happen that way. Javascript is a tool like any other. You can do things with it that are not doable with other tools. You can also use it to turn a page that does not really need client-side interaction and turn it into a nightmare. It can also cause plenty of security problems, which doesn't help either. On balance, it's a tool that is misused a lot for whatever reason, making it unpleasant to many.
"the idea that client-side javascript is some form of easy way of doing exactly the same as server side javascript is ridiculous."
I'd say the idea of using server side javascript is ridiculous. If you're doing server side processing you'd presumably use a better language (because you can, unlike in a web browser).
"I would love to see your conversation with your dev team or agency for a significant modern ecommerce website where you stipulated no client side code can be used but the results must be easy to use, have a great user experience and the sort of modern functionality that consumer require."
Have you ever heard the saying that security should be built in from the start? Where was that in your list of requirements?
"Have you ever heard the saying that security should be built in from the start? Where was that in your list of requirements?"
Client side scripting is not insecure or else the vast majority of sites written in the last 5 years would be insecure. You can create insecurity in your site, but that is not because it uses client side scripting. It is just, if not more, likely to happen from a back end dev who used concatenated SQL statements for user input rather than stored procedures.
If you were in a role where you commision projects then you would realise that security is part of a risk analysis through the whole lifecycle of the project. You don't say "No HTML5, No Javascript, No SQL, No Form FIelds" just because there is a possible security risk. A person who is good at the role will understand and analyse the risk and produce a specification which mitigates those risks to an acceptable level while still meeting the needs of the project and the organisation.
"To be fair Ticketmaster's policy has always been to pass everything on to third parties."
Yep, including the processing fee, the venue fee, the f**ck, I don't know fee, the just because we can fee and the ohhh, here's another fee fee.
Ticketshafters.
Just bought $75 tickets with $32 in fees !!!
Hope they get sued into the ground.
...."Don't admit to shit. Just deny everything and hope they go away. Most people can't afford to fight so they will just go away. Deny everything".
That's what's happening here. They are clearly at fault for using an external script but not actually checking what the fuck it actually does.
Not as serious obviously but so many local rags do it with all the pissing adverts and crap they have on their site to "make money". The amount of times you'll visit their sites on phones and get fake AV pop-up adverts. Some ones from up North I've had this happen with. All because whoever is coding their site, isn't checking the legitness (is that a word?) of the code they are embedding.
"so many local rags do it with all the pissing adverts and crap they have on their site to "make money". The amount of times you'll visit their sites on phones and get fake AV pop-up adverts. Some ones from up North I've had this happen with. All because whoever is coding their site, isn't checking the legitness (is that a word?) of the code they are embedding."
The big offender for this is ad auction exchanges like Google DFP. Occasionally bad code slips through the exchange's filters and wins up winning a bid and gets placed on my site like any other ad. It gets caught pretty quickly but never quick enough. But we're in to do nothing but review code, there aren't enough hours in the day for me to audit the code behind each and every ad served up via DFP.
Of course i wouldn't put a DFP ad slot on a payment page, either. I'm plenty stupid but I'm not that stupid
Everything ticketmaster is connected with has a bad smell. It has been seen that they scam ticket buyers with robot purchasers, and then resell the tickets for many times the original ticket price. Their robot callers outnumber genuine buyers by 100 to one, so the tickets are sold out in minutes (seconds??).
With their command of software and malware, I would not be surprised to see that the JS insert came from inside ticketmaster, as their data handler stated that all new JS was to be vetted by them prior to insertion, and they would have advised against this. That means a crook high up in ticketmaster did this. I would like to see an analysis of the exploit to see if it was operated by a bunch of robot callers???
Fine. I will see you in court.
I will seek 473 quintillion dollars in punitive damages. That's eight teen zeros if your vocabulary is lacking and I will liquidate your company and your client company and use your desk as a tool bench for car repair.
Juries love David v Goliath stories to adjudicate. But, my desire would be clear to a jurist, liquidate the companies involved that created the massive injury and properly punish them.
Because, their assertion is that they're not responsible for their own contractors contract ignoring errors and that's equal to, "It's not my fault that my gun went off while I was raping your daughter and now she is dead, it's the gun manufacturor's fault for it functioning properly".
At least, by the time I and my legal team are done telling and framing it.
From experience most web designers are only interested in making the site pretty with little thought of usability or any understanding of code.
This they will stick any old code in without checking it worked. Many designers I knew used to disable the script error pop up so they wouldn't see the error...
The best one was a site that complained they never got any messages from their contact us page.
I pointed out that the submit button had no script associated with it so iit would never send an email
:facepalm:
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
