Hello and welcome to the Wednesday, January 21st, 2026
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
penetration testing and ethical hacking. A good
reminder today from Xavier to, well, don't forget to look for
international domain names in your DNS logs. There are some
legitimate international domain names, and of course,
how many of them you'll see depends somewhat on your
users, which websites they frequent. But international
domain names also have the unfortunate ability to
impersonate the more commonly used ASCII domain names. And
well, that's exactly what Xavier is looking for here. If
you have a non-ASCII domain name, the label starts with XN
-Dash. So that's one thing to look for. In particular, if
the top level domain name is not an international top level
domain, but a standard ASCII domain, that's often a hint
that something fishy is going on here, as in someone
attempting to impersonate a particular website. So take a
look at that. However, how effective this particular
attack is also very much depends on the browser your
users are using. Safari tends to be a little bit more
vulnerable here in that it's more likely to actually
display those non-ASCII characters. While a lot of
other browsers, like, well, really a lot of Chrome is for
the big other browser, is typically showing the puny
code, which means the domain is then displayed with the XN
-Dash prefix and no non-ASCII characters are being
displayed. So take a look at the domain names or domain
logs and see if you find anything interesting. And
always kind of like these vulnerabilities in old
software that have been around for decades. Well, this
particular vulnerability has been around for exactly a
decade, was introduced in March of 2015. And in effect,
the inet utils version of the Telnet demon. Now, nobody
should be running Telnet anymore. But in particular in
IoT environments and such, it's still sadly somewhat
common. And in this particular case, it's the Telnet demon
that's started by inetd. So you have inetd that really
listens for incoming connections and then on-demand
starts various small services like, for example, telnetd.
And as part of this, it's possible to pass a user
variable to the Telnet demon that's then being passed
without any kind of sanitation to the actual login shell. And
here a user can just pass the root username and with that
become easily root. Interesting vulnerability, no
CVE assigned to it. I haven't tested myself. I'd have to
find a version of Telnet d that I actually still have
around. But yeah, looks very plausible. So if you're
running inetd, first of all, just turn off Telnet. There is
no real reason why you should still be running Telnet. But
definitely make sure that you also update just in case it's
getting enabled again later. And Let's Encrypt announced
that they concluded their testing on shorter lift
certificates and are making them now available for
everybody. Now, at this point, short lift certificates are an
option if you would like to use them and they are only
valid for six days. Then you need to select the short lift
certificate profile. And only more recent ACME clients
actually support a different certificate profiles. The
default is still 90 days for Let's Encrypt certificates.
What comes with the short lift certificates, that's one
reason why you may want to select them, is that you now
also have the ability to get a certificate for an IP address,
not just for a host name. Personally, I don't see a
great use case, sort of at least for the more general use
of IP-based certificates. I prefer to use host names
anyway to connect to different resources. It gives you a lot
more flexibility. But the one sort of use case is often
cited here is if you're trying to do things like DNS over
HTTPS or DNS over Quick, then of course that DNS server
needs a certificate. And well, the client may not be able to
look up the IP address based on a host name because it
needs a DNS server to do so. So that may be one use case
where you would like to use an IP address based certificate.
Again, they're only valid for six days and the default
hasn't changed. If you get a default certificate that's
valid for 90 days, then you must use a host name. You are
not able to use an IP address. And Oracle today released the
first quarterly critical patch update for the year. This
update fixes a total of 337 vulnerabilities. The one
vulnerability I saw sort of, you know, recurring for
multiple products is the Apache Tika vulnerability.
That was patched, I think, a month ago and is rated with a
CVSS score of 10 for many of the products. This also
affects the Oracle Fusion middleware, which has two
additional, actually two of these three vulnerabilities
are Tika related and rated with a 10. And then there's a
third vulnerability that's also rated with a CVSS score
of 10. So definitely pay attention to this. This Tika
vulnerability has been around for a while. So haven't seen
an exploit for it yet. But very possible that there is
already an exploit circulating. So definitely get
this patched and make sure you're not exposing more than
you have to. Well, and this is it for today. So thanks for
listening. Thanks for liking. Thanks for subscribing to this
podcast. And as always, thanks and talk to you again
tomorrow. Bye.
Bye.
