Blast RADIUS

Episode 297 –

This week on the podcast we discover the newly-disclosed protocol vulnerability in certain RADIUS implementations. Before that, we give an update on the continued fallout from the Snowflake customer databreaches including a new disclosure from AT&T. We also discuss a blog post from JFrog that details how they saved the world from what could have been the worst supply chain attack in history.

View Transcript

Marc Laliberte  0:00  
Hi, everyone, welcome back to the 443 security simplified, I'm your host, Marc Laliberte and joining me today is Corey

Corey Nachreiner  0:07  
Corey Gollum smag precious Swan ring key Nachreiner

Marc Laliberte  0:12  
of like all the references of things that we talked about in this episode, we went with the one that is just absolutely not going to make sense.

Corey Nachreiner  0:19  
Unless you li see one little detail that we say and one little, just don't use classic keys that act as one ring to rule them all. That's the reference You'll find out soon as

Marc Laliberte  0:33  
you go. On today's episode, we've got a jam packed series of news events, we'll give a discussion on at and T's recently disclosed data breach that's a little bit more serious than previous telco breaches. We'll give an update to the ongoing ticket master breach saga, a blog post from J frog on a potentially serious supply chain attack that they think was stopped. And then we will discuss blast radius, the latest protocol vulnerability affecting a authentication service that a lot of us still use every single day. Are you

Corey Nachreiner  1:09  
telling me we don't have any stories about how Geminis help cybersecurity forever? Gemini

Marc Laliberte  1:14  
is not going to solve a single thing.

Corey Nachreiner  1:19  
So who cares a bedroom, it'd be chat GP chat GP will solve cyber security forever. Honestly,

Marc Laliberte  1:24  
stronger chance of that one, I think Google has lost the game. But with that, let's go ahead and blast our way in.

So let's start today's first story with yet another data breach. And this time involving a cellular carrier that is not T Mobile. So I for one, I'm actually really excited about this one.

Corey Nachreiner  1:52  
Unfortunately, I am less so considering this one's mine. Granted, let's be fair, while they're AT T Mobile has had many in a row. This one has had them before to like what what mobile company hasn't had them at this point. Exactly.

Marc Laliberte  2:07  
And honestly, so I guess let's get into the meat of it because this is a little bit more of a potentially serious one. So at&t disclosed just this last Friday that it had suffered a breach resulting in the loss of phone records and information for quote, nearly all of its customers. The stolen data includes phone numbers, both cellular and landline, and records for both calls and text messages during a period of May 1 2022. Through October 31 2022. Some of the stolen data includes more recent records from January 2 2023, but only for a small subset of customers. They also said that includes records from customers that use at and T's network, but like they didn't explicitly name them, but thankfully, you know, like cricket mobile, or what's it like straight talk, I think is another at&t one. They were very specific that this doesn't include the content of calls or text messages just like metadata, like call durations, or the number of texts and who they were conversing with. But it doesn't even include like the timestamp of stuff to

Corey Nachreiner  3:21  
we should know that submitted it I guess lack of timestamp is good. But based on like the Patriot Act, Patriot Act in the past, metadata sounds benign, but it's not you can like it, even without times. I mean, there's some times geo related data in networking traffic and stuff. So I you know, metadata can sometimes tell you the habits and locations of targets. This type of data that bounty hunters can use ping data to locate people cut some cellular phone companies, while they are restricted from selling it directly. They sell to a second party and the third party may not have the same, you know, standards, and they sell it to bounty hunters and others. So I would not downplay the danger of metadata on that point.

Marc Laliberte  4:11  
So some of the records do include these cell site ID numbers, which can help approximate location of where the call was made, or where the message was sent. And so like, let's go down that rabbit hole for a second, like bounty hunters is one example. And I'd like to think that our justice system is perfect and bounty hunters only go after people that are truly guilty of something. But

