Addressing Issues

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

Attacker ARPs its Address

Attacker Forwards Traffic

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

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

Addressing Issues