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.
