Risky Business - Risky Business #739 -- ALPHV exit scams while Change Healthcare burns

Episode Date: March 5, 2024

In this week’s show Patrick Gray and Adam Boileau discuss the week’s security news. They talk about: The serious consequences from the Change Healthcare ransomware, and the need for a … nastier response Predator spyware maker getting a stern sanctioning A German military WebEx meeting gets snooped Mem-corrpution is still king And much, much more In this week’s sponsor interview Patrick Gray speaks to Karl McGuinness, Okta’s chief architect, about some new security improvements they’ve built into their IDP. Show notes U.S. Air Force employee charged with giving classified information to woman he met on dating site Ransomware attack on U.S. health care payment processor ‘most serious incident of its kind’ AlphV’s hit on Change Healthcare strikes a sour note for defenders | Cybersecurity Dive Office of Public Affairs | Justice Department Disrupts Prolific ALPHV/Blackcat Ransomware Variant | United States Department of Justice Developing: AlphV allegedly scammed Change Healthcare and its own affiliate (1) Hackers Behind the Change Healthcare Ransomware Attack Just Received a $22 Million Payment | WIRED Ciaran Martin on X: "“We have to find a way of making a ransom ban work” - me for @thetimes US launches antitrust investigation into UnitedHealth, WSJ reports | Reuters Brett Callow on X: "#Lockbit has de-listed Fulton County. Predator spyware endures even after widespread exposure, analysis shows | CyberScoop Predator spyware infrastructure taken down after exposure | CyberScoop U.S. bans maker of spyware that targeted a senator's phone Spyware maker NSO Group ordered to turn over Pegasus code in WhatsApp case Whatsapp Inc vs NSO Group Russia’s chief propagandist leaks intercepted German military Webex conversation The White House's Oddly Specific, and Really Quite Good, Software Engineering Advice A leaky database spilled 2FA codes for the world’s tech giants | TechCrunch In ConnectWise attacks, Play and LockBit ransomware exploits developed quickly | Cybersecurity Dive How to Secure the SaaS Apps of the Future | Okta Security

hi everyone and welcome to risky business my name's patrick gray and what you're hearing there is not our regular intro music it is sweet jane by the velvet underground terrific band some of our younger listeners might not know about the Velvet Underground, which was Lou Reed's band before he was, you know, Lou Reed. And yeah, there's no song called Sweet Dave. So we had to settle for Sweet Jane. What's on the screens in the special room, Dave? Sweet, Sweet Dave. Adam, did you hear about this?

I did. You know what? I almost feel bad for poor Dave. You mean Sweet Dave. Sweet Dave. This is like You mean sweet Dave. Sweet Dave. This is a US Air Force guy he's like 63 and the indictment for his

providing classified information to a presumably Russian spy. It's pretty sad reading unfortunately. Yeah he thought he was talking to

Natasha he was probably talking to Sergei right. So yeah. That's how it goes. Yes. This poor guy had you know

had been honeypotted over some sort of online dating platform and the transcripts are just... He's been arrested and I do feel a bit sorry for him as well. But, yeah, he was giving up all sorts of stuff and the transcripts are just wild because it's like,

my sweet Dave, what's on the screens in the special room? What do you call it again? The operations centre? You know, stuff like this. My God, why bother with all of this hacking stuff, Adam? Well, exactly. This week's show

is brought to you by Okta and we've got a terrific sponsor interview for you this week with Okta's chief architect, Carl McGuinness. Okta has introduced some terrific new features to guard against token theft and they've also introduced new integration options for vendors to use that really tighten things up. And obviously, they've had a bad run of headlines

over the last 12 months, which means the security team has been uncaged. And yeah, they've really come through with the good stuff. That interview is coming up later. And we did something unusual this week, and we're letting it run long, based entirely on editorial merit. So that's a 19-minute interview,

but I recommend all of you stick around for that one. Funny thing is, didn't do a single edit to that interview. I actually packaged it up and sent it to you, Adam, to see if you could cut stuff out of it and you had the same response as me. There was really nothing to chop there. It was a legitimately interesting interview, which i guess it's great when you

have sponsor content that's also just good content yeah it is it is yeah it's very cool uh so that's coming up later but yes let's get into the news now and uh look some listeners may have been able to tell uh that i was quite sick last week i wasn't at my best i was suffering from the toddler plague. But, you know, I'm back up to 100% now. So we're going to revisit this attack against change healthcare in the USA, because we touched on it briefly last week. And I guess the significance of this attack was kind of lost on me through my virus-induced haze. But it also has seemingly, like at least in terms of press coverage, it's certainly escalated.

Walk us through the latest with this because it's wild. It certainly is. So like Change Healthcare, it's a big American healthcare conglomerate that's involved in the kind of billing process and having prescriptions fulfilled and all sorts of things like that.

They got ransomware. The developments since then have been, the impact has been ongoing and we started to understand quite how big this org is. And then they were ransomed by AlfV. We saw a $22 million worth of Bitcoin transaction heading across the blockchain towards them. But then the AlfV administrators took the money, exit scammed with a fake FBI seizure notice on their leak portal and have absconded with the money. Which, you know, that's a thing that that group has done before when it was previously Black Cat and we've seen it with Reval and some of the other ransomware crews over the years. So not unusual, but it's really turned into a mess.

And there was some suggestion, I think you saw some reporting that said, yes, at least Change Healthcare did get the keys as a result of paying the ransom, but they're still in for a pretty rough ride. And, of course, the data theft portion was done by the affiliate who has not yet got paid and yeah big big mess it is a huge mess both in the ransomware ecosystem which we love to see and also in the healthcare system which we don't love to see i actually had a long call uh with someone who's a cso in the american healthcare soup uh this week to really talk through Change.

And Change is an interesting company because it does, as you said, it does a bunch of different things, right? It handles e-prescriptions and stuff, but it also handles things like pre-authorization services. And the big one that's really causing chaos is its claims clearinghouse, right? So you bundle up all of your claims,

