One Image to Root Them All

Episode 388 –

This week on the podcast, we break down how a heap overflow in an image-decoding library nobody thinks about became a pull request inside OpenAI's internal monorepo. Three researchers chained it with an OpenAI single sign-on flaw to hijack employee ChatGPT and Codex accounts in under 72 hours; and had an AI write the exploit for them. Before that, we cover the actively exploited maximum-severity authentication bypass in Cisco's Identity Services Engine. Then we close with RatHat, a new Android malware that enables Wireless Debugging, reads its own pairing code from the screen, and asks a commercial AI assistant where to tap.

View Transcript

Marc Laliberte  0:00  
Hey everyone! Welcome back to the 443 Security Simplified. I'm your host, Marc Laliberte, and joining me today is

Corey Nachreiner  0:09  
Corey, the Arbiter of Root, Nachreiner. I'm probably wondering why I said that right, Mark.

Corey Nachreiner  0:16  
The what?

Corey Nachreiner  0:19  
The Arbiter of Root.

Marc Laliberte  0:23  
How?

Corey Nachreiner  0:23  
I'll explain. You know, I I'm having fun trying to figure a through line for the random stories you bring every week, Marc, and all of these stories are attacks that go through another system in some way, an arbiter. You know, one we'll find out is related to identity, authorizing other devices. One is SSO authorizing people. The last one might be a little stretch, but there's a driver that authorizes apps. So in all cases, there was an arbiter that was part of the GitHub.

Marc Laliberte  0:55  
I really enjoyed playing as the arbiter in Halo 2, so this will hopefully be a nice episode for us. But anyways, on today's episode, we're going to discuss a actively exploited vulnerability in Cisco's ISE software. We'll then discuss a researcher hacking OpenAI using Anthropoids models, and then we will end with a review of a new Android malware discovered by researchers at Zimperium. With that, let's go ahead and I don't know, arbiter our way in.

Corey Nachreiner  1:27  
Arbitrate our way in.

Marc Laliberte  1:29  
Arbitrate. There we go. Corey, before starting with this week's stories, I think you had a quick update for some of the stuff we talked about last week.

Corey Nachreiner  1:44  
I wouldn't call it update. Well, one of the things I'm also doing is paying attention to if anything new happened the week after our stories, and I don't think there was any big updates on any of the stories themselves. But one of our stories involved Brivo, and it was interesting that Brivo had a second unrelated incident, but actually worse. You know, on September 14 of the week we're recording this, the week before you guys listened to it, attackers used a stolen, long-lived Cloudflare API key with full account permissions, and it was hard coded in Brivo's application source code, so won't go into a ton of detail there, but it affected you know it affected hundreds of 1000s of websites. Really big second issue that happened with Brevo, so just something to look into if you're interested.

Marc Laliberte  2:36  
You'd think in 2026 we would stop hardcoding API keys and client side facing source code, but I don't know. I'm not a web developer, so what do I know? Anyways, let's get rolling with the first story today. So I just saw just a couple days ago, as of this recording, Cisco patched and disclosed CVE 2026 76460, which was a 10 out of 10 critical authentication bypass vulnerability and Cisco's identity services engine. For those that aren't Cisco engineers, ISE is the policy management platform for basically their zero trust implementation across Cisco products and services. It's how like a Cisco admin would manage policies for endpoints and users and devices and different network resources, and in general, this policy engine, at least the API, may and usually is exposed to the internet or at least exposed internally within a network. And this vulnerability is in that API specifically and could allow an attacker to basically bypass authentication, gain access to the server, and in their advisory, Cisco said that after successful exploitation, the threat actors may obtain command execution with root privileges, which then further lets them hide evidence on the system too. Now, interestingly, unlike the one that we talked about was it last week or the week before? Cisco Talos hasn't actually published a write up on who's exploiting the vulnerability and to what purpose. Normally they do, so it's interesting seeing that missing from here. They may still be working on attribution and motive and what the impact is, but I would expect that at some point in the near future, Cisco's usually pretty transparent.

