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.
