what if...?

Hi,

what if evil guys hack my mom ISP DNS servers and use RPZ to redirect traffic from mom_bank.com to evil.com?

How can she detect this?

Eduardo.-

You mean besides SSL? :slight_smile:

Ken Matlock
Network Analyst
Systems and Technology Service Center
Sisters of Charity of Leavenworth Health System
12600 W. Colfax, Suite A-500
Lakewood, CO 80215

303-467-4671
matlockk@exempla.org

The snarky answer is "If your mom has to ask how she can detect this, she's
probably going to be unable to do so".

The more technically correct answer is that you can check the IP and TTL as
returned by your local caching nameserver, and compare them to the values
reported from the authoritative NS for the zone. Of course, this means you
have to hit the authoritative server, which sort of defeats the purpose of DNS
caching.

Or you can deploy DNSSEC.

Or you can deploy SSL (not perfect, but it raises the bar considerably).

Or you can google for "DNS RPZ" and start reading - the top hit seems to be
Paul Vixie's announcement: https://www.isc.org/community/blog/201007/taking-back-dns-0
and start reading - as about the 4th or 5th commenter points out, the threat
model is *no* different than a DNS server that forces in its own zones. The
commenter is talking in the context of a provider replacing a zone, but it's the
same issue if a black hat hacks in a zone.

Thankfully mom_bank.com is not valid, as underscores aren't valid in dns names :slight_smile:

Additionally, SSL certificates combined with DNSSEC/DANE can provide some protection. Some of this technology may not be available today, but is worth tracking if you are interested in this topic.

- Jared

You tell that to http://www.charset.org/punycode.php?encoded=xn--m_omaaamk.com&decode=Punycode+to+normal+text

Normal text
FMQQSQQT.com

to Punycode
xn--m_omaaamk.com

?

the one difference is that ISC will be shipping RPZ enabled code v.
  the blackhat having to hack the machine and modify the configuration.

  in the new BIND w/ RPZ, it will be much harder to determine when
  RPZ has been tweeked... Lowers the bar considerably. RPZ sucks

/bill

Dash - is a different character than underscore _

~Seth

Hi,

what if evil guys hack my mom ISP DNS servers and use RPZ to redirect
traffic from mom_bank.com to evil.com?

How can she detect this?

Does your Mom call you up every time she gets a dialog box complaining
about an invalid certificate ?

If she has been conditioned just to click "OK" when that happens, then
she probably can't.

Regards
Marshall

Uh, what?

~Seth

EIther way, the blackhat still has to hack the machine and modify the config.
The only difference is what config change they make.

You probably want to google for the dnschanger virus

Yes and...

If you have a really insecure DDNS update mechanism on your master RPZ zone, then I can see how RPZ might lower the bar *a little*, but I have to stretch my imagination quite a bit for that to happen.

If your ISP doesn't use RPZ (regardless of whether the code is present in BIND), then the bad guy has to hack the box, set up an RPZ configuration, and then pollute it with bad data. Much easier to just install a bunch of fake zones.

RPZ is a red herring here.

michael

Hi,

what if evil guys hack my mom ISP DNS servers and use RPZ to redirect =20
traffic from mom_bank.com to evil.com?

How can she detect this?

The bank signs their zone and mum's machine validates the answers
it gets from the ISP. This is not rocket science. This is not
beyond the capabilities of even the smallest client that mom would
use to talk to the bank. This is how DNSSEC was designed to be
used.

Validating in the resolver protects the resolver itself and the
cache from pollution. It also protects non DNSSEC aware clients
from upstream of the resolver threats. It was always expected that
clients would validate answers themselves.

Mark

Marshall Eubanks wrote:

Does your Mom call you up every time she gets a dialog box complaining
about an invalid certificate ?

If she has been conditioned just to click "OK" when that happens, then
she probably can't.

Everyone I have observed clicks "ok" or "confirm exception" (if I remember the phrase correctly) as soon as possible. Sadly I think only a few security conscious (IT) people will actually think twice and reject it if they don't trust it.

That to me proves this aspect ssl is somewhat flawed in that regard. But then I am preaching to the choir. :slight_smile:

Regards,
Jeroen

See the definition of "dialog box" at http://www.w3.org/2006/WSC/wiki/Glossary

    --Steve Bellovin, https://www.cs.columbia.edu/~smb