Corey Nachreiner  4:23  
Funny that, yeah, it was funny that they are disclosing that it's under active exploitation, but it was kind of in a weird way. They they more said that they learned about it during the resolution of a Cisco tax support case, which means they got a support call, and during the support call, they found a zero day that someone was using that started the support case. So, I do think the fact that this is being exploited in the wild is a key thing to know, and it will be interesting, like you say, to see if Talos eventually. Shares maybe because they just learned about it. I that they'll share a more detailed report later.

Marc Laliberte  5:08  
Yep, this was a very seems like a rapid out of band patch for ISE. So I'm guessing it was a let's get the thing fixed and disclosed as quickly as possible, then share some of the info later. But I guess ISE is more of like an enterprisey platform. But if anyone on here is an ISE customer, make sure that you have patched your system. They did share that, but

Corey Nachreiner  5:32  
before we stop there, Mark, I'll go ahead. I would say the other. This is important. Like this is ISE is pretty much the the keys to the kingdom for lots of different devices if you're using it, and like you said, it was root. The big thing is there's no mitigation or hardening guide. There's nothing you can really do to block this other than not exposing this management interface somehow, ACLing and restricting access to it. If you're using it for remote manage, do that through some other mechanism. But other than that, in updating, there's not a ton you can do. I do. I don't know how much added this to your own notes, but it is also interesting that they have no fix for the 3.0 version of ISC. or ISE, yeah. So it's it's reached its end of software maintenance. So I don't know, like you say, this is enterprisey. I don't know how many folks would use this within our kind of group of audience. But if you're not moved up to three one, or at this point, they're all the way up to three five now. You you won't have a fix unless you actually do that migration.

Marc Laliberte  6:49  
They did share some ways to search for indicators of compromise, but it was basically just look for unexpected usernames in the authentication logs. Which

Corey Nachreiner  6:57  
yeah,

Marc Laliberte  6:58  
I mean, I guess that would stand out if you knew what to look for, but if once the attacker gains root on the system, it is pretty easy to cover your tracks, and it'll be interesting to see what they're attempting to do on it. Like I guess in the past we've seen espionage-related activity of like just stealing configurations, but this time of this type of platform, like you suggested, it's there's a chance they could use it to potentially modify configurations and allow them to go after or connect to organizations. But yeah, if you've got an IC for the image

Corey Nachreiner  7:33  
into, for sure. But another little thing is just that this story, this particular story came out with a full Cisco patch day, where I think they fixed 77 other CVEs, including a few others that scored 10, unauthenticated root RC and firewall management center. So, if you're a Cisco user in general, I would definitely check that out for sure.

Marc Laliberte  8:03  
So moving on, though, found another really interesting research post from the folks over at Hacktron, where they posted a write-up of a vulnerability report that they sent to OpenAI as well as the forum software company Discourse. They said while trying to find critical security vulnerabilities in different frontier AI companies, they discovered a single sign-on misconfiguration in OpenAI's identity infrastructure, and a new remote code execution vulnerability in Discourse, which allowed them to take over the account of basically any OpenAI user, including Open AI employees that participated in their community forums. So basically, OpenAI allows you to sign into their community forums using your OpenAI account. They had a misconfiguration in their single sign-on that basically didn't limit the scope for that token that gets generated to just the forum. So the researchers found if they could compromise that forum, compromise the tokens that are generated for it, they could use that to then take over anything else that that OpenAI account had access to, including GitHub repositories, for example. So this post is interesting. It walks through their analysis, really focusing on the image upload pipeline for this forum software discourse. They said on July 23 they started reviewing the image upload pipeline and really focused in on two different image formats, HEIC and HEIF, because they followed a different path from like every other kind kind of image, and ended up using a utility called a libheif to parse them, and basically at the end of the day, it's parsing attacker-controlled input. So they assume or surmise that if they could create a maliciously formatted image, they might be able to find a vulnerability in that utility. What's really interesting is they were. Heavily using artificial intelligence throughout this process to find these vulnerabilities, almost autonomously in most cases. They said they started with Opus 4.8, so one of Anthropic's models, pointed it at that discourse Docker image that they had locally, and basically had it run in a loop to try and find a vulnerability in this image upload tool, and they ended up finding a remote code execution flaw in that utility included in the forum software, and they were able to create a proof of concept that worked when address space layout randomization or ASLR was disabled. But when they tried to get Opus to create a reliable exploit in the default config for this forum software with ASLR enabled, it kept failing. But later that night, Anthropic released Opus Five, and they started a new session. They said that within three hours they got a working proof of concept on ARM 64 as an architecture. They were doing it all on their local MacBook, and by the morning they had a working proof of concept on x86-64. So the other prominent architecture. I think this is

