Course 3: Network Security, Section 5Pascal Meunier, Ph.D., M.Sc., CISSPMay 2004; updated July 30, 2004Developed thanks to the support of Symantec Corporation,NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise CenterCopyright (2004) Purdue Research Foundation. All rights reserved.

Course 3 Learning Plan

Architecture Physical and link layer Network layer Transport layer Application layer: DNS, RPC, NFS Application layer: Routing Wireless networks More secure protocols: DNSSEC, IPSEC, IPv6

Application-Level Attacks

Name-space Protocols– DNS– NIS– NetBios (and friends)

Remote Procedure Calls– RPC– DCOM

Network File System (NFS) Routing Protocols

– RIP– BGP– OSPF

Learning objectives

Understand how name-to-IP (and reverse) mapping issues can result in vulnerabilities

Understand how SSL is useful Be aware of some general, high-level issues in

– Remote procedure calls– Network file systems

DNS

Motivation: DNS Attacks make news– “Al Jazeera Web Site Faces Sustained DoS Attack and

DNS Attacks” (2003)– Hillary2000.com (Hillary Clinton’s campaign)– Nike (2000)– Ricochet Networks (1999)– AOL (1998)

Domain Hijacking: A step-by-step guide– www.securiteam.com (10/2/2000)

What are DNS attacks, and how do we defend against them?

Outline

Review of DNS Protocol vulnerabilities and exposures

– Recon– Cache poisoning– Access control based on host names

Implementation vulnerabilities– Review of vulnerabilities in BIND– Code examples

Review of DNS

Domain Name System – Well-known implementation: BIND

Purpose: translate names that humans understand to IP addresses– e.g., www.cerias.purdue.edu => 128.10.252.9– Allows changing IP addresses of servers– Information is stored in "RR"s: Resource Records

Many RFCs (complex) Distributed system

– Not one server knows all the answers– Recursive requests may be needed

Can use either TCP or UDP

Organization

"Root" servers point to top level domain servers, like .com, .org, .edu, etc...

Those point to more specific servers. Eventually a server will know the answer “nslookup” is an interactive tool to explore the dns

hierarchy– deprecated

Equivalent on some systems is “dig”, "host"

Example DNS Lookup

% host www.google.comwww.google.com is an alias for www.google.akadns.net.www.google.akadns.net has address 64.233.167.104www.google.akadns.net has address 64.233.167.99

Note how a DNS name may resolve as several different IP addresses

DNS Is Not Bidirectionally Equivalent

% host www.purdue.eduwww.purdue.edu has address 128.210.11.200% host 128.210.11.200200.11.210.128.in-addr.arpa domain name pointer mortar.cc.purdue.edu.

A different tree is used for IP to host name queries!– Not as well-maintained (usually)– Note the "IN-ADDR.ARPA" domain

Domain name for IP address lookup RFC 1035 Section 3.5

– Note the IP address was reversed– Who controls the data?

Zones and Domains

DNS servers are organized by zones DNS name has domains: domain1.domain2.com

– ".com" is a "top-level domain"

What is the relationship between zones and domains?– A zone may include subdomains

Fancy way to say that a server will authoritatively answer queries for specified subdomains as well

Who Controls Data in "IN-ADDR.ARPA"?

Hierarchical distributed database– Data in different zones

Example query to find out for 128.10.0.0:– "dig 0.0.10.128.IN-ADDR.ARPA PTR IN"

– ";; ANSWER SECTION:

0.0.10.128.IN-ADDR.ARPA. 86400 IN PTR purdue-cs-

en.cs.purdue.edu."

– ";; AUTHORITY SECTION:

10.128.IN-ADDR.ARPA. 43269 IN NS

harbor.ecn.purdue.edu.

10.128.IN-ADDR.ARPA. 43269 IN NS

pendragon.cs.purdue.edu.

10.128.IN-ADDR.ARPA. 43269 IN NS ns.purdue.edu.

10.128.IN-ADDR.ARPA. 43269 IN NS moe.rice.edu.

10.128.IN-ADDR.ARPA. 43269 IN NS ns2.purdue.edu."

Host Name Lookups From IP

Conclusion:– The returned host name is under the control of the zone

where the host with that IP address is located