if you're a hospital or a general practice or an urgent care or whatever you bundle them all up and you sort of submit them to change they go out and handle the individual claims and you know you get money but if you were using them as your sole provider you haven't been paid since this thing started right and we're talking about small hospitals and urgent cares is you know they're they're the orgs that typically use this service and it's where change really focused its efforts in building its business they wanted to be the sort of number one provider for the smaller places so bigger hospitals less likely to be impacted by this but some of them are still using various change uh change health care uh services and they've been impacted and some of them are missing

some money because of that, but they will prevail, right? Whereas some of these smaller groups, they can't even make payroll, okay? It's that bad. And Change is owned by Optum, which in turn is owned by UnitedHealth, which is a huge organization in the United States,

which has actually just had an antitrust investigation launched into it by the Department of Justice in the united states which is actually just had an antitrust investigation launched into it by the department of justice in the u.s but their response has been and i think this is good right which is they are looking at the last 90 days claims history for a lot of these impacted organizations and saying look we'll give you an interest-free loan based on your claims history you know and we'll rate it out like that. And then, you know, so you can keep the doors open. The problem is though, you know, agreements like that need to be legally vetted.

And most of these smaller healthcare providers don't have in-house counsel. So it's not the immediate solution that we would like to think it is. What it looks like happened here, they got some of their services back up pretty quick. Some of them are back, but a little bit degraded. Currently, the only way to process claims through change is to do them individually through a web portal, which is just not feasible when there are hundreds of claims a day, even in some of these smaller shops. So my sources

speculated, and I suspect that they're right is that probably the backups got encrypted for that particular service so this is really bad to put it mildly i suspect they've paid because they needed to um and you and i were having a discussion before we started recording about like why you would pay you know even recovering once you have decryption keys can be very very difficult but but quite often you know you're going to need those keys to do things like pull certain files out of decrypts right like you might need a config or a directory or whatever you're going to need to pull that stuff out to help you rebuild obviously 21 22 million dollars whatever

it was is a massive ransom that they've paid and i don't think they would have paid uh unless they absolutely needed to but what i have also seen uh as this has played out uh increased calls for a ransomware payments ban yes yeah we have seen that yes so we've seen people like kieran martin uh writing opinion pieces he's the former you know ncsc guy from the uk and uh you know i'm getting word just sort of filter through to me that this is now a discussion in policy circles to me this is a really strange reaction uh to something like this because i wonder you know they've paid they will probably be able to bring back services quicker because they have paid. I don't think they would have paid if they could have restored services another way.

So if we were operating, you know, there's two sides of this argument. If we had a ransomware payments ban, you know, the argument goes that this would have been less likely to have happened in the first place. But, you know, here we are. And my argument is if there were a ransomware payments ban right now, there's a distinct possibility that change healthcare could go under and that would create an unacceptable mess in the US healthcare system. So I think it's a strange thing to advocate for because of this.

Yeah, like it's a hard set of trade-offs to kind of wrangle with and you know this is i guess a good example of where you might consider like there's human lives at stake potentially um you know health care is super important and you know i don't think change health care would have done this if they had another way which clearly they didn't and you know people are going to get ransomed you know even if they do have to pay the ransoms through some you know byzantine process involving cutouts and middlemen and what because we already do have people who provide you know ransomware payment as a service to try and insulate some of the customers and driving that further underground i mean i don't i don't process We've talked about that argument previously on the show.

I don't know that I'm fully on board with that when it comes to large companies. I think large companies, I think they would honour a ban. They just would have to because it's the law. They don't want to lose their ability to be directors of companies and stuff by breaking the law. So I don't think that's as much of a risk, maybe for some smaller orgs. But see, here's some of the consequences of a ransomware payments ban.

First thing I'm doing if I'm a Russian ransomware operator is I am going absolutely berserk hitting American targets because what I'm trying to do is pressure the United States government to reverse its policy. That's the first thing I'm going to do. And I'm going to try to create a political problem for the United States by sending some of these companies broke with ransomware attacks and people will blame the government. Yeah, because I mean, that's the real question

is if we banned it, do we think ransomware operators are just going to pack up and go home and give up or are they going to escalate? Yeah, the second thing is they might start moving down market into attacking SMEs that will have no option

but to break the law to pay ransomware payment. So this is one of those things that sounds like a good solution. I personally don't think it is, you know, and you've heard me advocate for takedowns and for offensive action against these operators. And what we've seen so far, at least from the Americans and the Brits, is they're targeting these ransomware as a service platforms infiltrating them pulling down a bunch of intelligence and then rmrfing them off the internet that's not really what i had in mind when i said release the hounds you know this is good but you know we want to take it a step further how hard is it when you have access you know forget

about accessing the infrastructure as i've argued a of times, there's a small number of people who are responsible for 90% of this problem. Get on their endpoints. I mean, how hard is it to get a Russian in trouble these days? You've got a lot of options available to you, certainly. Email a bomb threat to the Kremlin from their computer. You know what I mean? Like, it is not – you do not have to be terribly creative to think of ways that you might cause some drama

for Russian ransomware operators. If you had infiltrated Lockbit, use their tools, use their infrastructure, go ransomware russian steel mill using their stuff see what happens yeah yeah that's uh they would definitely get a pretty swift visit from the authorities and you know given that they are already paying for protection presumably from law enforcement and so on like that stirs up a whole nest of problems you know because of the corruption as well. So, yeah, like that would seem to be a pretty smart way to do it, right?

And even if it comes out that it was, you know, Western involvement was suspected, it doesn't really matter because the point is you've got these ransomware as a service platforms. If they're being used as a vector to, you know, commit harms against the Russian Federation, they'll just shut them down. Yeah, yeah. I mean, I'm also in favour of, you know, commit harms against the Russian Federation, they'll just shut them down. Yeah. Yeah. I mean, I'm also in favour of, you know, slightly more creative use than just seizing the website.

And I think, you know, we've had the conversation about whether ransomware is a, you know, law enforcement problem, a la FBI, or whether it's a, you know, SIGINT kind of problem, or whether it's something else. And I think to solve these problems we need to be a bit more creative than law enforcement because you know we can't really apply pressure through law enforcement because you're not going to get extradited you're not going to get in real trouble at worst you have to pay a few bribes you know being a bit more creative and ultimately you know a bit more dirty you, playing a bit mean.

