Hello and welcome to the Friday, January 9th, 2026
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ulrich and today I'm recording from
Jacksonville, Florida. And this episode is brought to you
by the sans.edu Undergraduate Certificate Program in Applied
Cybersecurity. Well, one of the challenges that we are
always faced with when we're looking at all of our Honeypot
data is that, well, how do we summarize it? How do we find
patterns in the data? And of course, there are some great
tools to do this. Today, we do have a blog post by Guy who is
talking a little bit about how he's using these tools in
order to analyze Honeypot logs. The tool that Guy is
using here is Cephy or Gephi. I think that's sort of
probably how it's being pronounced. This tool allows
you to essentially visualize relationships. And what Guy
did here was look, for example, at certain IP
addresses that are all uploading the same binary or
binaries with the same file name. That, of course, is a
good indicator that these particular IP addresses are
part of a particular botnet. Like one particular attack
botnet that Guy was looking at here was a red tail. Of
course, you could also look at what IP addresses they're
pulling these binaries from and the like. So there are a
bunch of relationships like this that you can look at to
better understand the data. This doesn't just apply to
Honeypots. Of course, this also applies to any other data
like this, any other log data that you have. And you're
trying to sort of identify relationships. So building
these graphs here, the underlying library here is
called GraphViz. That's what Gephi is using in order to
sort of provide this more interactive view of the data.
And then we have an interesting potentially
critical vulnerability in zlib. zlib, well, that's
everybody's favorite compression library. And of
course, it's part of many, many commercial and open
source products. It comes with a utility untgz. Untgz does
unpack tgc files. And one of the obvious parameters here is
the file name. The file name is then being copied into a
one kilobyte buffer without ever actually checking what
the length of that file name is. So we have a very classic
simple buffer overflow here. Exploitability, of course, is
a different question. Depends on, you know, whether that
untgz utility is reachable, how the file name is being
supplied to the utility and such. So lots of dependencies
again here, which, as I mentioned yesterday, sometimes
it's difficult to sort of assign such a simple CVSS
number or such to a vulnerability like this,
because it really depends a lot on how this particular
library is being used or this utility in order to figure out
how severe this particular vulnerability is. And every
year sort of between Christmas and New Year, the Chaos
Computer Club or CCC in Germany is running their
annual conference and Congress. That is often being
used in particular for the European community to release
new vulnerabilities and also have some social and policy
discussions. Well, the standout talk this time around
dealt with GNU-PG, the PGP implementation. That's very
popular and very widely used probably the standard PGP
implementation at this point. And well, the talk did
disclose 14 different vulnerabilities. Some of them
allow you to alter messages and without actually
destroying the signature. Others are just relatively
straightforward remote code execution vulnerabilities,
where if a user decrypts a file, the file then writes
arbitrary files to the file systems and can that way being
used for code execution. Simple things like null bytes
being used as a terminator. And as a result, nothing
beyond that byte being actually included in the
signature. So a number of interesting vulnerabilities.
Patches are on the way, but I don't think they have all been
released yet. I've seen some patch notes here. I'll link in
the show notes to the page that was set up here, PGP
.fail, which also includes a video of the talk. Great talk,
by the way, if you can stand the presenter's German accent.
Well, and if you had your Cisco switches reboot last
night, you were not alone. Interesting DNS issue here.
Turns out that if you used Cloudflare DNS in order to do
DNS resolution on your Cisco switches and only certain
models were affected, you ran into an issue where Cloudflare
altered the order of CNAME and non-CNAME records in the
answer. That apparently confused these Cisco switches
or their DNS client implementation, which then led
to a DNS error, which in turn led to a failure on the device
and caused it to reboot, which of course then led to some
downtime as the system rebooted. This should have
been fixed by now by Cloudflare. But ultimately,
this is kind of a bug in Cisco's DNS client
implementation. Not sure if there is some kind of patch
upcoming. You may want to take a look at it. It's possible
that other DNS providers would do similar things, but like
the order of these DNS records, the order is not
specified. It's sort of more just customary that you first
have the actual record and the CNAME. But in the meantime,
either disable the DNS lockup if you aren't sure if your DNS
provider plays games like this, or make sure that your
DNS provider complies with the standard that Cisco expects.
Well, and that's it for today and for this week, the first
week of the new year. If you wonder about my teaching
schedule, I'm actually taking a little bit of time off from
teaching the first couple of months here, but I will be
teaching again in April. First of all, in Orlando at our big
conference, I'll be teaching our Defending Web Application
class there. And then secondly, in Amsterdam, a
couple of weeks later, I'll be teaching the Intrusion Texting
class, SEC 503. So if you're interested, links to the
classes can be found at the bottom of the show notes.
Well, and that's it for today. Thanks for listening and talk
to you again on Monday. Bye.