Scenario:– Name-based authentication mechanism (.rhosts, rlogin,

etc...)– Attacker controls the remote zone

Says 128.10.242.11 is "innocent.victim.com"

– Victim's DNS trusts remote zone server "innocent.victim.com" is within "victim.com" so access is

allowed– Ref.: Bellovin 1995 "Using the Domain Name System for

System Break-Ins"

Fix Attempt

Do two lookups, using both trees, and refuse access if names are inconsistent

Example:– Let's say host "resources.benign.org" allows access

from "*.benign.org" Possible attack:

– It would be suspicious if "resources.benign.org" received a request from 198.210.35.192, whose DNS records pointed to "www.benign.org" but no DNS entry for "www.benign.org" included 198.210.35.192

DNS API

a.k.a. "resolver" OS support– Handles DNS transparently for application

gethostbyname returns the IP address gethostbyaddr returns the host name

– same names on Windows

Same function names for PHP, .NET, etc... Handling of results is opportunity for buffer

overflows There could be a malicious (or compromised,

poisoned) DNS server in the chain

Resolver Attacks

Host resolvers have caches for efficiency– e.g., "ns.purdue.edu. 6619 IN A 128.210.11.5"

Caches may be poisoned First Attack:

UDP packets with spoofed source IP address, pretending to come from the authoritative server Especially combined with a DoS attack on the server

DNS uses query numbers to keep track of requests DNS cache poisoning via BIND by predictable query IDs.

– CVE-1999-0024

Send UDP packet with the IP-domain pair you want the client or server to think is correct, with sniffed or guessed query ID

Additional Cache Poisoning Attacks

With DNS replies: Spurious (malicious) record returned in answer to another

query In addition to requested information

Malicious record returned as a normal part some answer Get Alice to query Malory's DNS server somehow (web bug,

link, etc...)

With DNS queries: Malory sends a query that contains a spurious reply;

Alice’s server believes it and caches it No need to trick Alice Similar to ARP poisoning and gratuitous ARP replies (replies

without receiver having sent a request)

Conclusion

You can't authenticate based on host names– You can't rely on DNS as per the original RFCs

DNS is more vulnerable if hosted outside your network– Some attacks (IP spoofing) prevented by ingress filtering

Don't accept packets from outside, pretending to originate from inside the network

Except if DNS server is hosted outside the network!– No defense then

DNS Masters and Slaves

a.k.a. Primary and secondary servers Two kinds of DNS servers for:

– Load sharing– Redundancy

How do you keep slaves up-to-date?

Zone Transfers

Get RRs (list of host-IP address pairs) for the zone Uses TCP for reliability Used by slaves to query master for information

– Polling mechanism (e.g., every 15 minutes)

Example:– "dig -t AXFR vulnerable.com > zone.txt"

Attacks on Zone Transfer

• Lower protocol vulnerabilities can be exploited to load desired information into secondary servers/slaves1. TCP session hijacking

2. ARP poisoning (if on same network segment)

3. VLAN attacks

• Desirable recon information (attacker requests zone transfer to own machine)– Should restrict it with IP address restrictions

Not critical, but an exposure nonetheless This is blocked from outside Symantec or CERIAS

DNS Notify

Notification to slaves/secondary servers when zone changes occur– RFC 1996– Uses UDP or TCP

All servers getting the notice:– Acknowledge the notice– Check with the server that the new zone version ("SOA

RR") is indeed more recent than theirs– If so, initiate zone transfers

Attack on DNS Notify

With a UDP packet, a notice can be sent– Other packet to tell slave the new version number ("SOA

RR")

Zone transfer still uses TCP Lower protocol vulnerabilities can then be exploited

to load desired information into secondary servers/slaves– TCP session hijacking– ARP poisoning (if on same network segment)– VLAN attacks

As previous attacks, but now the timing can be controlled by the attacker thanks to notify function

Other DNS Attacks

Administrative attacks against registrar (see Domain Hijacking: A step-by-step guide, akin to social engineering attacks)

SSL as a Defense

Server has matched private and public keys Public key along with the domain name (e.g.,

cerias.purdue.edu) is signed by a certificate authority (Verisign, Thawte); this is the SSL certificate– The signature is verified by using the CA's public key– Every browser has the public keys for CAs

You know that you are talking to the correct web server, and that the DNS system was not corrupted, because only that server knows its own private key, and the server’s private key is necessary for the encryption.

Question

Which access control rule is preferable?

a) allow from 128.10.240.0/20b) allow from cerias.purdue.educ) allow from all

