Addressing Issues Frank Flanagan
Jan 07, 2016
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 / [email protected] 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