We need to make these guys a problem for Russia. And it's not hard. I can't imagine it's too hard. Now, I've actually had one person say to me, oh, but we would cede the moral high ground. I don't think so, really, given that Russia is providing a safe operating environment for people who are ransom-wearing hospitals. I think if you were to do a, you know,

data theft extortion attack wearing a lock bit hat, you know, I don't think you're really seeding the high ground there if you're going in there and, you know, causing a bit of confusion. I mean, I wouldn't recommend going and ransom-wearing schools and hospitals and whatever. You know, you would have to think about this.

I mean, I don't think there's any way policymakers will go for this, right? But this is what it would take. Yeah i mean to some extent like paying the ransom is also seeding the high ground and we're doing that so yeah like let's come up with some you know harm minimization approaches that are a bit more active uh and i think you know certainly posting you know how much you love navalny on Alpha V's portal, reasonable, easy start. It's a little bit obvious, but yeah.

Something like that anyway. I don't know. I mean, it's just one idea that I had, which is a complete non-starter, which would be to go and ransomware some Russian defence contractors using Russian ransomware as a service platform. That's two birds with one stone, you know. It is, but the problem is it's escalatory, right? And it would sort of be interpreted as NATO involvement and whatever.

And then you get the angry Medvedev speech about how they're going to nuke everyone. No one needs the additional headache. But look, my point is, you know, you've got to, yeah, as you said, you've got to play dirty. You've got to think about how to get these people in trouble with the authorities, with actual organised crime groups, you've got to, yeah, as you said, you've got to play dirty. You've got to think about how to get these people in trouble with the authorities, with actual organised crime groups, you know. Get them to look like they're doing something

untoward towards Russian organised crime. I mean, there's just so many things you can do here which don't involve just getting rid of a hidden service or banning ransomware payments. Like, get creative. It's a small number of people. Make their lives hell. Yeah.

I mean, this seems like a thing the CIA would know how to do. I mean, they're kind of good at sneaky stuff. I mean, we may have suggested this a few years ago. I think, like, maybe the FBI are just a bit too clean-cut. G-Men and the NSA are a bit too kind of nerdy rule followers, and we need the CIA to get in there and make some mess. Yeah, we need the ones who do the head games. Yes.

Anyway, but yeah, this exit scam thing, I mean... What do you expect, right? I mean, they've done it before, they'll do it again. It's part of the natural process in the criminal underground. You see $22 million come across your Bitcoin wallet. It's pretty tempting to just, you know, mirror down one of the seizure notices, copy it up to your own site and peace out. Yeah, indeed.

Now, staying with ransomware, but a different crew now. Lockbit had listed Fulton County, like the courts, I think, there and was, you know, saying that it had explosive revelations about Donald Trump and whatever. And the countdown was running. They've now delisted that from their new sort of backup leak site. And the thinking here, at least from Brett Callow, is that they probably lost access to that data

during the law enforcement takedown and were just bluffing and now they're pretending that Fulton County paid, which is somewhat disappointing because I always like a bit of spilled tea, even if it's an ill-gotten gain. Yeah. I mean, I guess soon this will be, you know, like, oh my God, the deep states assisting Biden campaign by suppressing leaks

about Trump and F philton county or whatever so yeah my personal favorite now is that taylor swift is working for the pentagon uh i think she just posted a message i think it was instagram i don't know on social media anyway she just posted a message encouraging people to like go and vote um and that's been interpreted as like you know pentagon deep state mobilization. America, you crazy. You crazy. I mean, there's so many problems in the world that we are going to have to arrive at world government to solve.

And like Taylor Swift is going to be, you know, the world government in 20 years time. So it's got to start somewhere. Empress Swift. Empress Swift. Yes. Planetary Empress Swift. Planetary Empress. Look, I mean, we could do worse we could do

worse yes ah what else have we got here oh now let's talk about intelexa yeah so they're the makers of the predator spyware they took down their infrastructure about six months ago it was last year sometime after a report essentially doxed a lot of it it's happened again uh which is interesting and this all happened this time because of a report from Recorded Futures' Insect Group, which was published last Friday. And yeah, I mean, they have just run to the wall and pulled the power cable for their infra based on it being exposed this way. I find this interesting in a few ways. I mean, I wonder why they would take such a drastic step. I mean, I think, you know, the privacy of their customers is a thing that they, you know, most of the customers that we're seeing here are national

governments doing it against political opposition and journalists. So being snapped doing that is not a thing that you particularly want out of your spyware vendor and in some of so some of the infrastructure that got doxed the first time has come back in the same country with a little more obfuscation and i think sequoia was another one of the research groups that was looking into it and they were looking at i think um some of the african countries where they had seen a change in how the infrastructure was kind of obfuscated whereas some of the other places like indonesia they had come back and were basically doing exactly the same thing before using fake news sites from um iria and jaya we've seen them like no real effort to change modus operandi but there were some regions some countries countries, where they had changed things,

and I guess that was a result of the previous leak. So I think it's embarrassing for their customers, and that's not a service that they want to provide. But it's just interesting that now the researchers understand how to spot their infrastructure. This cat and mouse has escalated very quickly, because we're talking days from them spinning up new infrastructure having to pull it back down again.

And that's great, like solid work from the researchers. No, it is. And it's causing them real headaches, right? Because now they have to rethink in a pretty major way how they're going to do this. I can't imagine it's going to be tremendously difficult to establish some infrastructure where at least the c2 component is going to be stealthy enough you know through a cdn or whatever but i mean that's the problem isn't it if you're trying to operate like a large-scale c2 network for surveillance it's not like you can just go do

you know use use some major cdn because they're just going to kick you off. Yeah, and if you're trying to make lures people interact with to get infected in the first place, do need to be public and kind of out there enough for people to see. You can't hide that step. For example, in Angola, they had previously had some directly in Angola infrastructure. Now they've moved to like Portuguese speaking, but malicious.

That's not directly Angola, but they're going to use for targeting people there. So they're trying to be clever about it, but there's a limit to how clever you can be, I think. Yeah. So. Well, the good times at Intellexa just keep rolling at them because they've been banned from doing business in the United States because apparently their stuff targeted a senator's phone. Yeah, I mean, that was always a case of, you know, f***ing around and finding out there because, you know,

