← SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Stormcast Wednesday, October 29th, 2025: Invisible Subject Character Phishing; Tomcat PUT Vuln; BIND9 Spoofing Vuln PoC
00:08:04
SANS Stormcast Wednesday, October 29th, 2025: Invisible Subject Character Phishing; Tomcat PUT Vuln; BIND9 Spoofing Vuln PoC
Loading summary
Transcript1 lines
- [00:05]
A
Hello and welcome to the Wednesday, October 29, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ulrich, 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 in. 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. UTF8 encoding is very commonly used in email subjects, so that is actually quite common. I tried just to filter for a while all email that had any UTF8 encoded sub but well that and then we have a critical vulnerability in Apache tomcat affecting all versions going back to version nine. 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 effect. 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 bind9 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. That's actually not the real problem here. The problem is the good old belly quick check in DNS. A DNS response in addition to actually answering the query. It may include additional data and 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. Now the proof of concept here also shows 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, you know, Cloudflare, your ISPs, Resolver or whatever you're using for efficiency purposes, for speed purposes, that's usually queries quite a 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 a 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 DNSUPDOWN parameter you can configure then on the client script that's being executed in order to apply these parameters to 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 doing here with OpenVPN, this is less of an issue, but still update it. 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 by.