Risky Business - Risky Business #725 -- Microsoft knifes VBScript, passkeys the new default for Google accounts

Episode Date: October 10, 2023

On this week’s show Patrick Gray and Lina Lau discuss the week’s security news. They cover: Microsoft has killed VBScript Google to make passkeys the new default sign-in method MGM losses to exceed $100m Clorox has a bad quarter Why a bug in cURL could be really bad news Much, much more This week’s show is brought to you by KSOC. Jimmy Mesta, KSOC’s co-founder and CTO, is this week’s sponsor guest. He talks to us about how we can start applying real, actual IAM to Kubernetes environments. Show notes Deprecated features in the Windows client - What's new in Windows | Microsoft Learn Google Makes Passkeys Default, Stepping Up Its Push to Kill Passwords | WIRED AWS kicks off cloud race to mandate MFA by default | Cybersecurity Dive MGM Resorts’ Las Vegas area operations to take $100M hit from cyberattack | Cybersecurity Dive Clorox warns of quarterly loss related to August cyberattack, production delays | Cybersecurity Dive Blackbaud agrees to $49.5 million settlement with AGs of nearly all 50 states Cybercrime gangs now deploying ransomware within 24 hours of hacking victims Microsoft: Human-operated ransomware attacks tripled over past year Ukraine, Israel, South Korea top list of most-targeted countries for cyberattacks Microsoft: State-backed hackers grow in sophistication, aggressiveness | CyberScoop 67 X accounts spread coordinated Israel-Hamas disinformation: report John Hultquist🌻 on X: "We are currently seeing pro-Iran information operations actors promoting content across various social media channels, in favor of Hamas and critical of Israel’s response to the attacks. 1/x" / X Hacktivism erupts in response to Hamas-Israel war | TechCrunch ‘War has no rules’: Hacktivists scorn Red Cross’ new guidelines Joe Truzman on X: "Israeli Police Spokesperson: The Cyber Unit of the Police at Lahav 433 has frozen accounts of cryptocurrencies that served Hamas' terrorist organization to solicit donations on social networks. The Cyber Unit of Lahav 433, in cooperation with the Ministry of Defense, the…" / X Cloud giants sound alarm on record-breaking DDoS attacks | Cybersecurity Dive Israel's Failure to Stop the Hamas Attack Shows the Danger of Too Much Surveillance | WIRED Edward Snowden on X: "Netanyahu nurtured a zillion-dollar industry selling spying tools to despots that use them to break into the iPhones of critics, elected opponents, human rights lawyers, and even students (these are all real examples). Turns out they're not very useful for spying on Hamas, tho.…" / X HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks NVD - CVE-2023-44487 Maintainers warn of vulnerability affecting foundational open-source tool 23andMe user data targeting Ashkenazi Jews leaked online 23andMe User Data Stolen in Credential Stuffing Attack Thousands of WordPress sites have been hacked through tagDiv plugin vulnerability | Ars Technica From AI with love: Scammers integrate ChatGPT into dating-app tool Inside FTX’s All-Night Race to Stop a $1 Billion Crypto Heist | WIRED

Hi everyone and welcome to Risky Business. My name is Patrick Gray. Adam Boileau is off again this week. He had to follow up on some health stuff in the US, so he's just focused on that and we hope he gets well soon. And yeah, no need to worry about him. He's fine. He's just having a bad vacation, basically. So Lena Lau is going to co-host with me this week, and she'll be along in just a moment to talk through the week's news. This week's show is brought to you by KSOC, a company that does Kubernetes security. KSOC co-founder and CTO Jimmy Mester is this week's sponsor guest, and we had a really interesting conversation about identity and access management into Kubernetes environments.

There's a lot of RBAC plumbing in Kubernetes no one is really using. conversation, about identity and access management into Kubernetes environments. There's a lot of RBAC plumbing in Kubernetes no one is really using. So yeah, we look at the state of Kubernetes IAM and where all of that is headed. It's an interesting chat. And if you're running Kubernetes, you should definitely hang around for that interview. That's coming up later. But first up, of course, it is time for a check of the security news of the last week with Lina Lau. And Lina, let's kick it off now with an announcement from Microsoft that they are deprecating VBScript. Ding dong. The witch is dead.

Bye bye, VBScript. Let's all dance on its grave. Yeah, I think this is a great announcement. I think the last time I saw VBScript being actively used in a compromise was with the infamous supply chain, the SolarWinds Compromise, where they loaded VBScript onto victim systems and used that to perform their persistence. Why did they use VBScript though? Because you told me this before we got recording and I'm just thinking, why on earth would they use VBScript? Do you think it was just like whoever

did it was old, like me? I wonder the same question. If I had a magic crystal ball to look into their mind, I would ask them the same question too. Yeah. I mean, is VB Script something that you're likely to bump into as an incident responder these days? Or is it just, I mean, there's just so many other alternatives now, aren't there? I mean, I feel like I saw that ages ago, like towards the start of my career and tape it off towards,