you can't expect the US to not come after you after that. And so, yeah, they were on the, like, the entity list for export control like a year ago and now we're seeing like actual proper sanctions and i think this is the first case we've seen of a spyware maker getting like properly sanctioned as opposed to just entity listed and that's the companies that make up the intellects are kind of consortium cytrox is the the bit in north macedonia that makes the actual spyware, but they have sales organisations in Ireland and Hungary

and whatever else. But also the Tal Dillon, who was the founder, has been personally sanctioned. Yeah, and quoting from Kevin Collier's piece here at NBC, Americans and people who do business with the US are forbidden from transacting with Intellexa it's founded an architect Tal Dillian employee Sarah Hamu and four companies affiliated with Intellexa so yeah they're basically like you know the inverse Midas touch with these guys

you touch them and you turn to coal yeah it's one thing to to kind of make business hard like the entity listing bit does, but these level of sanctions are the sort of thing that if you wanted to be an investor or you wanted to work there, it might make you think twice because that's a thing that's really got the potential to mess up your life.

Yeah. Now, it's not just Intellectual, having a bad time. It's one that we love. NSO Group is being forced to turn over the source code to Pegasus in the case like WhatsApp has been suing them for hacking its customers and obviously Meta can afford very good lawyers because they've somehow convinced a judge that as part of discovery, they need the full source code to pegasus and the judges agreed and said yep hand it over which really i had to laugh when i read this um because i think

nso group had said oh well we'll just give them the installer not the actual malware just the part that does the exploitation and whatever and the judge like i've actually skimmed the judgment and it all seems pretty well reasoned the judge has just gone nope nope uh so yeah that's pretty funny and that's got a stick in the craw of i mean it's a group uh pretty pretty bad uh i i'm sure the you know security people at uh at facebook who get hold of that code will have quite a fun time digging through it and uh and providing some info i mean i don't know how they can use information to get in discovery but it would be i was wondering that as well like but i'm i would will have quite a fun time digging through it and providing some info. I don't know how they can use information and get in discovery,

but it would be a terrible pity. I was wondering that as well, but it would be real sad if that source leaked. Real sad. If that source leaked, right? If that accidentally got put on GitHub by mistake. Whoopsie, we checked it in. That happens to everybody.

Sorry, our bad, our bad. Real pity that someone forked it already and we can't delete it from the internet. Horrible,rible if that happens It's just amazing NSO is still limping along Honestly it is They've had such a lot of publicity around their product And people keeping an eye on

Where Pegasus is used I would have thought they'd closed up shop But clearly they're still making enough money to limp along That's right The cockroaches Of the spyware game, shall we say. Oh, yeah, let's talk about Webex because it looks like the Russian intelligence services got a hold of a Webex call

that was conducted by a bunch of German military folks and they were talking about possibly delivering Taurus missiles to – Taurus cruise missiles to Ukraine, and they were having a long discussion about that, and it was intercepted. Now, Tom Murren, our colleague, is writing about this one tomorrow because there's a bunch of interesting stuff here because people assume, oh, you know, conversations like this

are just going to happen skiff to skiff, you know, on high side only, on networks, and they're not going to be on, you know, low side devices and stuff. And that's just not really how it works these days. Like, the world has changed. And conversations like this, you know, can happen on WebEx and do happen on WebEx. But the way they got done here is that one of the participants was in singapore i believe i

think for an air show and so there was a lot of there were a lot of military types around there of course and of course there was some you know russian intelligence types stingraying the absolute crap out of every signal in the area and they managed to catch this when one of the participants dialed into the webex on their cell. Whoops. Yes, I mean, the perils of taking your mobile phone and using it in foreign countries is definitely a thing that I'm sure a lot of people who work in government mill know about. But the fact that the hotel Wi-Fi for some reason just probably wasn't working that day,

I'm sure that was a total coincidence and not at all involved in roaming you onto someone's malicious cell infrastructure. I did. You saw me wondering about that in Slack, right? Yes, yeah, yeah, exactly. So I don't know whether, you know, the Singaporean counterintel people, you know, need to go check what was going on on the network that day. But yeah, I mean, it's so easy when you run a WebEx call

or a Zoom call or whatever else and someone dials in midway through and they're coming from a cell phone or from some endpoint you don't recognise. It's kind of hard to stop and challenge them, especially when you're in a call with 40 people or something. I think when you're discussing the delivery of cruise missiles to Ukraine, it's reasonable to ask, hello, new person who just joined. But that's not what happened here.

It was actually captured by the looks of things from the cell phone uh you know from from the cell signal of of one of the participants yeah so like the etiquette i guess around you know how you deal with meetings like that i'm restricting it to only proper clients and not cell phone dialing or pstn dialing or whatever like we all got a bit loosey-goosey during covid and as you say not everything is done, you know, with high side level protocols because not everything needs that. But, you know. I don't know that anything terribly damaging came out of this.

And in fact, it actually counters some of Russia's key talking points, right? So the Germans are in there saying, well, you know, we've got to deliver these things, but we don't want to be involved in actually programming the routes of them because that would make us sort of a little bit more involved than we would like and how do we handle that? And, you know, that cuts against the Russian claim that they're at war with NATO, right? So I sort of wonder why they bothered to release this.

The other thing that struck me about this is the conversation on social media is like, oh, look at the Germans using WebEx, what idiots. But I sort of wonder if that's the message here, because if it were not for someone dialing in, in an insecure way, like the call would have been fine, right? So you would not have been able to pick it off the network, the encryption would have held up. The way then would have been to, you know, if you had an implant on one of the unclassed devices that this was happening from. And, you know, you've always got to balance this like you know do you slow down this conversation and everyone needs to be in a skiff using you know high assurance devices or do you let this happen

on devices that are you know connected to the internet but also sort of well managed and and and whatnot you know with your edr and all your custom rules and whatever so you know i think the the blanket assumption out there that you know using commercial off the shelf video conferencing stuff is inherently makes makes the germans idiots i just don't think that's correct no i think that's a that's a good take modern crypto on the internet you know has been battle tested i suppose in ways that the you know the phone network everyone enjoys uh misusing and you know second agencies that's their their bread and butter so yeah yeah exactly some very happy russians out there with their stingray yes just doing it old school yeah um now look uh another thing i wanted to follow up on

