CIS 4615 meeting -*- Outline -*-

* name resolution
   Based on chapter 24 of the book "24 Deadly Sins of Software
   Security" by Michael Howard, David LeBlanc, and John Viega (McGraw
   Hill, 2010)

** background
------------------------------------------
              BACKGROUND

Name resolution turns
     www.cs.ucf.edu into 132.170.216.158

DNS = Domain Name Service
      runs on UDP protocol 

How a DNS server works:

    - receives request (name + 16 bit ID)
    - answers if it is authority for domain
      or if it has a cached copy
    - otherwise forwards up the chain
         www.cs.ucf.edu
             cs.ucf.edu
                ucf.edu
                    edu
------------------------------------------
        that's an IPv4 address, use tracert to find these

        Q: What's the significance of using UDP?
        No connection is established

** attack
------------------------------------------
            DNS ATTACK

First step, find your DNS server
 1. Attacker controls DNS server
 2. Attacker sends your computer
    a packet, for intrusion protection
    your computer does a reverse lookup
 3. Attacker reads out address of your DNS
    server

Second step, find port you are using
  - only a search of 16 bits of ports

Third step, find request ID
  - it increments monotonically in many
    implementations

Forth step, forge reply with long 
   time to live field.

------------------------------------------

------------------------------------------
            DHCP

Even less secure than DNS
------------------------------------------

** lessons
------------------------------------------
              LESSONS

Moral: name and IP address are not secure

So designs should not trust DNS

Don't use name to make security decisions

Cryptography needs to handle

------------------------------------------
      ... man-in-the-middle attacks


** code audit
------------------------------------------
            AUDITING CODE

Look for:

  - host names being used
  - gethostbyaddr

  - use of UDP protocol

------------------------------------------
        Q: Why is UDP bad?
        no authentication because no connections

** testing
------------------------------------------
             TESTING

With real client and server:
  record and view information sent

  - look for anything that would
    be

Build

  - evil server
  - evil client

See what happens to client with

See what happens to server with

------------------------------------------
        ... bad if it were intercepted by an attacker
        ... evil server
             and try fuzz testing
        ... evil client

** redemption
------------------------------------------
             REDEMPTION

Use SSL, do all PKI checks

Or use IPSec

Or use Kerberos or Windows authentication
------------------------------------------

        Q: What could be the problem with checking passwords over HTTP?
        may have password cracking