Server Version#: 1.18.7.2457
Player Version#: 4.22.2
Yesterday my router reported about “possible DNS rebind attack for xxx.plex.direct”. And I checked the documentation on https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/. It says plex needs us to change router configuration and ignore this attack for plex.direct. My problem is why do we need to do this. Basically the DNS rebind attack refers to a situation that a Public DNS resolves a domain name to a local IP address. So isn’t that plex DNS resolves my PMS server’s domain xxxx.plex.direct to its private IP in my LAN? Alternativaly is it resolving xxx.plex.direct to its public IP for public network? I know this behavior is like some DNS load balance strategy broadly used by current day Web service providers, they provide different server IPs for different geographical area users.
At last, if i don’t configure my router to ignore this attack, what will be the consequences? Isn’t it i will have my PMS server showing with ‘Remote’ in plex.tv/web?
In the context of Plex this is not so much an attack but part of how a Plex client established a secure connection to the Plex Media Server.
Plex is using a server specific subdomain (xxx in your example) of the domain plex.direct when creating the server side certificate for the encrypted connection with your clients. However, as your server isn’t actually publicly available / has no public domain of its own (exceptions apply where users have their own domain name… which on the other hand Plex isn’t aware of)… this involves DNS rebinding.
As the support article you had linked, some routers and ISPs block this mechanism or want you to set an exception for services where you knowingly decide to allow it.
If you ask the router to block this, clients (remote or local) will run into trouble establishing a secure connection. I’ve run into this myself sometime ago. Without allowing the exception my local clients were e.g. not able to play online extras or web shows).
I checked that subdomain for my PMS server with ‘nslookup xxx.plex.direct’ and didn’t find it resolved to a private ip. This is confusing.
What i concerned is that if i leave my router to block this DNS rebinding, will i see my PMS server as remote even if i am in my LAN. I am unable to do NAT loopback on my router, so i am worried about the DNS response for my subdomain.
There’s some misinformation here about what the DNS rebinding attack actually is. The way it works is for the browser to make requests to a particular domain which is on a public IP address and the browser dutifully does the CORS checks to ensure that the JS code is allowed by that server to make requests. The trick is that the DNS entry for that domain has a very short TTL (Time To Live) and thus after the browser has done its CORS checks, the DNS entry is changed to be a private IP. This is the rebinding; the domain name is re-bound to a different IP address. Then subsequent requests to the same domain are pointed at the private IP instead. Then requests can be made by the JS code to that private IP address which is often used to attack an unsecured router.
Routers which enable protections against the DNS rebinding attack tend to do so in the most simplistic (and wrong) way. They just assume that every single resolution to a private IP space is such an attack regardless of whether it was rebound or not.
As per the lookups, you need to lookup the full hostname which is #-#-#-#.xxx.plex.direct where the #s correspond to the IP address and the xxx is the aforementioned certificate identifier. If this does not yield the private IP address, then your router is blocking it.
Without this, all of your clients in the LAN will be unable to make local connections to your server (unless you disable the encryption). They might be able to connect to your router’s WAN address to connect to your server (assuming that you expose your server through your router and your router supports this type of loopback).
If you block this, you might also end up with all “relayed” connections. (which means they not only consume internet upload and download data but are also rudely restricted to 1mbps).
Thank you for the detailed information, but i checked wikipedia about DNS rebinding https://en.wikipedia.org/wiki/DNS_rebinding, there is nothing about CORS.
And according to https://en.wikipedia.org/wiki/Cross-origin_resource_sharing, CORS is only about domain name, its not about ip resolved from domain name, and during DNS rebinding, only ip changed, domain name is not changed, the browser should not enforce same origin policy here, so DNS rebinding should not be related CORS. It just make a client being unaware about which server it is actually visiting.
Based on the analysis above, DNS rebinding is not a trick to bypass CORS.
I rechecked my subdomain for PMS today, and surprisingly found it changed to my private ip during visiting plex.tv/web, but after that it didn’t change back to its public ip anymore, even if i nslookup it from outside of my LAN. This is confusing again, if it always stays as private ip, then how does my remote clients access PMS from outside of LAN, They will see a private ip and fail to connect, right? But that is not the case, i successfully connected to my PMS from another laptop outside of my LAN. I inspected the connections that browser made, for the first time it was trying to connect to my subdomain, it failed, after some work of app.plex.tv/desktop, it was then trying to reconnect to my subdomain, and this time it succeeded. I imagine the process may be:
browser connected to plex.tv, got html and js codes.
js code checked whether it is in LAN, and told plex server
plex server changed the DNS result according to its policy
js code refreshed DNS result for xxx.plex.direct and connected to xxx.plex.direct
So basically the DNS result is changing during login process of plex.tv/web, and its result is determined by the negotiating of the browser javascript code with plex server. This makes me thinking about why not “HTTP DNS” but this complicated “DNS rebinding”, maybe it’s because of HTTPS, so that we have the browser’s green lock icon.
It is a way to bypass CORS protections. At first the DNS resolves to a server which responds to CORS requests allowing JS to make requests. Then the DNS changes to a different address. Since the browser has already done the CORS check, it hits the new IP address assuming allowing JS to make requests it desires. The name of the host hasn’t changed, only the address has and now the JS is hitting devices which didn’t give it permission via CORS (such as a router).
It’s possible that browsers have mitigated against this since but that is the classic attack using DNS rebinding.
If you look at the full hostname, you’ll see what’s going on. The clients outside of your LAN attempt to connect to #-#-#-#.xxx.plex.direct where the # correspond to the private IP address. This will fail outside of your LAN. Then they will connect to the same domain but with different #s which correspond to your WAN IP address. This succeeds (assuming that you have your router set to allow the port forwarding to your PMS). No DNS entry changes in this process; your client tries multiple hostnames, which correspond to different IP addresses, to reach the server.
Thank you, it is clear for me now. I didn’t notice there were two versions of #-#-#-#.xxx.plex.direct yesterday. So plex doesn’t change DNS record during visiting process, it just maintained two versions of it. And clients will choose between them. Because i don’t have a static public address, i asume PMS may be updating that public version of #-#-#-#.xxx.plex.direct periodically just like DDNS.
Yeah, i think DNS rebinding is capable of bypassing CORS, but maybe it’s not its primary purpose? For example normally as a router web interface, there is no restriction for the Host header at all, and one may access it with whatever hostname. The attacker may provide a website with ‘attacker.com’, after target has accessed this site for the first time, his/her brower has cached the html and javascript, then the attacker changes DNS result for ‘attacker.com’ and points to target’s router, 192.168.1.1 eg, the javascript codes then access this new ‘attacker.com’ smoothly. Because target’s browser has been accessing the same site ‘attacker.com’ across the whole process, there is no CORS problem at all. If this is right, then why bother involving another domain other than ‘attacker.com’ and introducing CORS.
Your PMS updates the entry on plex.tv that your clients fetch to find your server. If you IP address should change, you would see the numbers in the #-#-#-# part change to the new address.
DNS can be rebound intentionally so because servers can move IP addresses over time and there are other things such as load-balancing and so forth. You pretty much got the DNS rebinding attack right. The CORS is a requirement imposed by the browser so the attacker using their own domain to give a permissive CORS reply is essentially a way to disable that protection the browser provides. This can be done with any arbitrary domain.
The reason why this naive protection against DNS rebinding that many routers provide is done incorrectly is that it doesn’t bother to check if the DNS entries ever change. The entries for plex.direct addresses don’t ever change and we put long TTLs on them.