Podcast Detail

SANS Stormcast Monday April 14th: Langlow AI Attacks; Fortinet Attack Cleanup; MSFT Inetpub;

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

Podcast Logo
Langlow AI Attacks; Fortinet Attack Cleanup; MSFT Inetpub;
00:00

Exploit Attempts for Recent Langflow AI Vulnerability (CVE-2025-3248)
After spotting individaul attempts to exploit the recent Langflow vulnerability late last weeks, we now see more systematic internet wide scans attempting to verify the vulnerability.
https://isc.sans.edu/forums/diary/Exploit+Attempts+for+Recent+Langflow+AI+Vulnerability+CVE20253248/31850/

Fortinet Analysis of Threat Actor Activity
Fortinet oberved recent vulnerablities in its devices being used to add a symlink to ease future compromise. The symlink is not removed by prior patches, and Fortinet released additional updates to detect and remove this attack artifact.
https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity

MSFT Inetpub
Microsoft clarrified that its April patches created the inetpub directory on purpose. Users should not remove it.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21204#exploitability

SANSFIRE
https://isc.sans.edu/j/sansfire

Podcast Transcript

 Hello and welcome to the Monday, April 14th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I am recording from
 Orlando, Florida. Well, I think on Friday I briefly
 mentioned a vulnerability in Langflow where we saw at the
 time a single exploit attempt. Since then, the number of
 exploit attempts has skyrocketed. I think we have
 about a thousand now that we have captured some of them
 with their payload. All of these requests come from Tor
 endpoints as far as I've been able to tell. There may be a
 couple that I missed, but that sort of indicates that it's a
 little bit different botnet. If it is a botnet at all
 that's not doing the scanning, more likely sort of a single
 source that just obfuscates itself behind Tor. The payload
 that we have seen so far exclusively, and we don't
 capture payloads for all requests, is a simple check
 for Etsy password. It's just a cat Etsy password. That's the
 command they are executing, likely just to check if a
 particular system is vulnerable to this particular
 issue. Now, a little bit of background here. This
 vulnerability in Langflow was originally discovered by
 Horizon 3. Horizon 3, late last week, did publish a blog
 post with details including a proof of concept exploit. The
 exploit, once you see it, is pretty straightforward. The
 vulnerability has been patched about two weeks ago, like end
 of March, by Langflow. However, they never quite
 acknowledged it as a vulnerability. The root cause
 is a particular API endpoint that's essentially not
 authenticated and that then allows for this remote code
 execution, where you essentially inject arbitrary
 Python code that's executed by Langflow. Langflow itself is a
 tool that's been used by Genetic AI, meaning that it's
 used to essentially orchestrate different AI tools
 and then also tools that execute on what the AI
 outputs. So with that, if you are able to compromise
 Langflow, well, you actually are able to compromise these
 workflows likely as well. Now, Langflow can be used in
 different ways. You can use their cloud instance and, of
 course, you should be okay at this point or you can run it
 on-premise. They offer a couple of different varieties
 here, how you can run it yourself even on your own
 laptop desktop. Definitely update. And like I said, the
 real problem here, in my opinion, is that this
 vulnerability wasn't properly stated by Langflow. It was
 really Horizon 3 that actually even submitted the patch after
 it was sort of ignored by Langflow. They did apply the
 patch, but never acknowledged the vulnerability, never
 issued a CVE. Horizon 3 then got a CVE for it. And yes, the
 diary, of course, will list the CVE and links to some of
 the other materials like the patch and the blog post by
 Horizon 3. And Fortinet released an advisory, this
 time not about a new vulnerability. However,
 Fortinet did observe a threat actor taking advantage of an
 older vulnerability in their devices to deploy a simlink.
 The reason for the simlink was that this particular change
 then allowed the attacker to have read-only access to the
 device. So this was not exactly a backdoor, but
 definitely a good part of then maintaining persistent access
 to the device. Fortinet now, in response to this, did
 release another update that will detect this particular
 simlink, remove it, and also implement some countermeasures
 against simlinks like this. This is an update that you
 probably should apply, but remember, this is not a new
 vulnerability. This only really matters for you if your
 system was compromised using the old vulnerability. And
 just patching the old vulnerability using the
 existing update, well, does not, of course, get rid of
 this simlink. Let me have another update from Microsoft
 regarding last week's Patch Tuesday. Remember, we had this
 one patch that created an empty inetpub directory. This
 directory is typically used by IIS, and as it turns out, this
 was intentional. Microsoft does not want you to delete
 that directory. They're saying it's an additional protection
 against this particular vulnerability they tried to
 address with that overall patch, likely to prevent some
 simlinks or so being created here as part of that inetpub
 directory or instead of it. Now, we also had a couple of
 users reach out that told us, well, you know, I have this
 inetpub directory, but it's not empty. There are files in
 there, usually some older files. If you ever installed
 IIS or a related component, yes, it will have created this
 directory. It typically will have put some files in these
 directories. You'll see some install logs, configuration
 backups, and the like, and they're not deleted when
 you're removing IIS because, strictly speaking, they're not
 part of the software. There are additional files that you
 may also have added in some cases, like your webpage and
 the HTML files and the like, that are stored in that
 directory, and that's why Microsoft doesn't touch that
 directory even if you're uninstalling IIS. So, in
 short, leave the directory in place. If you already removed
 it, well, maybe put it back. Probably not a huge deal
 either way. Well, and that's it for today. Again, I'm in
 Orlando here at our Spring Sans event. And, actually, I
 forgot to pack my stickers, but I will have them with me
 tomorrow. So, if you see me tomorrow, I'll hand you a
 sticker. You'll also see occasionally, and I'll try to
 add this here, some of this video, a little QR code. It
 links to our Sans Fire event in July. Hope to see many of
 you there. And, over the next couple months, and so, of
 course, you'll occasionally see that QR code, just in case
 you wonder what happens if you scan it. I promise it's safe.
 Or just go to the Sans Fire page directly. Well, that's
 it. And, thanks for listening and watching, and talk to you
 again tomorrow. Bye.
 Bye.