Ticketmaster Hack – Perfect Example
Last week, it was revealed that Ticketmaster had engaged in unethical and illegal activities against direct competitors for their own advantage. When I read the article, the biggest thing for me was the multiple levels of security failures that occurred.
I’m not going to go into all the details of the hack. For that, I recommend you read the article above and the DOJ indictment as well. However, having read them, I will provide you with everything you need to do to prevent a scenario from ever happening, or, at least, significantly reduce the chances.
In this article, I will outline for you all the specific failures and how they could have been prevented using good ol’ basic security practices, applications security best practices, and modern security practices like Zero-Trust Security.
Table of Contents
- Ticketmaster Hack Mistake #1: Password Reuse
- Ticketmaster Hack Mistake #2: Inadequate Access Control
- Ticketmaster Hack Mistake #3: Poor Application Security
- Conclusion: It’s All About Layers
Ticketmaster Hack Mistake #1: Password Reuse
I’ve mentioned before multiple reasons why sharing passwords are bad, but one of those reasons is that when someone leaves the company, they still have access to your data. This is especially true when applications are readily available everywhere and anywhere.
In the Ticketmaster case, a former employee left the company and went to a competitor and provided the new company with usernames and passwords for Toolboxes that the Victim Company had established for three different artist management companies. This gave the new company access to proprietary information, including client names and details.
Password Reuse Prevention
Here are some steps to enact to prevent a former employee from accessing your systems after they leave.
Ensure all access to systems is tied to a unique individual
Every human with access to a system must have their own credentialed access. Shared access must be limited to service or machine accounts and stored securely in an auditable password safe (such as 1Password) with limited access to only information that they need to know.
Rotate shared credentials when privileged people leave
If someone with privileged access leaves the company, you should rotate any shared credentials they may have had access to. Incorporating an automated procedure to rotate credentials will minimize the effort to do this reactively. We strongly recommend using automation to rotate shared credentials to minimize your attack surface.
Ticketmaster Hack Mistake #2: Inadequate Access Controls
One of the first things I see whenever I do a Security Assessment is the lack of good de-provisioning of employees and contractors. I will inevitably find someone that had left the company up to a year ago with access to systems, sometimes privileged access.
Other times, I may find people with more access than required of their job. This is because they may have changed positions throughout their tenure at the company or been given “temporary” access to resources but never had that access revoked.
In the Ticketmaster case, the employee still had access to systems after he had left the company. Not only that, but he had a LOT of access. It’s questionable whether someone might need all that access to do their job, but often out of laziness, people are given more access than they truly need.
Inadequate Access Control Prevention
Have a rigorous access control process
One way to prevent access control is to have a rigorous process and checklist of offboarding employees and contractors. Access control would ideally be centralized with either IT or a DevOps / Infrastructure team to prevent inconsistencies.
Implement Single Sign On And Integrate All Applications
I am a big fan of automation. The less manual and complex a system is, the easier it is to maintain and the less prone it is to security vulnerabilities. Single sign-on solves all that for you. When a user leaves the company, you just disable their access in ONE place, and viola! All their access is removed from subsequent systems. It’s almost magical, really.
Review access periodically
Even with all of the above, there is always the possibility of access creep. Too many admins and/or too many privileges. In this case, have a system or business owners periodically review who has access to what and the level of their access, and re-verify whether that access is required or not. The best practice is to do this quarterly, but many would be ok with doing it semi-annually or annually; it really depends on the type of company you are and the data you are handling.
Ticketmaster Hack Mistake #3: Poor Application Security
There is a lot to application security, and for that, we recommend starting with the OWASP Top 10. For this article, we’ll just focus on the relative topics particular to the Ticketmaster incident.
Resource Enumeration
One of the issues in this case was the fact that their client portal URLs could be enumerated. This is known as Forced Browsing or Resource Enumeration. Anyone using a simple bash script, a web proxy tool like Burp or ZAP, or just manually via the browser can make such an attack.
Prevention: Use Standard Libraries – Do Not Create Your Own
Application URLs can be long and are often not enumerable. The worst thing you can probably do is make your own homegrown way to do this. There are a lot of nuances to this. As mentioned before, the more you increase the complexity, the more likely you are to introduce vulnerabilities. There are usually libraries available to you out of the box for almost all application languages. They have been tried and tested: try them out.
Lack of Zero-Trust Security / Security Through Obscurity
Access to the Victim Company’s client portal, aka Toolbox, was limited only by knowledge of the URL. According to the FBI report, the websites were not indexed by search engines (whew). However, the only thing in the way of access to the website was simple knowledge of the URL:
This is also known as security through obscurity. The only thing preventing access is simple knowledge of the URL. No authentication is required for access to the website.
Prevention: Zero-Trust Security
With the ubiquity of everywhere and anywhere access, we need to lean on principles of Zero-Trust Security. It’s a complex topic, but to sum it up, before access is provided, one must strongly authenticate themselves. This could be verification that you are coming from a company-owned machine, or knowledge of a password combined with a second-factor of authentication. The more factors you can involve with establishing trust of a person or machine, the better off you are.
Of course, every situation is different, so doing a proper threat modeling exercise is prudent.
Conclusion: It’s All About Layers
As a society, we are often looking for that silver bullet or magic pill to solve all our problems. But as we all know, there often is no such thing. The same applies to Information Security: there is no silver bullet or single solution to protecting our data, whether it be employee data, customer information, or intellectual property.
The Ticketmaster incident was a perfect example of how all these layers work together and how they are all necessary. There is no such thing as foolproof or zero-risk or hack-proof. What we are trying to do is at least slow down an attacker or make it really difficult to execute an attack. When considering security for your infrastructure and applications, you need a healthy combination of preventative, corrective, and detective controls to enact such a thing.
Think of a castle, for example. You have a moat, a drawbridge, someone responsible for opening and closing the bridge, guards in a tower on lookout, and multiple gates and doors internally until you can get to the vault. Is it impenetrable? History has shown it’s not, but some had more formidable defenses than others.
If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.
Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service) and DevSecOps As A Service.