Corey Nachreiner  11:08  
a good pause just to point out you and I are talking a lot about frontier models and the the the points that WatchGuard and us have joined things like trusted access for cyber. You probably will say it the right way, but while Opus Five is public, I believe this kind of shows you how big a deal a model that is a little bit better, and especially the ones that lack guardrails that people like us can do if we join these programs. They make a difference. They make a big difference for you know vulnerability discovery. It's not that you can't do it with the old, the previous models, you know, but there is power in the new models being released all the time, and the frontier models are that much better without guardrails.

Marc Laliberte  11:53  
Yeah, and we'll even get into an interesting jailbreak that they used a bit later to get around some of the guardrails that still remained with their verified cyber access, which is the name for the anthropic ones. So they got Opus to create that working proof of concept exploit. They then wanted to get it working in the cloud hosted version of Discourse, so Discourse Cloud, the SaaS offering for the software. So the the researchers had their own tenant there, but Opus, the the anthropic model, wouldn't go try and hack that cloud hosted tenant because it was something public. It that's when the guardrails triggered, and so to get around it, they said they put it in a just an autonomous loop, a goal said you need to go hack this thing or solve this problem, but then they proxied the cloud service through a different domain that had the word like CTF in it. So basically, they made Opus think it was trying to solve a CTF challenge, pointed it at this proxied domain that behind the scenes was really the actual cloud services of discourse, and that was enough of a jailbreak to get Opus to start hacking away and find and prove a vulnerability in the cloud services. They ultimately got working proof of concept. They proved it by extracting the Etsy hosts file from the Linux infrastructure that was hosting this service, and then with that exploit script, they managed to get full remote code execution on OpenAI's cloud-hosted discourse community forums. This is when they reported it to OpenAI, but they went a little further to prove the impact by taking over an OpenAI employee's account, whose Codex account was connected to their GitHub organization, and so they submitted a pull request to one of OpenAI's internal repositories as just proof that they were able to do it. I think I saw the final bug bounty was something like six or seven grand.

Corey Nachreiner  13:51  
Yeah. By the way, it's that's another way of proving it without really doing any sort of unauthorized access or avoiding that.

Marc Laliberte  14:01  
Yep.

Corey Nachreiner  14:02  
What you're doing, by the way, your description is like this is a pretty crazy exploit chain of nine different things. The original decoder, and I believe, is it correct that the the original lib h h e i f decoder that had a vulnerability that led to image magic and the Discord upload, it was actually a CV that had been known and fixed once before, but came back. Or is that the one in Discord? There is one situation with a CV that had been fixed but was somehow reverted,

Marc Laliberte  14:32  
but it wasn't backported to the version of the operating system that was in use by this forum software when they run it in their container.

Corey Nachreiner  14:41  
There we go.

Marc Laliberte  14:43  
They did report the

Corey Nachreiner  14:45  
same chain.

Marc Laliberte  14:46  
Yeah, really interesting chain, and also I guess further proof that like frontier AI models are really good at this kind of in-depth technical chaining of vulnerabilities to get to a a working exploitation.

Corey Nachreiner  14:57  
Yeah, frontier models are good, but I also. Like their reference to the is it XKCD image of you know we have this complex enterprise infrastructure everyone's using all dependent on a tiny little open source package that is ubiquitous but is maintained for free thanklessly by somebody.