Corey Nachreiner  4:33  
the third parties don't validate the bounty hunters. I mean, there's a lot of sexual assault or domestic abuse cases where the stalkers have used the bounty hunter bind mechanisms to get this data before in the same story we've seen like probably it's seven and 10 years ago, we're still seeing stories about that.

Marc Laliberte  4:55  
That could picture like a like a like think like a journalist said tuition, maybe not in the United States. But if we were to take this to another country, for example, where you know, their phone number, but you're trying to figure out like where they live, this type of data could help you locate either where they live or where they commonly reside during the day. And so it could be extremely valuable for hunting down someone only just if you only have their phone number, for example. So it is, yeah, potentially pretty dangerous data to be out there in the void now, most likely to be leaked at some point in the future. Yep. So at&t says they learned of this breach back on April 19, which if my math is correct, is almost three months ago, despite the notification coming out today, at the time of this recording, or at least this week. The data was stolen from their snowflake data lake, as you're sharing on the YouTube video here, during that recent surge of data theft involving snowflake customers, which again, not a vulnerability in snowflake itself, almost

Corey Nachreiner  6:05  
involving snowflake, just more credential leaks of big big customers, including apparently at&t, where

Marc Laliberte  6:12  
it seems like the common factor is compromised credential and no multi factor authentication protecting that credential.

Corey Nachreiner  6:18  
Oh, that seems like a new thing. That's never happened before.

Marc Laliberte  6:22  
Exactly. at&t says that they're working with law enforcement on this and that even one person has been apprehended. That did not confirm if any, like insiders were involved in this. But I think you hit the point there quarry that. Like, even if it's just high level metadata, even without timestamps, being able to potentially geo locate a phone number is serious enough. This is a pretty big breach. And more so than other telco breaches that we've talked about, where it's just just quote unquote, like user PII. Yeah.

Corey Nachreiner  6:58  
And the phone number itself, Well, honestly, I don't feel like my phone number is ever private, just having more threat actors to have access to the phone number. You know, this happened, it may have happened even in 2002, right. So are 2022 I shouldn't say. Like, I've noticed, and I'm sure everyone around is noticed more and more as smishing texts. So like, it's, it's nice that 18 T and T Mobile are trying to get allow us to report these machine texts to them. But maybe if they stopped leaking our phone numbers for threat actors, we might get less of them too.

Marc Laliberte  7:37  
One thing that's interesting about this whole snowflake data leak story, and we'll have another update here in the next story, too. So Mandiant was brought in to investigate this overall data leak incident. I guess it's a breach, but not necessarily like a snowflake breach. They said something like 150 156 victims they've identified so far, that have had their accounts compromised and had data stolen from their data lakes. We've seen

Corey Nachreiner  8:08  
so many numbers, but I think that like when we first reported it, for some reason, I remember 110. So I feel like that the number of customers having credential leaks and the snowflake thing, it's not adjusting by a scale of 1000s. But I feel like it's picking up a little bit.

Marc Laliberte  8:24  
What I'm getting at is we've already seen some like big name companies like show up on Hackforums from like shiny hunters or spider hunters, which we'll talk about in a second. And I would have anticipated something like this to have shown up like with extortion demands. And so the fact that it hasn't that someone has this data, they can clearly tell like what it is like call records and tax records associated with Americans that use at&t or anyone that like, I wonder why why have we not seen this show up? And what are they potentially using it for? If they have they're just not gotten to parsing the data that they stole or