is last week i think you and i got it wrong uh we got it wrong on the white house's report into memory safe languages, because on the day you and I were both like, well, you know, there's an awful lot of problems out there. And this seems very oddly specific engineering advice for the White House to be issuing. But then our colleague, Tom Uren, did his thing, which is to go out and actually research this instead of just shooting from the hip and flapping his gums like we do it. And he found that of the exploits that popped up in the wild in like the Google tag report, you know, covering, I think, last year, calendar year, you know, a substantial portion of them

were related to memory safety issues, right? So it was kind of amazing that still such a high proportion of the issues that we're're focused on despite all of these mitigations around memory corruption vulnerabilities so many of them would be just wiped out if people were to listen to the white house and and adopt memory safe languages so i think i think it is actually i'm sort of revising my position right what's the point having a mind if you can't change it i think i've swung around to thinking that the White House issuing guidance here and a bit of a roadmap is really good. And of course, because best practice today becomes table stakes in the future. And I think that's really what the White House is trying to signal here, which is if you are a

startup, you know, you're starting out, use a memsafe language, or you're just going to be ridiculed in five years from now because this is the direction we're going to make the world go. And I think it is a good thing. I didn't realise such a proportion of what actually pops up in the wild was related to memsafety. I thought logic bugs were just much more prevalent now. Yeah, I was also surprised actually when Tom showed us the numbers

for what percentage were actually either mem corruption or memory safety related and it's you know in my career as a pen tester it wasn't that often that we did memory safety bugs when we were finding novel bugs in people's stuff but it wasn't often that we would use memory safety tricks and in my hacking we tended to not use memory safety bugs because the reliability side of it was difficult. And we were very concerned of, you know, not breaking the things that we're testing and causing the exact problem that we're trying to prevent. But, you know, for the high value targets, which are phones and browsers and things, memory corruption bugs and

memory safety bugs are really still very, very widely used, and more so than I realized as well. So that was a good kind of reality check from Tom, because the sorts of things that you need to deploy a Pegasus or to deploy nation state grade stuff, memory corruption gets the job done, and the other concerns about it are the trade-offs are different in that world. So, yeah, I mean, I think you're right. Like, anything that moves the needle is good, and I didn't realize quite how much memory safety there was.

Let me just read the stats here. In 2019, Microsoft said that 70% of the vulnerabilities to which it assigned a CVE were memory safety issues. In 2020, Google said that 70% of its severe Chromium browser project bugs were related to memory safety. And 75% of the ODA Google found in the wild last year took advantage of memory corruption issues. So I didn't realize it was still a majority. know let's contrast that right and and probably the reason i was in that frame of mind last week is we were talking about stuff like this connect wise screen connect vulnerability why don't you just explain so this is also real funny and kind of frustrating because

we got look cyber security dive is a is an outlet we've been using to like as part of our daily news scrape for a while, and this is not intended as a criticism of them. They actually do really good work. I think they're one of the better InfoSec news outlets these days. But this one's funny because they say, in ConnectWise attacks, play and lock-bit ransomware exploits developed quickly.

Adam, why don't you explain to us what the exploit actually was? Because we talked about it last week. So the exploit here was, there's like a setup process that ConnectWise, you know, Connect Secure appliances go through when you initially set them up. That setup process, like you hit, you know, setup.aspx or whatever it was.

And there was access control on that. But if you whacked an extra slash on the end because of the way.NET you know routing works that gets delivered to the endpoint the endpoint checked for the literal string you know whatever it was you know setup page.aspx and if it had a slash on the end it didn't match that check, and you could bypass it from there to system code exec. So a pretty dumb bug, and the fact that that got used quite quickly, not really that surprising, I suppose.

Yes, it's surprising to see that turned into a headline. But this is also the problem when we see people who are less technical talking about the issue of zero days yes right because they talk about zero days as if they're all created equal like an end-to-end chain and ios is one thing and then you've got add an extra slash and that's another thing through the setup page yeah yeah and i think the reason i got twisted up on the memory safety stuff is because, you know, a lot of these bugs we're seeing in enterprise stuff these days, it's not related to memory safety. Because you don't need to do that, right? Like, because you can just dot dot slash your way to great victory.

One of the interesting stats that Tom pulled out was, so 75% of what Google Chromium bugs were memory safety. 25% of the SysRKev list is memory safety. Yeah. So that kind of shows the like for broad exploitation there are many things other than memory safety bugs for targeted real high value stuff memory safety is the thing that still delivers the goods you know 20 30 years after when we started to understand what you could do with that. No, that's the thing. That's what I'm getting at, right? So if you look at SysEcav, it's like memory corruption bugs

are not the one, you know. They're not the one. But if you look at, you know, what's happening to human rights defenders and stuff, it's going to be a memory corruption bug. Exactly, yeah. So it's just interesting that there isn't really one single answer anymore because technology is so complicated and the types of bugs and the types of reasons you're using hacking are so varied.

But, you know. But can we stop talking about Oday as if it's all the same? Yes, that would be a good choice, yes. Anyway, let's look at this one from TechCrunch now. SMSs. So, you know, SMS multi-factor auth has been a bad idea for a while for lots of reasons like SIM swapping and so on.

But this one just tickled my fancy when I was reading the news list and I wanted to put this in for the, like, it was my submission for the skateboarding dog segment at the end of the news where you have a little uplifting, amusing story for people to, you end their listen on um this is a company called yx international that's involved in in like sms delivery and so on used by platforms when they're building sms related things uh they appear to have left their database of text messages or the system that handles their text messages on the internet so you could and i'm going to assume this is like a mongo or a redis or whatever

you could just in real time see people's auth text messages with their multi-factor codes being delivered um which you know there's lots of ways this can go wrong, but this one's pretty bad. Yeah. I mean, I guess this is the sort of stuff and the bug that we just talked about. That's why I'm like, yeah, okay. Like, because last week, you know, I'm down with the toddler plague. I'm feeling really sick. I can barely concentrate. And I'm like, yeah, as if this is going to fix it when we've got, like,

