Thoughts on the Twitch Breach

What caused the Twitch breach and might it have been prevented?

One of my posts on Data Breaches.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

I always know a breach is big when my non-technical friends ask me about it. As I’ve said before in my cloud security classes and probably this cybersecurity blog and my cybersecurity book, you have to wait a few days before you can really say much about a security breach. In the first few hours, a rush of news comes out trying to be the first with the scoop. Everyone tells you to change your passwords and monitor your credit report if it involves consumers. The Twitch breach was everywhere and no different.

What caused the Twitch breach?

At the time of this writing, here’s what we know about the Twitch breach based on a statement from Twitch about what caused the breach:

[10/6/2021 @ 10:30PM PT]

We have learned that some data was exposed to the internet due to an error in a Twitch server configuration change that was subsequently accessed by a malicious third party.

Let’s break that down.

An error: It appears that the problem was a misconfiguration as this statement says something was in error. The attackers did not get in due to a zero-day or supply chain attack. Something existed in a non-compliant or expected state.

In a Twitch server: This would indicate the issue was with a Twitch server, not an S3 bucket. Only news reporters who don’t understand what an S3 bucket is call it a server. I presume whoever wrote this for Twitch understands that as well, so it does not seem to be a cloud data storage misconfiguration. It sounds like a server was running something on a port exposed to the Internet. If you are not familiar with ports and protocols and why this all matters I explain it in my book in a non-technical manner. However, the exposed data could have existed in an S3 bucket, as it did in the Capital One breach.

Configuration: Yes, someone caused a server to enter a non-compliant or unwanted state. It doesn’t say who implemented the configuration. Was the misconfiguration a result of an employee change or did a hacker get to someone’s credentials via a phishing email? Was social engineering involved or was it a disgruntled insider? We don’t know. All we know is that somehow, a server entered an unwanted state that led to data exposure.

That’s pretty much all we know and the rest is speculation.

Data exposure

Countless reports covered the exposed data in this breach. According to Threatpost, the leaked data includes the following:

The entirety of Twitch’s source code with comment history “going back to its early beginnings”

Creator-payout reports from 2019

Mobile, desktop, and console Twitch clients

Proprietary SDKs and internal AWS services used by Twitch

“Every other property that Twitch owns” including IGDB and CurseForge

An unreleased Steam competitor, codenamed Vapor, from Amazon Game Studios

Twitch internal “red-teaming” tools (designed to improve security by having staff pretend to be hackers)

Twitch claims no credentials were leaked in this breach. Wisely, Twitch does not store credit cards.

https://therecord.media/twitch-says-no-user-passwords-or-cards-numbers-were-exposed-in-major-hack

However, in the Threatpost article posted above, a researcher claims that password hashes got leaked. It’s always a good idea to change passwords after any data breach and ensure you are using multi-factor authentication.

Speculation

Based on the data exposed in this breach I’m wondering if the breach was caused by one of the following:

• Leaked administrative credentials that gave access to absolutely everything.
• Leaked credentials to a source control system since a lot of the data seems to be code.
• This could possibly be an SSRF attack similar to the Capital One breach if the information exposed existed in S3 buckets and a server misconfiguration exposed them.
• The misconfiguration could be something like too much permission and access granted to a server or a server got exposed to the Internet that should have been in a private network.

That list only consists of guesses. We can’t really know until we learn from the source exactly what happened. I hope they will share details so others can learn from it.

Governance

What we do know is that something entered an unwanted state. Governance is the effort to maintain systems in a secure state as defined by compliance or according to an organization’s security rules. I wrote about governance in a few other blog posts because I’m working on an updated class on AWS cloud governance now.

Security is hard, but the best thing an organization can do is automatically prevent misconfigurations through solid governance from the ground up. Leverage separation of duties through IAM Policies, enforce zero-trust networking that can’t be undone easily and prevent egregious exposure in an automated fashion. I can’t say for sure that would have helped in this case, because we don’t know the details, but it seems like it would have, based on Twitch’s statement that a server configuration was in an erroneous state.

Who’s making the most money on Twitch?

Let’s start with this. There are a lot of people on Twitch who are not making a lot of money. According to this article, you have to be in the top .01% of streamers to get big payouts.

An interesting note is that only 3% of the top Twitch streamers are women.

This report says 35% of the streamers are female.

One of the reasons for that could be that the top earners are mostly gamers. For some reason I don’t understand, people like to watch other people play video games. I know some women who are into video games but a lot more men and boys so that probably has something to do with it.

That said, I’m guessing people are missing out on some great content from women on Twitch.

I didn’t go through the entire list, but I did find at least one woman in the top 50. Several social media platforms just banned her and she can’t figure out why. I checked out her Twitter feed and it’s a bunch of photos of herself scantily clad. Way to represent and get females that respect they deserve. And way to support females putting out high-quality technical content, Twitch viewers.

Why was the Twitch breach such a big deal?

In part, because it involved an Amazon company, hosted on Amazon’s cloud service, AWS. So many people host their data on AWS and might be thinking, “If Amazon can’t keep data secure on AWS, who can?” Bear in mind that Twitch security is likely not governed by the same teams that govern AWS or Amazon. Twitch is a subsidiary of Amazon. Often companies have different people monitoring security within departments or lines of business in a company.

This was also a big deal because it reveals who’s making money, how much, and on what. People have been trying to glean this through various sources and now it is public knowledge. Knowing who makes the most money gives marketers something to emulate and patterns to copy.

As for the streamers, it makes some of the private information public. Some of them may like the notoriety but others may feel like now they are a target. This article has some of their responses:

The fact that Amazon paid millions for the company and all the source code got exposed probably isn’t ideal for the company. Now competitors will be able to dissect how they do what they do. This loss of intellectual property could lead to copycat sites and functionality.

The source code also reveals potential vulnerabilities attackers can leverage. Already we’ve seen a defacement of Twitch properties with a photo of Jeff Bezos.

Potentially attackers discovered that by way of analyzing the source code. More about how that works in this blog post:

The case for automated governance and zero-trust IAM and networking

As I already mentioned, organizations should strive for governance that prevents unwanted configurations. That’s step one in any cybersecurity program. If you can create automated rules to prevent misconfigurations, especially when it comes to critical systems that contain your intellectual property or sensitive data, that could help you prevent a data breach.

Leveraging an IAM strategy that doesn’t give one person or system too much access can also help. Limit administrative access and leverage segregation of duties.

Ensure you have zero-trust networking and permissions that only grant the necessary access for individuals and applications. Source control systems, if that’s what was impacted in this case, should never be exposed directly to the entire Internet in an organization of that size. Small businesses may do it temporarily to get by, but with most source control systems you can lock them down to specific IP ranges.

All these are topics in a new revision of my cloud security class coming out soon. I am expanding the initial configuration of AWS accounts to build in governance from the start and get deeper into IAM policies. In addition, I’ll be expanding the automation and networking portions of my class. Follow me here for updates.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab