Podcast Detail

SANS Stormcast Tuesday, March 17th, 2026: Proxy URLs; Local Network Address Restrictions; Advanced Phishing

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

previous
Podcast Logo
Proxy URLs; Local Network Address Restrictions; Advanced Phishing
00:00

Podcast Transcript

 Hello and welcome to the Tuesday, March 17, 2026
 edition of the SANS Internet Storm Centers Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in Cloud
 Security. In diaries today, I wrote up some attacks that I
 observed this weekend against our honeypots that hit a URL
 starting with /proxy/. Now this URL prefix is
 often used, well, as the name implies, for proxies. And
 that's how the attacker is attempting to use the URL.
 They're essentially attempting to use your web server as a
 proxy to reach internal IP addresses. Now, the particular
 IP address they're looking for here is 169.254.169.254.
 This is an IPv4 link only address, typically sort of not
 seen in a normal network, but it is used by cloud providers
 for metadata services. So each virtual host that you're
 setting up can reach an API at that IP address that then
 provides the host with specific configuration option,
 including credentials. And that's exactly what they're
 looking for here. So kind of a server-side request for
 Chariot hack. But of course, if they find an actual full
 proxy at that URL, then these attacks are a lot simpler.
 There are also some interesting sort of
 obfuscation techniques. For example, they're using these
 IPv4 mapped IPv6 addresses that are starting with all
 zeros FFF. And then the last 32 bits are just the IPv4
 address they're reaching, which here, because it's an
 hexadecimal, is then A9FE, A9FE. So what should you do
 here? Well, definitely make sure if you are running
 proxies on a web server, or if you have anything like the old
 sort of course proxies or so set up for cross-origin
 requests, make sure you properly secure them. Web
 application firewalls sometimes are configured badly
 here as well. And make sure they cannot reach that 169.254,
 169.254 address, or any other address for that matter, that
 you don't want them to reach. So I wouldn't really go here
 for a particular filter for this slash proxy. Like I said,
 it may be something that you need for some applications,
 but be careful how this particular proxy is
 configured. And then we got a new version of Microsoft Edge
 version 146. This version tracks the respective changes
 in Chromium. And of course, Chrome and other Chromium
 derived browsers will see the same changes. The reason I
 mention it this time, I usually don't mention these
 updates is where there's no security vulnerability being
 addressed here. But it's a security feature that I think
 is often overlooked, that has been introduced in version
 143, that gets sort of a couple adjustments here. And
 that's local network access restrictions. The problem is
 actually something related to the prior stories, where we
 have these proxies or, well, really server-side requests
 for a request forgery, where you can trick a web browser to
 request resources from a third -party site. So what local
 network access restrictions does is that there are three
 different zones defined, public IP addresses, these non
 -routable IP addresses, and loopback IP addresses like 127
 .001. And essentially, you're not allowed to cross over
 between those three zones. So if you're loading a public
 website from a public IP address, it's not allowed to
 request resources from like, you know, a 10.IP address, or
 a 127.001 address, or one of these 169.254 IP addresses.
 Now, what the latest change does is it actually allows you
 sort of administratively to configure some settings to set
 up certain allow lists of URLs that are allowed to violate
 this policy. This can be useful for developer purposes.
 Now, typically, users would get in some cases, like pop-up
 warnings and the like, but you can essentially disable those
 warnings to allow for easier automated testing. And in
 general, you know, to easier test a website or develop a
 website that may still run on a local system and be using
 the loopback IP address. But it's sort of part of a larger
 website that you're working on. Interesting feature, local
 network access and restrictions and definitely
 something that you sort of should be aware of. And we've
 got an interesting story that I think makes a good sort of a
 case study when it comes to a little bit more sophisticated
 phishing attacks and well aware user education may
 actually still be important. I have talked bad about user
 education in the past and the limits of it. But yes, it does
 provide sort of a final barrier of entry for some of
 the more sophisticated phishing attacks where sadly a
 lot of the automated and technical controls are
 failing. This particular example targeted a European
 security vendor. It was written up by Spec Ops Soft.
 The attack itself, I think, all the different pieces of it
 are not really all that terribly sophisticated. What
 often distinguishes the more sophisticated attacks as from
 the sort of more random attacks is really more that,
 you know, how much care the attacker is paying to make the
 attack look good. In this particular case, they're
 actually using an open redirect at a Cisco website in
 order to bypass any kind of Cisco email security gateway.
 They're then redirecting to another valid attack, an API
 email provider. Next, they're then going only in the third
 step to the actual phishing website. So that way, the
 email gateway, first of all, sees a valid URL that directs
 to a valid URL. And well, then they're sort of stopping
 checking. Also, the sender is spoofed, but DKIM is here
 faked by basically just using a misconfigured mail server
 that allowed them to relay this email. So all of these
 things like these open redirects and the
 misconfigured mail server is all sort of out of the
 control, off the target. These are third parties they
 interact with or even don't interact with. And that then
 leads to the executive, in this case, receiving the
 phishing email that will then attempt to steal Microsoft
 credentials. I think where I personally would have probably
 sort of gotten a little bit suspect of the entire email is
 when they had like the CAPTCHA then protecting the login
 page. That CAPTCHA didn't look right to me. But these are
 very subtle hints that many users probably won't identify
 necessarily as malicious. Well, and this is it for
 today. So thanks again for listening. Thanks for liking
 and thanks for subscribing to this podcast. And as always,
 talk to you again tomorrow. Bye.