Breach Alert at Dell

Jeremy at Firetail (00:01.07)
All right, welcome to another episode of the Modern Cyber Podcast. As always, I am your host, Jeremy Snyder, founder and CEO at FireTail. We're doing a little bit of a different thing today. This is one of a special series of episodes here on Modern Cyber. We're going to be analyzing a recently disclosed data breach around an API. Hopefully we won't do that many of these because hopefully the number of API attacks and breaches will actually be going down over time instead of going up as it's currently doing.

but we'll see how it goes. And as we find these events, we will bring them to you. And importantly, what we want to do today is to give you an understanding about what happened and how to think about maybe defending environments and designing APIs in more secure ways. And for that purpose, I am joined today by our security researcher, Victor Markopoulos, joining us from Athens, Greece. Victor, thank you so much for joining us today.

Viktor (00:52.912)
Hi Jeremy, thanks for having me on the podcast.

Jeremy at Firetail (00:56.334)
Awesome, awesome. So Victor, you do security research for Firetail as well as for other companies. I know you've been doing this work for a number of years now, just for fun. If you had to guess how many times have you found API vulnerabilities?

Viktor (01:11.888)
Well, depends. I mean, I've found big vulnerabilities like large impactful ones and smaller ones, but mostly every second API that I'm testing, there is some sort of vulnerability that could be impactful. So yeah, it's pretty common.

Jeremy at Firetail (01:33.07)
Yeah, fair enough. Well, today we're gonna be covering actually a name that I think everybody knows and that is Dell Computers. I guess now technically Dell EMC and a recently disclosed data breach. What do we know about this data breach so far, Victor?

Viktor (01:49.616)
So we know there's been 49 million records that have been breached by the thread actor called Melanick. We know the attack factor is the hebrary. They basically scraped an API through a partner portal. We know that the data types that were leaked, there weren't any email addresses, but there were physical addresses, full names, cities, and...

some other serial numbers of what those people purchased. And we also know that the bridge post is no longer online. The thread actor brought it down probably because someone bought the data or I don't know.

Jeremy at Firetail (02:36.782)
Yeah, yeah. Is that common, by the way, that the post goes down once the data has been purchased?

Viktor (02:43.104)
I'm not sure, I think so yeah. I've seen posts being brought up, like being coming online and then suddenly they go down. Probably someone already bought it. But yeah, it's common for them to go offline at some point.

Jeremy at Firetail (03:01.614)
Gotcha, gotcha. And I think one thing I should say before we jump into analyzing this attack is we have not been in contact with this threat actor. So the analysis that we're going to be looking at today really comes from the publicly disclosed sources. So we're going to be looking at information that we found from TechCrunch, from bleepingcomputer .com, from pcworld .com, from Dell's website itself, from...

Yeah, bleeping computer. And I think there might've been one or two other, but basically media sites where this event has been covered is going to be the primary basis of the analysis. So to that point, you know, let's dive into the analysis, I guess, help us understand kind of what happened and, you know, to the best that we can, how was the data breached? How was it extracted? How did the threat actor get access to the data?

What can you tell us if we start analyzing the attack?

Viktor (04:04.368)
Yeah, so basically also have to mention also that it's been covered by many news outlet media like Blig & Computer, TechRuns. So there's already a lot of analysis going on going on out there. So the third actor Menelik, they basically created a fake company that they asked from Dell through their own through their online portal to

to be partners. So they created a fake company or multiple fake companies. And probably this process is being carried out automatically by Dell. So there wasn't someone who could verify the details of the companies. And once they got accepted, they got access to a portal that they could use for...

scraping or actually for looking for some service tags. And what they basically did was they brute -forced the service tags. That's a seven digit number, seven digit string actually of alphanumeric characters. And they've been brute -forcing this for, as I said, for three weeks with 5 ,000 requests per minute. So that's quite a lot of logs and requests that Dell should be looking at.