Corey Nachreiner  9:04  
could be many things. I mean, you and I recently, even as of a few days ago, talk about the what's the timeline of credential leaks. This isn't a credential leak, necessarily. But when people steal from a web application, a huge database of credentials. It's often a couple of years before it is quote unquote, leaked to everyone on the underground. And we talked about how the initial attacker is going to monetize that in the most valuable way at first. So I think one you point out the accurately. If it's a huge database, they need time to parse it. And when you're talking credentials, they look at the domain associated with email addresses. But depending on how this data is they probably have to look at a group of like, maybe they start with government and political and journalist names that they can find in the list. So I think you're right that they probably some is parsing. Then before you just sell this big data bases one a one time payment for all of it, of course, you're going to piecemeal it because maybe if you get the right government person, you can sell it for $100,000 to some state sponsored, you know, I'm making up numbers here, but you get my point, there's going to be certain names that are very valuable that they'll sell one at a time. But then they'll, they'll want to keep making money from it. So I think it just, I Marc knows this just as well as I do. I'm just talking about it. But I feel like it takes them a little time to figure out the value of the data they have. And then they tried to get the most return for small pieces of data at a time, at the point where they've sucked most of the value out of it. And then it's just a ton of consumers. And then they maybe tried to sell the whole thing for 10k, then people stopped buying that, and then they sell it for 1,000k. People stopped buying that, and then it just eventually shows up everywhere. And that's just turning towards, oh, I'm sorry. Yeah, I figured you were going that.

Marc Laliberte  10:59  
Like this is potentially very valuable data in the right hands, like I don't think random Bozo on Hackforums going to buy stolen data, this won't necessarily be valuable to them. But thinking hostile nation state trying to track down Yeah, owners of phone numbers, like Russia trying to off more folks, this could be half

Corey Nachreiner  11:17  
the underground forms normal people can get to like breach that toe or whatever the new domain for it is, every time the FBI takes it down. If you can get to that form without paying a lot of money or proving criminal intent, it's not the real underground. So there are probably levels of underground that only really deep threat intelligence people that have people that have gotten into those forms over time, perhaps even doing Gray Hat activities in order to be allowed on. So I bet you there is a more private and less public forum somewhere on the dark web where they start selling it at first. But by the time it gets to the ones that are easy to get to. It's probably long past the you know, it's probably the data is and people have used a good amount of the most valuable data in whatever that breach type is. Yep. I will say but oh, sorry. Go ahead.

Marc Laliberte  12:12  
Oh, go ahead.

Corey Nachreiner  12:15  
This is because the way we should end I think is what customers should if you happen to be a TNC customer, I just wanted to mention that AT and T does have a site up for for customers not only explaining it but also kind of explaining what you should kind of consider if you are affected by it. So at least for individuals, if you're an anti anti user, there is a practical takeaway for you to check out if you need to. Exactly.

Marc Laliberte  12:42  
And I guess my last thought on this was three months is a pretty long time. Yeah. On the the modern era of breach disclosure,

Corey Nachreiner  12:53  
especially when we know there's states that for mandatory data breach disclosure have have there is once I think it's for a month, that is only one month required. So lawfully, there's some places you might have to do it quicker. However, I think anyone that's gone through it incident knows that sometimes law enforcement itself, will will create orders that prevent you from sharing data until there have done an organism helped with they don't want to scare off the hacker if there's something still going on or forensic information they can use to pursue this attacker sometimes. Law enforcement doesn't want to really let the threat actor know the cats out of the bag. So my only guess like I, I assume at&t would follow the law and we'd at least do mandatory stuff. So there's things we may not know where, you know, is it the take that long for them to figure it out? And do it? Are they behind on Vermont? Or is it maybe they were asked not to disclose by outside organizations until they all did some sort of coordinated effort. That's what I am probably leaning towards just considering the the type of data here it could be valuable to keep it secret that they're aware of while law enforcement investigates it is something that I wish we could know because we 90 days is a while now for something that really affects a lot of people. So we would want consumers are going to start to judge companies by how good they are and how transparent they are and security. So even at&t, it will be in their best you know it to their best advantage to disclose earlier just to have customer trust will you know they might care why did it take 90 days so it might be even unfortunate to AT and T to have had to wait that long but hard to say if it's at&t been slower than others or if it's some other thing we don't know. I think even we have had our you know, we don't have naive eyes anymore. We understand that there's definitely some external influences sometimes

Marc Laliberte  15:02  
agreed. So speaking of evolving breaches, and also speaking of

