A Website Reached Your Localhost Server by Changing Its Own DNS

Your tool runs a small server
on localhost.

A dashboard,
a debug API,
a helper for the desktop app.

It has no password.

Why would it.

It only listens on 127.0.0.1,
so only your machine can reach it.

That sentence is true.

It is also
not the protection
you think it is.

Your browser
is on your machine.

You open a page
on a site
you have never heard of.

It loads a script
and then waits.

The domain it came from
was set up with a very short DNS lifetime,
a few seconds.

When the browser asks again
what that name points to,
the attacker's DNS server
gives a new answer.

127.0.0.1.

Now the script sends a request
to its own domain,
on your tool's port.

The browser sees the same name
the page came from,
so the same origin policy is satisfied.

The request goes to your laptop.

Your server answers.

And the script can read the answer,
because as far as the browser knows,
it is talking to itself.

This is DNS rebinding.

It is old,
and it keeps working.

In 2018
Tavis Ormandy of Google's Project Zero
showed it against
the Transmission BitTorrent client
and Blizzard's update agent,
both of which trusted
anything that reached them locally.

There is one thing the attacker
cannot hide.

The Host header.

It still carries the attacker's domain,
because that is the name
the browser thinks it is using.

So check it.

Accept localhost,
127.0.0.1
and your own names,
and refuse everything else.

Rails added host authorization
largely for this reason,
and webpack's dev server
has an allowedHosts setting
for the same one.

Better still,
put a token on the local API,
created at start up
and shared only with your own client.

Browsers are moving too.

Chrome 142 started asking the user
before a public site
can reach the local network.

Do not build on the prompt.

People click allow.

Localhost is not a wall.

It is just the address
where the attacker's request
arrives.

– Serguey Asael Shinder