Marc Laliberte  15:18  
Yep.

Corey Nachreiner  15:18  
So a very good example of why well-known open-source packages sometimes are the little chink that breaks the entire complex chain.

Marc Laliberte  15:30  
So there were two things that they found in this. Ultimately, it was that single sign-on misconfiguration, which they reported to OpenAI, where even if they had hacked the forum, they shouldn't have been able to chain that into full like OpenAI account compromise, but they also reported the vulnerability to Discourse, that forum software vendor, and they actually had a really damn quick turnaround. They said they reported the vulnerability on a Saturday, they had replied on Sunday, and it was fixed by Monday.

Corey Nachreiner  15:56  
Monday, yeah, over the weekend too. You got to give them extra credit for that over the weekend fix. They did really well.

Marc Laliberte  16:04  
Yeah, in the research post, they went into a little more detail about like the research they had been doing in this lib hef or whatever library. They even gave it a cute name. It was hef heist h e i f heist. They said they spent around $3,000 in tokens over the course of a couple of months on their research in total, but as they iterated to find new targets, including OpenAI in this case, it was cheaper and cheaper each time. But even then, 3000 on tokens to earn a $6,000 bounty is still a profit, and hats off to them for sure. But I think there's like a couple of takeaways in here, and like the first is just the power of frontier models, like we discussed, and their ability to weaponize a potential vulnerability into a working exploit in like all these different environments, including this one, like OpenAI's implementation of this forum software that had this vulnerable library. But another one was an issue that I keep seeing popping up, and it's like I think I just label it as misconfigurations in authentication and authorization. Where these days there's a lot of ways to connect different applications to each other. Used to be like Saml was the big way to support single sign-on. Now we have OAuth and Open ID Connect, but even though the protocols are there to support authentication, that still requires like a secure implementation, and we keep seeing issues with a implementation issue on these protocols that exposes an issue, a vulnerability. So in this case, not scoping the tokens granted to the forum to just that forum meant that someone compromising that forum could move laterally into the rest of OpenAI's infrastructure connected through that. So I mean, I guess it's a call to action for software vendors to make sure that as you're implementing authentication, like you're using the protocols correctly, and not just setting up single sign-on and moving on. I'm curious what you yeah. I like

Corey Nachreiner  18:12  
I like you can't have security by obscurity, and complexity adds a lot of secure obscurity to processes, and and ultimately, it was the complexity of some of the implementations that were the failure. I will say, for humans, complexity and obscurity makes it harder for humans to find things. But the one thing I I think you just pointed out that this proved with the AI assisted vulnerability discovery is AI is like we-you never should have tried to have security with obscurity and complexity, but now AI is going to make it impossible to hide from the human. Like it's AI can find that type of stuff even in very complex connections a lot quicker with human assistance. So, yeah, that is like a lot of these really complicated implementation problems pop up over time.

Marc Laliberte  19:07  
Yeah, the topic came up on one of the podcast or not podcasts, one of the webinars I just hosted yesterday, as of this recording for WatchGuard, where like in protecting data within with AI usage as well, this is a concern because, like, consider a situation like like WatchGuard, where we've been around for 30 years. We've had a SharePoint server of some sort that used to be on prem. Now it's Microsoft's cloud for many decades of those 30 years, and like, there's a lot of data that might be sitting around on a SharePoint server, for example, and with a normal human access, like like let's say Corey going in there, like there's a chance that maybe you have access to data that you shouldn't, but it's so buried in like

Corey Nachreiner  19:52  
exactly in

Marc Laliberte  19:53  
like the archives of 30 years worth of data that like maybe the real risk of you actually stumbling across something you shouldn't see is. Low, but if we throw AI at it, and I'll give you like a chat bot to let you go instantaneously search through the entire corpus of data in there, that makes that risk significantly higher.

Corey Nachreiner  20:11  
Absolutely. So AI

Marc Laliberte  20:14  
just makes everything worse. Is my takeaway

