Byzantine fault tolerance summary (why 3f+1?) Some possibly network protocols relevant to network security * telnet - server listens on TCP port 23 - Usually requires passwords to be sent over the net in the clear - Can avoid sending pwd with s/key - Many old telnet servers had remotely exploitable bugs * ftp - Listens on TCP port 21 - Old protocol requires server to connect back to client * ssh - Listens on TCP port 22 - On by default in many OSes; has had remotely exploitable holes * BSD rlogin/rsh services - TCP ports 513 & 514 - Use hostname/IP address in ~/.rhosts for authentication * ntp (Network time protocol) - Request & reply use UDP port 123 - Many Old versions have remotely exploitable bugs * dns - Listens on TCP and UDP ports 53 - Most requests UDP packets from and to port 53 * RIP - src/dst port UDP 520 - Lets you change a host's routing table * RPC-based services (YP/NIS and NFS) - Listen on a different port each time they are run - portmap service on TCP & UDP port 111 maps RPC program to port - Many RPC progs should not be accessible to outsiders - NFS at least always uses TCP&UDP 2049 - NFS basses access control on IP address to some extent * X-windows - TCP port 6000 - Users can run "xhost +", letting anyone see their screen & typing * ICMP echo request/reply, time exceeded, host/port unreachable - Mostly harmless - Ping of death could crash Linux boxes with over-large ICMP * ICMP redirect - Changes a host's routing table * IP fragments - Maybe can't tell what in them without reassembling - Teardrop attack crashes windows with overlapping fragments * IP options - Some harmless, some (e.g., source routing) very dangerous Packet sniffing attacks Compromise host, run sniffer Get passwords, NFS file handles, etc. You can often break into an account with a forged TCP connection Suppose ~user/.rhosts has "client user" in it Forge rsh connection to look like it's from reserved port on client Issue "echo badhost baduser >> ~/.rhosts" command Don't even need to read reply -- can then use a real TCP connection How might you find out what IP address and username to forge? Find someone's email address in an archive Message has client IP address and mail server IP address Maybe the person can rlogin to his/her mail server w/o a password A variety of protocols offer a lot of information on hosts Finger often tells you who's logged in from where SNMP can sometimes list open connections (including to rlogin port) Infer structure of the network from the DNS E.g., hosts cluster1, cluster2, ..., clusterN might trust each other DNS attack Basic structure of DNS: A zone is a portion of the namespace run by one administrative unit E.g., nyu.edu, cs.nyu.edu, edu, com, and "." 9the root domain) The data for each zone consists of a set of resrouce records A records map hostnames (www.nyu.edu) to IP addresses 128.122.108.9 NS records give you nameservers for subdomain zones PTR records map IP addresses to names Each zone has a number of authoritative servers Typically one primary, several secondary which copy data from primary How to map a name like "www.nyu.edu" to an address? Must retrieve an address (type A) resource record from appropriate server Ask root server Doesn't know, but tells you about server for edu, ... which tells you about server for nyu.edu, which tells you www Obviously relies on extensive caching (can't overload root servers) How does edu server tell you about name servers for nyu.edu? nyu.edu. NS CMCL2.nyu.edu. There's a chicken and egg problem. How to get addr of CMCL2.nyu.edu? So edu server must return additional "glue" records in nyu.edu zone: CMCL2.nyu.edu. A 128.122.253.92 Client nameserver adds those glue records into its cache How does an rlogin server find the name of connecting client If client is connecting from 1.2.3.4, server must query 4.3.2.1.in-addr.arpa PTR Again will query recursively, starting possibly from the root Eventually server for 3.2.1.in-addr.arpa zone replies: 4.3.2.1.in-addr.arpa PTR www.nyu.edu Can we trust the contents of PTR anser? No, network could belong to attacker, attacker can claim to be anyone What if we then lookup A record for www.nyu.edu to verify? It's better, but still not secure. Consider the following PTR reply: 4.3.2.1.in-addr.arpa NS www.nyu.edu www.nyu.edu A 1.2.3.4 This says client must contact DNS server www.nyu.edu to get PTR record Glue record gives www.nyu.edu address as attacker's machine Client inserts this record into its cache, and then queries 1.2.3.4 4.3.2.1.in-addr.arpa PTR www.nyu.edu Same IP->name mapping, but now name->IP check will succeed from cache How might you solve the DNS attack problem? Many obvious solutions would decrease cache hit rates, overwhelm root servers The Morris TCP attack Now suppose instead of DNS name, you wanted to forge IP address in TCP Suppose you can't eavesdrop on network, but you can forge packets (very realistic) Recall TCP connection setup And rules for ACKing (must ACK seqno of next expected byte) You could send SYN, not get SYN-ACK, but then send ACK with data anyway Data could be 'echo + + >> ~/.rhosts' ==> after which you can log in Problem 1: How do you know what initial sequence # to ACK in data packet Used to be very predictable: increment by 128 each sec, 64 each conn. So just connect to victim server, and figure out next ISN from current Problem 2: Real host may send RST to unexpected SYN-ACK Say client whose IP address you are forging is running a server E.g., telnet server on port 23 You can overwhelm port 23 with SYN packets until it ignores them It will likewise ignore the victim server's SYN-ACK packet The Joncheray active attack against TCP Now suppose you can eavesdrop between client and server Now, want to tamper with existing TCP connections Stonger attack: E.g., can hijack a connection authenticated with s/key Recall that in TCP each side has a flow-control WINDOW of sequence numbers One side can packets for up to WINDOW bytes in parallel before getting ACK (assuming congestion control allows) What is a *desynchronized state* of TCP No data in transit, but SVR_SEQ != CLT_ACK and CLT_SEQ != SVR_ACK Two cases: 1. CLT_SEQ < SVR_ACK + SVR_WIND and CLT_SEQ > SVR_ACK I.e., client skipped some bytes, but next pkt will be in window 2. CLT_SEQ > SVR_ACK + SVR_WIND or CLT_SEQ < SVR_ACK Any packets sent by client will be lost How can we desynchronize a TCP connection? Early desynchronization Client connects to server Attacker sends RST to server Attacker sends SYN to server forged to be from client Now server will have connection with same ports, different SVR_ACK Null data desynchronization Attacker generates a lot of data that will be ignored by the application E.g., NOP operation in telnet does nothing Sends this NULL both to client and to server Drives up CLT_ACK and SVR_ACK so they are no longer in range How to exploit desynchronized TCP connection? Attacker send arbitrary data in either direction Client and server may send each other data, but those packets will not affect the state of the other party's TCP What is an ACK storm? Why do we get these? Unfortunately, each side will send an ACK in response to any bogus ACK That ACK in turn will generate an ACK Ping-pong will continue until a packet is lost Fortunately, no retransmit as long as ACK pkt didn't contain data Packet filtering Nice properties: Keep as little state as possible Can statelessly block any incoming TCP connections Filter any incoming packet with SYN but not ACK bit set What about UDP, ICMP, and fragments? UDP can block most, but want protocols like NTP and DNS to get out Can use a stateful firewall E.g., allow UDP back only if in response to request ICMP on case-by-case basis Host/net unreachable probably fine Redirect never Echo reply maybe