Corey Nachreiner  15:12  
ticket master to bad we have to say snowflake every time because to your point, it seems like snowflake is getting a lot of because we mentioned it a related to breach it really is not their fault miss it other than not requiring MFA. It really was not their fault. I agree.

Marc Laliberte  15:30  
But speaking of other breaches involving snowflakes, data lakes, ticket Master is still dealing with threat actors, the ones known as spider hunters and Shawnee hunters, threatening to leak data that they stole from their their snowflake data lake. So last week, for example, spider hunters leaked 166,000 barcodes from Taylor Swift tickets. Ticketmaster was quick to respond saying that those are actually useless. They're a part of their mobile ticketing platform that has anti fraud measures, including rotating those barcodes every second, so one that was valid right now is most likely not valid anymore even a few minutes later. Spider hunters though came back just this last week saying ticketmasters lying about the impact, and that they also stole barcodes associated with physical tickets and print at home tickets. And they ended up leaking a spreadsheet with 38,000 Examples of these for anyone to have, including tickets, I think, yeah. 39,000 cluding tickets to artists like Aerosmith, Bruce Springsteen, Foo Fighters, Red Hot Chili Peppers, events like the Cirque du Solei

Corey Nachreiner  16:41  
Have you already lost your Seattle roots there in Texas you forgot Pearl Jam. Come on. You got a Seattle banned the grunge bands and there? Yep.

Marc Laliberte  16:53  
So these barcodes unlike the mobile tickets cannot be automatically refreshed, they can only be voided and reissued because they were either physically printed on a ticket that was mailed out, or generated for a print at home ticket that's sent via email. Spider Hunters also released a internal document from ticket master on how to turn this data into a printable barcode. So if you want free tickets to one of these artists, breach forums is the place to go apparently. But so spider Hunter is is still attempting to extort Ticketmaster and sell the rest of these, these barcodes. So I, it seems like Ticketmaster and their IT team is having a really rough week, or I guess a rough month after the snowflake breeches. And this one is a little more difficult to like, at least with a print at home ticket you in theory sent it to an email and so you can void it send them an email again saying by the way we suffered a breach and here's your new ticket. mailed tickets are a little more awkward because I mean a physical ticket now that you have to reprint tell them no don't use the other one hope that that you know seven year old person going to see fish or whatever is capable of recognizing they're using the right ticket like that becomes a quite a bit bigger of a challenge I think to recover from. Absolutely.

Corey Nachreiner  18:16  
Is it oh by the way, is these are horrible hackers, it should not happen. But the pop culture part of me doesn't really have too much sympathy for Ticketmaster.

Marc Laliberte  18:30  
couldn't have happened to a nicer company. Yes, I

Corey Nachreiner  18:32  
you not only should you increase your security practices, you should probably better your security and anti monopoly practices to but yes,

Marc Laliberte  18:42  
a little less monopolistic. And I'd have some more sympathy, I think.

Corey Nachreiner  18:47  
But yeah, it this is a harder one to recover. It's it is kind of interesting to see if a ticket Master has any response to this response. Because it's we don't judge any company including Ticketmaster for having breaches, necessarily, because we realize that it's a in the war against hackers, good guys have to do every single darn thing, right? And hackers need to just find one little mistake or leak or third party, you know, connection. And humans make mistakes. It's actually very difficult in big organizations to do everything perfectly. So we judge companies more on the transparency of their response. So my biggest concern with this is on the flip side also, by the way, I don't automatically trust threat actors. If you're breaking into networks and stealing things, you're not really a trustworthy source. But I am every time a threat group says that a company is publicly lying about something in their PR response. It does tweak my ears up I don't automatically trust the attacker. But I think transparency is one of the most important things You can't be transparent about everything. You know, we just talked about cases where law agencies may prevent companies from sharing certain details. And you also really can't share that a law enforcement has done that either. So but But certain things we hope to see companies be transparent about. So it'd be interesting to see how this develops. And if it, it comes to light that the threat actors are actually correct. And the evidence is, you know, it's a little bit compelling when you have CVS files and actual, you know, details.