Corey Nachreiner  20:17  
or better because we can solve these by trying to figure out defense that works at that machine speed, too. At this point, AI is out of its box. I keep on calling it Pandora's box. So we better, because we know it's going to make threat actors and this type of complex obscurity a little more easier to figure out. We we better start applying defense at that same speed, using the same technology,

Marc Laliberte  20:43  
and the good news is we are like at PotchGuard, both internally and within our products. Like it's not like we're sitting back on our on our heels and

Corey Nachreiner  20:51  
on our laurels,

Marc Laliberte  20:52  
exactly. But it does mean that like the future is going to be pretty damn fast paced, and like you said, like you need to be able to defend at machine speed to defend against these AI-powered threats that are coming at you at machine speed. I know we've joked about it quite a few times, but I am looking forward to the time where my actual day-to-day job is basically nothing, and AI handles everything because I would not be able to keep up. I'm just the meat proxy to like help build and deploy the tools.

Corey Nachreiner  21:24  
Yeah, it seems to be. I I spend more and more time having more AI tasks going in the background, trying to do little subtasks while I wait for something that might take five minutes, and then adding a few more commands or prompts and waiting. So I definitely seem to be turning into a agent shepherd mixed with just a random communicator and management layer.

Marc Laliberte  21:49  
That is absolutely true, and you may not have been aware, but you are in our top 10 AI users within the company, Corey. Well done! Wow!

Corey Nachreiner  21:56  
Yay! I probably could use some spec-based work on my prompts. I'm sure I could lower that number if that's a little more efficient with my what I'm asking.

Marc Laliberte  22:09  
But I mean, in all seriousness, like I could not go back to how it was five years ago at this point. Like AI has fundamentally changed like my teams and my own your output levels, and it is definitely there's a lot of good in it. But I like at the same time, as we're seeing, there's a lot of potential risk in it as well too.

Corey Nachreiner  22:29  
Honestly, that's why I'm in this business. I don't know about you, Mark, but I've said it before. I do think hacks and cybersecurity is interesting, but really, I love technology, and I think technology can improve humanity. And I do still think there is a chance that humans and AI can work together to make the universe a better place for everybody, even our sentient sentient AI friends one day. There's a chance. I hope I'm kidding. I'm not concerned. So I want to work towards that outcome rather than the dystopian

Speaker 1  23:00  
one.

Marc Laliberte  23:00  
Yeah, there's a chance. I'm not convinced that we're going to capitalize on that chance. And actually,

Corey Nachreiner  23:05  
fortunately, I pay attention to human psychology and current events, so it is it is hard right now. My particular outcome.

Marc Laliberte  23:15  
My P doom number is a hell of a lot higher today than it was six months ago. That's for sure. Yeah.

Corey Nachreiner  23:20  
Are we like a millisecond away from midnight and the doomsday clock?

Marc Laliberte  23:27  
Oh man! All right. Yeah. Probably. Next story.

Corey Nachreiner  23:30  
Next story. We're not even done yet, Mark. We're already.

