Handler on Duty: Xavier Mertens
Threat Level: green
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
My Next Class
Application Security: Securing Web Apps, APIs, and Microservices | San Diego | May 5th - May 10th 2025 |
Network Monitoring and Threat Detection In-Depth | Baltimore | Jun 2nd - Jun 7th 2025 |
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
Application Security: Securing Web Apps, APIs, and Microservices | San Diego | May 5th - May 10th 2025 |
Network Monitoring and Threat Detection In-Depth | Baltimore | Jun 2nd - Jun 7th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Jul 14th - Jul 19th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 22nd - Sep 27th 2025 |
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.