Marc Laliberte  20:35  
So I think I can ticketmasters case, I guess, in anyone's case, if you are maintaining such a critical data store, I feel like MFA is probably one of the single most important things you should enable for protecting access to that data. Z. You remember the topic we never

Corey Nachreiner  20:51  
talked about? Right? Exactly. Why is it that MFA MFA? How many times does the industry have to say credential stolen and leaked credentials are, according to Verizon data breach report, 39% of these breaches are this and MFA is typically the fix. And

Marc Laliberte  21:07  
if you for some reason cannot enable MFA, which is not the case with snowflake. Credential rotation becomes important. Because for example, the the rumors around this one where it was a third party company, one of their users was compromised by info stealer malware like several years prior to this breach. And so even a simple credential rotation sometime over those past few years, could have potentially prevented this for

Corey Nachreiner  21:33  
No way. I think it is technically possible with snowflake. But even in the one use case where you can't have MFA, they do provide alternate like, for for user accounts with snowflake, you MFA is there and you can use it. But MFA but snowflake is again, one of those big database back ends where you often have service accounts. There isn't like maybe you could argue that the company connecting to snowflake should use user accounts for everything and not service accounts. But if you do have a service account, you cannot use MFA for it. But snowflake has a great write up on how you can use key pairs or you can use what was the other you can use OAuth. And they do have alternate authentication mechanisms for service accounts that are better than passwords. But like you say, if you really have to have a service account with a password, and you can't use a user account with MFA, you better be rotating in 90 days. Such a weird detail, by the way, because we encourage you not to rotate passwords with MFA. because users are not good at actually changing passwords properly. But if you don't have MFA rotation comes right back to becoming very critical. 100%

Marc Laliberte  22:47  
Yep. So something tells me like, I mean, as with probably most people in this world, the threat actors, in this case have a vendetta against Ticketmaster. So I'm betting This is not the the last story or last bit of the story that we hear these

Corey Nachreiner  23:03  
guys were supporting Taylor Swift who didn't like Ticketmaster for her audience either, I think, yep. Do you think like, if anything is big enough to get ticket master to change their practices? It is is it threat actors doing this? Or is it just Taylor Swift with all her Swifties I guess losing that audience a big enough monetary issue for tick,

Marc Laliberte  23:24  
I wonder what the US SEC is going to win with their lawsuit to break up the ticket master monopoly. High Hopes for that one. Anyways, moving on. So just this last week, actually, like today, at the time of this recording, security research firm J frog, who we've talked about a few times published a blog post describing how they helped prevent what they call one of the most catastrophic supply chain attacks in history against the Python ecosystem. So J frog there, they do source code analysis, looking for malicious code and secrets that may leak out into both public and private repositories, as part of what they call like a community effort. Or like community service effort they for free scan Docker Hub NPM, which is the JavaScript package index, pi pi, just the Python package index, to look for malicious packages and leak secrets. And in one of the recent sedans, they found a GitHub Personal Access Token from a user that had administrative access to effectively the entire Python ecosystem. So real quick GitHub Personal Access Tokens, they come in two different flavors. The more modern ones are called granular or fine grained access tokens where it's basically think of it like an API key to authenticate with an account. And you can assign certain permissions to certain repositories with these tokens. So for example, I could have a Personal Access Token with my GitHub account. gives like read access to a single repository. GitHub has an older, which they call classic Personal Access Token, which basically gives all the permissions the user has on all of the repositories they have access to. It's basically just an API key to assume that users identity on GitHub. And it was that latter one, the classic one that ended up leaking into a public repository. So they found this Personal Access Token from a user with admin access. Inside a compiled Python function inside of a Docker image on a public Docker repository. They noted that there's two potential attack scenarios for this. So one where an attacker could backdoor like a basic C Python function. So C, Python is like the core of the Python library, I guess, is actually compiled C code. It's not like Python scripts, which are still used, either interpreted by Python or even in some core library functions. So it's compiled code, which makes it a little more difficult to find things like a malicious implant, or in this case, the secret. The second scenario, which is extremely frightening was because this administrator had access to the Python package index like infrastructure, they could have an attacker that had this credential could, for example, tamper with or modify the Python package index and infrastructure to just inject malicious code into every single package downloaded from pi pi. That's a, this is honestly pretty scary if this had fallen into the hands of an attacker all from just a simple mistake. Like they walked through how they think that it ended up there. They said that the the administrator briefly added an authorization token to the source code they were testing. They then ran that Python script, which got compiled into a.pi. C binary, basically, Python, when you run certain scripts, in order to make it run faster, effectively, it'll compile it into binary code, and then execute that instead of interpreting the script real time. They then remove the authorization code from their source code file, but they didn't clean out that.py. C file. And they pushed both the clean source code and the unclean compiled code into this Docker image and