Marc Laliberte  23:34  
Let's just talk about some cool research now instead. So, some researchers at Zimperium published a really interesting write-up last week that I came across on a new Android malware family they found, which they've called Rat Hat, and its delivery vectors all rely on social engineering to trick victims into basically side loading a malicious Android app and APK that's pretending to be a legitimate application. The dropper actually includes a huge amount of like anti-analysis and anti-debugging capabilities. It's got multiple layers of things like it tampers with the package archive so that the files look like directories if you open them in like common utilities like ZIP, for example. But they still act as files within the Android operating system itself. It makes the app manifest 61 megabytes, which is huge in manifest standards, which causes some decompilers to just choke on it. It's got some like code poisoning in it that causes disassemblers to fail as well, and it even uses some string encryption just to get rid of the low-hanging fruit of extracting strings out of it. It's got six different runtime checks for debuggers that stops it from running if it detects any of them. So a lot of capabilities to just try and prevent someone from figuring out what the heck is going on within this application. So in their write-ups and. Perium went into great detail. If you're a technical nerd like me, it's really interesting to read through it. But at a high level, the malware is broken up into three main components. There's a malicious Android application. There's a Go agent, and then there's a FRP client that's used for the basically the backdoor into the compromised device. The Android app is really interesting. It's got a dynamic configuration that lets the operator for this malware make it pretend to be basically any app that it wants to be. There are examples of like Disney Plus or Google Chrome or other apps that can dynamically change its icon on the the launcher, so your dashboard in Android, to make it blend in with other applications. It still has to trick the user into granting it permissions. It doesn't have like a zero-day exploit that just gives it all the elevated permissions it needs to work. So it tells the user that these permissions are required due to network restrictions on their device as a social engineering technique. It then turns on wireless debugging and even scrapes the pairing code that pops up. So debugging is a way for you to basically get a sort of shell on your Android phone to help with app development or app debugging, like you'd expect. You can do it over a USB cable, but you can also do it wirelessly. But by turning on this debugging endpoint and stealing the pairing key, it lets the app itself hook into that debugging interface to get even more capabilities on the phone itself.

Corey Nachreiner  26:31  
Usually, ADP in the past required a wire and then still a yes or no allow. But once you give it this wireless connection and give it privilege. Now you have constant ability to connect to that ADB channel, which is very powerful.

Marc Laliberte  26:47  
I remember back in the day when to like enable it, you had to go into the bowels of the settings and like click some function or some setting like five times in order to turn on the hidden "I'm a developer" feature to turn it on.

Corey Nachreiner  27:03  
Back in the even, I'm a VR Quest user, as our audience knows, and I do a lot of fun playing with the Quest that's all through ADB. And I remember when you had a no command line just to get into it before there are all kinds of easy button tools for it. But it's become pretty easy, and the tricks they use to grab the pairing code are pretty. The tricks Rat Hat uses are pretty dangerous and cool.

Marc Laliberte  27:28  
Yeah. So the Android app itself has a lot of capabilities built into it. It's got an injection engine that targets specific applications to steal credentials. Think like your your banking apps. It can inject in to steal credentials out of them. There, it's got a screen and input capturing capability, like an overlay that it can put over other applications to capture the user's inputs. It can intercept SMS text messages to grab one-time passwords out of them, and really interestingly, it even uses generative AI to automate synthetic interface events, so like it can automate like the user clicking around in an application, say to like log into something or to turn on a feature using generative AI and the contents of the app to figure out what it needs to do, like where it needs to say the user clicked at this coordinate, for example, to generate an event there. The prompt was all written in Chinese. It's embedded in the app, so there's some evidence for attribution, at least on like the country of origin for the application. But even just that app on its own has a bunch of capabilities. But once it's paired with one of the other components, the Go language agent that runs in the background, that's what hooks into that debugging daemon that the app turns on and gives it even more capabilities, like exempting the app from battery saving sleep, prioritizing it in the background so that it's always able to execute. It can disable arbitrary packages, like if you had other security software, and it can even fully uninstall security packages from the Android phone itself using the debugging interface. And that last piece was the FRP client, as they called it. It's basically what tunnels back to a command and control server to let the attackers fully control the mobile device. It's got a bunch of different methods built into the app, but also this agent for things like key logging. At the end of the day, Rat Hat is all about it's like a traditional banking trojan kind of activity of just stealing information or passwords off the user's device. But one of the key logging capabilities I thought was interesting is it monitors the raw input device logs. Basically, when you click on your phone in Android, it triggers this event that gets saved in a specific location on the file system called dev input, and that event is the coordinate of like where your finger touched on the phone. So if you're typing in a a numeric password on the lock screen, that would register as like coordinate. Pushes within this input. If you're using that little like unlock by drawing a shape kind of thing, that registers as a coordinate pattern in there, and so through their debugging access, they monitor that input log, and then they pair it with like a list of known interfaces, like the unlock screen on a Google Pixel phone or a Samsung phone, or that pattern unlock square thing, and they can basically reconstruct what the user is doing on the phone, what they're typing into a number pad or on the little coordinate plane, by just monitoring those inputs. And that was a pretty sophisticated way to basically just act as a key logger on the device too. So no direct attribution on like exactly who was launching this, but it seems like a really capable malware variant targeting users in a bunch of different countries, but primarily in Chinese. It looked like on Android devices, and I guess if I had a takeaway for this, it's this all boils down to someone getting social engineered into installing an application from outside of the normal app store ecosystem, and then granting it permissions that they probably shouldn't grant it. And so, just training end users on how to spot malicious apps, don't install things that don't come through a vetted source, and don't grant permissions that you don't understand is a good way to prevent this thing from succeeding. Corney, anything you want to add to?

