SANS Stormcast Wednesday, October 29th, 2025: Invisible Subject Character Phishing; Tomcat PUT Vuln; BIND9 Spoofing Vuln PoC

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

previous

Invisible Subject Character Phishing; Tomcat PUT Vuln; BIND9 Spoofing Vuln PoC

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, October 29th, 2025
 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 Cloud
 Security. Well, in Diaries today we got an interesting
 new phishing trick that Jan wrote about. It involves
 invisible characters in the subject of the email. Now, the
 trick has been quite common in the body of the email, where
 it's being used to break up words that are often being
 used to trigger spam filters. But now attackers are also
 using it in the subject line, probably for the same reason.
 Here the subject as seen by the user is your password is
 about to expire. So a classic phishing subject line that of
 course may get blocked by common phishing filters. But
 here the attacker is then inserting invisible
 characters. Now, strictly speaking, the characters being
 used here are not really invisible. One, for example,
 that Jan observed here is the soft hyphen, which should
 still be displayed as a hyphen. But many email clients
 like, for example, Outlook in this example, do not display
 them as part of the subject of an email. So they basically
 just disappear. And that's sort of how they're bypassing
 these filters. You cannot just look for, hey, are they using
 some odd spaces or things like this? But you also have to
 look for characters that may be legit in some contexts, but
 are here just used to break up the text. UTF-8 encoding is
 very commonly used in email subjects. So that is actually
 quite common. And I tried just to filter for a while all
 email that had any UTF-8 encoded subject. But, well,
 that's... And then we have a critical vulnerability in
 Apache Tomcat affecting all versions going back to version
 9. It's a directory traversal vulnerability that may lead to
 remote code execution. However, in order to exploit
 this vulnerability, the put method has to be enabled.
 Well, the put method allows you to upload files to a web
 server. So if you enable that put method, it's really
 critical that you only constrain that upload to very
 specific directories. If you even want to allow sort of a
 simple put method like this that just uploads files. The
 problem here is that due to a directory traversal
 vulnerability, this put method can then be used to upload
 files into arbitrary directories, which could lead
 to uploading web shells and with that remote code
 execution. Now, put is also often enabled like in the REST
 APIs. They're probably not here affected by this. It
 should require that you actually upload a file. But
 regardless, if you are running an out-of-date Tomcat server,
 if you do use and have enabled the put method in your
 application, you probably do want to update this quickly. I
 would expect an exploit to be released shortly if it hasn't
 already been released. And we do now have a proof of concept
 exploit for the bind 9 spoofing vulnerability that
 was patched a few days or last week. Well, the problem here
 is actually a little bit more severe than I envisioned it
 when I first talked about this vulnerability. I talked about
 this possibly being like a weak random number generator
 or such for a bind. And that's actually not the real problem
 here. The problem is the good old Bellywick check. In DNS, a
 DNS response, in addition to actually answering the query,
 it may include additional data. And it has been one of
 those ancient DNS spoofing vulnerabilities where an
 attacker could just add arbitrary spoofed data as
 additional records. Well, that appears to be the problem here
 that an attacker is able to do just that. And now the proof
 of concept here also shows a configuration for a vulnerable
 bind server. It does configure a particular domain as a
 forward-only domain, meaning all requests are sent to
 specific forwarders. This has been an issue in the past
 where bind specifically trusted responses coming back
 from these explicitly configured forwarders. It's
 possible that this is the same issue here, that the root
 cause is the forwarder configuration. So if you don't
 use a specific forwarder, then you may not have a problem
 here. On the other hand, many configurations use specific
 forwarders because that sort of is a very standard
 architecture for a DNS, where your local DNS resolver just
 forwards queries to some trusted resolver like
 Cloudflare, your ISPs resolver or whatever you're using. For
 efficiency purposes, for speed purposes, that's usually a
 quite nice configuration. Also for simplifying your firewall
 configuration, it's nicer to use these forwarders. These
 forwarders aren't then necessarily cleaning up any
 responses that they are receiving. And that mismatch
 between the forwarder not cleaning them up and your
 resolver trusting the forwarder, that sometimes
 leads to problems like this. But anyway, we do have a proof
 of concept exploit available now. That means you better get
 patching on this. Still, it may only be exploitable in
 specific configurations, but I haven't had the time to sort
 of dig into all of it and try all the configurations here to
 see what exactly then triggers or doesn't trigger this
 vulnerability. Then we do have a vulnerability being
 addressed in OpenVPN. The vulnerability is severe. It
 can lead to arbitrary code execution, but exploitation, I
 think, is a little bit tricky here. The problem is that when
 you're connecting to an OpenVPN server, the OpenVPN
 server may push various configuration parameters,
 among them lists of DNS servers that you should be
 using. Well, in this DNS up -down parameter, you can
 configure an undeclined script that's being executed in order
 to apply these parameters to your operating system. And the
 problem is that the parameters aren't properly sanitized
 before they're being passed to this parameter and to the
 script. And as a result, you may essentially have an OS
 command injection vulnerability here in OpenVPN.
 So to exploit it, as far as I understand it, you need to
 connect to a malicious OpenVPN server, connecting to a
 trusted VPN server. And that's what most people, I think, are
 doing here with OpenVPN. This is less of an issue, but still
 updated. It should be relatively easy to update. It
 affects all the Unix-like operating system, like macOS,
 Linux, and the like. Well, and that's it for today. Thanks
 for listening, and thanks for sharing, and thanks for liking
 this podcast and subscribing to it, and talk to you again
 tomorrow. Bye.
 Bye. Bye. Bye. Thank you.