SANS Stormcast Friday, November 6th, 2026: RootEvidence Cisco IOS Opt-Out Scans; OpenSSH musl sshhole (CVE-2026-123158); Refrigeration OT Hardening; Zyxel GS1900 OOB Write (CVE-2026-107441)

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

previous

RootEvidence Cisco IOS Opt-Out Scans; OpenSSH musl sshhole (CVE-2026-123158); Refrigeration OT Hardening; Zyxel GS1900 OOB Write (CVE-2026-107441)

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 Friday, November 6, 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 Cloud
 Security. In Diaries today, nothing too exciting. We did
 have in our honeypot some interesting, I thought
 initially, Cisco IOS vulnerability scans that come
 from a company RootEvidence that does one of these sort of
 exposure management, vulnerability management style
 net wide scans. What they are doing differently than other
 companies is that in their HTTP requests, they are
 including two opt-out headers, opt-out email and opt-out URL,
 which basically gives you a website where you can opt out
 of these scans or an email address where you can do the
 same. Interesting approach and I've not seen this being done
 by any other similar companies. We have literally
 dozens of companies doing essentially sort of the same
 thing. And I've always been a little bit curious about the
 immense sort of traffic we've seen our honeypots from these
 companies. And so coming up with some standards like this
 would certainly make some sense. But, well, if you want
 excitement, we do have an interesting critical
 vulnerability in certain types of SSH installs. Now the
 problem here isn't exactly in SSH. It's in musl. musl, if
 you haven't heard of it, is a variety of standard C
 libraries. So it's a replacement for libc or glibc.
 And it's often used in smaller footprint systems, like most
 importantly in the Alpine Linux that's often used in
 containers. But also OpenWrt and such uses musl. So
 anything that basically has a small memory footprint, not a
 lot of CPU cores and such, often uses this library. And
 sadly, well, they changed how crypt, the function that
 verifies passwords works, which in conjunction with SSH,
 then leads to any password that's longer than 256
 characters being considered valid. Now the sshhole
 website has a good sort of walkthrough what exactly
 happened here and all the little details, a little bit
 too much to cover it here in the podcast. But what it comes
 down to, if your system uses musl instead of glibc, and
 again, Alpine Linux is probably the number one item
 here that you should look at. And if your version, your SSH
 daemon is first of all enabled, which of course is
 often not on containers, and if it does allow password
 -based logins, and if it does not use libpam, which is often
 actually disabled or not even compiled in a lot of images,
 then you may be vulnerable. So a couple conditions here to
 actually enable this vulnerability, but certainly
 something to look for. And if you're vulnerable, very easy
 test, just try root. It has to be a user that doesn't have a
 password defined actually. So that's another sort of
 dependency here. In that case, just try a long password,
 anything longer than 256 bytes should automatically log you
 in no matter what you type. So the content is irrelevant,
 just the length matters at that point. Interesting
 vulnerability and one of those, you know, where APIs
 change and this case, I think, change in very weird and kind
 of a little bit obviously wrong ways. And then of
 course, other software relying on these APIs like SSH, well,
 they then come to the wrong conclusion that the password
 may be correct. It's actually not correct. And a number of
 United States government agencies came together to
 publish a brief advisory for owners of refrigeration
 systems, well, to explain how to harden them. That of course
 comes after we had all of these attacks against grocery
 stores and in some cases also against the stores on military
 bases that led to the spoilage of a huge amount of food in
 refrigeration systems. The advice that they are providing
 is, in my opinion, pretty straightforward. For example,
 they state you should eliminate net exposure, you
 should isolate operational technologies, credential
 security, all of these good things, applying patches,
 where I think an advisory like this is most useful if you
 need buy-in from management or such to actually implement
 these things. Then a document like this may give you the
 backup that you need in order to justify spending time on
 actually implementing some of these solutions and maybe even
 in some cases to degrade some of these services like, for
 example, remote manageability of some of these systems. So
 take a look at this if you are dealing with any systems like
 this. What they're recommending here pretty much
 applies to any kind of OT, so operational technology that's
 connected to a network. It's not just refrigeration
 systems, even though they, of course, triggered this
 document.
 And if you're using any Zyxel GS1900 series switches, well,
 be aware there is an update for the firmware out fixing a
 vulnerability that's currently being exploited. The advisory
 doesn't state so, but it does credit Binarly with the
 vulnerability. And what Binarly basically discovered
 was that they came across a malware repository that
 included a Python script exploiting this specific
 vulnerability. It appears to be a variety of vulnerability
 that Zyxel published in the past, but, well, didn't
 apparently publish completely. So definitely get this up to
 date. The advisory does, however, state that the attacker
 needs network access in order to launch the exploit. So they
 already have to be essentially in your network. The exploits
 that Binarly has seen are typically then stealing
 configuration data, including hashed passwords from affected
 switches. Well, and that's it for today. Thanks again for
 listening. Thanks for liking. Thanks for recommending this
 podcast. And just as a reminder, in the show notes,
 you'll find a link to the Difference Maker Award, where
 I am nominated this year for one of the awards. So would
 appreciate your vote. But lots of other good people here that
 are nominated for various categories and also a link to
 future classes. The next one being mid-December in DC, our
 Defending Web Applications class. Thanks.