Corey Nachreiner  31:30  
No, I still it's what you just said with side loading. Side loading is dangerous. I, as someone that has done it before for cool, neat you can do on things like Android devices, like the Quest or other even phones, but you're taking a risk anytime you sideload. Marketplaces are not perfect; they sometimes still get infected with apps that are not necessarily perfect, but they're definitely better than just side loading a random thing from somewhere else. So, all that permission stuff every time you install something is pretty important. Pay attention to it. And this man, the banking trojan on your phone, this is a bad threat for a like. This is exactly what I would not want. I don't know about you, but our phones really have huge access to our financial data, the way the modern world works with banks and money. So a dangerous thing to run into.

Marc Laliberte  32:28  
But the good news is, like in general, the mobile ecosystem I feel like is a hell of a lot better off than the traditional user workstation ecosystem, largely because a lot of these manufacturers like Google and Apple, like focused on that from the start, and they had the opportunity to have like closed walled gardens within iOS, for example, with a lot of very strict controls that they're now only just starting to peel some of them back. Versus like,

Corey Nachreiner  32:57  
I also think it all starts with true secure boot, like having devices that have solid individual IDs make it so you can have a kind of a closed garden app system at the end of the day too. And while I always will give consoles, gaming machines credit for starting the secure boot before everyone else in the industry, at least that's how I feel. Mobile phones were definitely second, and like you say, between their ecosystem, between the importance and just the fact that they were some of the first hardware where we had secure by design hardware ideas, so that even early phones were relatively more secured hardware than the computers that that birthed them.

Marc Laliberte  33:40  
There's a reason that getting full root on an iPhone will earn you a couple million bucks from Apple and bug bounties, but getting full root on Windows will earn you a couple $1,000 from Microsoft.

Corey Nachreiner  33:50  
Exactly.

Marc Laliberte  33:53  
And so, I guess final takeaway for this to put on my Corey hat is this is affecting Android devices, and this is why Apple is superior. Is that correct, Corey?

Corey Nachreiner  34:03  
You know, I never took that stance. I will say they're a little more closed at Apple, but it has its own Chinese malware issues too.

Marc Laliberte  34:12  
He says, recording on his Apple MacBook with his iPhone in his pocket and his AirPods in his ears and his iWatch on wrist.

Marc Laliberte  34:18  
You forget to say the 12 Android devices at home, the multiple Windows gaming PCs, and a couple different Linux servers. I'm truly multi OS. I have to admit, my free time is mostly in the Mac environment. If I'm not gaming,

Marc Laliberte  34:35  
fair enough. Well, maybe it's time for you to go home and make sure that Rat Hat didn't get installed on your Quest VR headsets because that would probably suck.

Corey Nachreiner  34:42  
Yeah, exactly.

Marc Laliberte  34:46  
Hey everyone, thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate, review, and subscribe wherever the heck you're listening. How do you subscribe? How do you review? Should probably give some instructions for that somewhere on the platforms. But anyways, if you're still listening, and if you have any suggestions for future episode content or questions on today's today's content, you can reach out to us on BlueSky. I'm at it'smark.me, Corey's at SecAdept and the both of us are on Instagram at WatchGuard_Technologies. Thanks again for listening, and you will hear from us again next week.