you know what I mean? It's like, oh, God, even if everything was written in Rust, like, this is still going to happen. Yes. Sigh. We should write everything in Rust, like this is still going to happen. Yes. Sigh. Should write everything in Rust and we should fix dumb stuff like this. Yeah.

Yeah. Well, mate, that's actually it for the week's news. We're going to crack on into this week's sponsor interview now, but a pleasure to chat to you as always, my friend, and we'll do it all again next week. Thank you. Thanks very much, Pat. We certainly will.

That was Adam Boileau there with the Check of the Week's security news. It's time for this week's sponsor interview now with Okta's chief architect, Carl McGuinness. And as you know, Okta has been on the receiving end of some negative press, shall we say, over the last year or so. Some of it deserved, some of it not. But the end result is that Okta was developing an image as an IDP that needed to improve its security. And they have. They've introduced a bunch of new features.

So you're going to hear Carl talk about some very clever steps Okta has taken to combat token theft. He's also going to talk about ways app providers can integrate better with IDPs like Okta, you know, through some of these new features. And honestly, one of the reasons he's done this interview is so that all the CISOs listening to this interview can encourage their vendors to adopt some of these new features. Like one of the features they've introduced is universal logouts. And Carl actually didn't have time to talk about that one in this interview. But yeah, vendors can now actually log people out of apps

based on signaling from the IDP if the app vendors implement that feature at least. And yeah, that means no more manual revocation of sessions. Okta is even suggesting language you can put in your vendor questionnaires for that one. Like SaaS applications must publish a standard interface Okta is even suggesting language you can put in your vendor questionnaires for that one. Like SaaS applications must publish a standard interface for revoking access to an application, including OAuth tokens.

So they're trying to help you along to put the squeeze on your vendors there. I've linked through to a blog post Carl has written about this, but yeah, I'll drop you in here where Carl explains one feature where you can now pin sessions to like network ASNs, which is a really good idea. Administering your identity infrastructure is going to come primarily from a stable environment, which means we can bind a given session to a network zone, an IP address, or an ASN from an ISP, assuming that that workload is going to stay somewhat consistent for an

administrative task session. So if I'm trying to like do a use case, I got a help desk ticket, I'm doing something that's going to be relatively fixed for that task. It may change, you know, I pick a task up tomorrow or something I'm doing. At that point, we would just re-auth you again and rebind the new authentication context to that ASN and to the IP address. So we shortened- Sorry to cut you off there, but I thought the ASN idea was a really good one because that covers your admins who might be working from home. But I mean, they're not going to change ISPs, right?

Exactly. Their IP might float around and I just thought, huh, okay, pinning it to an ASN, great idea. Yeah. And the beauty is that if it does change, it's self-remediating, meaning that we just go back to the user and ask for a phishing-resistant auth again. So it doesn't block them. It just puts that friction point back into it,

which is, again, there is scenarios where you have a laptop maybe, and you're at a conference or something, and you got a text, you got to go do something, and maybe you go from your bad Wi-Fi to your tether to your phone, and you might cross ISPs at that particular time. These are all edge cases that are out there in the world.

But again, if that 80% use case is low friction where you don't have to keep re-authenticating and the worst case scenario is for the administrators, we bounce you back to a phishing resistant auth challenge. It's the right tradeoff for security usability for where the technology is today. 100%. It's the right trade-off for security usability for where the technology is today. A hundred percent. So continuing on that thread is that that's some of the investments we've made in the Okta service and sort of how we've addressed some of the challenges today. But we've spent a lot of calories looking at how can we really make a dent in this going forward in the ecosystem. And there are a couple of key technologies that have been sort of been incubating for

a while that are ripe and sort of mature and ready to start being adopted widely by applications. So the first technology really is called out of the OpenID working group is called Continuous Access Evaluation Profile. And this has been something that we've been incubating with some others in the industry for many years now. And we've finally gotten it to a fully baked form and we announced support for it at our conference and with our first vendor which is Apple and it's a pretty interesting use case that I want to kind of articulate the use case and then I can go into why this is an interesting protocol so Apple has obviously managed devices for the enterprise I want to have my iPhone or my Mac managed by

corporate IT and I need to be able to use a managed account to sign into my managed iCloud so I can get access to some of the management functionality that's available by Apple's products. So Apple has its application connected to the IDP. It has access and signed in. And once you sign in on your device, the device can synchronize data and connect to its cloud services like iCloud in the background. So what happens if in the identity provider, I go in and, for example, I do an MFA reset as an attack vector and I try to reset a user's user authenticators and then try to sign in. I don't want to keep that user signed in on the device into the iCloud. I want iCloud to be able to force a re-authentication of that user back to the IDP again because something significantly changed in the security posture assumptions

of how that session or that long-lived session was created. So continuous access evaluation profile is sort of a published subscribe protocol that standardizes a set of messages that an identity provider can send to an application or an application can send back to an identity provider to provide an update saying, hey, this significant activity has happened. You may want to take action. So in the case of Apple, we're saying a credential changed event or a session was logged out so that the Apple control plane for its backend can respond to that and no longer assume that the long-lived user experience of me just being on the device should stay that way, that it needs to do

something to force the user to go back to reestablish itself. That previously was not something that was really possible because really the only control from a standard perspective was really this SCIM-based deprovisioning mechanism, which was as an IDP, I could sign a user in, or I could say the employee is terminated, kill everything. But the kill everything definitely has side effects, right? For example, it may destroy a user's data in the application. It may be irrevocable.

It may have all these other downstream effects. What really what I want is I want to reattest or reassess the user's assurance. I want to make sure it's them. I don't necessarily want all the side effects of a termination. So there's no ability to sort of tell the application that, hey, you may want to do these other things related to a security change in my assumption of security posture, like the device health, the user assurance, something changed on the security posture, a policy changed in the product, without me terminating you. So now we have this other ability to go to the application and inform it that these key events are happening on the IDP side that gives the ability to the app to

