Addressing Issues

Frank Flanagan

Mac Addresses

Each NIC has a factory assigned MAC address e.g. 90.74.BF.8F.80.CF This a 48 bit address It is uniquely assigned, each vendor is assigned a block On most NICs it may be overridden by software MAC authentication is not therefore very strong

MAC addresses are not very useful to network administrators No control over what addresses you purchase

- Makes routing very difficult

IP Addresses

IP addressing and Ethernet addressing were originally developed separately and somewhat incompatibly

Originally an organization obtained a block of addresses assigned by a NIC

Now most organizations obtain only a few addresses and use NAT/PAT

Routing within and between organizations can be performed based on IP addresses

All Ethernet frames are transmitted using MAC source and dest addresses

So a mapping between MAC and Ethernet addresses is required

Initially was done using using hand configured tables

ARP

Address Resolution Protocol was created to solve the MAC to IP address mapping

ARP is intended to be used by machines on the same sub-net as one another

Say A (131.1.1.3) wants to make a connection to B(131.1.1.5) but does not know the MAC address

A forms an ARP request packet and sends it to the Ethernet broadcast address FF.FF.FF.FF.FF.FF

The machine owning the IP address sends an ARP response giving its MAC address

If the destination is not on the same subnet the address of a router is returned

ARP Details

ARP is not part of IP and does not have IP headers ARP packets having a broadcast destination address are

not forwarded by routers ARP records are aged and deleted from local caches

eventually Records typically have a life of up to thirty minutes

Old Style Ethernet

When Ethernet was originally conceived it was a cable bus All traffic in a network had to pass every node and nodes,

by good grace rather than by anything enforceable, were intended to process only traffic intended for them

Various physical topologies were adopted while still leaving the Ethernet as a logical bus

Bandwidth limitations as opposed to security concerns led to the adoption of switched Ethernet

Switched Ethernet

The old style hub or cable is replaced with a switch The switch forwards all broadcasts to all segments It dynamically senses the MAC address(es) on each

segment Normal packets are only forwarded to the correct segment With modern UTP networks there is usually only one device

on each port of the switch Therefore each segment should only see the traffic to or

from the machine on the segment But everything depends on ARP working properly

The Problems with ARP

Machines may send UNARPs i.e. delete me from your arp table

Machines may send gratuitous ARP responses this may happen legitimately for instance with two boxes working as a hot standby pair

Proxy ARP used when using NAT or routed networks may be manipulated

See for instance http://www.phenolit.de.arpoc http://www.monkey.org/~dugsong/dsniff http://www.packetstorm.securiyy.com/sniffers/smit.tar.tgz

NB: Neither DCU nor I accept any liability for anything you chose to download from the internet

Normal Communications

Switch

C

A B

A Communicates with B

Attacker ARPs its Address

Switch

C

A B

A Communicates with B

AR

P I A

M B

Attacker Forwards Traffic

Switch

C

A B

A S

ends pa

ckets to

B's IP

Add

ress but

A's M

AC

Add

ress

C Forwards Packets to B

Defenses

Static ARP entries for key systems arp –s <ip-addr> <mac-addr> This undoes much of the ease of use of arp but is likely to be worth

the effort for key systems ARP watching

ftp://ftp.ee.lbl.gov/arpwatch-2.1a6.tat.gz Rely on static IP to MAC database Lose most of the benefits of ARP Cannot use DHCP

RARP

RARP reverse of ARP Maps MAC addresses to IP addresses Used by BOOTP and DHCP to dole out addresses RARP is broadcast based

Significant attacks are against higher layer protocols DHCP provide client systems with dubious configuration DHCP tends to alllow unauthorized systems to gain a

presence on the network

Bootp/DHCP Defenses

Static IP addresses – loses all benefits of DHCP DHCP/BOOTP MAC configuration

Data base of MACs ARP monitoring Port Security

Domain Name System

ARP/RARP provide translation between MAC and IP addresses The IP addresses known to ARP are numbers

DNS provides translation between numeric and symbolic IP addresses

Unless you are willing to revert to using numeric addresses there is little choice other than using DNS

Unfortunately as everyone relies on DNS for address translations, on a world wide rather than just on a local network basis as with ARP, hacking DNS is one of the most dangerous attacks available.

DNS Name Lookup

C

Authoritative Name ServerLocal Name Server

Firewall

geth

ost b

ynam

e(w

ww

.dod

gy.c

om)

91.11.12.13

DNS Protocol

Client executes gethostbyname() Local resolver library sends request to local name server If local name server does not have address it queries

authoritative name server Local server will cache address on the way back DNS uses both UDP and TCP

UDP for requests < 512 bytes TCP for larger requests Just about every firewall is configured to alllow outgoing port 53