Question

Which access control rule is preferable?

a) allow from 128.10.240.0/20b) allow from cerias.purdue.educ) allow from all

Discussion

Which DNS problems would you try to fix first?

a) Authentication of serversb) Complexity of the protocolc) Implementation errorsd) Integrity of the datae) Availability of the servers

Discussion

Which DNS problems would you try to fix first? a) Authentication of servers

– UDP allows IP spoofing and injection of malicious data

b) Complexity of the protocolc) Implementation errorsd) Integrity of the data– Cryptographic mechanisms for integrity also provide

authenticity (e.g., signatures)

e) Availability of the servers• Important, which is why there is a redundant server

architecture

Question

Why should you consider SSL in your next client-server program?

a) it’s faster b) it replaces DNS c) it guarantees that you are talking to who you

should be d) it provides reliability and guarantees that the

DNS system hasn’t been corrupted

Question

Why should you consider SSL in your next client-server program?

a) it’s faster b) it replaces DNS c) it guarantees that you are talking to who you

should be d) it provides reliability and guarantees that the

DNS system hasn’t been corrupted

Mini-Lab

Explore DNS– Can you get a zone transfer?– Do you understand the various types of records?

Hint: "IN" stands for "internet"– DNS can store information about lots of things

– How much information can you get? Are there exposures?

– Why do some DNS names have dots at the end? e.g., "www.benign.com."

– Hint: think about relative vs absolute paths

– Suggested time: 15-20 minutes

NIS (Network Information Services)

SUN technology "NIS clients download the necessary username and

password data from the NIS server to verify each user login"– How much can you trust the client?

Doesn't encrypt the username/password information sent to the clients with each login

All users have access to the encrypted passwords stored on the NIS server– Crack at leisure

NIS+

Completely different from NIS More secure Domain namespace Credentials checked every time a NIS+ object is

accessed– DES credentials must be generated by an administrator

for each "principal" A principal is a user or a machine (process with root

privilege)– Client machines (processes) are authenticated

More difficult to manage

NetBIOS

Network Basic Input/Output System– Session level protocol

NetBIOS over TCP– For the purposes of this tutorial, we consider it at the

same level as DNS– Used almost exclusively by Windows– Major worm propagation vector

Three services:– NetBIOS Name service– NetBIOS Datagram service– NetBIOS Session service

NetBIOS Name Service

NetBIOS name identifies computer for file sharing and domain authentications

UDP port 137 Name resolution in a network segment Map NetBIOS names to IP addresses

NetBIOS Names

Domain names Computer names User names Workgroup names Special

– e.g., "\\–__MSBROWSE__"

Types of names– Unique– Group

Spoofing NetBIOS Names

nbtdeputy– http://www.securityfriday.com

Registers a NetBIOS computer name on the network

Responds to NetBT name-query requests Resolves IP address from NetBIOS computer name Legitimate use:

– Help access servers on different segments/networks

Hacker use:– Impersonate trusted server (while server is under DoS)

Collect usernames/passwords Distribute trojans

Other NetBIOS Issues

"Browser elections"– A malicious machine can be elected as "Browse Master"– Maintain list of "shares"

Shares (jargon)– Anything "shared" over NetBIOS

Disks Printers Hidden

– IPC$ (Inter-Process Communication)

– Malicious Browse Master could in theory: Intercept confidential documents when they get printed Fake trusted file systems so people use trojans or save their

confidential documents there etc...

Access Control for Shares

Active Directory can specify mechanism Authentication mechanisms

– Kerberos (requires infrastructure support)– LM (old, insecure)– NTLM

drops back to LM in some occasions Cryptanalyzed, has exploitable weaknesses

– Schneier and Mudge 1998 "Cryptanalysis of Microsoft's Point-to-PointTunneling Protocol (PPTP)"

– Exploit by Urity (2004), securityfriday.com– NULL sessions (no passwords)

Guests etc...

Listing Account Names

Anonymous users (NULL sessions) can:– List domain user names– Enumerate share names

Exposure Prevention

