Podcast Detail

SANS Stormcast Monday, August 10th, 2026: Linux Shell Forensics; Criticial MacOS Patch; More N-Central Hotfixes; Exploited Metabase Vuln;

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

previous
Podcast Logo
Linux Shell Forensics; Criticial MacOS Patch; More N-Central Hotfixes; Exploited Metabase Vuln;
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Monday August 10th, 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 cyber
 defense operations. In diaries we got Xavier talking about
 Linux, forensics, and here about actually new to me tool
 Atween. I think that's how I would pronounce it. The goal
 of the tool is to create a better bash history. So
 typically we do have some form of history file often called
 .bash_history, but the exact format, how
 stuff is being logged and what the file is called depends on
 various configuration options. And of course,
 the file is
 not always correct. It doesn't really show you how long a
 command ran, for example. And also, well, the size is
 usually rather limited in default configurations. And it
 also limits what information is being logged in particular
 when a user sort of changes users with sudo and the like.
 So Atween is attempting to fix some of these issues. The
 basic idea is that the flat bash history file is replaced
 with a SQLite database. SQLite database, of course, being not
 really that much more expensive, kind of not to run
 to operate than a flat text file, but giving you a more
 searchable structure to the data. And with that, a few
 more data items are being logged, like for example,
 start and end time or duration of the particular command when
 it was run. Also, which user ran it, the current working
 directory. And it's also configurable in the sense that
 for example, you may exempt certain commands from being
 logged, like for example, commands that are being used
 to change passwords. And that's rather flexible, you
 could for example, not log anything that contains the
 word password. If you're familiar with MySQL, it does
 something similar with its history, which honestly,
 something gets a bit annoying when I'm searching like for SH
 passwords and such in our database. But yes, neat tool
 that you can install on your Linux systems. Of course, you
 have to install this ahead of the compromise to get the most
 out of it. An attacker could be able, likely, to modify,
 just like the bash history. In particular, if they have a
 system or some kind of root access to the system. Now,
 there's another option have sometimes been proposed to use
 for bash history. You can also send all commands to syslog.
 This can be a reasonable idea in particular, if you want to
 log the data off the host and keep them out of the reach of
 the attacker. But be aware that syslog usually is not
 encrypted. So anything would be sent in the clear unless
 you use some of the newer syslog versions that actually
 can be run over TLS. And a small note also is diary. You
 may see there are 29 comments to it. Someone made it past
 our captcha for the login. I'll take a closer look at
 that later and see what exactly happened there. But
 yes, that's why our comments first need to go through
 manual approval. And they didn't pass that step. And it
 looks like I missed an important Apple update for
 Friday's podcast. On Thursday, Apple published new versions
 of macOS. That affects the latest version of macOS 26 as
 well as the two prior editions of macOS. This version does
 fix a single vulnerability in screen sharing. But this
 vulnerability sounds rather interesting, meaning critical
 in that it does allow an attacker to access screen
 sharing without authentication. Now, as far as
 I know, screen sharing is not enabled by default in macOS.
 So that mitigates it somewhat, but it is frequently enabled
 for remote access to macOS machines. So wouldn't be that
 unusual. This particular patch or this particular
 vulnerability, I should say, was discovered by Alfredo
 Pesoli and Binario Atlas. There is also on Twitter
 someone who reverse engineered the patch and was able to
 create an exploit for it. They promised a write-up for today,
 for Sunday. Haven't seen it yet as I'm recording this
 podcast, but I would suggest that this vulnerability is not
 terribly difficult to exploit at this point. And the
 targeted exploits are probably already being used. So
 definitely make sure that if you have screen sharing
 enabled, you must apply this patch today. Well, I think it
 was just last week that I talked about issues about
 enable where they patched a problem, but didn't patch it
 correctly. Then they released a hotfix. Well, they now
 released a second hotfix on Thursday. This second hotfix
 should now solve the problems for now, but it's kind of
 telling when they're stating here in introduction to their
 hotfix advisory that this is not a duplicate of our
 previous communication. Hotfix 2 is required, even if you
 applied the earlier hotfix. So that's a quote from their
 advisory. Definitely, if you're running enable in
 particular and central, that's the product that's affected
 here by these latest issues. Please make sure you do apply
 these hotfixes. You do apply hotfix too, because the
 vulnerability is already actively being exploited. The
 advisory also lists a couple indicators of compromise that
 may be helpful in case you are affected by any of the exploit
 activity. And talking about already exploited
 vulnerability, if you're running a database, please
 apply the latest updates. There is a SQL injection
 vulnerability that allows attackers essentially
 arbitrary access to your database. Apparently, the API
 slash session slash reset underscore password endpoint
 is affected here. So if this endpoint was exposed in your
 system, and given that exploitation was ongoing,
 please take a look at the GitHub issue regarding this
 particular vulnerability. I'll link to it in the show notes,
 because it has some instant response tips here, how to
 make sure that no like invalid sessions or such are still
 connected to your database. Well, that's it for today.
 Just as a reminder, I have classes coming up in September
 in Vegas. That's the Web Application Security class. And
 then in October in Amsterdam, again, the Intrusion Detection
 class. If you're interested, as usual, in the show notes,
 you'll find a link to upcoming classes that I'll be teaching.
 Thanks. And that's it for today. And talk to you again
 tomorrow. Bye.