Jeremy at Firetail (05:06.062)
Mm -hmm.

Jeremy at Firetail (05:23.47)
Yep. Yeah.

Viktor (05:32.048)
And yeah, as I said, that's a lot and there was probably no rate limiting or anything from Dell's point of view.

Jeremy at Firetail (05:32.206)
Yeah.

Jeremy at Firetail (05:43.566)
Yeah, it's interesting though. I mean, you mentioned three weeks and I know, you know, before we went on to record, we did a little spreadsheet analysis, but it looks like if, you know, if what they said is true, 5 ,000 requests per minute for three weeks, that's about 150 million requests and they got 49 million records. So that says to me that, you know, it's not every request was successful, like, cause there's a mismatch in the number of record counts, right?

Viktor (06:13.424)
Yes, it appears that they were successful in once every three requests. And to be honest, that's a pretty good rate.

Jeremy at Firetail (06:25.39)
Yeah, and it's... okay. Okay. I wasn't sure if that means that, you know, they had a good or a bad brute force algorithm that they were using to try to scrape this data.

Viktor (06:37.872)
It doesn't really matter, the algorithm matters that they kept going as long as they could and Dell didn't really stop them or had any monitoring in place. And yeah, one every third request being a successful one, that's a pretty good trade because usually, I mean, a pretty good one would be also once every five or 10, I think. So in my eyes, it's a pretty good trade.

pretty good, pretty successful at that.

Jeremy at Firetail (07:09.358)
That's interesting. So when you're performing, let's say, pen tests, or when you're checking for vulnerabilities, you know, you don't just stop at testing for one record or two records, you actually issue a number of requests to see if any of them are going to be successful.

Viktor (07:24.676)
Yeah, so in my case I do it as a proof of concept so I don't really run it for like three weeks. But yeah, you kind of have to be sure that brute forcing is also covered.

Jeremy at Firetail (07:30.958)
Sure, sure.

Jeremy at Firetail (07:41.31)
Yep. Yep. Yeah. And it's interesting. I mean, in addition to kind of, let's say the brute forcing aspect, like, you know, we search for service tags, Dell service tags, and you get the formats, and you get a number of formats, and there's probably different service tag types for different types of products. But then it's relatively easy to guess what a service tag should look like, right?

Viktor (08:06.544)
Yes, it's publicly available, the format of this service tag. So you can pretty much first calculate all the possible permutations of this service tag, and then you can just try them all together and see what sticks.

Jeremy at Firetail (08:27.726)
Yep. Yeah, absolutely. And I'm curious. I mean, if we think about kind of things that should have been done differently on here, you know, there's a couple of things that come to my mind. I would say like the first one is no rate limiting is really a bad security practice on an API, right? Because even a legitimate partner shouldn't be requesting that much data that quickly, right?

Viktor (08:53.296)
Yeah, also, yeah, it's pretty unheard of to have like, to send 5 ,000 requests per minute. That's almost like 100 requests per second, I guess. So yeah, this definitely screams that there is an automation, a script in the background.

Jeremy at Firetail (09:14.67)
Yeah. What are the other things if you look through the sequence of events here, what are the other things that you looked at and you said, they probably should have done better?

Viktor (09:26.064)
Well, for starters, they should have probably checked the legitimacy of those fake companies that the threat actor created. Of course, Dell is a pretty big company, so there should be also some kind of automation at least being involved.

But there should be some kind of maybe automation that integrates with some sort of background checks or information checks, as if this company exists or what information they provide. So that's also something that you shouldn't be allowing anyone to just integrate with your internal API systems and freely being able to request anything.

Jeremy at Firetail (10:17.326)
Yeah, it's just weird to me that, you know, you have a partner portal and you're not actually checking who's signing up and are these people actual partners? Right. It seems on the other hand, probably it should be more like a partner signs up with Dell and they receive a targeted invitation to the partner portal rather than self -registration. But I don't know. I know a lot of companies do partner self -registration, Amazon, Microsoft, and number, you know, so I can't really criticize that too much, I guess.

