SANS Stormcast Tuesday, April 8th:

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

previous

next

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 Tuesday, April 8th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Quick update from Didier today to
 answer a question actually that came up in class and
 that's regarding Didier's tool XOR Search. If you're not
 familiar with XOR Search, it's one of Didier's famous Python
 scripts and what it does is it brute forces various XOR
 parameters to figure out if certain strings are present in
 a file. So it assumes that the file is XORed with one
 particular byte value and then tries all 255 and checks if
 any of the results contains a particular string. That of
 course can easily then be used to figure out what is the
 right key here in order to decode the file. The problem
 that came up in class is, well, can you also search for
 a regular expression? And the quick answer is no. But Didier
 has a trick for you here, how you can still achieve regular
 expression searches. The trick is that you're just dumping
 all the strings. There is a mode in XOR Search that will
 basically apply all the XOR values and then extract for
 each XOR values any possible printable string, similar to
 the strings command. And then you can take that list of
 strings and apply your regular expression with a regular
 grab. Now, I hear Didier is working on a version of XOR
 Search that will officially support regular expressions.
 But that's, as far as I know, not quite there yet. But keep
 looking for it. Maybe it'll be out by the time you listen to
 this podcast, given how fast Didier sometimes updates these
 tools. And as we use more and more AI systems in order to
 automate processes, there is a new tool, the Model Context
 Protocol, that has gained quite a bit of prominence.
 It's essentially a standard way how you can define
 interfaces between your AI model and tools like, for
 example, a code editor. Now, when I first saw that, all
 kinds of alarm bells went off, considering that I'm now
 allowing essentially the AI model to completely control my
 code editor. But I guess, you know, for AI people, that's
 just normal. Well, it turns out there are indeed some
 interesting vulnerabilities here. Invariant Labs has a
 blog post where they summarize some of these issues. None of
 them is really surprising to me. It's just sort of a
 standard dependency supply chain style issues that we had
 for years with all kinds of libraries and package managers
 and such. For example, imagine that the description of the
 tool may not be complete. There may be additional parts
 of the tool that are not made obvious to the user. Or after
 you approve a particular tool, well, the tool may change and
 then do something malicious. So don't really think that
 anybody is sort of too surprised by these
 vulnerabilities. Not even sure if I even call them
 vulnerabilities. But just things that more or less come
 with the territory. If you hand over control of tools
 like code editors or your desktop, for that matter, to
 an AI tool that you don't completely understand and
 haven't completely reviewed how it works. In particular,
 the sort of incomplete description and such. Yes, you
 can read the full description, but it's just not really made
 obvious to the user. And Google has added an
 interesting privacy improvement to Google Chrome,
 fixing an issue that has been around for, I think they're
 saying 20 years. Sounds about right. It's around the fact
 that links that you visited are colored differently in
 your browser. And that coloring can be adjusted via a
 cascading style sheet. Where the privacy issue comes in is
 that the site then can also check whether or not a
 particular link has this visited color applied or not.
 Now, the reason this may not be such a huge privacy issue
 is that on the site itself, if you're clicking on a link,
 well, the site knows that you clicked on the link. But by
 inserting links that you may have clicked on on other
 sites, well, this particular malicious site may still be
 able to figure out part of your browsing history. So what
 Google Chrome is doing now is it only applies the visited
 color if you clicked on the link while you were on the
 site where you're seeing the link. So a little bit sort of
 a partitioning here, a same origin idea. So if I'm going,
 let's say, to Yahoo, I click on a link and then I later go
 to Google. Google displays a link to the same URL. It's not
 going to be displayed as visited. It's only going to be
 displayed as visited if you clicked on the link while you
 were on Google. So each site, each origin sort of gets its
 own history list, which allows the browser to distinguish
 where you clicked on the link. Interesting improvement. Don't
 think it really affects usability that much. Of
 course, you may see now on a site a link with the non
 -visited color, even though you earlier visited it. Don't
 really think that's a big deal. Usually it really sort
 of applies on the same site. You want to see if you visited
 the particular subpages or so on that site. Well, and that's
 it for today. Thanks for listening. Thanks for liking
 or recommending this podcast. And well, remember, it's Patch
 Tuesday. Well, and about Patch Tuesday, talk to you again
 tomorrow. Bye.