like, I don't really do IR anymore, but towards the end of me working in IR. But the only, like, memorable incident was the solar winds one and that was what 2019 2020 ish yeah yeah so that's uh so they've announced they're deprecating it and that means that any new windows installs i think it's turned off by default it's still lurking there though so people can turn it on if they happen to be running business critical vb macros or whatever. But you know, I certainly just have always associated VB script with malware. When you think about stuff like even the Melissa worm back in the late nineties, like when VB script was new, it didn't really improve from there, did it? Well, now you can still enable it as a feature

on demand if you really, really want to use VB script. So there you go. If you're a VBScript, if you're a VBScript user, it's okay. You'll be okay. Now, some other good news. Google has announced that it is now making passkeys, the default sign-in option for Google accounts. This obviously is going to, like if they do this at scale, this is obviously going to have an absolutely massive impact on phishing. I do wonder, though, for people who are highly targeted, how far this will get them, because obviously the next step for attackers would be to just target their passkey provider, you know, which might mean their iCloud account or whatnot.

But I'm guessing, like, you know, this is going to be a net win for sure. It's just great to see these pass keys actually out there and being, you know, adopted en masse. Was that your reaction as well? Yeah, I think any mechanism to try to prevent phishing or any mechanism to try to reduce the attack surface of using login usernames and passwords is a good win. Anything that slightly reduces the risk of compromise is always a win. Even if it introduces new attack vectors or new attack surfaces, it's moving in the right direction. I think we do just need to wait and see what rough edges there are on this. Yeah, I think it'll be, I think once this hits a critical mass adoption point, we're going to see threat actors pivot into trying to compromise it, or even they're probably

trying to think of ways to compromise it now. So I think this will be really interesting to see what kind of attacks of it. And, you know, staying with MFA as an issue, AWS has announced that it's bringing in MFA by default into highly privileged AWS accounts and eventually other account types. This is all starting midway through next year, apparently. I mean, this is a great initiative, but again, same problem, right? Like, you know, it's only going to be as strong as their processes are for doing account resets and disabling MFA. But I'm guessing they've put some thought into this, otherwise they wouldn't have announced it. Yeah, I think it's a really good step in terms of mandating MFA by

default, because for some reason I've worked in IR and I've seen a lot of companies that don't have MFA enabled for sensitive accounts. I'm not too sure why. I hope, but I'm not too sure why, to be honest, but I've seen it happen even now. Yeah. Yeah. So you think making it mandatory is important? Yeah, absolutely.

But I think it raises the question of what you talked about earlier in terms of identification and authentication, because in terms of attacks against MFA even being enabled, I've seen threat actors, Russian threat actors, iterate through various accounts trying to look for an account where they haven't actually set up MFA but have been prompted to and then they actually enrolled their own malicious device for the MFA. Right, so they're doing something like dumping Azure AD and then looking for that field that says this user has been provisioned a username and a password and is awaiting MFA verification. Exactly, exactly, exactly. Okay. Yeah. Oh man. And I mean, that's it, isn't it? Right? The edge cases. But you are taking care of a lot of the low-tech attacks. And I think that's the important thing with MFA, isn't it? Yep. Little wins. Well, and look, speaking of, you know, socially engineering around MFA, we have a report here that says MGM's,

the total cost of the attack on MGM is going to be about $100 million, which I guess is in line with what we expected. But God, that's a lot of money when you imagine it, right? Yeah, I think the report also said that their hotel occupancies fell around 88% during September compared to 93% last year, but 100 million is massive. But JPM security said that MGM's insurance policies covers around 200 million. So whether or not that covers that 100 million, I'm not sure. Yeah, yeah, yeah. And we'll see what that does to everyone's premiums, right? And Clorox. So we spoke, I think it was like last week or the week before, like we spoke about how Clorox, the bleach manufacturer, had also been targeted in some sort of attack.

It looks like that was Scattered Spider as well, like the group or style or whatever you want to call it. It's the kids. It was the youths. It was the youths what done it. Young generation. Yeah, yeah, yeah. So Clorox got ransomware and it disrupted operations.

And it looks like this is going to result in actually a really bad bunch of quarterly results for them. Historically, we've seen share price hits from cyber incidents be very temporary. But it looks like Clorox has actually got a real paddling from the market over this, which I find interesting. But yeah, I mean, it's not often, is it, that we see big financial damage to these companies. Like normally it's like the case of MGM, where they take a bit of a hit and they roll with it. In the case of Clorox, like they really got a solid spanking. Yeah, I think it comes down to how good your business continuity practices are. Because I think this leading to production delays, that's not a, you know, one month issue

