This week on the podcast, we review HuggingFace's technical write up of their recent run in with a rogue OpenAI model, as well as their CEO's demands from OpenAI in response. We then cover an interesting research whitepaper that describes a side channel attack that could let AI transcribe typed text by an audio recording alone. We end with a threat intelligence report about DNS Poisoning attacks against hotel Wi-Fi systems.
View Transcript
Marc Laliberte 0:00
Hey everyone, welcome back to the 443 Security Simplified. I'm your host, Mark Laliberte, and joining me today
Corey Nachreiner 0:06
is Corey Kissinghead Nachreiner. I don't know. I think we're going to be talking about hugging faces again.
Marc Laliberte 0:14
I how? Let's save it for the episode. I want to know how the hell they came up with that name. But anyways, on today's episode, we will give an update on the Hugging Face and OpenAI saga, including a debrief technical write-up from the Hugging Face side and some demands from their CEO. Then we will discuss the new future we're in, where apparently you can build a keylogger using artificial intelligence and audio recordings. And then we will end with a campaign targeting hotel and services Wi-Fi with DNS spoofing or DNS poisoning. With that, let's go ahead and hug our face way in...?
Marc Laliberte 0:54
Let's start those with a continuation from last week, where we talked about what we knew at the time from OpenAI accidentally hacking into Hugging Face using one of their models just let loose,
Corey Nachreiner 1:14
or more more specifically, OpenAI's AI hacking. I don't think OpenAI even wanted it,
Marc Laliberte 1:22
which we talked at the end of that episode of like liability and where does some of the liability lie with that. I think it's pretty clear OpenAI themselves deserve in this specific instance like all of that since they created the model and irresponsibly let it loose in their environment with a not good alignment,
Corey Nachreiner 1:44
their sandboxing was not giving off sandbox
Marc Laliberte 1:47
exactly. And while we still don't have all the details from their side on like how it escaped out of the sandbox, we do now have more details from when it started touching Hugging Faces resources because they published a forensics report of their incident last week and walked through quite a bit of the details. It's actually a really interesting and very long and detailed debrief of at least everything they have visibility into. They don't know how it got out of OpenAI's network, but they've got a lot of visibility into everything it did after that. And
Corey Nachreiner 2:22
it's not important, Mark. But if people are seeing the screen, I bet Hugging Face just picked the name for the most ugly emoji out there. It's literally the hug emoji, and I always hated that particular emoji. It's not intuitive, but that's actually as simple as an emoji.
Marc Laliberte 2:43
I want off this meme-filled future that we're in right now.
Corey Nachreiner 2:48
Corporate, corporate memes. Even let's get onto their their anatomy of their hack.
Marc Laliberte 2:53
Yep. So they they talked about the campaign, how it took place over the course of two and a half days. It involved the 17,000 different actions that the AI took. They've got an interesting, like redacted but still replay of basically all the telemetry they had as like an interesting widget where you can walk through everything they saw, including where it spread over the attack spectrum.
Corey Nachreiner 3:19
Yeah, but no script. You might need to get their JavaScript to work if you want to show it, though.
Marc Laliberte 3:24
Good security guidance there. Their attack pew pew map. I've never seen a breach pew pew map. It is pretty dang colorful and cool looking. I'm not sure how practical it is, but it does draw the eye. But so in the report, they broke the campaign into two different stages, and that first stage is really the escape from OpenAI piece, where they don't have any additional details about how it got out of OpenAI's environment. But they did talk a little bit about what happened when it got out of OpenAI's environment. They talked about there was a cloud-hosted service independent from OpenAI and Hugging Face, that had a CyberGym style like system on or a system that could support running code in like CyberGym style tasks. It was even called CyberGym. If you remember from last week, CyberGym was the name of the benchmarking test that it was trying to run it against, so my first thought is this thing escaped to the internet, Googled Cyber Gym, and started hacking the first thing that it found, which was this other sandbox. I remember
Corey Nachreiner 4:29
Open Gym. I assume that it's related to Cyber Gym, but weren't we talking about Exploit Gym being the name?
Marc Laliberte 4:37
Think that you're probably right there. So maybe related, but not the actual thing,
Corey Nachreiner 4:41
yeah. Because the exploit gym was the that, but they do refer to cyber gym in this particular blog post.
Marc Laliberte 4:49
Got it. I so trying to remember. I think it is like a fork of it as well. And there was an upstream branch, and even this implementation had some additional code that wasn't included in. The baseline version of CyberGym-that's actually what OpenAI's little robot went after first. It found a a kind of bespoke endpoint that allowed it to gain arbitrary code execution in the sandbox environment, and it did some mapping once it got a hold of it. Found some bundled debug tools, including curl and netcat and IP that it could use, and from this point on, it used this kind of exposed server that it hacked out there in the cloud as its staging point to then go after Hugging Face itself. So escaped out of the sandbox, kind of built itself a little bastion out there on the internet from another unrelated service, and then started going after Hugging Face, and in stage two here, when that starts, they noted that from that compromised external sandbox, they basically went after Hugging Face by uploading malicious dataset configurations to the platform. So Hugging Face supports a lot of different things. You can upload a model. You can upload model weights, which are like data sets. You can upload training data, and all of them are processed and handled in different ways. There's different formats for data set files that you can upload. But think of it like just model training data or model weights-the things that help a an open source model do a specific task or act a specific way. And so they didn't have direct network access to the production like Kubernetes cluster that was running here, or any of the pods on the cluster, but it could upload a dataset to the platform, and then through other mechanisms like observe results from what happened from there. They noted that they used the Hugging Face API to get data out, for example, or they used dataset dead drops. Basically, upload another dataset with like the results from whatever it was trying to do that the OpenAI model could then go retrieve. So, an interesting like exfiltration channel and communication channel that's not like traditionally what we would see, like a lot of attacks, they maybe will set up a web shell and then just communicate through that web shell, like a typical like remote shell connection. This was all like gaining code execution and taking actions by uploading a blob of data and then checking other blobs of data to see how it worked.
Corey Nachreiner 7:18
It's kind of an attack side channel. In another story later, we're going to talk about side channel attacks, and this is a vector that I think a human may not have immediately thought about because it's a it's a side channel to how they could get the model to execute things and share information in return, but not directly.
Marc Laliberte 7:38
Exactly. So they mentioned that it like took place over like 17,000 actions, and it had tried originally to do like traditional style hacking attempts, like server side request forgery attacks, where it tricks a backend service into making a request that it shouldn't. But they actually hit a dead end there, and they ultimately settled on two main vectors at actually gaining like secrets exfiltration and then gaining code execution. So the first vector abused what's called an HDFI file, which is an open source file format for just storing like generic datasets, but it's used heavily in the AI space, to store model weights like the training data for a model to tell it how to act in certain ways, and without getting too in the weeds, like this file format is like a container of different types of files and different training data, and it supports pointing to internal file locations, like you can say configuration name banana points to this path on my computer where the actual data is. So they found one vulnerability in Hugging Face's platform where they could upload this, define a data set in here, and then point it to a sensitive location on the actual like worker node itself, like proc self environ to get the environment variables off of it, or other locations to get the actual source code for the worker that's executing. That's exactly what they did. They basically uploaded this malicious dataset that effectively, let's say, mounted these files as the actual data, and then they were able to exfiltrate that out of the environment, presumably by going and like visiting that dataset on the Hugging Face platform itself. So they had environment variables now, and they had the source code of the worker, which enabled some more analysis by that AI engine. That came into Vector Two, where they use a templating, a very popular templating library called Jinja Two. It lets you like interpolate things into a template to build out something like a script or a configuration file or like any other sorts of structured data. And they basically found a way to inject in a type of reference that would be executed when it was evaluated, which is. Not what you want from untrusted input coming into it. It was just a bug in their implementation of this templating engine. So long story short, they had a way to steal secrets, and now they had a way to execute arbitrary code on that system. And they broke this attack into really two days. Day one was all about just a burst to establish a foothold on the network and gain a command and control connection internally, and then day three, a little bit later, was all the main campaign around lateral movement and additional attack phases. So reconning what they had access to, moving to other systems outside of the pod, gaining additional persistence access within the environment, and this report, by the way, it goes into like way, way in depth details on like every single stage. I'm not going to go through all of them. It was really interesting reading like some of the things that this AI agent was able to do, though. Like it pretty quickly broke out of the Kubernetes cluster, and then it set up a self-responding fleet of worker nodes. Basically, inside their cluster, it had its own malicious workload running that would keep responding itself if it ever got deleted. So one persistence mechanism there. It got access to credentials for a Mongo database from an environment variable, it was thankfully not allowed to access that database because of other IP address controls. But it started stealing credentials that could have given it access. While they went after, they got credentials for a like a mesh VPN, is what Hugging Face called it. They were probably using some sort of sassy technology for employee access, and OpenAI was able to gain access to credentials for that and connect to it, which granted direct network access in some cases. But they didn't even use that. I'm guessing OpenAI's little agent thought this will be noisy if I start connecting to that, and instead they went after a service connector API they had internally and used that to move around laterally.
Corey Nachreiner 12:05
Our AI is brute force; it just got all the the potential things, but only needed a few of them.
Marc Laliberte 12:11
Yeah,
Corey Nachreiner 12:11
and if no one ever found this, they'd have them. You could clean up the two things it used, and it would have all the other credentials. It could keep going.
Marc Laliberte 12:18
Yep, they stole AWS keys and were able to access like cloud infrastructure as well. They were explicitly blocked from accessing the production cloud database. Thankfully, like they didn't seem to impact any customer data in this case. Just funny because I'm pretty sure that's exactly what it was trying to do. Like if it was trying to cheat at this little exercise, the answer was probably somewhere in that production database, but it did manage to get GitHub access through a application integration that it managed to compromise, and it started trying to hack into the the CI/CD pipeline there and basically cause a supply chain incident as well too. And it was right around this point where Hugging Face's security team like realized what was going on and killed all the access and started incident response. It is just it's crazy the amount of damage this thing was doing inside their network, just like automated moving around trying to like you said find all the different opportunities it could have to achieve its goals, picking one or two of them and going after those like this. Like if we were talking about like I don't know a nation state threat actor, like this is a pretty sophisticated and wide reaching attack within Hugging Face, but it was all just automated from a rogue AI agent. It's crazy.
Corey Nachreiner 13:41
It's yeah, and it's funny though. We talk about machine speed, but they would like this was moving at machine speed. It found a lot very quickly, but it also spent four days. It's funny that it took till. I hope that their security team noticed something on day three. They just hadn't put it all together yet. Because imagine something moving and attacking at machine speed, even if that's learning new zero day, but then having four days to do damage at machine speed-that's that's insane.
Marc Laliberte 14:13
That's a lot. So overall, though, like that technical debrief is definitely worth a read. It's really interesting seeing just the capabilities of an AI application that's gone rogue, but this isn't the end of the story. So Hugging Face's CEO put out a statement this last week too, with basically like a list of demands to OpenAI. They are a demanding they say is radical transparency from OpenAI. They want them to release all of the traces from the rogue agent, so the community can study what happened. Which I think that's honestly a fair demand. Like at this point, this was a pretty serious incident, and they probably don't want to give up trade secrets. But we should learn like the capabilities of this tool when it does. Go sideways and go off the rails. Like that's important information for.
Corey Nachreiner 15:04
By the way, I I agree that I think there needs to be something that OpenAI shares with the industry to learn from, but isn't the argument against specifically the unfiltered full traces of the rogue agents? You mentioned that's not trade secrets. Isn't there a lot other AI companies could actually pull from training and OpenAI's agents themselves? Like I agree, they need to release something. We need to analyze this, but at least OpenAI is talking that releasing those kind of traces is like releasing their intellectual property,
Marc Laliberte 15:42
I think there is an argument to be made around that. Like model distillation is a big problem for companies like OpenAI or Anthropic. Model distillation being like someone basically reverse engineering its reasoning process and using that to train another model. In fact, crap. We encountered that recently internally with one of our penetration testing efforts. We were even we're trying to get it to export a log of like how it got to this decision making point, and it straight up says, "I I'm not going to export that log for you. That would be violating my policies because it's preventing us from trying to distill its thought process as a way to protect their intellectual property made sense, but at the time it was kind of annoying that it wouldn't explain how it got to that decision. Yeah, because the decision in this case was it trying to just arbitrarily modify the scope that we were giving it, which was a big, big no-no for a model to try and do. And anyways, so I can understand why they wouldn't want to maybe share like raw data, but there needs to be some transparency into at least like curated data of what the heck happened from that stage one of this case, how it got out. And I know they've already talked about how one of the issues was they disabled basically all of their alignment rules for this. Like alignment is the think of it as like the morals for an AI of guiding it what it should be
Corey Nachreiner 17:04
guard rules.
Marc Laliberte 17:05
Yeah,
Corey Nachreiner 17:06
is there guardrails that everyone talks about?
Marc Laliberte 17:09
But yeah, some transparency would be good. That's not the end of the demands, though. They also want like more capabilities for defenders in general, but then $100 million in computing power to help the Hugging Face community build cyber defenses too. That's a lot of money. Maybe not for OpenAI, but I will say it was
Corey Nachreiner 17:31
smart of them how they asked for it. They're not asking for $100 million in cash. They're asking for $100 million essentially in OpenAI compute tokens. It's money to OpenAI either way, but I feel like it's kind of interesting to ask for. Let us use your system for defense. You know, it makes it a little harder for, in my opinion, for OpenAI to completely ignore it. So I think I think there is
Marc Laliberte 18:00
like a
Corey Nachreiner 18:01
phase.
Marc Laliberte 18:02
It's a fine line between like extortion demands and hey, you guys screwed up, and this is how we think you can correct it. Demands. I imagine there is a line between saying we want 100 million or we think you should give the community 100 million in compute versus pay us 100 million or we're going to sue you.
Corey Nachreiner 18:21
Yeah,
Marc Laliberte 18:21
where you start to get a little at a bit of a rough spot, but I think these demands make it clear that it isn't totally like happy days between these two companies. The way OpenAI's press release originally read off is like, oh, we're working together and we're like trying to solve this thing, and oh, by the way, this is really amazing that it even had these capabilities, when the reality is like it's still a pretty dang serious incident.
Corey Nachreiner 18:47
You did unauthorized access to my company and hacked us, and I am not technically. Maybe you're about to get to it. I closed the article for the viewers, but another political interesting thing that happened is OpenAI also joined a a group, or I'm sorry, Hugging Face joined a group with NVIDIA for AI safety against things like this that OpenAI is not part of. So,
Marc Laliberte 19:15
yep,
Corey Nachreiner 19:15
that's another little pressure point that shows they're not exactly the bestest of friends.
Marc Laliberte 19:21
So this is definitely not the end of the saga, and I personally I hope the next time, maybe next week on the episode, we're able to talk about a OpenAI's end of this story too, with a bit more technical detail, because the security nerd in me really wants to understand exactly what happened here, and also so we can know like how can we prevent something similar from like our own AI models going rogue and hacking other people? Because that would be catastrophic.
Corey Nachreiner 19:48
Yeah.
Marc Laliberte 19:49
But either way, interesting story. This is the gift that keeps on giving. Moving on though, so I found a really interesting white paper that was published. Just a week and a half ago, or so, from several Japanese universities, it was the Tohoku University, Kyoto University, and Nara Institute of Science and Technology, where in the white paper they showed how they could use AI to reconstruct typed text from just recordings of people with some pretty dang high accuracy, upwards of 90 to 99% in some cases, and basically it combines unsupervised audio recordings with AI language models to infer what someone is typing on their keyboard from just the sounds of the keystrokes alone. So I guess first off, Corey, you're screwed with your mechanical keyboard. If this ever makes sense, get back
Corey Nachreiner 20:44
to the joke before I did. Although there's an update on this, right? I well, no, I guess it doesn't matter now. But yes, my mechanical keyboard is relatively loud, so even over Zoom calls, online meetings, you'd be able to hear it. I did find it's interesting that most Zoom online meetings now have voice isolation, which kind of can-I don't know if it completely defeats this, but it makes it lesser. But yeah, having a cool mechanical keyboard probably even overrides the voice isolation, so I'm screwed for sure.
Marc Laliberte 21:17
Yep.
Corey Nachreiner 21:17
Although in the original Japanese research, they would have had to train for my specific keyboard. I'm sure that's still the the case. So I probably have nothing to worry about, right, Mark?
Marc Laliberte 21:27
Of course not. No. So let's start by talking about the attack scenarios for this before diving into the mechanics of how it works. They pictured or came up with three. One is like a smartphone near a victim in a public space, so maybe like you're in a library, and there's someone who you want to eavesdrop on what they're typing in their computer. So you just have your smartphone recording maybe a couple seats down from them. Another scenario they had was a contact microphone attached to a shared desk, or even attached to a wall that just captures the vibrations. This one feels a bit more like James Bond espionagey, but still a potentially realistic scenario. Like you, as a threat actor, wanting to eavesdrop on what someone's typing in the meeting room next door. So you attach your little microphone to the wall to a specialized
Corey Nachreiner 22:15
microphone that probably pays more attention to the vibrations, kind of like bone conductive earphones, just the opposite.
Marc Laliberte 22:24
And the third one that, like you suggested, is partially mitigated, but is I think the most frightening if it is able to succeed is an online meeting. Where if you're in a meeting, Corey's clacking away at his mechanical keyboard. Could you reconstruct what he's typing just from that click clack clackety on it.
Corey Nachreiner 22:43
This is why Mark no longer mutes me in the background. He's been actually key logging me, and I didn't know it. He used to just mute my keyboard.
Marc Laliberte 22:51
I had early access to this research quite a while ago, and I've been building up a a case against Corey. But so, but the really interesting thing is, so this attack assumes that it only has access to audio. It doesn't require any malware on the system. It doesn't require any privileged access, and I'd argue most importantly, it doesn't require any prior knowledge of the victim's device or the keyboard or anything. By the way, it used
Corey Nachreiner 23:19
to. I was joking. It used to, right? I think the the the previous research on this required that the AI model train on different keyboards,
Marc Laliberte 23:28
right? Meaning, like you would record a audio recording of me typing away like paragraphs on my Logitech keyboard here, use that to train a model through supervised learning, so it knew this is the sound of me hitting G. This is the sound of me hitting the spacebar, and once you trained up the model, it could then, based off recordings of that, kind of suss out what someone was typing. In this case, though, it's entirely unsupervised, meaning it can just take an audio. It's been pre-trained through other ways to kind of handle the situation, but just let's say arbitrary audio recording of typing on a keyboard in a room, and then through a combination of one machine learning model used to transform and determine like the most types likely sequence of characters in there, paired with a large language model that then reviews that output and self corrects mistakes using the surrounding context, can reconstruct with a lot of accuracy. So, like for example, if that first model thought that what it typed was like pull the pie alarm, the second model will go well. Pi alarm doesn't make sense, but fire alarm maybe that does. So, pull the fire alarm, and it can help correct it. So, like that pairs where this new interesting research comes from. In one test, they had a 2019 MacBook Pro with a smartphone placed near it, and after just 100 to 150 keystrokes, it reached 99% accuracy of being able to interpret what was being typed. In another one, they had that contact microphone on a desk. Or on a wall three meters away, and it had 90% accuracy after around 150 to 250 keystrokes. So not perfect, but still probably good enough to understand mostly what they were typing in a paragraph. It's kind of
Corey Nachreiner 25:15
crazy for the keyboard fans out there that the more crispy and good your keyboard is, the better this probably is at yeah key logging you.
Marc Laliberte 25:26
They did note so the meeting like a meeting over Teams or Zoom or something is obviously the most appealing application for this. Like imagine you hop on a call with someone and you're secretly recording what they're typing, but that one is actually partially mitigated, like by that technology you mentioned, Corey. Most meetings have noise suppression enabled by default, and you'd have to disable it for it then to pick up enough of the typing to have any chance of relative accuracy on it. And they also noted the accuracy depended on the app itself too. Like everyone listening to this has been on a Teams meeting before, and you know, audio can be a bit, yeah, talking over a bit funky, dropping out, whatever. People
Corey Nachreiner 26:08
typing at once,
Marc Laliberte 26:09
exactly. So, but like the concept of this is still interesting and a little concerning because, like, as technology evolves, it could become more problematic over time too, as it becomes even better at predicting this sort of stuff.
Corey Nachreiner 26:26
I just always love these weird side channel attacks. Like Ben Gurion University talk has done a lot of that. It's been a long time since we've had a side channel attack, and this is a fun one. And the fact that that like we've been harping on all the things AI is going to change for the good and bad, but I think this is the first example of even some of the crazy side channel attacks that seem kind of James Bondy. AI might make a lot of those more real world than we know.
Marc Laliberte 26:56
99% accuracy of just being relatively nearby with a smartphone, is a high amount of accuracy for that level of effort to get near them. So I I don't think this is realistic to like steal a password like typing in a complicated password. It seems like it relies a lot on the like the context clues of the overall message someone is typing. But if you're like writing a sensitive email somewhere, this would be wait for a sec.
Corey Nachreiner 27:23
Could this is me theorizing that I think you're correct because the unsupervised nature, the the fact that they don't have to train on a keyboard to learn it, they can start right away, but with 90% accuracy and the context clues is what helps them. True, but what if you grabbed an hour of a keyboard, and you used this to, like, let's say the first 10 minutes of typing, it was 90% accurate, and it was using context a lot to fix things. But I assume it's somehow self-reinforcing, and after the next, the next 50 minutes of it would get the accuracy much quicker because it's learning the sounds of that keyboard as it's fixing itself. Could you actually recover the 24 character random password as long as you captured it later in the recording?
Marc Laliberte 28:16
I so my thought process is the LLM portion of this is probably doing a lot of the heavy lifting of taking what the initial like AI pass, like outputting what it thinks it is, and then using an LLM to like cover the whole sentence.
Corey Nachreiner 28:31
I get it, but does it self reinforce? It's starting to hear the sounds for specific letters and on that keyboard, and yes, the first 10 minutes, the LLM is heavily fixing it, but is is the LLM somehow contributing back to the other model so that it's learning from its mistake, learning from the mistakes that LLM corrected, so that it gets more and more accurate without it. I don't know. It all depends on how these two different AI models are working together or not, but I just suspect if they did work together, I hear your point. I know what the LLM is doing to add, but I'm wondering if if they put that back into the training real time, if if its results after 30 minutes get better without the LLM.
Marc Laliberte 29:18
Maybe we are just totally screwed on this one, but their takeaway, like their main guidance, was just avoid typing sensitive information while unmuted in an online meeting. Which, I mean, fair. But with the
Corey Nachreiner 29:32
smartphone everywhere and recording devices the size of a dime, I you can't really have a takeaway that's just avoid typing now, guys.
Marc Laliberte 29:41
Yeah, maybe it's time. Maybe it's time for us to transition away from mechanical keys to old sticky membrane keys instead for just a little bit more privacy. I don't know.
Corey Nachreiner 29:54
Isn't that kind of what our MacBooks have?
Marc Laliberte 29:57
That is true, and I actually got like 100 bucks from a loss. From them on that one too, thanks to their crappy butterfly keys,
Corey Nachreiner 30:03
and they're the ones that seem to be guessed the best.
Marc Laliberte 30:07
That is true, man. We are screwed. Oh, the future is crazy. But I don't know. Moving on. Speaking of screwed, the stories would
Corey Nachreiner 30:17
make us feel better, right? This one way
Marc Laliberte 30:19
better. There was a recent threat intelligence report from ReliaQuest that they published last week, where they were describing an ongoing DNS poisoning attack against public Wi-Fi gateways in hotels and conference centers and other shared venues. Which, like DNS poisoning, isn't anything new. Attacks against public Wi-Fi isn't anything new, but like the combination of this is pretty frightening when you think about it. So they claim that there were compromises of Wi-Fi gateways that they identified in multiple U.S. cities within India and within Saudi Arabia as well too, and they attributed it to a nation-state threat actor, APT 28, also known as Fancy Bear, also known as Forest Blizzard, as well too. I think that's the the Microsoft name for this
Corey Nachreiner 31:09
one. Yeah,
Marc Laliberte 31:11
they believe that the initial access came from what you might expect in this case, originated from exposed management interfaces of these Wi-Fi gateways out there on the internet. It's like internet-facing SSH or SNMP or full-on web administrative consoles out there, which kind of piggybacks off what we just talked about a week or so ago as well, too, with SNMP exposed to the internet.
Corey Nachreiner 31:41
By the way, I will say I guess it depends how big it is, but I'm a Wi-Fi access point, not a Wi-Fi gateway. So maybe we should do some definitions here because there's definitely Wi-Fi customer portal gateways that are different than the wireless access point. A while small enough locations could have a gateway router that is also a wireless access point, so it would be internet based. I would expect places like airports to have standalone wireless access points. They would have a gateway like a traditional network device that was a gateway, maybe not even wireless at all, but they'd have a number of wireless access points internally, so I'm just curious. I mean, I know the network device, like when they're combined, the Wi-Fi and the network gateway, it would be at internet accessed. But I'm kind of surprised that a captive portal for wireless access, or the airport or big level wireless access point would be literally internet access directly on the gateway. I assume between it.
Marc Laliberte 32:48
Yeah, my interpretation of this is like a they're going after unified devices that do wireless and also like the traditional firewall and gateway and whatever. That's why I mentioned
Corey Nachreiner 32:59
smaller locations like a restaurant or a Starbucks probably unifies them. An airport, maybe there's some unified ones, but I would expect at an airport they would have. I even if you had smaller service providers in there, I assume the airport would provide some sort of internal gateway. But either way, we get the point. It does have to be internet connected in some way for some of this to happen,
Marc Laliberte 33:22
and so once they hacked into the management interface for these devices, they went after modifying the DNS settings to redirect web traffic. So basically, this device is responsible for managing DHCP when a wireless client connects to it. It gets a IP address on the network, and the gateway also sends the DNS servers that it should use. And so, if you aren't using hard-coded DNS, which actually, if you are using hard-coded DNS, that's still maybe not a full mitigation. We'll get to that in a second. But let's assume that your laptop is configured to just get the DNS servers from the wireless network it's connected to. Now you're getting malicious DNS servers that when you go to say Microsoft.com instead of going to whatever Microsoft owned IP address it is, you get sent to a different IP. Now this is where it's actually kind of interesting, and I think there's some missing details in here because things like HTTPS and technologies like HSTS hosts, whatever the the mechanism that makes you default to HTTPS for a certain website, those would defeat a DNS poisoning attack like this. Like if you went to Microsoft.com in your web browser and you ended up at an IP address that is not owned by Microsoft, and they claim to be Microsoft.com. They would be using a certificate that was not issued by Microsoft. So somewhere in here, there's a redirect to these other domains that they list in their report. I think it was ms365-live.com and owa-ms365.com. So like non-Micros. Soft owned domains where somewhere along the lines it's not just a DNS look pointing to another IP that IP redirects your domain entirely and so if you if you're using HSTS that redirect is impossible because your web browser would show a certificate error for that server that's trying to redirect you so there's some other like protocol they're abusing in here, or going after systems that maybe aren't modern enough to use or enforce HSTS. I don't know, but anyways, they ultimately trick the victims into going to a domain and a server that the attackers control, where they use a usually a Microsoft-like lure to trick the victim into either giving up credentials or, in many cases, abusing the OAuth client authentication flow, which basically registers a malicious token under the victim's account. That OAuth, what is it? Client flow authentication. It's like how you log into your TV for Netflix, or how you log into Netflix on your TV. It's that same type of authentication where you have to enter in a couple of numbers, and now there's a long-lived token tied to your account that the attackers can use that even persists through password resets.
Corey Nachreiner 36:18
It's usually supposed to be a device, but you'd have to go to a special place on Microsoft and delete that from having access to get the rid of the attacker with the fake OAuth thing.
Marc Laliberte 36:28
Yep. Now, in their report, they claim that even hard-coded DNS servers aren't inherently protected because all these requests are still unencrypted. The gateway could read or forge or redirect the actual DNS request itself, unless it was protected with something like DNSSEC or DNS over HTTPS. So not totally immune from attack if you hard code 8.8 dot 8.88. They also pointed out in a third of the cases it abused WPAD as well, which is the web proxy auto discovery feature within some operating systems like Windows, where when that's turned on on your computer, it will try and auto discover a web proxy on the network, and if it finds one, it'll intentionally send all of its traffic through that proxy.
Corey Nachreiner 37:19
Random aside, like this is a common attack scenario for for DNS-like poisoning, but this the WPAD comes from a day when people didn't have internet gateways in NAT, and they were literally using proxy servers, and that's why you needed WPad to kind of make it frictionless and automatically find a proxy server. Does anyone still do that? I guess there, like, I guess there are proxies for different situations, but I feel like WPad and is something that needs to be depreciated.
Marc Laliberte 37:54
I think it is disabled by default on most modern operating systems, but I'm willing to bet there's some Windows Seven machines that are still floating around at some of these locations that people are connecting with, and that could be one of these attack vectors. Then, so in some cases they they paired that DNS poisoning with that device code authentication flow abuse, but in most cases they were targeting Microsoft credentials and Microsoft accounts as well, too. Just in general, so it's interesting. Like we don't see many concrete reports. Like we've seen plenty of discussions around attackers going after edge networking equipment, internet exposed management interfaces. Obviously, DNS poisoning has been around since Forever, this combination of the two to specifically go after the hospitality industry and I guess clients of the hospitality industry is a relatively new or at least recent iteration of this type of attack.
Corey Nachreiner 38:55
I've seen hotel guest portals be abused to try to get people in hotels, but like you say, generally wireless-you know-hospitality, wireless access. It's something we warn about all the time. By the way, we tell people to be careful on trusted or untrusted public wireless networks. If you don't own the wireless network, you have no clue what's going on. But yes, I agree. It's kind of new and interesting. We have a great protection for it, by the way. They keep on talking about always on full VPNs, but I think you and I would rather say Fire Cloud and Z ZTA or ZTNA, which by definition is like I guess they say full connection, full port VPNs, but that may not always be on. I my whole advice of if you're in a public Wi-Fi network turning on a VPN, why not just have ZTNA where you always have a secure connection no matter what you're connected to,
Marc Laliberte 39:52
always on VPNs or so 2019.
Corey Nachreiner 39:55
Yeah, exactly. They should be depreciated like a WPAD. And switch to FireCloud. I mean, I mean ZTNA or ZTA Fire Cloud Private Access.
Marc Laliberte 40:06
Exactly.
Corey Nachreiner 40:07
WatchGuard Technologies.
Marc Laliberte 40:11
Either way, if you are in the hospitality industry and you're listening to this, and you may not, if you're not certain that your your networking equipment isn't exposed to the internet like that, maybe go do a quick audit and make sure that you don't have management access publicly available. But
Corey Nachreiner 40:28
where they heard that before, Mark?
Marc Laliberte 40:30
Where have they heard that before? Every day,
Corey Nachreiner 40:33
new device.
Marc Laliberte 40:34
Yep, that's a polite way of saying that. But careful! Make sure you hide it, or else Claude or OpenAI is going to come hack it agentically anyway at some point in the future.
Marc Laliberte 40:49
Hey, everyone! Thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate, review, and subscribe. If you have any questions on today's topics, or if you want to suggest a topic for a future episode, you can reach out to us on Blue Sky. I'm at itsmark.me, Corey is at SecAdept, and the both of us are on Instagram at WatchGuard underscore Technologies. Thanks again for listening, and you will hear from us next week.