Podcast Detail

SANS Stormcast Friday, February 27th, 2026: Finding Singal (@sans_edu intern); Google API Keys and Gemini; AirSnitch Breaking Client Isolation

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9828.mp3

previous
Podcast Logo
Finding Singal (@sans_edu intern); Google API Keys and Gemini; AirSnitch Breaking Client Isolation
00:00

Podcast Transcript

 Hello and welcome to the Friday, February 27th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I am recording from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Bachelor's degree program in Applied
 Cybersecurity. Well, talking about our Bachelor's program,
 today we have another guest diary by Austin Bodolay. Austin
 looked into, well, one of our Internet Storm Center honeypots.
 That's a part also of the Internet Storm Center 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, who else? 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
 like 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 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 Joe 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 of 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 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 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 then
 they're 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 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, 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, you know, that may break sort of some behavior that
 people are expecting from these API keys.
 So we're going to get to the next step. 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 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,
 the clients cannot sort of sniff each other's traffic,
 even if they basically just have a good old Wi-Fi 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 find in wired
 networks, where you sort of, you know, connect to different
 ports in a switch and then are able to sort of impersonate a
 host that's connected 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
 gigahertz network, while the victim is on the 5 gigahertz
 network. And by using these two different networks,
 impersonating MAC address, basically it comes back down
 to just a good old MAC 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, the
 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, best practice. But of course, if you have more of 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. And 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, you
 know, 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 assumed
 at 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 leave a good review in your favorite
 podcast platform and talk to you again on Monday. Bye.