SANS Stormcast Tuesday, October 28th, 2025: Bytes over DNS; Unifi Access Vuln; OpenAI Atlas Prompt Injection

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

previous

Bytes over DNS; Unifi Access Vuln; OpenAI Atlas Prompt Injection

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 Tuesday, October 28, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich. Today, recording from
 Jacksonville, Florida. This episode is brought to you by
 the SANS.edu Bachelor's Degree Program in Applied
 Cybersecurity. Today, Didier ran an interesting experiment
 looking into a question that often comes up when you're
 looking at DNS covert channels. Which characters can
 actually be transmitted as a host name? Now, it should be
 pretty straightforward. The RFC allows upper lowercase
 letters, numbers, the dash, the underscore, and then,
 well, a dot to separate labels. But, of course, that's
 the RFC. What's reality? Well, Didier looked here at two
 constraints. First of all, the operating system. If you're
 using the operating system's resolver library, it may
 restrict what letters you can send. And then, well, whatever
 recursive resolver you use. And Didier here looked at
 Cloudflare and Google. Well, it turns out that the Windows
 resolver library actually is quite restrictive. It only
 allows the standard characters. Linux, on the
 other hand, and Didier here picked Ubuntu as an example,
 is less picky and does allow pretty much any character in
 the standard ASCII set. So, any 7-bit character from 0
 through 7F. Once you take the resolver as the only
 constraint and basically use some Python library or
 something like this as your client resolver, well, in that
 case, things get more interesting. Now, of course,
 you can send any character. The operating system no longer
 constrains you. It's only the recursive resolver that you're
 using. In this particular case, either Google or
 Cloudflare pretty much allow any character to be sent and
 transmitted via their resolvers. The only constraint
 now is that Google implements this XOR scheme in order to
 change the upper and lower case of letters to prevent
 some spoofing attacks. And that then constrains that you,
 well, basically only can use case-insensitive data because
 Google may change the case of letters. Interesting results.
 And, well, basically, if you're using DNS cover
 channels, try to use Cloudflare as your recursive
 resolver because they are really just transmitting
 whatever you sent. And again, this is when you're using host
 names. Of course, when using text records and such, you're
 not constrained by any host name rules and you would be
 able to use any character that you can represent as part of a
 text record. And we have a critical vulnerability in the
 Unifi Access product. It was identified by Catchify
 Security. There is no detail yet available as to how the
 vulnerability would exactly be exploited, but it does have a
 perfect score of 10 and would allow an attacker without
 authentication to gain full access to the API of Unifi
 Access. So at the very least, they should then be able to
 basically bypass Unifi Access. Unifi Access is used to manage
 door locks and the like. So that's certainly one problem.
 But given the score of 10.0, it probably also means that
 further arbitrary code execution is possible on the
 controller running a Unifi Access. As I mentioned so
 often, make sure that you're blocking access to these type
 of APIs. But no exploit yet, as far as I can tell. I
 imagine that an exploit is probably available within a
 couple of days and that we'll find out that it's either a
 hard coded password or something like this or maybe
 some additional header that you need to add to the request
 in order to bypass authentication and access
 control. And the piece of software on a normal user's
 machine that probably has the largest attack surface is the
 web browser because it is being exposed to large amounts
 of external information that is often unstructured and
 really hard to process safely in many cases. So what better
 than add AI to the attack surface? That at least is what
 OpenAI did with their Atlas browser. The problem now is
 that of course, just like with any other AI tool, they did
 not separate control plane and data plane. They mix it all
 together and URLs may now include instructions for the
 browser for the OpenAI part of the browser, which then can
 lead to data leakage. Interesting demonstration here
 by Neural Trust. I've seen also others come up with
 similar blog posts for similar ideas of adding AI to
 browsers. The problem always comes down to is that text
 being returned by various websites like URLs in this
 case can be interpreted by the AI engine and then of course
 get access to files or other data that the browser has
 access to. In short, don't use these browsers for now, at
 least not on a production system. Definitely experiment
 with them and maybe you'll find some other neat new jail
 breaks and prompt injections for these browsers.
 Well, that's it for today. Thanks for listening. Thanks
 for liking. Thanks for subscribing to this podcast
 and as always talk to you again tomorrow. Bye.