respond. And that's a pretty significant enhancement for these applications as we increasingly lived in these long-lived session outcomes. Apps today are no longer just cookie-based in the browser. You have native applications with signed-in OAuth tokens that are permanently accessing synchronized data for weeks, days, months that need to be managed over time and forcing the user to sort of like time limit those tokens to hours and then pop the browser up and re-authenticate through at a fixed interval when there was no change to the security posture creates user backlash. It creates help desk tickets. It's why am I always having to sign back into my Zoom client or my chat client just because you want to be able to re-evaluate the posture. So with this continuous access evaluation profile,

there's a way to evaluate posture in the background if something changes then do the notification and then have the parties respond and it creates this bi-directional communication capability that wasn't possible with skim and sso yeah it's pretty significant for the security landscape to help move the needle on this long live session problem statement yeah i mean there's it's always been kind of frustrating right that you get your app to trust your IDP, your IDP says, yep, this user's good, and then the IDP kind of loses visibility as to what happens next, you know?

So if there has been some sort of token theft and the attacker just takes that and uses it straight with the app provider, you know, the IDP doesn't see that, can't do anything about it, so there are blind spots, right? So I'm guessing that this type of back and forth messaging between IDPs and application providers, like it's going to be, you know, it's going to get broader and broader, right? Like this

is just one step, I'm guessing. Yeah. So this is a key building block, right? So we didn't have a standard building block. We've now defined the building block. We now are starting to find the key use cases for the building block and particularly credential change events inside of the account, as well as token revocation or session revocation events can be broadly communicated across an ecosystem. Oh, just quickly, will you be able to, like, for example, we were talking about pinning sessions for octa to asns i mean i imagine through extensions like this you would be able to pin those tokens like app providers will be able to pin those tokens to asns as defined by the idp etc etc exactly yeah okay cool yep yep and so then then also if the asn changes legitimately or something for some other reason you could broadcast that out to a bunch of other parties and they can subscribe to it and then update their pinnings on their side. Yeah.

So it's more of a fundamental communication layer. And then some of the key standard events drive some of the use cases. And so we're doing a use case driven approach on adoption of the events. And we'll always be adding more events as we find commonality around use cases. But just that communication layer wasn't really standardized. It was this one way I signed this SSO, throw it over the wall, no idea what happens. I can't really talk to it again later. Now I can have this ongoing conversation about a session. So I have the session ID and I say, hey, there's this other thing you may want to know about this session ID. And you can keep adding context or refreshing context over the life

because you can just keep telling, hey, this context changed, this context changed, and then allow the other party to update accordingly to it. Yeah, now this is probably the big, you know, sophisticated change that we've seen because, you know, obviously Okta is doing a big push at the moment to make security a selling point after, you know, a lot of negative press, let's be honest.

But, you know, there's a bunch of simpler changes that you've made here as well. There's going to be step up auth for critical tasks, zero standing privileges for Okta admins, requiring MFA for access to admin consoles. Okta's made a bunch of changes just over the last couple of months, right? Agreed, totally. So protect our service. We're the foundation as the IDP. So our barrier has to be much higher because if you can take over account takeover, session takeover at the IDP level,

the blast radius is significant because all the other applications trust the IDP. So as I mentioned at the beginning of the conversation, we've done a bunch of work to use the technology available to do the session-bounding, IDPD-bounding, do MFA re-auth, require MFA for administrators,

invest in device-bound phishing-resistant authentication. A lot of folks out there, even just at the MFA level, are still operating sort of on this traditional phone-based authentication model of SMS or push-based authentication,

which was sort of like the Gen 2 gold standard. But that now isn't sufficient to today's attack vectors with phishing. And so phishing is becoming such a scaled attack vector that you really need phishing resistant authentication end-to-end across these things. And so even that's just its own adoption awareness campaign from a rollout perspective. So that's how you're treating it? Like an awareness campaign is what you're doing?

Well, it's mandatory in our product for our use cases going forward. We're giving it for our administrators for free for access to the Okta applications. So it's like YubiKeys or whatever. YubiKeys is an example of it. We have a software-based solution. We call that Okta FastPass.

So that's something you can install on your actual device as well as adopting a pass keys, which is the industry standard for phishing resistant authentication going forward. So we're not dictating any of these. It's sort of, they all have different use cases, but- But you are mandating phishing resistant MFA for admins of the future, is that right?

We're mandating MFA right now. And then over time, I have to go back and check the rollout schedule, but getting MFA is a requirement for accessing the administrative access. And then we provide a free phishing resistant authenticator as part of our software based authenticator. Making that mandatory, I'd have to get back to you on deployment guidelines for when that may be happening, because there's a bit of making sure there's enough of the authenticator distributed to make

it. Yeah, yeah. No, I mean, but that's why I'm asking about it because that's, that's a tough nut to crack, right. To actually get people to go and use the stronger technology here. I mean, that's why I'm like, wow, you know, do you have a plan for that? But, you know, I certainly wouldn't judge if you're not making it mandatory because it's a, it's a heavy lift. The key part is that we're providing a software based solution out of the box.

That's the key. That's the key bit. So you don't need to go procure, buy additional hardware tokens. You don't need to get anything else besides the Okta service. So within the Okta service, when you sign in, there's an integrated onboard and roll flow. You download the software agent on your phone or on your desktop. You do an enrollment. You have a phishing resistant device based authenticator built onto your platform for your use cases, all part of being an admin of Okta. And then making

that the default policy for all administrative access, I have to get back to you. I don't have that quite handy. If that was part of the first rollout or not. That's just my curiosity. Now, look, I understand one of the reasons that you're here to have this conversation is because uptake on this sort of messaging part that we were talking about just earlier where the application can speak to the IDP and back and forth like that. Adoption on the application vendor side has been not what you would like. I mean, it's very new, but you would like to encourage CISOs who are listening to this to then encourage their application vendors to participate here. Is that right? it's very new, but you would like to encourage CISOs who are listening to this to, you know, to then encourage the application vendors to participate here. Is that right?

That's correct. I want to back up one second, because there was a second technology investment that was foundational to the ask. So the first part was this continuous access evaluation profile coming out of OpenID Foundation. The second is really proof of possession tokens for OAuth. So OAuth has standardized a proof of possession token specification called DPOP, or Demonstrating Proof of Possession. It's how you can take a key, a private key, and bind an OAuth token to a private key so that only the holder of that private key can use an OAuth token. And so a lot of SaaS applications today are based on OAuth for how they native apps access their cloud services, but they're not using this DPOP standard to bind their access and