Viktor (10:26.512)
Yeah.

Jeremy at Firetail (10:46.99)
and then on the, on the kind of monitoring and yeah, yeah. Also big companies on the monitoring side, like what are some best practices in API monitoring that you think probably should have been in place?

Viktor (10:48.656)
Yeah, it's also a big company.

Viktor (11:01.604)
Well, definitely the checking the, I imagine the thread actor wouldn't be using just one IP source, but this is also always good to check if there is an enormous amount of requests from one IP source and definitely to have some sort of authorization checks.

to retrieve any data that anyone would ask. You wouldn't have... Sorry, from the start. And of course, some authorization checks should be in place so that you wouldn't allow anyone to freely request for the data of any other buyer.

Plus, I can imagine that there are some information that were given back from the API that's a bit excessive. Like, I don't know if a physical address should be given back to anyone based on a random seven -digit service tag. So this would be maybe some more information that should be given to the API in order to check.

Jeremy at Firetail (12:21.422)
service tag, yeah.

Viktor (12:27.856)
if that's something, if the legitimacy and the authorization of the requester.

Jeremy at Firetail (12:34.99)
Yeah, that's actually a great point. I mean, if we look at what was posted here in the data included, so just giving a service tag number, you get back a full name, address, city, you know, state or province, postal code, country, system ship date, warranty plan, serial number, Dell customer number and Dell order number. All of that was given back in response to just a service tag number. Now,

Some of that I understand if you think about the warranty stuff, you're probably using a service tag to call for customer support. And so that warranty information is interesting. But at that point, let's say when you're the service rep receiving the call, do you really need the customer's full address? Do you really need their Dell customer ID at that point? So that's a really interesting point.

Viktor (13:28.08)
Yeah, exactly. I'm not sure. Like I said, there should be more checks in order to retrieve this information.

Jeremy at Firetail (13:34.35)
Yeah. Yeah. Yeah. I think one of the other points that you mentioned just a second ago at the base of this entire event is really the authorization check. You know, should any partner be able to access any service tag record? Maybe there are legitimate reasons that the answer to that is yes. Maybe, you know, it's a global warranty or global support kind of thing.

But interestingly, you know, here, for instance, it says the top five countries are us, China, India, Australia, and Canada. Let's say that this threat actor came from France. Is there a reason that a random partner who self -registers from France should be able to access Chinese customer service tag, you know, information records, customer numbers, et cetera. So that authorization question, I think we can't overlook it, right?

Viktor (14:30.992)
Yeah, no, that's a good point. And don't think of cross -country information. Even within the same country, it shouldn't be happening. But yeah, the base of all these stories that the authorization, it's the baseline defense, so to say. Even if you get a fake random person posing as a legitimate company, partnering up with Dell, even if this happens, you shouldn't be...

having those authorization issues. So that's the actual, like the 90 % of the impact lies in the authorization, missing authorization actually.

Jeremy at Firetail (15:15.278)
Yeah, and in fact, I think that's the story we see again and again in API security is that it comes down to authorization time and again. Yeah.

Viktor (15:22.544)
Yeah, I think probably like, I don't know, 90, maybe not 90, but like 80 % of the cases that I see with APIs have to do with authorization checks.

Jeremy at Firetail (15:34.094)
Awesome. So well, that's 80 to 90 % of the cases that you see. For those that are listening, you'll have to see if that number matches what's coming up in our API security report, which will actually be released in the next couple of weeks here. And we'll have our analysis from the API data breach tracker available on the Firetail website. I think we'll leave it here for today, Victor. Thank you so much for taking the time to walk us through understanding this incident in more detail. And thanks for listening to Modern Cyber.

Viktor (16:02.096)
Thanks for having me again.

‍