Corey Nachreiner  27:26  
the pie See, would we be where we?

Marc Laliberte  27:29  
We wanted we know exactly well, if they had just not pushed it through repository, you don't necessarily have to in fact, it's arguably better practices to not to, like have a Git ignore file that excludes those types of files, GS as they aren't updated as frequently as the source code. In good news for this one, though, so as soon as J frog found this, and they realized, like the potential impact, like the number of packages and infrastructure this admin had access to the immediately notified the Python package index as security team, who revoked the token and responded back to J. Frog and 17 minutes, which is a pretty dang quick response to this one, and extremely impressive from their security team.

Corey Nachreiner  28:18  
By the way, I was just going to add that we just got this supply chain issue a few months ago, that felt like it could have been horrible with X, Y util. Only because it's a super ubiquitous single package all over Linux. But like you say, this one's even worse, because it would affect many, many very popular packages. I mean, wow.

Marc Laliberte  28:44  
Yeah. The entirety of the Python ecosystem is how they described who

Corey Nachreiner  28:48  
knew WatchGuard supply chain predictions would never come true supply chains, not a problem, don't worry, people, you're fine. It

Marc Laliberte  28:56  
is honestly, this should be just a wake up call in general that a simple mistake like this, like a single user with elevated privileges using an older form of an access token, making one mistake and one file that showed up in a public repo could have caused extremely damaging outcomes in Python. Like the Python, it's nuts. There were some takeaways J frog had. So for example, don't just look for secrets in uncompiled, like scripts and text files, specifically looking compiled code as well too. If you are a software development organization, and you're using GitHub, go through and replace all of your classic GitHub if anything

Corey Nachreiner  29:44  
in any sort of like platform you use for Development says classic you should probably move on

Marc Laliberte  29:53  
that's all I don't know. I stuck around with teams classic for as long as I freaking good.

Corey Nachreiner  29:57  
But that's not like a key thing. to development, just a messaging application, um, but yeah, anyways,

Marc Laliberte  30:04  
I get what you're saying yes. And then also, when it comes to Personal Access Tokens, make sure you configure them with only the minimum level of access required. Don't just give it like effectively god mode to everything. You

Corey Nachreiner  30:18  
are not Gollum.

Unknown Speaker  30:20  
My precious one ring.

Corey Nachreiner  30:22  
Sorry.

Marc Laliberte  30:24  
There's one ring at one, we're wanting to roll the bones of that idea. And honestly, this goes beyond GitHub to like, if you are controlling permissions to an application, take the time to figure out specifically what access you need. Grant that and nothing else.

Corey Nachreiner  30:44  
Cool. Awesome story. Oh, say that. These privilege are zero trust. Wow, three stories. Interesting. Marc, there definitely couldn't be any other really security stories affecting us. That has to be enough when you went offline? Oh, there's what

Marc Laliberte  31:04  
there's more. Oh shoot. Last week, researchers at Cloudflare Microsoft, UC San Diego CW why Amsterdam, which I don't know that acronym, I'm assuming it's a college. And Bastion Xero published a white paper describing a protocol vulnerability in radius authentication. And they even gave it a fun little name, blast radius. The CVE for this one is CVE 2024 3596. And a successful exploit could allow an attacker to theoretically theoretically access any device that uses radius authentication without valid credentials. So the potential impact is substantial. But there are quite a few mitigating circumstances that I think makes this less severe than it potentially could have been. I

