SANS Internet Stormcast Feb 5th 2025: Feed Updates and Rosti; Resurrecting Dead S3 Buckets; Let's Encrypt Changes; Edge Device Security

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

previous

next

Feed Updates and Rosti; Resurrecting Dead S3 Buckets; Let's Encrypt Changes; Edge Device Security

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 Hello and welcome to the Wednesday, February 5th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I am recording from
 Jacksonville, Florida. Today I updated some of the
 documentation around the website. There are a good
 number of data feeds that we either create in-house or that
 we pull from other public sources. And these data feeds
 are often mentioned, for example, when you're looking
 up an IP address and one of the IP addresses you're
 looking up shows up in one of these data feeds. It will be
 listed in the IP info page. But we never really documented
 well what these shortcuts, these acronyms we're using
 actually mean. So this has been fixed now with a couple
 of additional links throughout the pages that will probably
 be expanded as I find more opportunities to do so. And
 the diary that I wrote today does explain a little bit sort
 of what we are doing here. Again, our API is free to use
 if you would like to download any of these thread feeds.
 Just understand that they're not to be supposed to be used
 as a block list. I actually prefer to call them data feeds
 instead of thread feeds. I messed it up sometimes myself
 a little bit. The reason I call them data feeds is that,
 you know, for example, we have feeds of public NTP servers,
 which are not malicious. But sometimes it's nice to know
 that an IP address that you're investigating is associated
 with the public NTP server, because that could explain
 some of the traffic that you are seeing. You also have like
 top level domain servers that you probably definitely don't
 want to block, but they sometimes do show up in some
 block lists that are sampled somewhat carelessly, because,
 well, they're often used for DNS lookups, sometimes also by
 malware. One particular feed that I actually added today, I
 would like to point out, and that's R¨o;sti, short for
 Repackaged &Umlo;pen Source Threat Intelligence. This particular
 feed is actually compiled by parsing a large number of
 blogs and news articles and the like for indicators of
 compromise. At this point, we are focusing on the IP address
 and how we are representing the data. But we'll need the
 feed and source, for example, if you see an IP address in
 your logs, and now you try to figure out, hey, has someone
 already written something about this IP address, and
 then this lookup can be quite helpful. So any feedback is,
 as always, appreciated. And as I point out in the diary as
 well, if anybody has a great idea how to represent the data
 better on the IP info page, let me know. It has gotten
 sort of messy because, well, we have sort of keep, we keep
 adding stuff to it, but I think it sort of needs
 probably a little bit of reorganization. Well, and
 watchTowr is added again, this time not with
 vulnerability per se, but really with sort of, you know,
 insecure behavior, maybe sloppy behavior on behalf of
 some organizations. The problem is that you may have
 created a web application. This web application is
 including data from an S3 bucket. So there may be some
 JavaScript, HTML images, whatever that is stored on an
 S3 bucket, and your web application is pulling in that
 data. The problem now is if that particular S3 bucket ever
 gets abandoned. So you forget about the web application, you
 no longer pay AWS for that particular S3 bucket, it's
 getting destroyed. Well, someone now is able to
 actually recreate that S3 bucket. And with that inject
 data into this existing website of yours. Now chances
 are that this website is not really used much anymore, but
 it may still have a valid TLS certificate for your
 organization. Some users may still have it bookmarked. And
 of course, if they receive a link to that website, they may
 believe it's associated with your organization. And well,
 rightfully so. So they may be more tempted to click on it,
 opening them up for injection attacks that are caused by new
 content being stored on that resurrected S3 bucket.
 Interesting attack, and definitely sort of one of
 these sort of housekeeping items where if you use an S3
 bucket in your application, you probably have to note
 somewhere that if that S3 bucket ever gets deleted,
 removed, well, you probably need to alter that application
 or maybe also discontinue the use of that application, which
 often may be the right solution here. And in a blog
 post, Let's Encrypt noted that they will no longer send out
 emails if your certificate is about to expire. The reason
 behind that is, well, first of all, cost. Secondly, that they
 found that these emails aren't really all that valuable. So
 better come up with your own notification system in case
 certificate is about to expire. And I think you should
 have that anyway. I actually personally didn't find the
 Let's Encrypt emails to be too useful, because often they
 arrive for certificates I may have created like for a quick
 experiment for development site or such that I only
 temporarily used. So you basically start ignoring those
 emails. Anyway, so set up your own monitoring system, sign up
 for a service that does this for you. They recommend
 RedSift, which is based around Hardenice and they offer a
 reasonable, generous free service for what that is,
 let's say you have 250 certificates. So up to 250
 certificates, they'll monitor for you for free if you still
 would like to receive email alerts. And CISA, in
 coordination with a couple of other international government
 security agencies, has published some guidance for
 the security of edge devices. I mentioned them a couple
 times a week, probably various routers, firewalls, VPN
 concentrators that are often vulnerable to fairly
 straightforward, easy to exploit vulnerabilities. The
 guidance that they published is pretty much common sense. I
 don't think anybody listening to this podcast will be
 surprised by any of the advice being given here, but it makes
 a good checklist to make sure that you don't miss anything.
 And of course, also good to justify to management and the
 like, why you're spending your time, for example, trying to
 come up with out of band ways to manage these appliances
 instead of just connecting to the web admin interface via
 the internet. Well, and this is it for today. So thanks for
 listening and talk to you again tomorrow. Bye.