Podcast Detail

SANS Stormcast Monday, June 22nd, 2026: IPv4 Mapped Phish; nginx bug; squid bleeds; AMD encryption fix

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

previous
Podcast Logo
IPv4 Mapped Phish; nginx bug; squid bleeds; AMD encryption fix
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Monday June 22nd, 2026 edition
 of the SANS Internet Stormcenter 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
 cybersecurity engineering. Well, Xavier came across an
 interesting phishing email that used IPv4 mapped IPv6
 addresses. These addresses are really more an operating
 system construct. So you will not see these addresses on the
 network. That's something I often see people describe, but
 on the network, you would see an IPv4 packet in this case.
 The main reason for these IPv6 addresses and basically start
 with all zeros, then FFFF and the last 32 bits are the IPv4
 address that's sort of embedded in this address. The
 real reason for these addresses is really more than
 that. You know, when you're writing networking software,
 you can really just write IPv6 software and then it will
 automatically be able to connect with IPv4 hosts. But
 the operating system then will basically create an IPv4
 packet, not an IPv6 packet when connecting to such an
 address. So the main purpose of these addresses is
 obfuscation from scanning tools. Your antivirus, anti
 -malware, anti-spam will not necessarily see an IPv4
 address here. They think they sort of have an IPv6 address.
 And then of course, they won't find it on any block list. So
 at least that's what I think is sort of happening here.
 That's why attackers sometimes use these addresses. Now in
 the host header, when you're copy pasting this address into
 a browser, you will still see the IPv6 address here. But
 it's really not just a string that used as a host name,
 which happened to be that address. So from a filtering
 point of view, I think you can just essentially consider all
 these IPv4 mapped IPv6 addresses malicious and just
 block emails that contain these strings. And F5 fixed
 two critical vulnerabilities in NGINX, the web server and
 often also used as an HTTP proxy. The more important one
 of these two, or should I say more critical one, is
 affecting Quick or HTTP 3. It's a use-after free, so a
 memory management, vulnerability that is
 exploitable for remote code execution if an attacker can
 make it past address space, layout, randomization or ASLR.
 So definitely get your NGINX servers patched. The second
 vulnerability does have quite a few requirements as to
 specific configurations that you need to run. It's also a
 buffer overflow, so also something that you should
 address. But I think exploitation may be a little
 more likely for the first one in particular if you don't use
 ASLR on your system, like if the binary wasn't compiled for
 it, which does happen sort of in the IoT world, not so much
 sort of if you're running a major Linux distribution. And
 talking about HTTP and proxies, probably one of the
 more popular ways of implementing a proxy, in
 particular if you're sticking with open source software, is
 SQUID. And while we do have a vulnerability in SQUID, that's
 a little bit a reminder of Heartbleed, in that it leaks
 parts of other users' requests. The way this would
 be exploited is that an attacker is able to send
 requests through the proxy and is able in the reply to
 receive data submitted by other users. So a victim would
 log in to a website. Now the attacker would then connect
 through that same SQUID proxy to an FTP server. And due to a
 parsing error in directory listings via FTP and SQUID,
 yes SQUID also does deal with FTP, the attacker would then
 be able to see some of the content submitted via other
 users via HTTP. So interesting vulnerability, probably a
 quick fix here is not to allow FTP and that hopefully is
 nothing that you're needing too much, but there is also a
 patch available for this vulnerability. And it was just
 last week that I referred to a publication that discovered
 that AMD turned off memory encryption on its consumer
 -grade processors, in particular the Ryzen 9000 line
 of CPUs, which is sort of their current consumer CPU.
 Well, AMD, after being called out for it, never really
 explained why it was removed, but stated now that in a BIOS
 update in July, the feature should be re-enabled.
 Remember, this was one of those odd issues where you
 could enable it in the BIOS, but it was actually not
 enabled in the CPU due to a firmware change in the CPU. So
 I guess they're now trying to undo this change and hopefully
 come July, your memory encryption will work again.
 Well, and that's it for today. So thanks again for listening.
 And a quick note about my schedule this week. There will
 only be a podcast for Monday, Tuesday, Wednesday. I'll be
 traveling at the end of the week. So there will be no
 podcast on Thursday and Friday. Thanks and talk to you
 again tomorrow. Bye.