SANS Stormcast Wednesday, January 21st, 2026: Punycode Hunting; telnetd vuln; 6 day Certs and IP Certs; Oracle Patches

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

previous

Punycode Hunting; telnetd vuln; 6 day Certs and IP Certs; Oracle Patches

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, 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.