that could escalate to several months of production delays. Because you've got to sort of get everything back and running again, right? Yeah, exactly. And also, I think the other side of it is that ransomware operators know that that would hurt a specific company, which is why they target operations and systems that would control distribution. We got a bit of a conclusion to the rolling disaster that was the Blackboard ransomware and breach that happened back in 2020. They've reached a $49.5 million settlement with the attorneys general of nearly all 50 US states. Here they

are years later paying a massive fine. Yeah, I think what's interesting is the legal case with Blackboard showed repercussions and the onus on companies to implement data measures or remediate basic security gaps and the onus on companies to accurately inform people of the breach and actually knowing the inform people of the breach and actually knowing the full scope of the breach and who's actually targeted. But that raises questions for a company like, you know, what is a nominal state for a company where you can say we do not have basic security gaps or we have implemented robust data measures? It's a really difficult thing to kind of benchmark. I mean, it is, but usually when

you look through the findings of something like this and you say, well, how is one to know what is appropriate? And then you read through like the complete lack of controls. You're like, oh, okay, right. Like, you know, that's fine. Yeah. So I understand what you're saying, but I think, yeah, probably in this case, they were pretty bad. And there was also, you pointed this out to me too, there was a point where they'd actually denied certain types of data had been stolen. And then I think they were proven wrong. Yeah, it's hard because like during when an incident happens, you're supposed to provide information around what's happened. So you kind of provide straight away every single finding you find. But sometimes, you know, IR consultancies make mistakes or, you know, data gets misinterpreted. And sometimes there's handovers where you decide to swap consultancies

midway through an engagement. But what that means for the incident is they don't go and carry off where the first consultancy performed the IR. They start from the beginning, square one. And so that elongates the whole remediation and IR process. Now, what else have we got here? Oh, yeah. So Microsoft released its big threat report, right? And there's a lot of interesting information in it. You took a, you had a read of it. What did you make of it? What were the interesting things that you found in Microsoft's threat report? What was your take out of it? I think the primary thing that I found interesting was that most ransomware attacks did not succeed in encryption. I think that would be something that a lot of companies would read and think of and think, oh, that's an awesome success in terms of reaction to a threat and, you know, not leading

to encryption. But then for the organizations where it did progress to deployment of ransomware and actual encryption events, it brings up questions for companies like, you know, do they have a solid method of data restoration if their data is encrypted? Do they have a ransomware playbook that could have stopped them from getting encrypted? For example, can they approve shutting off the network? Can they approve initiating app whitelisting? You know, more aggressive mechanisms that would prevent spread of ransomware. Yeah. And I mean, I think one thing that the, you know, the large scale ransomware stuff proved to us is that, you know, enterprise backup solutions were really inadequate. Right. And I guess that's what you're getting at is like,

do you actually have a restoration plan? Yeah, exactly. I mean, a lot of these news reports about ransomware hitting various organizations has resulted in them doing things manually and physically. And so that brings up the question of business continuity plan. Like if you get hit by ransomware, sensitive database files gets encrypted and you can't handle day-to-day business ops, what's your secondary plan? How do you continue business? Yeah, yeah, exactly. But another thing that you pulled out of the Microsoft report was this focus of state actors increasingly on information operations. And this is something we saw the Ukrainian CERT talk about as well. Yeah, I mean, if you look at a lot of the write-ups

about nation state targets and what they're doing, espionage makes a lot of sense because a lot of it around, a lot of espionage is related to political goals the more information you have about you know an ally or you know a state enemy the better informed you are in terms of making decisions and policies and figuring out if if your political policy can be set in place and it's interesting especially in the Microsoft report how they talked about Russia and they stated that the disruptive attacks against Ukraine actually tapered off. And even Russia is now heavily moving into espionage, focusing specifically on disinformation. Well, I mean, disinformation and espionage are not the same thing, right? You know, I mean, espionage is about collecting that information. But I guess,

you know, so when the Ukrainians talked about it, they were saying that the Russians were going after like media organizations and high profile people and whatever to try to spread disinformation through those accounts. But it's not just the Russians. No, China does it as well, buying social media accounts, spamming social media accounts with fake comments. It's a common tactic that I think a lot of companies, not companies, countries now utilize in order to spread, you know, further their political agenda. Yeah. And Iran as well, right? Yeah, absolutely. And I think the whole thing around espionage is really interesting because in the article, it talked a lot about North Korea as well and how North Korea has evolved their

capabilities. And Microsoft stated that they saw one thing that they hadn't seen before, which was North Korea actually performed one supply chain attack to trigger another supply chain attack. So it's like supply chain with another supply chain and then the target. It's like a wrapped up double supply chain attack. I think we've seen them do that before. Or maybe Microsoft is talking about something that we reported on, but they're very clever with that stuff the north koreans right now uh we're actually seeing a bunch of disinfo and misinfo hitting the internet uh at the moment uh because of this utterly awful uh situation in you know this utterly awful israel hamas gaza uh mess and uh