refresh tokens to the individual device. And so the foundational ask is that if you can bind your tokens to your device and you can use CAPE to signify changes in long-term sessions, you can significantly increase the security posture of ensuring that these native applications that have these long-lived access can only be run from a device that came from the IDP authorizing that. And if anything changes on the IDP or credential context,

you can send a message to the application to destroy the tokens. And so that's sort of two parts that are kind of needed. The cape alone won't necessarily solve the problem if you also don't sort of start moving your implementation to proof of possession tokens on the OAuth layer. Yeah, I mean, at this point, you know, an attacker needs to be on that box, right?

If they want to get a usable token. So you've shifted the bar from just like, yeah, some sort of simple token theft to you must have malware on the box and do a bunch of really tedious reverse engineering i mean it can still be done but it's harder it's harder and you have to do it on the device so you have to continuously run your software of attack on the device which is then trying to shorten that window because edr and other security technologies that you may have in your environment gives you a time to detect and remediate because

they can't offline take that token to some other device that is not on your network or not under your visibility and keep running the attacks. Because it has to have the private key on the device to be able to send the tokens. I mean, I'm assuming then that that private key is in some sort of secure enclave and it can't just be walked out, right?

So that's it. That's a choice on the SaaS vendor. If the device has TPM when they generate, the standard just tells you how to do the key binding, but not where the key comes from is up to your deployment. Yeah, yeah, cool. So you would like to encourage application vendors to get behind this.

I mean, it's fairly new, so I'm not surprised that uptake isn't quite there yet. Have application vendors been responsive when you've approached them and said, hey, this is a new thing that we're doing. It needs you to cooperate. Yeah, So we've gotten some early signal that, hey, this is interesting. Some of the larger organizations have CISOs themselves that have been bit by this in other key applications and identify the need. But when you sort of get to

the enterprise product manager that owns some of these requirements, some of the messages I'm hearing, at least, is that this hasn't come up in their conversations. Their customers are not coming to them saying, you know, sort of this was similar to five to 10 years ago when, you know, you could say that SS, maybe 10 for SSO, but five years for SCIM, a PM in those organizations would say, oh, I don't know, I don't have a user's API, go figure it out. And it was a combination of both the customer and the industry driving the vendor saying, no, I won't buy your software unless you support, you know, SCIM to do lifecycle management. We haven't gotten to that level of sort of ask from the community on how long-lived sessions should be managed inside these SaaS applications. It's left to an exercise for the reader. So whether it's these re-authentication strategies, whether it's IP ASN binding, whether it's support for CAVE, additional support for token binding for your OAuth tokens, there's a set of requirements that we think the app of the future should every app should have it's moving the needle from SSO and skim is good enough to SSO and skim are table stakes it's these

six to seven other things that are now becoming what is the future table stake that we need to start seeing roadmaps and adoption of for us to have that long-term relationship with you as a vendor of your software that's the conversation that we need to shift. And that's really where I think your audience can help shift that conversation. So these things aren't science projects. There's a lot of proof points of the technology being early implemented today. There's examples of vendors

that are sort of early on the adoption cycle. But these conversations happen now because these cycles take, you know, six, 12, 18 months on companies' roadmaps to get this stuff out into production. So if we're not starting it today, you know, it just keeps kicking the can down the road and the problem keeps getting bigger.

So the ads really is... I mean, I can totally see that, like, because, you know, SSO integration is that big pain in the ass thing that startups have to do, you know, just to get it functioning. And I can imagine this just being part of that roadmap for startups in the ass thing that startups have to do, you know, just to get it functioning. And I can imagine this just being part of that roadmap for startups in the future. And yeah, it's something that people are going to sort of have to retrofit, right? If they're going to want to keep winning

contracts, I can see that that's where it's going. Yeah. So it starts by driving that awareness, then it's reduced the cost or the friction for adoption. That's another area that Okta sort of is investing a lot in. We have a customer identity business that empowers SaaS developers to build SaaS products that have these identity standards built into them to accelerate time to market, reduce costs to build these things. So we're looking at it holistically, not just from having support in our IDP, but thinking about how can the ISV adopt some of these capabilities? How do we bake it into a SaaS offering? So you just get this stuff if you want to build a SaaS application.

So whether your journey is take an existing app and retrofit, build a new application, whether it's, I want it to roll some of these capabilities out today because I'm building my own application. We're really thinking about this across all those dimensions, because this is, like I I said at the beginning of the conversation, sort of a call to action for the industry of like this. The threat model is changed in this post authentication world where session token theft is is the problem. And we have a lot of these tools and some of them are ready and some of them are in the pipeline and some are coming next year. But we need to keep pushing on the journey together and not, not just wait for some, some day in the future for us to have these conversations. So that's kind of what was the main driver is you should expect your IDPs to be first in line. They should be adopting this

stuff early because they are the key attack surface area that if you attack the IDP, you're, you've, you've gotten everything, but the IDP ideally can only be a successful long-term in this problem statement if the applications also get it. Yeah, no, a hundred percent, a hundred percent. Because like, if I'm stealing someone's token for some service, you know, I don't need them to touch the IDP, right? Like I just don't need to. And the fact that that's a huge blind spot is something that I've talked about on the

show many times over the years. So it's nice that we've actually got a path out of that. Carl McGuinness, fascinating conversation, really good chat. And, you know, this is all great stuff. I hope the adoption goes really well. Thanks a lot for your time. All right, thanks. That was Carl McGuinness of Okta there.

And by no means was that an exhaustive list of the changes they've made. I do hope you enjoyed that interview. And, yeah, I've linked through to the blog post that an exhaustive list of the changes they've made. I do hope you enjoyed that interview and yeah, I've linked through to the blog post that Carl wrote about all of this in this week's show notes. But that is it for this week's news. I do hope you enjoyed it. I'll be back soon with more risky biz for you all. But until then, I've been Patrick Gray. Thanks for listening. Thank you.