SANS Stormcast Wednesday, August 6th, 2025: Machinekeys and VIEWSTATEs; Perplexity Unethical Learning; SonicWall Updates

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

previous

Machinekeys and VIEWSTATEs; Perplexity Unethical Learning; SonicWall Updates

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 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.