you know i know we got some listeners in israel too and Israel too and our thoughts with all of you and it's going to remain awful for a while. Unfortunately, this situation is just, we've got probably a war kicking off in a heavily urbanised place and the suffering is just going to be piled on top of suffering and it's been a miserable few days.

I can only imagine what it's like for people in the region, just awful. And adding insult to injury is the fact that we've now got a bunch of misinformation, disinformation and hacktivism campaigns kicking off around all of this. You know, the hacktivism stuff, it's, you know, some of it is going to be state backed, some of it is just going to be spontaneous, but the disinformation stuff is going to be state-linked, right? And we're already seeing Iran-linked operations pushing disinformation. So just scrolling through social media, I've seen a lot of videos of Putin speaking in Russian, but the subtitles are completely incorrect. And it's basically

transcribing or fake transcribing that he's saying that he wants to escalate conflict in Israel. And I'd seen these videos not just on Twitter, but also on TikTok and Instagram as well. So it's really interesting that these videos are now being spread everywhere. And as a consumer, you're not really in a position where you're going, OK, let me watch this video on social media. Now let me go and check if it's real. It's not really like a normal thing for a consumer to do. So I think that raises the question of like where does the owner sit is it the platform that's meant to go and discover that disinformation's being spread or you know or is it up to the consumer to be more wary about what they're you know well I mean I think it's the job of the platforms right

and I think I think it's really clear in retrospect what a good job Twitter was doing of filtering disinformation and gore, right? Because we've had this horrible event happen and, you know, it's just been a disaster on social media. Now, what you were talking about there, Kevin Collier's got a write-up on this Putin stuff. So there's like 67 accounts on Twitter that were spreading coordinated disinformation about Israel and Hamas. Putin stuff. So there's like 67 accounts on Twitter that were spreading coordinated disinformation about Israel and Hamas. But we've also got a Twitter thread here from John Hillquist

at Mandiant. But John Hillquist has been describing pro-Iran information operations, and they've been promoting content across various channels. I'm not sure if this connects to the videos that you were just talking about. But the point is, there's a lot of activity. And you know, the platforms really need to be doing a good job on this. And they're not, right? I mean, the fact that you're describing seeing all of this stuff everywhere is a pretty good testament to that. Yeah, because it's not just on one platform, it's several platforms, like someone puts a video up onto, let's say, X, someone, a random consumer, or maybe a fake bot account, then proliferates that on a secondary media channel. And then it just proliferates and makes this stuff go viral. But let me ask you this, Lena, do you think we're going to see,

you know, because we did see a pivot towards disinformation from the Russians and from the Iranians kind of like prior to this conflict, now that this conflict has kicked up, do you expect that this will accelerate? Because I do. Yeah, absolutely. Because it helps them push new rules and disinformation is a way for nation states to kind of promote their agenda,

their political agenda and their political goals. So of course, you're going to see that proliferate, especially given that everyone is already married to their phones and constantly scrolling social media. It's how they connect with the day-to-day person. Now, look, just staying with the situation in Israel and the cyber police there, the cyber unit of the police at Lahav have frozen a bunch of cryptocurrency accounts that were doing fundraising for Hamas. They worked, I think, with Binance, yeah, to do that. I mean, it's just crazy that Hamas

thinks they can fundraise through like Binance accounts and like that's all going to be fine. Yeah. And apparently they also worked with the Ministry of Defense and they actually also froze a bank account at Barclays as well that they were depositing funds into as well. So it's a mix of crypto and also an actual bank account. Yeah. I mean, I don't know if these were actually Hamas accounts and Hamas addresses or people who were just fundraising for them. But either way, like, I'd imagine that every single exchange, every single, you know, entry point into the crypto ecosystem. Yeah, I mean, they're going to need to watch out for this. And this is why we need financial regulations and KYc and stuff like that

right so yeah now uh some really interesting technical news we've had a blog post uh come out from i mean i saw the cloudflare blog post but google aws and cloudflare are all warning about this http2 rapid reset dos condition so this is actually a CVE impacting a whole bunch of implementations of HTTP2 that can allow attackers to do really effective DOS. Why don't you start off by actually describing the bug and then we can talk about what people are doing with it, because this is like quite bad. Yeah, so the bug is basically a vulnerability in HTTP2 that allows a threat actor to send hundreds of thousands of requests and cancel them at scale.

And that's what overwhelms the site and causes the quote DDoS. Yeah, yeah. And this is actually being used, right? Yep, Cloudflare said that they were noting 201 million requests per second, and they tied it to a botnet of around 20,000 machines. And this is pretty insane because I think the previous statistic on what Cloudflare said was their biggest attack was 71 million requests per second. Yeah, I think Google said, yeah, it peaked at 398 million requests per second,