TCP/UDP to resolve names This means that it is often a target

Terminology

Zone Transfer – intended to transfer data between primary and secondary DNS servers for redundancy

recursive requests or non-authorities requests –Request for information on an address for which this server is not

authorities i.e. a request which will either be fulfilled from the cache in the server or will cause the server to make a request from an upstream name server

Vulnerabilities

Poor access controls Caching servers do not manage their own cache Databases tend to be ASCII Dynamic DNS update

Microsoft especially uses DDNS to allow client systems to update their own resources on DNS servers.

Zone Transfer Recursion – Most default DNS systems allow remote

systems to query them for systems for which the server is not authoritative

DNS is very trusting DNSSEC is one possibility

The Promise of Improvement

The IETF has designed a number of security extensions for DNS but deployment keeps getting delayed to avoid interoperability problems.

Like IPV6 I suspect that these may actually get deployed some time during my lifetime

DNS Harvesting

Hackers often harvest data from DNS The DNS database may contain many records:

IP Address records Reverse records Name server records Host Information records

- Do not use

Service Records- Associates service with a server or a set of servers (Active Directory

makes extensive use of these records)

Text Records – Do not use Well known service records – similar to SRV records

DNS Harvesting Tools

http://www.samspade.org http://www.solarwinds.org dig nslookup

Denial of Service Attacks

DNS Request Flooding – Flood a server with requests for systems for which it authoritative

DNS Response Flooding – As request flooding except with a live spoofed source address, this floods the supposed source network with responses from faked requests

Recursive Request Flooding – flood a target name server with requests for addresses for which it is not authoritative thus flooding both the target and the authoritative server for the domain Do NOT accept non-authoritative requests from unknown source

addresses DNS flooding relies on the difference in size between small

DNS requests and large DNS responses

DNS Cache Poisoning Explained

DNS servers are constantly sending out questions ("What's the IP address of www.xxx-xxxx.com?") and receiving answers ("www.xxx-xxxx.com is at 209.237.229.14").

They don't actually authenticate the source of the answers -- there's no way for your DNS server to be sure that the answer actually came from the REAL xxx-xxxx.com. Some DNS servers don't even check that they asked a question that corresponds to an answer they received, and just believe any answer someone sends them.

The simplest form of cache poisoning is simply sending fake answers to someone's DNS server; for each safeguard a DNS server might apply to prevent cache poisoning there's usually a workaround that goes one step further. This is why SSH has all that stuff with strict checking of host keys.

Now I Digress

It's just like fraud schemes in the real world -- some guy walks up and says he's from the gas company. You let him in, he steals your beer. Next time you ask him for gas company ID. He shows you a fake one. Beer stolen.

Next time you call the gas company phone number printed on his ID. It's his buddy's phone number; the buddy tells you the guy's legit. Beer stolen.

Next time you call the gas company's number as shown on your latest gas bill. It's his buddy's other line; they sent you a forged gas bill. Beer stolen again.

Indeed, perhaps they simply bribe a real gas company employee to steal your beer. It's a never-ending arms race.

Daniel F. Boyd / boyd@csgeeks.orgLast modified: Tue Jul 30 16:02:41 2002

Registration Fraud

Hi I am Frank from Microsoft can you register the following domain for me?

Sounds implausible It happened Domain registrars are supposed to confirm lots of things

and typically only accept changes only from a single email address

Buffer Overflows

There have been a number of successful buffer overflow attacks on DNS The most notorious was the BIND8 Transaction Signature Attack This managed to get random code to execute It was an early stage attack so it worked on both recursive and non-

recursive DNS servers It was used by the li0n worm among others

DNS Spoofing

Intercept a DNS request to redirect client to a fraudulent address

DNS spoofing tools exist such as the imaginatively named dnsspoof

DNS spoofing requires faking a DNS request ID This is now supposed to be difficult due to the introduction

of random DNS IDs There are a number of interesting proposals to used the

birthday paradox to overcome this

DNS Hijacking

Either compromise an upstream name server or Replace a name server in the domain of interest Can be achieved by attacking a poorly protected upstream

DNS server

Securing DNS

Run the DNS servers with the least privilege possible Run as little as possible on the servers Use multi tier DNS

One in the DMZ for the outside world One in the core for internal users

All patches Firewall Do not support external recursive queries

Verisign’s Sitefinder “Service”

Verisign now manage the top level .com domain among others

They introduced a modification to the top level DNS in that no domain could be non-existent instead if you mistyped a name you were redirected to a Verisign site with some helpful suggestions e.g that when you typed googl you might have intended to type google and a lot of advertising

This caused outcry among the internet community and broke lots of useful things like testing for valid domains before accepting email

This was suspended but is now rumored to be on the verge of being resurrected