Transcript 4.DNS_RPC_NFS

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




Remote Procedure Calls




DNS
NIS
NetBios (and friends)
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






Domain Hijacking: A step-by-step guide


“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)
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


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



Well-known implementation: BIND
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.com
www.google.com is an alias for
www.google.akadns.net.
www.google.akadns.net has address
64.233.167.104
www.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.edu
www.purdue.edu has address 128.210.11.200
% host 128.210.11.200
200.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 "INADDR.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-csen.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



gethostbyname returns the IP address
gethostbyaddr returns the host name




Handles DNS transparently for application
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/slaves
1. 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



Zone transfer still uses TCP
Lower protocol vulnerabilities can then be
exploited to load desired information into
secondary servers/slaves




Other packet to tell slave the new version number ("SOA
RR")
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/20
b) allow from cerias.purdue.edu
c) allow from all
Question

Which access control rule is preferable?
a) allow from 128.10.240.0/20
b) allow from cerias.purdue.edu
c) allow from all
Discussion

Which DNS problems would you try to fix first?
a) Authentication of servers
b) Complexity of the protocol
c) Implementation errors
d) Integrity of the data
e) Availability of the servers
Discussion


Which DNS problems would you try to fix first?
a) Authentication of servers


b) Complexity of the protocol
c) Implementation errors
d) Integrity of the data


UDP allows IP spoofing and injection of malicious 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 clientserver 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 clientserver 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


NetBIOS over TCP




Session level protocol
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





Registers a NetBIOS computer name on the
network
Responds to NetBT name-query requests
Resolves IP address from NetBIOS computer
name
Legitimate use:


http://www.securityfriday.com
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.htm
l
 "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


Remotely control software components with
account name and password


Allows writing distributed applications
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!



Root on a client machine can assume the identity
of any other user (su) and change that user's
files



Remote user ID is trusted as correct
use the root_squash option in exports
 Replaces "root" with "nobody"
 On by default in RedHat 9+
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/N
FS-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