SANS Stormcast Tuesday, October 28th, 2025: Bytes over DNS; Unifi Access Vuln; OpenAI Atlas Prompt Injection - SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)

Summary4 min read

Episode Overview

Title: SANS Stormcast Tuesday, October 28, 2025: Bytes over DNS; Unifi Access Vuln; OpenAI Atlas Prompt Injection
Host: Johannes B. Ullrich
Theme:
A fast-paced daily rundown of noteworthy cybersecurity events. Today's episode dives into the practicality of DNS covert channels and allowed hostname characters, a critical vulnerability in Unifi Access control systems, and the prompt injection risks introduced by OpenAI's Atlas browser. Each segment not only covers recent findings but contextualizes their impact for defenders and practitioners.

Key Discussion Points & Insights

1. Which Bytes Can Be Sent Over DNS Hostnames? (Bytes over DNS)

[00:16–02:12]

Didier Ran an Experiment:
Explored which characters can be practically transmitted as a hostname in DNS queries.
RFC Allowances vs Reality:
- RFCs technically allow upper/lowercase letters, numbers, dash (-), underscore (_), and dots (.) for label separation.
- Real-world constraints stem from both OS resolver libraries and the chosen recursive DNS resolver.
Operating System Differences:
- Windows Resolver Library: “Quite restrictive. It only allows the standard characters.” (Johannes, 00:47)
- Linux (Ubuntu as example): “Less picky and does allow pretty much any character in the standard ASCII set. So any 7 bit character from 0 through 7F.” (Johannes, 00:56)
When Using Custom Resolvers (e.g., Python Libraries):
- The only constraint becomes the resolver itself (Cloudflare or Google).
- Both allow nearly any character.
Special Note on Google:
- Applies an XOR scheme to mangle the case of characters, making data essentially case-insensitive as an anti-spoofing measure.
Cloudflare Preference:
- “Try use Cloudflare as your recursive resolver because they are really just transmitting whatever you send.” (Johannes, 01:36)
TXT Records Bypass Restrictions:
- For text records, any character representation is possible.
Practical Guidance:
- Know your limits—especially if using DNS for covert channels or exfiltration.

2. Critical Unifi Access Vulnerability

[02:13–03:21]

Unifi Access Product:
- Controls physical access, like door locks.
Vulnerability Details:
- Identified by Catchify Security; critical (CVSS 10.0 score).
- “Would allow an attacker without authentication to gain full access to the API of Unifi Access.” (Johannes, 02:34)
Potential Impact:
- Bypass of physical security controls.
- Full controller compromise and likely arbitrary code execution.
Current Knowledge:
- No exploitation details released yet.
- No known exploits in the wild as of recording, but “I imagine that an exploit is probably available within a couple days.” (Johannes, 03:01)
Host’s Security Hygiene Reminder:
- “Make sure that you're blocking access to these type of APIs.” (Johannes, 02:54)
Speculation:
- Could be due to a hardcoded password or an oversight in header checking.

3. AI in Browsers and Prompt Injection: OpenAI Atlas Case

[03:22–04:24]

Broader Context:
Web browsers are already highly exposed—adding AI, as with OpenAI’s Atlas Browser, introduces further risk.
Prompt Injection Issue:
- “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.” (Johannes, 03:39)
Demonstration:
- Neuraltrust showed how URLs can include instructions (prompt injection) exploiting the AI assistant in the browser.
- Other researchers have demonstrated similar flaws.
Inherent AI Security Problem:
- Text from potentially malicious web content (e.g., a crafted URL) can trigger unsafe behavior in the AI, including data exfiltration.
Practical Guidance:
- “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 jailbreaks and prompt injections for these browsers.” (Johannes, 04:16)

Notable Quotes & Memorable Moments

On DNS Allowed Characters:
“The Windows resolver library actually is quite restrictive. It only allows the standard characters. Linux on the other hand... is less picky and does allow pretty much any character in the standard ASCII set.” (Johannes, 00:47 & 00:56)
On DNS Covert Channels:
“If you're using DNS covert channels, try use Cloudflare as your recursive resolver because they are really just transmitting whatever you send.” (Johannes, 01:36)
On Unifi Vulnerability:
“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.” (Johannes, 02:34)
On AI Browser Risks:
“What better than add AI to the attack surface? ...they did not separate control plane and data plane, they mix it all together and URLs may now include instructions...” (Johannes, 03:30-03:39)
AI Browser Caution:
“Don't use these browsers for now, at least not on a production system.” (Johannes, 04:16)

Key Timestamps

00:16–02:12 — Bytes over DNS: Allowed hostname characters across OSes and resolvers
02:13–03:21 — Unifi Access critical vulnerability & potential security implications
03:22–04:24 — OpenAI Atlas, AI in browsers, and prompt injection risks

This episode illustrates that technical standards and real-world security constraints often diverge, and that both old (DNS) and new (AI) technologies bring exfiltration and exploitation risks when not well-contained. Practitioners are advised to heed evolving vulnerabilities—especially with high impact devices and novel AI-powered endpoints.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Tuesday, October 28, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ulrich, today recording from Jacksonville, Florida, and this episode is brought to you by the Sans Edu Bachelor's Degree program in Applied Cyber Security. Today 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? What? 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, NDA 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 sen 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 use Cloudflare as your recursive resolver because they are really just transmitting whatever you send. And again, this is when you're using host names. Of course, when using text records and such, you're not constrained by any hostname rules and you would be able to use any character that you can represent as part of a text record. 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 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 days and that will 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 a 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 neuraltrust. 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 jailbreaks and prompt injections for these browsers. Well, and 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.