surpassing the peak DDoS attack observed during 2022, which topped off at 46 million, 46 million requests per second. So it's kind of interesting, right? Because like a lot of DDoS is just brute force volumetric. This is interesting in that it's actually relying on a CVE. I mean, is this bug going to get patched and how does it find its way into all those implementations? And like, it's a bit unclear at this stage. Yeah, it's really interesting because I think the way that the threat actors are doing this request is by sending the request,

then canceling the request, then sending the request and then canceling the request at scale. But what's really interesting is the people behind Cloudflare are saying that this might be reminiscent of log4j because they're noting that a lot of different variants of performing this, exploiting this bug is now emerging. Now, Lena, there's a bug coming, apparently, like there's a patch coming for

curl, which apparently is quite serious. And you think, oh, so what? It's just curl, you know, the cute little command line tool. But, you know, curl is used everywhere, right? Like curl is used by so much software and a bug in the curl client could be actually really bad. Yeah, it would be really bad. It would affect so many different security tools and software. And I think that's why they're not disclosing information about the bug itself, like too much detailed information that tells you specifically the problem so that people can't go and create a proof of concept around it. And, you know, curl can be used to send web requests, perform data transfer, and how it's going to,

the scope of how it's implemented in all the various tools will be really, really difficult for any vendor or even, you know, a blue team to understand. And I feel like the reliance would be on vendors figuring out how they've implemented curl and then publishing security advisory about how their tool is impacted and what the degree of the impact is. Yeah. I mean, so this is a crazy one because, you know, they were talking about that HTTP2 thing being like log4j. To me, this one's more like log4j because it's all over the supply chain,

right? Like it's absolutely everywhere. And look, I think it's great that they're not telling people exactly what the bug is and just telling people get ready to roll a patch real quick. But it's open source software. As soon as that patch gets committed, everybody's going to know what the bug is. And if it's something as dumb as some of these other, you know, what was that bash? Was a shell shock. Like if it's something like that, oh boy, it's going to be an interesting time on the internet.

Yeah, I think you're going to see a lot of red team, not red teams, threat actors, red teams, maybe even just normal security researchers trying to reverse engineer the bug, trying to trigger the bug and write proof of concept scripts for it in the upcoming months. It'll be really interesting because-

I don't think it's going to be upcoming months. I think it's going to be day of. Like honestly, if it is a simple to exploit bug, I think we're going to see exploit code for this like pretty much instantly. All right. Touch wood. Patch releases today, apparently October 11. Well, that's, you know, it's October 11 in the US.

So that is tomorrow. So yeah, basically this show will be going out like hours before it goes. So by the time we next reconvene, we will know. We will know. But it's also one of those things where I'd imagine, you know, just there would be just so many applications and whatnot that would use curl in a way that is not even transparent to the people who are using it.

Like this is a SBOM-ish problem because a lot of people are going to be having, they're going to have curl everywhere in a lot of their enterprise software and not even know it. Yeah. But that's the, that's the question. How are you supposed to know what your enterprise software uses? Like, it's not like you buy an enterprise software and they give you a manual that says, Hey, by the way, we use curl, we use blah, blah, blah, blah, blah. But I mean, you literally, you literally just described a software bill of materials, right? And this is probably a great example of like why organizations like the US government are pushing it so that people can know right yep now uh we have seen a cred stuffing attack against the genetic profiling service 23

and me uh and uh people are leaking data targeting Ashkenazi Jews, which is just incredibly depressing. So initially this was reported as there was like a breach and then 23andMe came out and said, oh no, it was just cred stuffing. But surely if you can exfil data on nearly a million people, I think it's about a million people, through cred stuffing, like maybe your controls aren't that good and you should maybe stop that. Like, was that what you thought when you read this? Because I thought it doesn't matter that it's cred stuffing. Like,

that's just too much exfil. The amount of cred stuffing that would have been going on to get that much data would have been really easily detectable. And they're kind of just trying to say it's not our fault it was cred stuff yeah i kind of felt like they were pointing the finger at something else and avoiding the actual problem which was that you know some compromise occurred and the data was able to be leaked out at a mass scale but what was also really interesting about the news was that they mentioned that they weren't sure if ashkenazi jews were the actual target like they it was a targeted attack against people who were Ashkenazi Jews

or if they actually leaked a whole bunch of other data and they compiled and split the data to only compile a bunch of Ashkenazi Jews. Yes, I think that's probably the likely scenario there. But either way, it's just like, God, you know, I just despair sometimes. Like it's just real nasty. it's just real nasty uh yeah and the timing stuff yeah and the timing as well just before everything that's happened i mean god it just um yeah real real gut punch to a lot of people um now look i wanted to talk to you about this one because there is apparently like a campaign going on targeting WordPress sites. And they've been owned through a bug in something called the TagDiv plugin. So owning WordPress sites as a means to do stuff like malware distribution,

