Podcast Detail

SANS Stormcast Wednesday, March 18th, 2026: IPv4 mapped IPv6; KVM Vulnerabilities; AWS Bedrock DNS Covert Channel

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/9854.mp3

previous
Podcast Logo
IPv4 mapped IPv6; KVM Vulnerabilities; AWS Bedrock DNS Covert Channel
00:00

Podcast Transcript

 Hello and welcome to the Wednesday, March 18, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in
 Penetration Testing and Ethical Hacking. Today I took
 a little bit closer look at the IPv4 mapped IPv6
 addresses. That's something that came up yesterday when I
 looked at these proxy requests in our honeypot and just to
 see a little bit, you know, how they work and how they're
 being used. Now, really, these addresses should never be seen
 on the network. They're really sort of more an internal
 operating system construct to allow essentially IPv6 only
 software to still communicate via IPv4. But yes, you know,
 they are still somewhat usable. Now, I did a quick
 test here with ping 6. Ping 6 does not work because, well,
 even if it would convert it to IPv4 as it should, ping 6 only
 sends IPv6 packets and that, of course, will not work. But
 other tools like, for example, WGET or your browser will
 happily accept these mapped addresses. They'll translate
 them to IPv4 and basically then communicate over the
 network just using the IPv4 address. Not sure if there's
 really sort of a security problem here with this. It
 could be abused for some kind of obfuscation, like you often
 see people use odd IP addresses like octal formats
 or just the long integer format in order to obfuscate
 IPv6 addresses. This is really just another way to sort of
 encode an IP address as a string in that sense and
 probably doesn't really add any additional threat. Yet
 another reminder that you probably shouldn't deal with
 IP addresses just as a string. Well, look at the nature of
 the IP addresses. If it's IPv4, it must be a 32-bit
 unsigned integer. So treat them like that and that
 usually gets you out of trouble. And Paul Asadorian as
 well as Ronaldo Vasquez Garcia did publish a blog post for
 Eclipseum outlining some of the vulnerabilities they found
 in these cheap low-end IP KVM systems. We talked about them
 before. These are sort of these, you know, anywhere
 between sort of $25 and $100 IP KVM systems that have
 become quite popular in the past. And I wrote in the past
 also about how to better secure them. I was actually a
 little bit almost surprised the positive side that they
 didn't for the most part find any sort of, you know, huge
 vulnerabilities. There's one vendor that is labeled here
 where they had a remote code execution vulnerability. That
 vendor is also in so far problematic as there appear to
 be no patches forthcoming to address these vulnerabilities.
 The other vendors, there were some vulnerabilities that
 should be fixed. Like for example, brute force
 prevention was missing for some of them. That's of course
 a problem with devices like this that are pretty much
 secured with username and password and also something
 that's not that terribly hard to do for a device that really
 only has sort of one real user. But the other vendors
 are coming up with patches if they haven't already been
 released. So in so far that part of market doesn't seem to
 be as desolate in some ways as the rest of the IoT device
 market. And one problem that's coming up with the recent
 grace about AI agents is the problem that well, how do you
 allow an agent to securely execute code that they
 created? One solution of course is sandboxing and AWS
 does offer the Bedrock Agent Core Interpreter. That's a
 sandbox. Well, basically interpret the code that the
 agent wrote and then, well, basically run it. Now, this
 sandbox is supposed to be isolated and with that limits
 sort of the exposure to the outside world and any attacks.
 Well, turns out this is not quite true. Beyond Trust found
 that the agent inside the sandbox is still able to send
 and receive DNS traffic. So this way DNS can be used as
 the good old covert channel. That's really sort of what in
 some cases I almost feel DNS was intended to be. And with
 that you now gain access to the sandbox and also outbound
 from the sandbox that isn't supposed to happen. And that's
 sort of why you originally used the sandbox. They have
 reported this to AWS and AWS has deployed respective fixes.
 But yet another example where you have to be careful. And in
 general, the idea of sandboxing agents is still
 sort of, I think, at least under development in the sense
 that it's really hard to have a useful agent and not give it
 access to anything. So the sandboxes, even if you pre
 -populate them with data or so you want the agent to act on,
 are usually somewhat limited in their functionality. Well,
 that's all that we have time for today. So thanks for
 listening. Thanks for liking. Thanks for subscribing. And as
 always, special thanks for leaving good comments in your
 favorite podcast platform and talk to you again tomorrow.
 Bye.