Corey Nachreiner  31:57  
mean, let's be honest, radius shouldn't be somehow internalized period. I mean, it doesn't have natural encryption of its own. So hopefully this is internal or over VPNs are over strongly encrypted connections. Yep. So

Marc Laliberte  32:11  
the adversary does need to have a man in the middle access between the victim device they're trying to authenticate into, and the RADIUS server that that device or service uses to authenticate. It also only specifically affects radius deployments that use pap chap, or MS chap v2. It does not affect deployments that used eet based authentication methods. extensible authentication protocol that I remember

Corey Nachreiner  32:37  
why you may not get into this happen chap are so old, and the vulnerabilities with them have been discussed for forever. So hopefully you are on to eat by now.

Marc Laliberte  32:49  
Yep. It also doesn't affect deployments where there's TLS encryption used, or other radius authentication, like 802 1x, or those used by like WPA two, or WPA three enterprise. So it relies on Performing a Successful collision against the MD five hashing algorithm that pap chap and MS chap v2 use

Corey Nachreiner  33:14  
are cryptographically secure algorithm, you can't collide that, can you Marc? Oh, wait, they depreciated that years and years ago? Hmm. It turns out

Marc Laliberte  33:23  
it's relatively trivial. So we can they've got a whole white paper that goes into the fine details about how this attack works. But we can do like a bit of a high level overview. So in the attack scenario, the attacker tries to authenticate to a vulnerable system with just any username and password doesn't matter. Neither of them have to be valid for this to work. Behind the scenes, that service will send what's called a access request message to the RADIUS server. If the credentials were valid, the server would send a Access Accept message back to that service, the user is authenticated, and they're allowed it. If the credentials are not valid, it instead sends a Access Denied packet back to the server pretty simple access requests and then either a accept or deny

Corey Nachreiner  34:13  
the as if you put someone in between.

Marc Laliberte  34:16  
So the access request includes a like 16 byte random value called the request authenticator. That also includes different attributes that you might use to say, proxy this through something else, or from the server side to relay like what groups the user is a member of. So there's different attributes that can be included. The server when it's returning its access, except it includes what's called a response authenticator value, which includes, it's derived basically from that request authenticator random bit, a shared secret that only the service and the RADIUS server should know and other data like some of those attributes for example. So an attacker should not be able to in person In a RADIUS server without knowing that shared secret that shared secrets actually extremely important and radius, because if you have it, you could impersonate the RADIUS server and just send your own access accepts all you want. Blast Radius works by intercepting both the access request from the service and the Access Denied message from the server. And it modifies the Access Request to include some additional data in the proxy configuration attribute. And it modifies the Access Denied message to convert it into a valid Access Accept message, it abuses something in Mt five or some an attack against envy five, called a chosen prefix hash collision collision, basically, you control the data that is being used to create the Envy five hash. And by modifying that data in a certain way, you can make the computed hash collide with another hash that might be accepted. So the attacker can modify the Access Request, they intercepted and modify it in a way that the data is included in the MD five calculation and with the right data that can forge a access except response that has a valid MD five that matches what the client is expecting. So you have to modify both intercept both do your random data modifications till you get an MD five collision, and then send that back to the service, it'll go, Oh, yep, and be five checks out, this all must be good. And the user with bogus credentials will get authenticated. Now in practice, again, they need to be man in the middle between these because they need to block the actual access, accept and denied messages from moving back and forth. And it takes around five minutes in order to compute a successful collision. And authenticate to the devices. Most radius configurations have a timeout of like 30 to 60 seconds. And so this may take four or five or six authentication attempts in that window. But ultimately, if you can man in the middle and modify these and you've got sufficient processing power, you can create a collision that lets you authenticate with whatever the heck credentials you by the way,

