On 09/16/2013 01:13 PM, Brian Lavender wrote:
> How is it that attackers inject false information into DNS?
> 
> https://wiki.sonic.net/wiki/DNSSEC
> This prevents hackers from injecting false information (aka DNS cache
> 'poisoning'), in an attempt to re-direct people trying to access a real
> website to a fake, phishing or criminal site.

        I will attempt to answer you question by giving a very high
        level overview.

        I do ask others (Rick, Alex and any other person who knows DNS)
        to keep me correct if (when) I say something wrong, if if they
        feel I left something out which needs to be covered.

        Quick History

        Before what we now know of as the 'Internet' we had a network of
        machines which were mostly connected via modems and would use
        UUCP to pass files and E-mail. This networked used was was known
        as the 'bang path' method figure out how to get to a machine.
        For example an old address I use to use was along this line:
        
        intelca!decvax!inhp4!<some machine on the east coast>!username

        which means send the E-mail to intelca, then to decvax, then to
        inhp4 (in HP Indian Hills New Jersey), and then to a machine
        which was connected to it and then to the user mbox.

        Latter we added a couple of other symbols ie '@' to help with
        the processing.

        Then to make life easier, Peter Honeyman developed a program
        which would take what was called the UUCP maps and build a
        file by the name of 'path-file'. This text base file would
        contains the hostname and a bang-path line for how to reach
        the site.

        Paul Vixie (and others) decided we needed a better method
        and developed Bind which used the Domain Name System instead
        of bang-paths.

        What this now does is provide a key-value database which
        contains the domain name such as 'mydomain.tld' (tld means
        top level domain, such as .com, .org, .net and so on). The
        value part of the database contains one or more IP addresses.
        Really it is much more complicated then this but this is a
        very nice and simple way to thing of it.

        There is a lot more which can be covered in the history area
        but I have a quick dirty overview.

        Today with DNS

        Let me cover what happens with Ubuntu as this is what most of
        us are currently using. And the ideas are very close to all
        systems.

        Depending on how you are connected to the Internet, somewhat
        controls type type of name services you run. For most of us
        we are on a dynamic IP and uses DHCP when we connect. Even if
        we are using a M$ system, a Mac or whatever we still follow the
        same base set-up.

        When we connect using DHCP we receive the IP address of the
        name servers we are to use. This information goes into the file
        /etc/resolv.conf.

        Of late, Ubuntu has gone one more step, they have set-up what is
        called a 'caching name server' when you use DHCP. This means we
        keep a cache of domains and their IP address which we use to
        look-up instead of having to ask our ISP for this information
        (thus adding a slight handshake delay). In Brian's and my case
        our ISP DNS 'forwards' is the Sonic DNS servers.

        If you run your own name service (BIND-9), depending on how you
        set it up you can still use your ISP as a 'forwarder'. This
        means, instead of doing a recursive search up to the TLD and
        then down to the DNS server for the domain we just ask the ISP
        if they have the domain in their cache (and most of the major
        sites will be already in the cache). By using 'forwarders' you
        can save a lot of time by not having to do the full search.

        The default method of setting up a DNS server (BIND-9) is to
        not use forward and do your own searches.

        Cache Poisoning - man-in-the-middle

        BIND-9 like all programs has bugs in it. Because of how
        serious the bugs can be, BIND normally has a very quick turn
        around time to fix problem. But that does means all of the bugs
        have been found.

        For this lets assume that I have found a bug in an older version
        of Bind which Brian has not updated to yet.

        Buy using this bug I can change Brian's DNS cache to point to
        me as a 'forwarder' (or ever as a TLD DNS server). This means
        I know become a Man-In-The-Middle, and I can now force Brain
        to use my fake-Google search engine, or even point his browser
        to nude-babes.ru instead of Google.com. And depending on where
        he is at, at the time (think being at work and having this
        happen), he could be put into a very bad spot.

        Reason for DNSSEC

        To try to prevent the man-in-the-middle issue, we now want to
        insure that the machine we are talking to is the one and only
        machine we will trust (NOTE: all security is based on TRUST!!!)
        By using DNSSEC, we have a handshake which happens which goes
        like this:

        Hi! I'm NS1.Sonic.com here is my ID key, can I have yours.
        Thank you. I see you are Brian's machine and you have confirmed
        I'm NS1.Sonic.com. Now here your requested data.

        While that is not fully correct, at a high level we don't need
        to worry about it any more. We have exchanged keys and we have
        both agree to have valid responses.

        Does this prevent Man-In-The-Middle?

        NO!!!! There are still bugs which can be used which has not yet
        been found. And we should also acknowledge there are some BIG
        ISP who have been known to act as a Man-In-The-Middle, such as
        both Comcast and AT&T (such as Room 641A which was discovered
        by Mark Klein in 2006 http://en.wikipedia.org/wiki/Room_641A )

        Even with DNSSEC, we TRUST the upstreams sites to give us the
        correct information. DNSSEC, does reduce the chance from outside
        but it does not all together stop having the DNS cache poisoned.
        And if our upstream 'forwarders' lie to us, then we have in
        valid information.

        Also if you have physical access to the 'wire' you can always
        add taps (room 614A style).

        Who is the biggest Man-In-The-Middle?

        Simple, the NSA!!!!. We already know AT&T is in bed with the
        NSA. Room 641A proves that. As for Comcast we have not had a
        whistle-blower yet to come forward.

        A number of us know about Mae-West which is one of the largest
        networking hubs and a major one for the Internet. Mae-West is
        in San Jose. IN THE SAME BUILDING AS THE IRS AND THE FBI.

        If you can put a T-Trap on the network and capture all of the
        data, it is also possible to introduce a man-in-the-middle!

        As I said, security is all about trust. Right now, there are
        a lot of people who agree with John Gilmore (and EFF) about
        the lack of trust with all of the encryption standards which
        the NSA has been involved with and had input.

        Anyway I know this has somewhat gotten off scope and some might
        say I pulled out my tin-foil hat. But right now, to me Edward
        Snowden and Wikileaks are heroes.

                                                                Tony
        

        

_______________________________________________
vox-tech mailing list
[email protected]
http://lists.lugod.org/mailman/listinfo/vox-tech

Reply via email to