– Set the registry RestrictAnonymous to 1 Still permits a remote anonymous logged in user to call the

function NetUserGetInfo– Acquire detailed account information

Exploit: "GetAcct" (www.securityfriday.com)

– RestrictNullSessAccess to 2– Can be set through the LSA (Local Security Policy)

XP, 2000

Worms Exploiting "Weak Shares"

"Share level access" for the File and Print Sharing service (TCP port 139)

Passwords in Windows 95/98/ME are easily retrieved– Normally, if a password has N characters, and each

character has 64 possible values, then the password space is 64^N

– Windows password characters can be guessed one at a time, so the space is 64*N instead Because the server assumes that the length of the password

sent from the client is correct

– References Tereman (2000) securityfriday.com Microsoft Security Bulletin (MS00-072)

Recon Tools

nbtdump.exe, winnbtdump.exe– dumps NetBIOS information from Windows NT, Windows

2000 and *NIX Samba servers such as shares, user accounts with comments, etc, and the password policy

Note that port 445 also provides direct access to NetBIOS– Attacks against port 139 can also use port 445– Windows 2000 and later

References

RFC 1001, 1002 Northrup 1998 "NetBIOS: Friend or Foe?"

– http://www.windowsitlibrary.com/Content/386/10/1.html "NetBIOS is highly vulnerable but we must live with it for

some time"

Mini-Lab (20 minutes)

Use the Nessus vulnerability scanner to find NetBIOS issues on the class server– Right-click the desktop

Under "vulnerability assessment", select "Nessus"– That will start the Nessus daemon– Note the user name and password

Login to the Nessus client window Tab for tests

– Unselect all the tests (button)– Select the Windows tests

Tab for machines to be scanned– Enter the IP address of Windows server

Start the scan Click on the network icon and computer in the results

Discussion

Can the server be compromised through NetBIOS?– By guessing the administrator password, Nessus can

access the registry remotely to scan for vulnerabilities Disable remote registry access Choose a good administrator password

– Win 95/98/ME should disable NetBIOS or install a firewall

What else could an attacker do? What would you do to secure the server?

– Are the NetBIOS services needed?

Remote Procedure Calls

Sun's rpc Microsoft's RPC 92 entries in ICAT ("rpc") as of May 2004 Example:

– saned in sane-backends 1.0.7 and earlier does not check the IP address of the connecting host during the SANE_NET_INIT RPC call, which allows remote attackers to use that call even if they are restricted in saned.conf. CAN-2003-0773

– And we know how insecure IP-based restriction can be anyway!

RPC

Use Port 111 (TCP and UDP) "portmapper" to know on which port services are provided (port 135 on Windows)– NIS– NFS– mount– sadmin– etc...

Utility: rpcinfo Exposure if accessible from the internet Most of these services are not needed from the

internet and contain vulnerabilities and exposures

DCOM (Microsoft)

Runs on top of Microsoft RPC– Allows writing distributed applications

Remotely control software components with account name and password– e.g., Internet Explorer

Exploit: "IE'en" ("Soap" securityfriday.com)– capture user ID and password in plain text, even on SSL

sites

NFS: Network File System

Root on a client machine could be trusted as root on the server!– Remote user ID is trusted as correct– use the root_squash option in exports

Replaces "root" with "nobody" On by default in RedHat 9+

Root on a client machine can assume the identity of any other user (su) and change that user's files– Solution: Share ("export") only directories where

everything belongs to root (with the above squash option)– other squash options available

Setuid programs: blocked by "nosuid" option

Additional Reference

http://www2.educ.umu.se/~bjorn/linux/howto/NFS-HOWTO-6.html

Questions or Comments?

About These Slides

You are free to copy, distribute, display, and perform the work; and to

make derivative works, under the following conditions.

– You must give the original author and other contributors credit

– The work will be used for personal or non-commercial educational uses

only, and not for commercial activities and purposes

– For any reuse or distribution, you must make clear to others the terms of

use for this work

– Derivative works must retain and be subject to the same conditions, and

contain a note identifying the new contributor(s) and date of modification

– For other uses please contact the Purdue Office of Technology

Commercialization.

Developed thanks to the support of Symantec Corporation

Pascal Meunierpmeunier@purdue.eduContributors:Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera