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.
