Hello and welcome to the Wednesday, August 6, 2025
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
Penetration Testing and Ethical Hacking. Last week
when we talked about SharePoint, one of the things
that kept coming up was the VIEWSTATE. The VIEWSTATE is
how .NET applications kind of maintain state. In forms,
you'll typically see that VIEWSTATE being included as a
blob. Now, whenever we send something to the user like
this, you of course have to protect its integrity. And
that's part of where the Machinekey comes in, where
the data is digitally signed or protected with Mac. Now,
the other option is that you can also encrypt the data if,
for example, you have some sensitive data that's included
as part of that VIEWSTATE. But the real problem with
SharePoint was that the exploit did allow access to
the Machinekeys that are used to basically create the
integrity protection. Without that protection, an attacker
-speak user is able to create malicious VIEWSTATEs that,
when deserialized on the server, can lead to arbitrary
code execution. And that's exactly what Boyan is walking
you through here, how the VIEWSTATE is being used and how it
can be app used. The VIEWSTATE is either stored in your
web.config file or in the registry. However, if you have
multiple servers that, for example, share a load, then
you must store it in the web .config file because all the
servers must use the same VIEWSTATE. So they're essentially
compatible with each other. If one of them creates a view
state, the other server is able to read it. But what this
means is if an attacker is able to read web.config, well,
they then have also remote code execution on the server.
Boyan is going over a couple of locations where the view
state may be found. And with that also, you know, scripts
and such that can be used to still take advantage of it.
YSO-serial.net is sort of the tool of choice to create
malicious objects for embedding in the VIEWSTATE
that can then be used to actually launch any kind of
attack. And as Boyan here demonstrates with a little
sample application, it can easily then lead once the view
state is generated to remote code execution. Like in this
particular case to a remote shell. It's a very detailed
diary. If you're particularly into penetration testing,
let's just try to better understand from a defensive
point as well what's up with the VIEWSTATE, what's up with
these Machinekeys we talked so much about last week. This
is really sort of a very thorough and detailed
walkthrough of what this really all means. And I keep
saying there are two kinds of AI and LLM companies. Those
that observe intellectual properties and those that will
fail. Latest example here, Perplexity. Perplexity
apparently is modifying its user agents to bypass any
protections that websites put in place to specifically do
not allow Perplexity to spider their content for machine
learning. Cloudflare documented this here in their
blog post. Essentially, what's happening with Perplexity is
that they will initially use their public and normal user
agent that identifies them as Perplexity. It's Perplexity
user. Now, if they run into any problems, let's say that
robots.txt protects the site from not being spidered by
Perplexity user. Or you have a web application firewall.
Well, in that case, they will actually modify their user
agent and then still try to access the site. They'll also
try to connect from different IP addresses. So essentially
do whatever an attacker would do to bypass some filters like
web application firewalls. Robot.txt is specifically
designed to be used by well -behaved and ethical search
engines that are spidering the site. If you're looking, for
example, at the internetstormcentersrobot.txt
file, we exclude a couple of pages that are just too
dynamic and don't really provide much value for a
search engine. On the other hand, would cost us some
effort to actually produce those pages. And that's
exactly what's happening now with Perplexity where their
aggressive spidering could actually cause damage like
denial of service attacks. We have seen things like this
before, not just from Perplexity, but I think it was
last year we saw and we still see this actually occasionally
where OpenAI is hitting our honeypots with basically
attack URLs. WordPress attacks and the like that are coming
from OpenAI's network from systems that identify
themselves as basically part of their cluster of systems
that is spidering the web for content to be included in
learning. So I guess AI now learns from our honeypots.
Well, a couple of days ago, I reported about findings from
Arctic Wolf that they see compromises of SonicWolf
firewalls that may be taking advantage of so far unknown
vulnerability. Well, we now have a little bit confirmation
that at least something strange is going on here.
Google Mandiant Huntress saw similar attacks and there is
now an official statement from SonicWolf about this, as they
call it, ongoing investigation. Still no
confirmation that there is an actual survey. So it's still
possible that these are backdoors or something left
behind by prior exploits. But they did come up here with
some recommended mitigation steps. And number one here is
to disable the SL VPN services. Of course, that may
not be practical as they also state here. If that's why you
have this particular device, maybe you can restrict access
to the SL VPN component to trusted source IP addresses.
So that may be sort of the second best thing to do. The
other options they have here is just the basic best
practice, things like multi -factor authentication or
such. But the Arctic Wolf write-up specifically stated
that some of the compromised devices they have seen had
multi-factor authentication enabled. So that's not
necessarily going to keep you safe here. It's just adding an
additional barrier likely for an attacker to overcome. Well,
and that's it for today. So thanks for listening. Thanks
for subscribing and liking this podcast. Thanks for
recommending it. And as always, special thanks for
leaving any good comments in your favorite podcast
platform. Thanks and talk to you again tomorrow. Bye.