Corey Nachreiner  37:10  
I think there's going to be much better mitigation advice, we're going to be given in a second. But since it does take multiple requests to have enough time to do a collision, I presume one things people can do is pay attention to radius failed authentications. And anytime you see a number of them in a very short period of time, it should probably trigger you, even not knowing this vulnerability exists, it could be something you should always have alerts on via whatever, you know, incident response alerting system you use.

Marc Laliberte  37:41  
And also, I mean, just know that is right now. And every single day, it gets easier gonna get faster

Corey Nachreiner  37:47  
and faster and be five. So Moore's laws, computers get faster, collisions get faster, and maybe we'll be gone. Exactly

Marc Laliberte  37:56  
by this time next year, there's a decent chance that you'd be able to do that collision within the 32nd Timeout window. Yeah. So there are mitigations that recommend, for example, radius over TLS, which is called like rad sec, I think is the fancy name for it. And any Eapp based authentication protocols are immune to this particular attack. And again, it does require man in the middle in that connection, which is not a trivial thing to obtain for an attacker. It would require having access hopefully to the internal network, if you're hopefully not doing any radius,

Corey Nachreiner  38:31  
right.

Marc Laliberte  38:35  
But so I think this is it's a serious vulnerability, but I think the mitigating circumstances make it in practice, less practical to actually launch check ins are less likely.

Corey Nachreiner  38:47  
High impact and risk low likelihood.

Marc Laliberte  38:50  
Yeah. Quick response from WatchGuard. We do have a P cert advisory up on piecer.WatchGuard.com. That will continue to update as we launch our investigation in the impact high level it looks like because it impacts anything that uses pap chap or Ms. Chaffee to theoretically some VPN authentications, the firebox appliance could be vulnerable. Basically anything that isn't IP to which uses Eapp, Ms chap v2, so it's immune, but authentications to the other VPNs and even the port 4100 authentication page or Access Portal may be affected. It notably does not affect things like WPA two authentication for wireless both on access points and on Wi Fi. fireboxes if you're authenticating to a RADIUS server, and so it is a bit of a mixed bag depending on which service you are

Corey Nachreiner  39:43  
we know if we've gotten to the auth point part I feel like auth point probably uses radius in certain scenarios.

Marc Laliberte  39:50  
It can for like what the off point gateway and I think that investigation is still ongoing, but by the time we air this episode, that'll probably have changed and just check out the advisory on peace. Start WatchGuard.com But man protocol vulnerabilities are always a little scary because there technically isn't a way of doing it hatch. It's a protocol vulnerability, you just have to immediately deprecate your use and move on to something else.

Corey Nachreiner  40:13  
But on the flip side, I mean, like PAP and CHAP, they've been like in my mind deprecated forever, right? Like, yes. But it's cool. That's it's cool. When the protocol vulnerabilities you have choices of different authentication mechanisms and radius it'd be worse if the protocol was one option only. And there's a vulnerability in it. Yeah,

Marc Laliberte  40:35  
under percent. And always an exciting week. It

Corey Nachreiner  40:39  
feels like fun week fun week. Always world It's not morning. It's sunny outside babies are still laughing. We're okay. We are through this everybody. But every once

Marc Laliberte  40:53  
in a while, I just want to unplug everything and go live on an island somewhere where we didn't even

Corey Nachreiner  40:58  
get started. AI is going to make us get there quicker.

Marc Laliberte  41:04  
And on that happy note, make sure that you set up MFA and disable radius.

Corey Nachreiner  41:11  
And don't let AI recall everything you do.

Marc Laliberte  41:14  
Oh, everyone, thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate review and subscribe. If you have any questions on today's topics or suggestions for future episodes, topics can reach out to us on Instagram. We're at WatchGuard underscore technologies. Thanks again for listening, and you will most likely hear from us next week.

Corey Nachreiner  41:39  
Have you posted your lunch on Instagram yet? I'm sure inquiring 443 listeners want to know since you're not like the influencer