Ticketmaster Chat Feature Leads to Credit-Card Breach

Tens of thousands of people have been caught up in a data breach at Ticketmaster UK, which exposed credit-card and personal information for UK and some international customers.

Customers in North America are not affected.

The ticket-selling giant said that on Saturday it found malware within a customer chat function for its websites, hosted by Inbenta Technologies. Worryingly, the malicious code was found to be accessing an array of information, including name, address, email address, telephone number, payment details and Ticketmaster login details.

The malware managed to stay under the radar for months as well, Ticketmaster said. The breach affects those who purchased, or attempted to purchase, event tickets between September 2017 and June 23 of this year. About 5 percent of its customer base is affected, the company noted, which according to the BBC’s calculations works out to 40,000 or so victims.

Ticketmaster has since disabled the feature, which was running on Ticketmaster International, Ticketmaster UK, GETMEIN! and TicketWeb websites. It also said in a website notice that “forensic teams and security experts are working around the clock to understand how the data was compromised,” and said that it has notified the affected customers.

The reality is that all businesses today rely on a complex cyber supply chain – including the use of free, open-source software, custom third-party components or simple commercial off-the-shelf applications, according to Tamulyn Takakura, product marketing manager at Prevoty.

“Today, companies are forced to assume security risk from their suppliers, because it’s impractical to mandate a consistent level of security across an organization’s technology supply chain,” Takakura told Threatpost. “Unlike the automotive industry, where there are only so many suppliers for vehicle parts, the application supply chain is fluid, and it isn’t always apparent who the supplier is.”

Hackers are aware that this means the supply chain is low-hanging fruit for network infiltration – as seen perhaps most infamously in the Target breach, where the company’s HVAC system proved to be the weak link.

“In an ideal world, any company that creates applications should empower developers to code with security best practices in mind throughout the entire software development life cycle (SDLC), and provide proper training and even security certifications,” said Jeannie Warner, security manager at leading application security provider WhiteHat Security, via email. “Every plugin which interacts with a transactional site deserves a security review in the decision process (code vs. buy). Hackers are finding that smaller companies that create useful plugin software are even easier to hack than the main site, due to the lack of rigor often found in smaller development shops without a mature SDLC.”

The chat vector in particular may sound familiar: In April it was revealed that the credit-card information of hundreds of thousands of Best Buy, Delta Air Lines and Sears Holdings customers was compromised thanks to a shared third-party provider, [24]7.ai, which provided online chat services to collect payment information.

Some researchers aren’t as forgiving of the security breakdown as Takakura. “Fool me once, shame on you. Fool me twice, shame on me,” Pravin Kothari, CEO at CipherCloud, said via email, referring to the [24]7.ai incident. “Ticketmaster’s website security was compromised by a malware-laden chatbot which they had installed on quite a few of the Ticketmaster websites worldwide. This is deja vu all over again.”

He added, “Lesson learned? Think carefully about installing third-party web services and giving them access to your cloud infrastructure, until your security operations center team has a chance to thoroughly audit their security; and, evaluate the risk of integrating their services with your own critical cloud infrastructure.”

Warner noted that there are best practices that can help clear up the third-party supplier security morass, including getting together with internal stakeholders to agree on acceptable vendor security standards.

“Establish controls that third-party vendors must meet before they can be deployed in the organization,” she advised. “Ask for Attestation letters or other certification reviews before employing plugins on any transactional website.”

Communicating those security standards to vendors and then establishing a timeline for compliance would be next on the to-do list; and form there, processes should be put in place to monitor the security status of third-party vendors at regular intervals.

“Security is a process – but a trusted website partner needs to be as secure as your own internal standards,” she said.

READ MORE HERE