I mean, that's as old as time itself. The reason I wanted to ask you about this is, you know, how important are compromised WordPress sites still in the sort of malware and crime ecosystem? Because for a time, like they were really a big part of it. Are they still? To be honest, I actually have worked cases on it recently, like within the last 12 months, I've worked WordPress compromised sites. And the compromise narrative is pretty similar. Like they will go for a third party plugin or they'll go for some WordPress component that has a vulnerability.

And then that will lead to the threat actors doing some kind of code injection. And then how they do the code injection is where the difference in compromise occurs. Because historically they would use that to upload a web shell or something like that. But now the recent years, a lot of the WordPress compromise is focused like redirecting you to weird sites porn sites site

redirections to proliferate like spam campaigns and other types of things so it's just doing dumb stuff like that these days right yeah because it used to be used like quite a lot for drive-by downloads like back when that was still a thing that was you know easy to do the way people would push that sort of malware was through WordPress sites. So I did just kind of wonder what sort of threat actors are doing this sort of stuff. And it sounds like kind of the boring ones, right? Yeah, yeah. But then they'll also do things like they'll create admin accounts. Like I think the last case I worked on, they compromised a plugin, logged in, injected some code, performed malicious

redirections, and then also created a backdoor admin fake, like fake admin account. Yeah, so if someone cleaned it up, they could come back and just do it again. And extend out that ownership. Anyway, so look, a couple of times on the show, we've spoken about how business email compromise actors are able to use large language models

to craft more convincing sounding emails. And the days of spelling error and grammatical error filled uh you know bc messages are kind of done thanks to large language models now we've got another novel use of uh of chat gpt style stuff in the romance scams apparently uh scammers are now using love gpt uh to uh to know, woo their victims, Lena. Yeah, if you think about how much people use dating websites like Hinge, Bumble, I can't think of any other app from the top of my head.

There's so much data to process and so much an AI could be trained on in terms of what makes a normal profile and how a normal conversation would flow between two people who are romancing each other. So it makes complete sense that this is the next natural evolution for how a romance scam would occur. Yeah, I mean, I don't think the threat actors

are getting access to people's conversations on those apps to train it. But what I find interesting is it would be able to self-train like towards certain goals, certain objectives, right? And, you know, I mean, we're getting to the point where one of these malicious models might be able to give you tips in the future. If you want to secure that. Romance tips? Yeah, exactly. Like if you want to secure that,

that, you know, like a first date instead of a bank account detail, you know, maybe this is the way to do it. Yeah, maybe that's your next business idea, Pat. There are companies out there that have built chat models, which are meant to be like an online boyfriend and girlfriend. And I know people who spent hundreds of dollars to do it. It's become almost like the norm, I think. And I just think it's going to get more, more like that in the future. That just makes me sad. I'm going to be honest. Now, look, we're going to wrap it up with a story here from Andy Greenberg overberg over at wired and he's got this terrific write-up into uh so so just when ftx declared bankruptcy when it all fell apart and it's so like i'd even forgotten that this happened but it was announced at the time like it was news at the time but there were

attackers draining ftx wallets of cryptocurrency as all of the thing was hit as the whole thing was hitting the fan andy greenberg's got a great write-up about this uh in in wired and the interesting part i think is that it looks like because ftx was so disorganized it looked like they were having to race against the attackers to actually locate the coins to move them out of harm's way before the attacker could do the same so this is like proper movies a movie style incident where the uh you know the staff were racing against the attackers to to find and secure this stuff yeah i found it so interesting when the write-up talked about on november the 11th the ledger x ceo sent a message to the 20 FTX staff with the subject line urgent. And then it goes on to

say how no one had any idea where they stored their cryptocurrency, how the secret keys were managed. And it was only known by a select few people who never even appeared in the meeting. Reading this, I just sort of got, and there's nothing in the story to really indicate or prove that this is the case, but I get the impression that maybe whoever did this, they had been in that network for a while. And then when they saw the announcement of the bankruptcy proceedings, they're like, well, we have to pull the trigger on this attack now. Otherwise that money is going to get moved over to bankruptcy trustees. So like, I think the timing, like that might explain the timing is I think this was probably a threat actor that had long-term persistent access into the environment and just went, okay, it's now or never.

Yeah, exactly. And I think that was what happened in that call that they had with the LedgerX exec when they talked about, why don't we change the secret keys? But then they were aware that someone might've been already in the network able to grab the new keys. But what I found really interesting in the write-up- But yeah, everything was in hot wallets, right? Which is just crazy. Yeah. What I found really interesting was that they said that FTX had no SISO and they didn't have an actual dedicated security team. I found that really interesting, especially for an exchange of that scale.

You mean FTX didn't know what they were doing? You mean a company doesn't have a security team? You don't say, Lena. You don't say. All right, well, we're going to wrap it up there. Lena, thanks so much for joining us and filling in for Adam to do this week's news. And we'll talk to you again in early December. It's been great to have you again.

