It's not a new feature... it's the one I brought to your attention several posts ago.
DNS rebinding attacks
- Thread starter Parkinsond
- Start date
Please provide comments and solutions that are helpful to the author of this topic.
It's not a new feature... it's the one I brought to your attention several posts ago.
@Parkinsond Thanks for one more thing, I had ControlD as a backup, but it seems that is sucked in the beginning and it still sucks now. I switched backup to AdguardDNS. 
May I ask why not use NextDNS?@Parkinsond Thanks for one more thing, I had ControlD as a backup, but it seems that is sucked in the beginning and it still sucks now. I switched backup to AdguardDNS.
You are always welcome@Parkinsond Thanks for one more thing, I had ControlD as a backup, but it seems that is sucked in the beginning and it still sucks now. I switched backup to AdguardDNS.
NextDNS is great; have been using for a while.
But Adguard DNS has two advantages:
1. I can include Hagezi TIF list (not available in NextDNS, although it has its own TIF)
2. On testing for DNS rebinding vulnerablity using ControlD tool, Adguard DNS with Hagezi DNS rebind protection list included passed, while NextDNS with DNS rebinding protection option enabled did not.
I meant as a backup, sometimes NextDNS fails for hours, but I always had a trouble with ControlD, I blamed my tweaks, but clearly ControlD was to blame, it fails basics.
Last edited:
That's weird. I've been using ND for years and I don't remember it failed before.
It happens once or twice a year, maybe during a maintenance, but still I would expect it to switch to another server. Once it lasted the whole day (PC+phone), unbearable.
Yes it is unacceptable.It happens once or twice a year, maybe during a maintenance, but still I would expect it to switch to another server. Once it lasted the whole day (PC+phone), unbearable.
Now BD has added a signature for the fake Chrome Updater
Trojan.genericS.11373
God BD is so stupid. To test that BD has added a signature for the fake Chrome Updater, I unzipped the file and BD instantly detected the infected file and i receieved "disinfection in progress", but when I checked BD notifications it seems that it deleted a OneDrive registry key as a potentially unwanted lol
Trojan.genericS.11373
God BD is so stupid. To test that BD has added a signature for the fake Chrome Updater, I unzipped the file and BD instantly detected the infected file and i receieved "disinfection in progress", but when I checked BD notifications it seems that it deleted a OneDrive registry key as a potentially unwanted lol
Last edited:
The Network Access Protection flag has actually been enabled by default in Brave since v1.54, released July 25, 2023. They pushed forward with it well before other major Chromium browsers.
Seems the new is moving from being optionally enabled by flag to be enabled by default for Edge, as described on Neowin.
@Parkinsond
Theoretically, a DNS rebinding attack can also occur via websocket, albeit under very specific conditions.
In the absence of a specific flag for LNA protection of websocket, you could remedy this by blocking websocket in your adblock.
However, this could cause some features on certain websites to malfunction.
If, of course, you have a certain predisposition to paranoia...
P.S.
If I remember correctly, you use uBoL.
This DNR rule blocks websocket.
Try it:
Theoretically, a DNS rebinding attack can also occur via websocket, albeit under very specific conditions.
In the absence of a specific flag for LNA protection of websocket, you could remedy this by blocking websocket in your adblock.
However, this could cause some features on certain websites to malfunction.
If, of course, you have a certain predisposition to paranoia...
P.S.
If I remember correctly, you use uBoL.
This DNR rule blocks websocket.
Try it:
Code:
action:
type: block
condition:
resourceTypes:
- websocket
---
Last edited:
Paranoid patients do not use MDIf, of course, you have a certain predisposition to paranoia...
@Bot
Can you make me a table listing the specific ways in which a DNS rebinding attack could occur via websocket?
Can you make me a table listing the specific ways in which a DNS rebinding attack could occur via websocket?
Here are the main realistic ways DNS rebinding and WebSockets can interact, under the quite strict conditions where it’s actually exploitable.
| Scenario | What has to be true | How WebSocket + DNS rebinding helps the attacker | Practical notes / mitigations |
|---|---|---|---|
| 1. Internal web app exposes a WebSocket control API |
|
|
|
| 2. Router / NAS / IoT admin panel uses WebSockets |
|
|
|
| 3. Local development / debugging servers with WS (devtools, frameworks, DB dashboards, etc.) |
|
|
|
| 4. Internal apps using WS as a “thin RPC layer” over HTTP |
|
|
|
| 5. Legacy / misconfigured services that interpret WS handshake as HTTP |
|
|
|
Key points
- For WebSocket-based DNS rebinding to be practical, you usually need:
- a reachable internal service that actually speaks WebSocket (or mishandles its handshake), and
- weak/no authentication or trust based only on “it’s coming from the LAN”, and
- a browser that will complete the WS handshake to a private IP after DNS rebinding (this is exactly what LNA/Private Network Access aims to restrict).
- In most typical home-user setups, this is more theoretical than everyday, unless your router/NAS or some internal app exposes WS-based admin endpoints without proper auth.
If you want, I can also map these scenarios specifically to how Chrome’s LNA / Edge’s equivalent should limit them, and what gaps might remain for WS compared to plain HTTP(S).
You may also like...
-
-
-
-
Ongoing Attacks Exploiting Critical RCE Vulnerability in Legacy D-Link DSL Routers- Started by Parkinsond
- Replies: 10
-
