← SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Stormcast Friday, February 27th, 2026: Finding Singal (@sans_edu intern); Google API Keys and Gemini; AirSnitch Breaking Client Isolation
00:09:22
SANS Stormcast Friday, February 27th, 2026: Finding Singal (@sans_edu intern); Google API Keys and Gemini; AirSnitch Breaking Client Isolation
Loading summary
Transcript1 lines
- [00:05]
A
Hello and welcome to the Friday, February 27, 2026 edition of the Sands and its Storm Center's Stormcast. My name is Johannes Ulrich and today I'm recording from Jacksonville, Florida, and this episode is brought to you by the Sans Edu Bachelor's degree program in Applied Cybersecurity. Well, I'm talking about our bachelor's program. Today we have another guest diary by Austin Bod. Austin looked into one of our Internet StormCenter honeypots. That's sort of part also of the Internet StormCenter internship that these students participate in. And, well, he struggled with a very common challenge, information security. And that's too many alerts. Now, you wouldn't really think so, but even for a simple honeypot connected to a random home IP address, you still have this problem. And Austin now turned to, well, Welsh chatgpt to AI for help to try to understand these alerts better and is here documenting some of the challenges. One of the conclusions here, that is something that people often recognize at this point is that in order to really better understand alerts, you can't just rely on just looking at inbound data and seeing basically what gets stuck in your firewall or what inbound requests trigger certain IDS rules, or in this case, just honeypot hits. But what's going back is sometimes as important, if not more important, to really figure out what a particular attack is trying to accomplish. And Jo Leon with Truffle Security has published an interesting blog post about some unintended consequences with Google API keys. Once Google started offering Gemini their AI system, Joe works with Truffle Security. And Truffle Security, of course, is famous for the software they're creating that helps you find stray and leaked API keys. Now, the problem with the original Google API keys was that Google didn't consider them a secret. You may have seen them, for example, being used for Google Maps. And the fundamental problem there was that you basically, if you wanted to use the Google Maps API from a web application, you often had to deliver that API key as part of JavaScript to the client so the client would be able to see these API keys. And Google did offer a couple weak ways how you could constrain those keys, for example, by using a specific refer. But ultimately the idea was, hey, this API key can only be used to access public data from the Google Maps API. You put some sort of billing constraints around it. So someone can't just steal the key and then run up your Google Maps bill. And well, if it leaks and it's being abused, you may Just rotate the key. That was sort of a little bit the idea here with these Google Maps API keys. But what sort of happened was that by default, when you're setting up an API key like this, it's unconstrained, meaning that it has access to all the APIs that this particular project has access to. And now you enabled Gemini and, well, the same API keys that you published to your website for Google Maps can now be used to query Gemini. And, well, Gemini now does in some cases have access to sensitive data. And that's the problem that's happening now here. And that are literally sort of GitHub, repos, Pastebin and such, with thousands of Google Map keys that have been leaked in the past. Like I said, really leaking them wasn't sort of avoidable the way you're supposed to use them. And even if you're creating a new key now, it's still being created by default as sort of an unconstrained API key. So what you have to do now is double check how your API keys are configured, maybe set up different projects or such to better isolate them from each other. Google has not yet fixed this problem. They're working on a fix for it initially. Actually, they sort of considered it. Well, it's the way it's supposed to work. So they weren't initially even sort of suggesting a fix here, but apparently they're working on it now. But there's no timeline when a fix will be released, and the fix may even not be retroactive, given that that may break sort of some behavior that people are expecting from these API keys. And if you thought we were done with WI FI related vulnerabilities, well, we got a new tool and a new paper here from researchers at the University of California, Riverside. The tool is Airsnitch. And what they're going after is client isolation in WI FI networks. If you're setting up a modern WI FI network, you often enable a feature called client isolation, which means that clients can't talk to each other. And the. The idea is also that even though they may use the same credentials to actually connect to the network, each client gets unique keys. And with that, clients cannot sort of sniff each other's traffic, even if they basically just have the good old wifi sniffer way, just collect all of the WI FI traffic. At least that's the idea with client isolation. What they're showing here in the paper, and I can't really do it justice here in this podcast. There's a lot going on here, but the fundamental idea behind this paper is that an attacker can play tricks, well, similar to what you sometimes find in wired networks where you sort of, you know, connect to different ports in a switch and then are able to sort of, you know, impersonate a host that's connect to one switch port by connecting to another switch port. That's a little bit the idea here. And part of the abuse here also comes from broadcast traffic. Broadcast traffic of course has to be readable by everybody on the network. And well, that of course is then encrypted with group keys. So these are some of the basic ideas here. But the way this is usually then implemented is where an attacker may, for example, connect to the 2.4 GHz network while the victim is on the 5 GHz network. And by using these two different networks impersonating Mac address, basically it comes back down to just, you know, good old max spoofing. In the end, at least for some of these attacks, the attacker is able to not just intercept but also inject traffic and doing that bi directional in this. Now, a couple of architectures that are particular vulnerable here is if you have an access point and you have two SSIDs defined, a guest one and an internal one. So in order to exploit this, the attacker still needs access to the network. So this does not work completely passively like some of the older attacks. The attacker needs to connect to the network. So they need to have credentials to connect to the network. But if one access point has both guest and internal network, then a user on the guest network may actually be able to inspect traffic and inject traffic into the internal network. So I think that's one of the most concerning vulnerabilities here. One workaround is to use different VLANs for these two networks, which in enterprise networks is usually I would think, a best practice. But of course if you have more like a home style router and access point, then often they don't have VLAN capability and they just rely on the two different SSIDs to essentially separate these two networks. They all sort of use the same sort of IP address range, which further complicates kind of keeping them separate. So, interesting paper here. If you're looking into like what devices are vulnerable and how to mitigate some of this, please refer to the full paper. Like I said, there's a lot more to it here, a lot of details, a couple different sort of ways this attack can work. But assume that this point, pretty much any sort of access point, even a lot of enterprise networks are vulnerable to at least one of the attacks presented here. Well, and that's it for today. A little bit different content today with these two bigger stories and skipped some of the new vulnerabilities here. But anyway, hope you liked it, hope you'll subscribe to it, and I hope you'll leave a good review in your favorite podcast platform and talk to you again on Monday. Bye.