Thank you for having me. That was Lena Lau there from Sintra. And that is spelled X-I-N-T-R-A. Sintra offers a bunch of training. You can find them at Sintra.org. And big thanks to Lina for filling in for Adam. She'll be back in early December to co-host another episode, that time with Adam as well.

It is time for this week's sponsor interview now with Jimmy Mester, the CTO and co-founder of KSOC. KSOC does Kubernetes security, and Jimmy and I spoke about IAM in Kubernetes versus in cloud and SaaS environments. And yeah, this was a really interesting conversation. I do hope you enjoy it as well. Here's Jimmy Mester. I think when it pertains to cloud native

and just cloud in general, we all know and have dealt with IAM in some way, shape or form where, you know, you have some SSO that you're given, you have access to certain things and you don't have access to other things. engineering it takes to understand what's appropriate, what's not, and then observability layered on top of that and detections that work in time to react to something that could have happened. It's a really tall order. And I mean, we deal with Kubernetes, but that's no different really than cloud IAM. Once you have access to a cluster, you essentially have root SSH style access to a box in production and you can do whatever you want. You can elevate privileges, you can access cloud resources, you can cause some real damage. And we are severely lacking in observability, telemetry, and even the tools to build the right profile for individuals. We just don't have it. So it's a real thing these days.

Yeah. I mean, we'll get to the Kubernetes specific stuff in a moment because I feel like in a Kubernetes context, we're almost better positioned to actually get that observability. But when it comes to things like, you know, SAS services and IAM and the interaction between those two things, I mean, the lack of observability in those contexts is mind boggling. Like it's,

it's hard to imagine that we've accepted this, you know what I mean? Like the, the lack of visibility we have like a uniform logging, things like that ability to correlate, you know, authentication events against like application, ability to correlate, you know, authentication events against like application actions and stuff, it's a mess.

But like, what's the approach, you know, you've been spending time looking at this, but more around like how roles and access and users are provisioned into Kubernetes environments. Like how are people doing that at the moment? Like give us a walkthrough of the good, the bad, and the ugly of the way companies people doing that at the moment? Like, give us a walkthrough of the good, the bad, and the ugly of the way companies are doing that at the moment.

Yeah. And I totally agree with your sentiment on SaaS. That's a bit of a dumpster fire. But Kubernetes is a bit different, right? Because you're sort of closer to the bare metal. It is. Yeah. And I think there's unlimited, almost unlimited ways to deal with identity and access control inside of Kubernetes.

And your cloud is very flexible and so is Kubernetes. So what we see and we deal with this every day is our customers typically have 20, 30, 50, 100, maybe 200 individual Kubernetes clusters. You may have upwards of a thousand developers, some of which are more infrastructure centric, some of which are writing features and microservices. So what ends up happening is you just grant kind of generalized group based access to everyone if you're lucky, right? So if you start on day one as a developer, you're going to have to debug your services. Everyone says, you know, you should be checking your telemetry and using Grafana and wherever. But at the end of the day, people still use Kubernetes and kubectl and access these clusters to do what they need to do. And they

don't have a clear, you know, way to, you know, the access is generic, right? Usually you get placed into a group called admin, you get it in maybe one or all of the clusters, it just depends. And it's kind of off to the races, it is usually tied to your identity provider. So oftentimes if you're in AWS EKS, you'll use IAM to kind of map that identity. But I see what you're saying, which is it's like a binary attribute in a directory somewhere, which is this person's an engineer, let them do anything they want. Yep. They are in this, and it could be by namespace if we're lucky, that's like level two, where people care about which cluster individuals are accessing, and then they scope it down to namespace.

But they're not going to scope it down to like which application, which services or whatever, right? Not typically. It's just the overhead is just vast. And to kind of compound on that, you're typically dealing with a kubeconfig file, which is kind of like a static file on disk on your laptop. It could have some hard-coded credentials. You could have bad authentication that doesn't force MFA, things like that.

And if it's stolen or a service account token is stolen, it's very likely your Kubernetes API is on the internet. We saw the giant research article last year, I think it was, I think from census, 850,000 Kubernetes clusters were found on the internet. And that's because that's the default behavior of EKS. And you can access Kubernetes API from the internet. So it's just a, it's just a bit of a tangled mess to get to a point where you feel comfortable with the role that somebody has. And if you're really mature, you can do a just in time, sort of setup, right? Where it's like, I need it for this hour. And I need these things. And I'm going to do my job, and it's going to be logged, and it's going to be logged and it's going to go away.

But I don't see that very often. No. And I mean, there's those companies that do the just in time admin stuff to specific services and some of them operate as like a proxy to those services and things. And that gives them all the logging and compliance and whatever, you know, that's one approach, but I'm guessing that, you know, you're going to be looking at introducing some, you know, tech and features around this. Yeah. I think phase one is get folks in from the incident response and, and kind of detection engineering teams, the observability they need. Um, like who's, who's knocking at the door? Are there anomalies? Can I go back and do a user access review audit

