
Attacking Private Networks from the Internet with DNS Rebinding - kiyanwang
https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
======
joemag
Do you even need to play with DNS caching? Aren’t subdomains excluded from
cross-origin request blocking?

Can badsite.com request a resource from subdomain.badsite.com, and the browser
will allow it. The JavaScript on badsite.com can be clever then, and begin
probing <ip>.badsite.com, so all badsite DNS need to do is resolve that to
<ip>.

~~~
detaro
Same origin policy is an exact match on the protocol/domain/port tuple, so
subdomains are not same origin.

~~~
angry_octet
While this is true, it is complicated by TLS terminating cloud services and
the complexity nightmare that is TLS. For example, sub-domain takeover.
Basically, TLS rules don't behave exactly as CORS:
[https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-
aw...](https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aws-and-
trailing-dot-domains/)

You could also use the dangling domain to get a Let's Encrypt certificate.

It is quite common for sites to allow cross-origin loading from their own
subdomains, with CORS and CSP headers.

------
h43z
If you want to play with custom javascript payloads I created a website that
lets you set one.
[http://dnsrebindtool.43z.one/](http://dnsrebindtool.43z.one/)

------
_trampeltier
I was always wondering, if it would be possible, for example, to write an SMB
Client in Javascript and so get access to an open SMB server in a LAN from a
Website. (I don't know JavaScript at all)

~~~
penagwin
I don't know much about SMB, but unless it's api is over http/https then
AFAIK, no it wouldn't work. You might be able to get away with TCPSocket but
it's super draft phase and no browser supports it. This means there isn't a
direct way to directly connect to sockets over TCP, and UDP has been a problem
here too (Games like agar.io can't use it.)

Maybe there's a new way to do it I haven't heard of, but that was the state of
things last time I checked.

~~~
jquast
websockets? at least for "scanning"
[http://localrouter.net](http://localrouter.net)

~~~
detaro
Websockets are on top of HTTP, so they don't provide anything for accessing
non-HTTP resources.

------
netsharc
Not a comment about the subject being discussed, but about the style of the
article, why the heck is that 1 paragraph full of emojis? Dear author(s),
please don't do that, it makes me think of Kindergarten and "fill in the
blanks according to the picture":
[https://i.pinimg.com/736x/bd/5c/cc/bd5ccc19946fba6d7484e4787...](https://i.pinimg.com/736x/bd/5c/cc/bd5ccc19946fba6d7484e4787b5785a2
--sentences-the-words.jpg)

------
textmode
As a matter of preference mainly for speed and reliablity, not as any sort of
"security" measure, I do DNS lookups in advance and store the data, using
various custom solutions.

Thus I do not need to do any lookups while viewing a page. The addresses are
already available to HTTP clients locally, e.g., via HOSTS, a cdb key-value
store, or an authoritative nameserver serving a custom zone file on the local
network. In other words, I am not using a caching resolver.

"DNS cache poisoning" publicity circa 2008 gave me the impetus to end reliance
on shared caches and later caches altogether. But it was the speed when not
using a cache that kept me interested. It still does, even today.

Maybe "DNS rebinding" publicity will cause others to question the need for
using shared caches, or even caches in general. Maybe not. In any event, with
the increasing availability of bulk DNS data from a variety of sources, it is
much easier to devise methods for avoiding caches today than it was in 2008.

~~~
pfg
Does your approach respect TTL, i.e. by updating your source of truth after a
record expires? Because you'd still be affected by DNS rebinding attacks in
that case - and if not, I imagine there'd be quite a bit of breakage when IPs
change?

DNS caching in combination with an enforced minimum TTL (of something like 60
seconds) can be useful in mitigating certain categories of rebinding attacks
(for example an attempt to bypass SSRF checks). Your solution might share this
property if it behaves similarly.

~~~
textmode
I control the frequency of updates to the data. If something changes I see it.
I decide whether I want to trust it. Usually in the case of a change I will do
some research on the new IP address. "TTL" is a concept used for DNS caches. I
do not use a cache.

~~~
nstart
This sounds interesting. Quick questions.

1\. Is it possible at all to release some source code related to this? I know
it's a big ask but I didn't want to leave without asking :)

2\. Would it be ok to describe what this solution looks like a little more? Is
it /etc/hosts being edited using a service? Is it at a deeper level? Do you
use your own DNS server?

I'd love to adopt something similar, hence the curiosity :)

~~~
dvfjsdhgfv
I was using a similar solution but probably quite different than the parent. I
first generated the list of entries using Tinyproxy (turned out it was much
easier than inspecting local DNS cache): you install Tinyproxy somewhere and
use it for a few days. Then take the log and cut the lines:

    
    
      CONNECT Sep 08 08:29:04 [18050]: Connect (file descriptor 6): DOMAIN [IP]
    

So basically you almost have your hosts file ready, you just need to switch
places of the DOMAIN and IP, cutting out all before and the brackets. A minute
or so.

I used it for a short time and never bothered to take care of the updates
though. I guess I'd have to temporarily disable the hosts file and run an
async DNS resolver such as adnshost:

    
    
      adnshost -Vq +Dt
    

\- filtering out the INET string to create a diff. It seems to much hassle to
me though, to manually inspect DNS changes - I have so many things to do, I
see no much reason to bother with every IP change on the Internet.

------
amaccuish
Many dns servers have an option to block rebinding. For dnsmasq it's stop-dns-
rebind. I added an exception for Plex, which relies on it for their personal
ssl certs.

Quite a lot of routers use dnsmasq internally. Ideally this would be a default
setting.

~~~
Stephen304
It seems to be the default for Unbound, at least on OPNSense. Though the POC
allowed me to discover that my phone had been bypassing my local resolver
because I tried to put 1.1.1.1 as a fallback in pihole as second option to my
router, but for some reason pihole had been preferring CF over my local
router.

Edit: To clarify, it seems that unbound by default blocks all RFC1918
addresses in DNS queries unless you specifically allow it for a specific
domain (eg. plex.direct). OPNSense doesn't seem to expose an option to allow
RFC1918 addresses in all dns responses.

~~~
crtasm
Pihole doesn't fallback, it spreads DNS requests between all the upstream
servers you specify.

Your router well may do the same.

~~~
Stephen304
I have OPNSense configured not to forward queries so it uses root servers
directly, but it's of no consequence because like I said above, Unbound on
OPNSense blocks RFC1918 responses by default anyways. As long as my devices
are using my router as a resolver, I'll only get public IPs as responses to
DNS queries. My misconfiguration in pihole just temporarily bypassed that.

------
chii
But if you need to have the malicious DNS server connected as a requirement,
aren't you already owned? The DNS server can tell you the bank's hostname is a
malicious IP, and then you can both steal credentials, or MITM.

~~~
tptacek
No, the malicious DNS server is the one for the domain the _attacker_
controls, not the target.

~~~
chii
But if you use a DNS server that's not trustworthy, how can you be sure that
the site you're seeing is indeed the correct one?

~~~
tptacek
I think you're confusing authority servers, which control the content for
domains, and query resolvers. This attack works because it only requires an
attacker to control an authority server, any authority, on the whole Internet.
They can just register a domain to do this with.

------
sml156
I tested the POC and it said I had several devices, Anyone want to help me
search my small apartment for them because I would love to play with them.

    
    
       {{Object.keys(roku.devices).length}} Roku found
       {{Object.keys(googleHome.devices).length}} Google Home found
       {{Object.keys(radioThermostat.devices).length}} Radio Thermostat found
       {{Object.keys(phillips.devices).length}} Phillips Hue Bridge found
       {{Object.keys(sonos.devices).length}} Sonos speaker found

~~~
mirimir
No, that's just what it shows when it can't find anything.

------
fulafel
Yet another symptom of the broken security model that is security through
context dependent addressing (rfc1918 addresses or split horizon dns).

We should just give all things globally addressible addresses, and do ACLs
explicitly. (Or have a really air gapped network).

------
OrangeTux
Very interesting write up! But how likely is it to have control over the DNS-
server someone uses? You either need to setup a malicious one and let the
victim use your server. Or you've to hack the DNS-server the victim already is
using.

~~~
matharmin
This attack doesn't need control over the victim's DNS server. It uses
attacker-controlled domain names to access private IPs via XHR. The DNS
rebinding bypasses the standard CORS protection (without this protection the
attacker could've used the IP directly). This attack is very easy to protect
against (validate the Host header), but lots of IOT devices don't do this.

------
voltagex_
If I have *.int.my.domain mapped to internal hosts, am I putting myself at
greater risk of rebinding attacks?

------
mirimir
OK so I hit [http://rebind.network/rebind/](http://rebind.network/rebind/)
from this VM. Gave it full JS permissions. And hey, it just spins its wheel.

Which isn't surprising, given that this VM's LAN router/firewall is a pfSense
VPN-gateway VM. With another pfSense VPN-gateway VM as its uplink. With
another pfSense VPN-gateway VM as _its_ uplink. Oh, and a hardware
router/firewall on the ISP uplink.

The first pfSense VPN-gateway VM would likely have been enough. There's no
reason to expose your LAN to the Internet.

~~~
detaro
VPNs do nothing to protect against DNS rebinding. It's possible you have
something in your stack that does intentionally or as a side-effect (e.g. if a
pfSense host handles DNS, it might reject private IPs in responses, or cache
longer than it should), but it's unrelated to your VPNs.

~~~
mirimir
One point is that my pfSense VMs have no routing to any physical LAN. Not
without a guest-to-host breakout, anyway. The fact that they're VPN gateways
is irrelevant for this.

Another point is that I have multiple LANs, to compartmentalize. There's no
one router that can mix local devices and Internet hosts.

