Podcast Detail

SANS Stormcast Tuesday, May 6th: Mirai Exploiting Samsung magicInfo 9; Kali Signing Key Lost;

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

Podcast Logo
Mirai Exploiting Samsung magicInfo 9; Kali Signing Key Lost;
00:00

Mirai Now Exploits Samsung MagicINFO CMS CVE-2024-7399
The Mirai botnet added a new vulnerability to its arsenal. This vulnerability, a file upload and remote code execution vulnerability in Samsung’s MagicInfo 9 CMS, was patched last August but attracted new attention last week after being mostly ignored so far.
https://isc.sans.edu/diary/Mirai+Now+Exploits+Samsung+MagicINFO+CMS+CVE20247399/31920

New Kali Linux Signing Key
The Kali Linux maintainers lost access to the secret key used to sign packages. Users must install a new key that will be used going forward.
https://www.kali.org/blog/new-kali-archive-signing-key/

The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster
Many out-of-the-box Helm charts for Kubernetes applications deploy vulnerable configurations with exposed ports and no authentication
https://techcommunity.microsoft.com/blog/microsoftdefendercloudblog/the-risk-of-default-configuration-how-out-of-the-box-helm-charts-can-breach-your/4409560

Podcast Transcript

 Hello and welcome to the Tuesday, May 6, 2025 edition
 of the SANS and Night Storm Center's Stormcast. My name is
 Johannes Ulrich and today I am recording from San Diego,
 California. In diaries today, well, I saw some initial
 attacks against Samsung's Magic Info CMS. This is a
 somewhat defunct, not quite a really sort of maintained
 piece of software anymore. But last August Samsung did
 release a patch for it, fixing an arbitrary file upload
 vulnerability that then can lead to remote code execution.
 This particular vulnerability was not really noticed much,
 part probably because of the very sort of short sort of one
 -liner that Samsung published about it. Last week,
 Cybersecurity Info did cite some research reports. Sadly,
 I didn't see a link to the actual research report or any
 more attribution to it. But this particular article about
 the research report did quote it, noting a particular URL
 that's being used to upload these files and then also some
 additional details about the vulnerability. Well, a couple
 days later, we started seeing some actual exploit attempts.
 These exploit attempts appear to be coming from what's sort
 of often described still as Mirai, basically a botnet that
 does exploit various vulnerabilities, often of
 course IoT style vulnerabilities. This I would
 definitely not necessarily sort of call an IoT style
 vulnerability. It is more a server component used to
 basically manage content. That's what CMS content
 management servers are doing. Not really sure how successful
 these exploit are, but they sort of follow very much the
 standard pattern where the initial upload uses a number
 of different ways like TFTP, WGET, CURL, FTP and such to
 download the second stage. The second stage is then the
 typical shell script that lists the next download that
 attempts to download the actual Mirai bot for various
 architectures. Actually, very extensive list in this
 particular version. And then, well, they basically just
 trial and run and whatever version they get to run. Well,
 then try to find additional victims. It's very well
 recognized by VirusTotal, so definitely not a new threat.
 I'm obviously a bit careful characterizing stuff like
 this, Cilis Mirai. Yes, they probably still share some of
 the original Mirai code, but that has been worked on,
 changed, updated so many times now. So many vulnerabilities
 have been added by various actors to be exploited by
 these botnets. But ultimately, they still don't really do
 anything different than the original Mirai bot. Anyway, if
 you're running any of these Samsung match again for nine
 CMSs. So make sure they're patched. Like I said, the
 patch was released last August, but not really
 advertised much. So it may be easy to miss this particular
 patch. And if you're a user of Kali Linux, be aware that Kali
 Linux lost access to their original signing key. What
 this means is that they had to create a new signing key for
 any packages used by Kali Linux. And as a result, well,
 you may get some signature verification failures if
 you're trying to update Kali Linux. They don't specify how
 or why the key was lost. It could be as easy as them,
 well, basically losing a hard drive. The key was stored on
 not having a proper backup. They specifically state that
 the key was not compromised. So any packages that you have
 from before the key was lost that are signed by this
 original key should still be considered trusted. But the
 problem is since basically the key was lost before they were
 able to push a new replacement key, you now have to do so
 manually and manually mark that key as trusted, that new
 key in order to validate any future packages. This is
 mostly a problem if you're automatically updating your
 system. One possible solution that they recommend is just to
 rebuild the system from scratch. If you're downloading
 Kali Linux now from the official website, well, you'll
 get the new keys already preinstalled on the image. Not
 a great thing to happen. But well, stuff happens. And good
 reminder to always keep multiple backups and if
 possible, also just a simple printed copy of any key keys
 for critical issues like this. And researchers at Microsoft
 published a blog warning of default configurations
 commonly deployed in popular Kubernetes Helm charts. Helm
 is a packet manager for Kubernetes. And Helm charts
 are essentially scripts that you're using to deploy
 applications. So all the necessary packages are being
 installed and the application is completely installed and
 configured in your Kubernetes cluster. But as so often, many
 of the default settings in these Helm charts aren't
 necessarily appropriate. In particular, they're exposing
 ports. They're not necessarily configuring the system
 securely, including often missing passwords. If you are
 using Helm charts, definitely read the article, and then
 read the article. And you'll be aware of some of these
 issues. So you can then fix up the configurations and make
 sure that they are secure. Well, that's it for today in
 San Diego on Tuesday evening. I'll actually give a talk
 about some of the developer supply chain risks. If you
 happen to be here at the event, welcome to attend. If
 you just happen to be in the area, send me a message if
 you're interested. I may be able to get a couple of people
 in here. So that's it for today and talk to you again
 tomorrow. Bye.