of an individual, right? What did Patrick do last month? And what is the role that he is placed in? And do those things match up? Are there excessive permissions? Is he kind of just like trying to list secrets in every cluster? We should point out too that, you know,

the software that you sell, you know, it's not something that you have to spin up on every single, you know, instance, every single, you know, computer. It's like every cluster gets this. So to be able to pull in all that logging just from, you know, one install per cluster, I'm sure that people would like that.

Yes, please. Yeah. And it's, you know, one install per cluster. I'm sure that people would like that. Yes, please. Yeah. And it's, you know, KSOC aside, I think it's best practice to be logging these sorts of things, right? Well, the reason I mentioned that is because a lot of people will sell like a Linux agent that you're supposed to, you know, bake into every single, anyway, you get what I'm saying now, right? Yeah.

I mean, I have certain opinions on the whole proxy access control sort of model, but you could start by just using the logs Kubernetes has available and making them usable. You're already doing better than your peers, probably. And then second to that is actually inspecting Kubernetes RBAC, right? And if we like cloud, like AWS IAM, for example, is complicated, right? There's a lot of attributes, there's a lot of granularity. And then usually the focus is there, right? It's like, I'm going to build a robust IAM policy or set of policies for these groups. And then they forget about it in Kubernetes where you have RBAC, which is an equal kind of a mess where you have objects and verbs and, and you have, you know,

lots of different knobs to turn to really get RBAC dialed in. So the plumbing is there. There's a lot of plumbing yeah yeah so so like is the idea is the idea that eventually i mean you know as you say start with the logging because everybody needs that and is the idea eventually that you can do some of the manipulation of all of this built-in plumbing in kubernetes to try to you know wrangle the access control problem a bit yeah yeah i mean if you if you know what people, and when I say people, I also am including service accounts, right? That's a whole different beast in and of itself. Programmatic.

It's real funny when you talk to any PAM vendor, right? And it's like, everything's great. And then you mentioned service accounts and they're just like, shut up. Yeah. Just malfunction. Yeah. Yeah. I mean, I think service accounts are, are even trickier in Kubernetes, but those aside, if you can, you know, if you can monitor what's happening, you can make better informed decisions, right? The, the built-in that there are built-in groups inside of Kubernetes, there's admin, cluster admin, editor, viewer. Those are probably okay. If you're just starting out maybe in sort of a test environment. But I don't think most people understand what admin really gives you. And it's quite a lot. So

yeah, we're dealing with identity at the infrastructure layer, just like we would with your public cloud. And I think it's kind of still the wild west. So I'm excited to build on top of that, I guess. So, I mean, I imagine the eventual goal is engineer does their SSO and then boom, get provisioned everything that they should and nothing that they shouldn't. That's, yeah, that would be the long-term goal, right? We have probably a collection of tools that could be strung together

to do something like that. Um, yeah, but it's going to be a headache I think is what you got to hit. Right. Like, yeah, I mean, you know, you mentioned, I mean, all the plumbing's there, right. But like that, it doesn't, that doesn't make a product just cause you can do it. Doesn't mean it's, it should be done. Right. Correct. Yes, that's true. And then there's some wacky things. Just like in AWS, I am like with assume role and things like that. We have the option to impersonate other roles and et cetera, inside of Kubernetes.

And it just gets over the top with how difficult it is. And we did a lot of research with this over the past six months, looking at like all of the kind of public Kubernetes breaches, attacks, bug bounty reports, et cetera. And it was like, there's an entry point that's usually something like remote code execution, exposed dashboard, something like that. But typically the next step, if you're in a Kubernetes environment, is to take advantage of RBAC and access the Kubernetes API to steal a service account token

and impersonate that token and deploy your cryptocurrency miner or whatever you're doing. So it's not that this isn't a theoretical thing, but it's the same as we're dealing with MGM and these other identity-based breaches. it's happening inside of Kubernetes and in your cloud infrastructure today. All right. Well, Jimmy Mester, thank you so much for joining us on the show to walk through all of that. Yeah, I mean, it feels like we are behind in cloud slash SaaS land, behind in Kubernetes land as well. And like, I just have a feeling the next two, three years is going to be playing catch up on all of this, but thanks a lot for joining us to, to walk us through the Kubernetes side of it.

Absolutely. Always a pleasure. That was Jimmy Mester there with this week's sponsor interview, and you can find KSOC at ksoc.com. That is K S O C dot com. Big thanks to KSOC for sponsoring this week's show and big thanks to Jimmy for his time. And that is it for this week's show. I'll be back tomorrow with another edition of Seriously Risky Business with Tom Uren in the Risky Biz News RSS feed.

But until then, I've been Patrick Gray. Thanks for listening. Thank you.