Presentation is loading. Please wait.

Presentation is loading. Please wait.

Network Security: Protocol Analysis, Firewalls Tuomas Aura.

Similar presentations


Presentation on theme: "Network Security: Protocol Analysis, Firewalls Tuomas Aura."— Presentation transcript:

1 Network Security: Protocol Analysis, Firewalls Tuomas Aura

2 Protocol analysis: Classic key-exchange protocols and flaws

3 3 Needham-Schroeder secret-key protocol The first secret-key key-exchange protocol 1978 Kerberos is based on this protocol Trusted server T shares a secret master key with everyone. Encrypts a ticket and session key with master keys: 1. A → T: A, B, N A1 2. T → A: E TA (N A1, B, K ses, ticket AB ) 3. A → B: ticket AB, E ses (N A2 ) 4. B → A: E ses (N A2 -1, N B ) 5. A → B: E ses (N B -1) K TA, K TB = A’s and B’s master keys K ses = session key selected by T ticket AB = E K TB (K ses,A) Encryption mode assumed to protect integrity. Nowadays, we would use standard MACs but they did not exist in the 70s. For example: E K (M) = AES-CBC K (M, HMAC-SHA-1 K (M))

4 4 Needham-Schroeder analysis The protocol again: 1. A → T: A, B, N A1 2. T → A: E TA (N A1, B, K ses, ticket AB )// ticket AB = E TB (K ses,A) 3. A → B: ticket AB, E Kses (N A2 ) 4. B → A: E Kses (N A2 -1, N B ) 5. A → B: E Kses (N B -1) T encrypts session key under A’s and B’s master keys Authenticators for key confirmation N A1 guarantees freshness of ticket and session key to A N A2 and N B guarantee freshness of authenticators to A and B But no freshness of the ticket to B…

5 5 Needham-Schroeder vulnerability The protocol again: 1. A → T: A, B, N A0 2. T → A: E TA (N A0, B, K ses, ticket AB )// ticket AB = E TB (K ses,A) 3. A → B: ticket AB, E Kses (N A ) 4. B → A: E Kses (N A -1, N B ) 5. A → B: E Kses (N B -1) Vulnerability discovered by Denning and Sacco 1981 Freshness of the ticket not guaranteed to B Assume attacker compromises an old session key and has sniffed the corresponding ticket, or Assume attacker compromises A’s master key K TA. A’s master key is replaced but, before that, the attacker manages to obtain a ticket for B Replay attack by C who knows an old session key: 3’. C(A) → B: ticket AB-old, E K AB-old (N A ) // ticket AB-old = E K TB-old (K AB-old,A) 4’. B → C(A): E K AB-old (N A -1, N B ) 5’. C(A) → B: E K AB-old (N B -1) How to fix?

6 6 Denning-Sacco protocol Public-key key exchange 1981; flaw found in 1994 A obtains certificates from trusted server T for both A’s and B’s public keys 1. A → T: A, B 2. T → A: Cert A, Cert B 3. A → B: E B (T A, K ses, S A (T A, K ses )), Cert A, Cert B K ses = session key selected by A Cert A = A, PK A, S T (A, PK A ) Analysis: Expiration time missing from certificates → need to be added! Public-key encryption for secrecy of K AB → ok Public-key signature for authenticity of K AB → but what exactly is authenticated? Time stamp for freshness of session key → what about quick replays?

7 7 Denning-Sacco vulnerability The protocol again: 1. A → T: A, B 2. T → A: Cert A, Cert B 3. A → B: E B (T A, K ses, S A (T A, K ses )), Cert A, Cert B The signed message S A (T A, K AB ) does not contain all possible information. Q: What is missing? A: The signed message is not bound to the identity of B Q: Does it matter when only B can decrypt the message? A: B could be bad! → B can forward the last message to anyone else e.g. to C: 3’. B(A) → C: E C (T A, K AB, S A (T A, K AB )), Cert A, Cert C C thinks it shares K ses with A but it is really shared with B Legitimate user B can impersonate legitimate users → insider attack How to fix?

8 8 Needham-Schroeder public-key protocol The first public-key key-exchange protocol 1978; flaw found in 1995 [Lowe95] A and B know each other’s public encryption keys or obtain certificates from a trusted server T as needed A and B exchange key material: 1. A → B: E B (N A, A) 2. B → A: E A (N A, N B ) 3. A → B: E B (N B ) N A, N B = secret nonces K ses = h(N A, N B ) Analysis: Session key secret and fresh, entity authentication ok Session key not bound to A

9 9 Needham-Schroeder public-key vulnerablity The protocol again: 1. A → B: E B (N A, A) 2. B → A: E A (N A, N B ) 3. A → B: E B (N B ) K ses = h(N A, N B ) A authenticates to C. C can forward the authentication of A to B: 1.A → C:E C (N A, A) 1’.C(A) → B:E B (N A, A)// Re-encrypt for B 2’./2.B → A:E A (N A, N B )// Allow through 3.A → C:E C (N B ) 3’.C(A) → C:E B (N B ) // Re-encrypt for B C thinks it shares K ses with A but also B knows it (for A, everything is ok… in a way) Insider attack: legitimate user B impersonates another user A How to fix? Hint: what could be added to each message? Does it help?

10 10 Wide-mouth-frog protocol Toy protocol but interesting A and B share secret master keys with trusted server T. T delivers session keys: 1. A → T: A, E K TA (T A, B, K ses ) 2. T → B: E K TB (T T, A, K ses ) K TA, K TB = A’s and B’s master keys shared with T T A, T T = time stamps K ses = session key selected by A Analysis: Encryption must protect integrity → implement with a MAC Otherwise, looks pretty good… but there is a subtle issue with the time stamps

11 11 Wide-mouth-frog protocol The protocol again: 1. A → T: A, E TA (T A, B, K ses ) 2. T → B: E TB (T T, A, K ses ) K TA, K TB = A’s and B’s master keys shared with T T A, T B = time stamps K ses = session key selected by A Attack: 1. A → T:A, E TA (T A, B, K ses ) 2.T → B:E TB (T T, A, K ses ) 1. C(B) → T:B, E TB (T T, A, K ses ) 2.T → C(A):E TA (T T2, B, K ses ) 1. C(A) → T:A, E TA (T T2, B, K ses ) 2.T → C(B):E TB (T T3, A, K ses ) 1. C(A) → T:B, E TB (T T3, A, K ses ) 2.T → C(B):E TA (T T4, B, K ses ) ……………… Attacker can keep the session key alive for ever Problem: authenticated messages 1 and 2 can be confused with each other How to fix? Add type tags (e.g. “WMF Msg 1”, “WMF Msg 2”) to make the meaning of messages unambiguous

12 12 What is a protocol flaw? Researchers like to present spectacular attacks and flaws but the reality is often less black and white Limitation on the applicability of the protocol: Do insider attacks matter? Multiple parallel executions by the same principal? Is the protocol used for its original purpose or for something different? Requirements for implementations: Encryption mode in old protocols must protect integrity (include a MAC or use non-malleable encryption) Signed and MAC’d messages must include type tags and be parsed unambiguously New requirements arise over time: Man-in-the-middle attacks DoS protections? Identity protection? Has the protocol become the weakest link after improvements to other parts of the system?

13 Advanced protocol properties 13

14 14 Station-to-station (STS) protocol Variation of the original STS Signed ephemeral Diffie-Hellman: 1. A → B: g, p, g x 2. B → A: g y, E K ses (g y, g, p, g x, S B (g y, g, p, g x ), Cert B ) 3. A → B: E K ses (g, p, g x, g y, S A (g, p, g x, g y ), Cert A ) K ses = h(g xy ) What could be wrong? What does the encryption E K (…) achieve? No known flaws (and STS has been well analyzed) Encryption with the DH session key → identity protection Why does it need to be ephemeral DH?

15 15 Modified STS Add a cookie exchange: 1. A → B: N A 2. B → A: N A, N B 3. A → B: N A, N B, g, p, g x 4. B → A: g y, E K (g y, g, p, g x, S B (g y, g, p, g x )), Cert B 5. A → B: E K (g, p, g x, g y, S A (g, p, g x, g y )), Cert A K = h(g xy ) What does this modification achieve? Responder B verifies A’s IP address before the DH computation → prevents CPU-exhaustion attacks with a spoofed attacker IP address Even better: make B stateless between messages 2 and 3: N B = h(A,B,N A,N B-periodic ) where N B-periodic changes every minute What is the cost of this defence? Is it worth it?

16 Tools for protocol analysis

17 17 Dolev-Yao model Standard model for protocol analysis: Network is the attacker. Honest nodes send messages to the network and receive messages from the network Honest nodes are simple reactive state machines: Honest nodes initiate protocol runs, respond to received messages, and move from state to state Honest nodes can execute multiple protocol runs in parallel: unlimited parallel instances of the state machine Honest nodes do not reveal their secrets Attacker plays a game: Attacker has some initial knowledge, such as public data, the secrets of several conspiring nodes, and old session keys Attacker can receive initial messages from honest participants Attacker’s knowledge grows from each received message Attacker can perform message decomposition, composition, and cryptographic operations — but only if it know the necessary keys Attacker can send messages to honest participants to trigger response and state change, and to increase its knowledge Attacker tries to reach an unsafe state where some security goal is broken Unsafe states defined based on attacker’s knowledge and honest nodes’ state, e.g. A thinks it shares K ses with B, and the attacker know K ses

18 Protocol analysis tools Examples of tools for verification of cryptographic protocols: Proverif — Bruno Blanchet (ENS, Paris) Horn clauses and Applied Pi calculus Constraint Solver — John Millen (SRI) and Ricardo Corin (INRIA-MSR) Prolog, CAPSL language for protocol specification Isabelle theorem prover — Larry Paulson (Cambridge) Lambda calculus, high-order logic (HOL) Murphi — Stanford/Utah Practically every formal analysis method has been tried

19 19 Proverif example Demo of protocol modelling with Proverif Proverif models are usually written in Pi calculus, which is easier for a programmer We use Horn clauses — closer to the Dolev-Yao model Recall the Needham-Schroeder public-key protocol: 1. A → B: E B (N A, A) 2. B → A: E A (N A, N B ) 3. A → B: E B (N B ) N A, N B = secret nonces K ses = h(N A, N B ) Dolev-Yao model: Network = attacker Honest parties are simple reactive state machines Attacker’s knowledge set grows over time Security proof in Proverif is sound Sound security proof = complete algorithm for finding all attacks Approximations → may sometimes find attacks that are not real

20 20 Function and symbol definitions Public-key encryption: fun encrypt/3.encrypt(tag, msg, pk) = E pk (msg) Nonces: fun Na/3.Na(x,y,s) = x's nonce for y in the role of A fun Nb/3.Nb(x,y,t) = y's nonce for x in the role of B fun Nc/1.Nc(u) = Attacker's nonce Type tags for messages (could also leave out and find more problems): fun Msg1/0. fun Msg2/0. fun Msg3/0. Host and their states: fun H/1.Honest host H(i) fun C/1.Corrupt host C(i) fun stateA/3.stateA(A,B,N A ) = state in role A after sending Msg 1 fun stateB/4.stateB(A,B,N A,N B ) = state in role B after sending Msg 2 fun acceptKeyA/4.acceptKeyA(A,B,N A,N B ) = final state in role A fun acceptKeyB/4.acceptKeyB(A,B,N A,N B ) = final state in role B

21 21 Attacker’s capabilities Create principals, either honest or corrupt: c:H(i); c:C(i); Attacker knows the message tags: c:Msg1; c:Msg2; c:Msg3; Attacker may generate new nonces (not actually needed): c:Nc(u); Attacker's cryptographic computation: c:encrypt(tag, x, C(i)) -> c:x; c:tag & c:x & c:h -> c:encrypt(tag, x, h); c:tag & c:x & c:y & c:h -> c:encrypt(tag, (x,y), h); Note: “c:” is a predicate meaning “attacker knows”

22 22 Honest principals’ behavior Role A: c:H(i) → c:(stateA(H(i),b,Na(H(i),b,s)), encrypt(Msg1, (Na(H(i),b,s),H(i)), b)); c:stateA(H(i),b,na) & c:encrypt(Msg2, (na,nb), H(i)) → c:(acceptKeyA(H(i),b,na,nb), encrypt(Msg3, nb, b)); Role B: c:encrypt(Msg1, (na,a), H(j)) → c:(stateB(a,H(j),na,Nb(a,H(j),t)), encrypt(Msg2, (na, Nb(a,H(j),t)), a)); c:stateB(a,H(j),na,nb) & c:encrypt(Msg3, nb, H(j)) → c:acceptKeyB(a,H(j),na,nb); Modelling state as attacker’s knowledge → attacker can go back to old states of the honest participants. Why is this a sound approximation? 1. A → B: E B (N A, A) 2. B → A: E A (N A, N B ) 3. A → B: E B (N B ) K ses = h(N A, N B ) 1. A → B: E B (N A, A) 2. B → A: E A (N A, N B ) 3. A → B: E B (N B ) K ses = h(N A, N B )

23 23 Defining attack Attacker knows the session key between honest principals: c:acceptKeyA(H(i),H(j),na,nb) & c:na & c:nb -> c:attack; c:acceptKeyB(H(i),H(j),na,nb) & c:na & c:nb -> c:attack. If the attacker knows only one of the nonces, is that an attack?

24 24 Results Proverif can prove c:attack → protocol is not secure Manually beautified Proverif counterexample: encrypt(Msg3,NB,B) encrypt(Msg3,NB,C)) encrypt(Msg2,(NA,NB),A) encrypt(Msg1,(NA,A),B) encrypt(Msg1,(NA,A),C) Selected messages only; renamed principals and nonces read from bottom up Fixed protocol — add B’s name to Msg 2: 2. B → A: E A (N A, N B, B) Proverif output: RESULT goal unreachable: c:attack()

25 25 Exercises How to attack the Needham-Schroeder secret-key protocol if the encryption is no integrity-protecting, e.g. E K (M) = AES-ECB K (M) ? Read about the Yahalom and Otway-Rees protocols. Can you find any flaws by yourself? Model the Needham-Schroeder shared-key protocol in Proverif How would you model identity or DoS protections with a tool like Proverif? (This is a difficult question.)

26 Firewalls: Stateless packet filter 26

27 Intranet /24 27 Firewall Perimeter defence: Divide the world into the good/safe inside (intranet) and bad/dangerous outside (Internet) Prevent anything bad from entering the inside Block communication that is evil, risky or just unnecessary Internet

28 28 IPv4 and TCP headers Which field should a firewall use for filtering? (TCP flags: CWR ECE URG ACK PSH RST SYN)

29 29 Stateless packet filter Allow or block IP packets based on their IP header fields and TCP/UDP port numbers Fields with static locations in most IP packets: protocol (TCP/UDP/ICMP), source and destination IP address, source and destination port, TCP flags, ICMP type and code Packet filter is defined as a rule table Linear list of rules Each rule consist of conditions and an action For each packet, the first matching rule is found Two possible actions: allow (=accept, permit, bypass) or block (=drop, deny, discard), maybe also allow and log or block and log

30 30 Packet filter example (1) Example rule table: inbound to our SMTP server ProtocolSrc IPSrc portDst IPDst portActionComment TCP * BlockStop this spammer TCP** AllowInbound SMTP TCP **AllowSMTP responses *****BlockDefault rule

31 31 Packet filter example (2) Allow web access from our subnet… not quite right! ProtocolSrc IPSrc portDst IPDst portActionComment TCP /24**80AllowOutbound HTTP requests TCP* /24*AllowHTTP responses *****BlockDefault rule Allow only outbound connections: ProtocolSrc IPSrc portDst IPDst portFlagsActionComment TCP /24**80AllowOutbound HTTP requests TCP* /24*ACKAllowHTTP responses *****BlockDefault rule (TCP packets, except the first SYN, have ACK flag set)

32 32 Packet filter example (3) University lab network /24 (address , netmask ) HTTP/Mail/DNS server ProtocolSrc IPSrc portDst IPDst portFlagsActionComment UDP***53AllowDNS queries in and out UDP*53**AllowDNS responses TCP * AllowDNS zone transfer TCP** AllowInbound SMTP TCP** AllowInbound HTTP TCP ***BlockBob’s test machine TCP** *BlockBob’s test machine TCP** /2422AllowInbound SSH TCP /24***AllowAll outbound TCP TCP** /24*ACKAllowAll TCP responses *****BlockDefault rule Is this correct? Could we limit inbound DNS queries to the server?

33 33 Router as packet filter Firewall rule table is similar to a routing table, with the option of dropping some packets Most routers can be used as a packet filter Choice of filters may affect router throughput Intranet /24 33 Internet interface1interface2

34 34 Ingress and egress filtering Filter packets with topologically incorrect (probably spoofed) source IP addresses Ingress filtering for local network: At the gateway router of a local network, drop inbound packets with source addresses that belong to the local network Egress filtering for local network: At the gateway router of a local network, drop outbound packets with non-local source addresses Ingress filtering for ISP: At the gateway router towards a customer, drop packets from the customer if the source address does not belong to the customer Egress filtering for ISP (less common): At the gateway router towards a customer, drop packets to the customer if the source address belongs to the customer

35 35 Anti-spoofing filter example Filter based on input interface (part of the policy shown only): 35 Intranet /24 35 Internet interface1interface2 Input interfaceProtocolSrc IPPortDst IPPortFlagsActionComment 2* /24***BlockIngress filter 2* ***BlockRouter address 1* ***BlockRouter address 1* /24***AllowEgress filter 1*****BlockDefault rule (If1) ……

36 Dynamic packet filter

37 37 Dynamic firewall Stateful filter: change filtering rules based on previously seen packets Outbound TCP or UDP packet creates a pinhole for inbound packets of the same connection Unlike stateless packet filter, can support UDP connections TCP pinhole closed with connection, UDP after eg. 30 min May also allow inbound ICMP messages that match outbound traffic Support for special protocols: FTP: firewall may sniff PORT command in FTP to open port for the inbound connections X Windows

38 38 Typical network topology (1) Services accessible from the Internet are isolated to a demilitarized zone (DMZ), i.e. somewhere between the intranet and Internet 38 Internet interface1interface2 Intranet /24 Public server (web, , DNS) interface

39 39 InputProtSrc IPPortDst IPPortOtherActionComment 2* /24***BlockAnti-spoofing 3* /24***BlockAnti-spoofing 2* /24***BlockAnti-spoofing 1* /24***BlockAnti-spoofing ** { , , } ***BlockAnti-spoofing (router addr) 2TCP** AllowAccess to server (HTTP) 2TCP** AllowAccess to server (HTTPS) 2TCP** AllowAccess to server (SMTP) 2UDP** AllowDNS query in and out 3UDP **53AllowDNS query in and out 1TCP /24* * Allow, create state Access to server from intranet 3TCP * /24*StateAllowResponses 1UDP /24* Allow, create state DNS query 3UDP /24*StateAllowDNS response 1* /24* /24*BlockUnnecessary 3* /24* /24*BlockUnnecessary 1* /24*** Allow, create state Outbound connections 2*****StateAllowResponses 1TCP /24* { , , } 80 Allow, create state Router management -TCP { , , } /24*StateAllowRouter management ******BlockDefault rule

40 40 Typical network topology (2) Two-firewall configuration for isolating publicly-accessible services from the Internet All inbound connections use ssh and go through a hardened bastion host in the DMZ 40 Internet Intranet /24 Public server (web, , DNS) interface interface interface2 FW router AFW router B interface1 Bastion host

41 Gateway Router / NAT 41 NAT IPv4 addresses are in short supply Native address translator (NAT) is a mechanisms for sharing one IPv4 address between multiple hosts Hosts behind NAT can only act as TCP or UDP clients Internet Internal IP addressesInternet addresses src= src port = src= src port =

42 42 NAT IPv4 addresses are in short supply Native address translator (NAT) is a mechanisms for sharing one IPv4 address between multiple hosts Hosts behind NAT can only act as TCP or UDP clients Gateway Router / NAT Internet Internal IP addressesInternet addresses dest= dest port = dest= dest port =

43 43 NAT as a firewall NAT maps internal pairs to external pairs and back NAT creates the mapping after seeing an outbound packet → a node on the intranet must initiate the connection→ NAT acts as a dynamic firewall NAT reference types: Full cone NAT: NAT doesn’t remember peer addresses Port-restricted cone NAT: NAT remembers peer IP address and port and filters inbound packets Symmetric NAT: different external port (and even address) depending the peer address and port Port-restricted and symmetric NATs function as firewalls Real NATs rarely implement exactly one of the one of the reference types, and often have additional firewall functionality

44 44 iptables Firewall implementation for Unix/Linux Complex policies can be defined as multiple chains of rules: Action can be a reference to another chain Provides modularity (“subroutines”) for firewall policies Example:

45 Transport and application- layer firewalls

46 46 Circuit-level proxy Transport-layer proxy as a firewall When an intranet client needs to connect to a server outside, it connects to the proxy instead Proxy terminates TCP and UDP connections. Creates a second connection to the server on the Internet Proxy is simpler than a host, easier to harden against attacks Proxy can filter and normalizes connections SOCKS management protocol between client and firewall Client requests new connections from firewall Authentication and authorization of client requests, e.g. GSSAPI Error messages to client Supported by most web browsers Firewall router can be set up to forward only some connections to the proxy for closer inspection

47 47 Application-level firewall Application-level firewall filters application data E.g. gateway, intercepting web proxy Need to implement the entire application protocol Telephone call blocking and barring vs. wiretapping Encrypted data cannot be filtered → what do you do? Are latest applications and features supported?

48 Firewall issues 48

49 49 Why filter outbound connections Security: Prevent people from accessing untrusted services or dangerous content Prevent compromised machines from spreading viruses to the Internet, phishing etc. Cost: Businesses and other organizations are charged by megabyte → block access to P2P, VoIP Productivity: How do employees spend their time? Liability: Does free Internet access by employees or visitors expose the company to legal risks?

50 50 Firewall traversal Network admins prefer to block traffic by default → New applications and protocols will not work New applications will not gain popularity if an administrative decision is needed at each site → application developers (and users) do their best to circumvent firewalls Web services over port 80, everything over port 443 Skype, Bittorrent etc. Question: Should all new network applications be standardized and get a port number from IANA, so that they can be filtered by the firewall?

51 51 Debugging firewall rules Firewall rules are difficult to configure Order of rules matters → fragile configurations Configuration language and its exact semantics and expressiveness vary between implementations Stateless packet filters have limited expressive power Performance depends on hardware Router may become slower when filtering is enabled, or when specific filters are deployed. What is processed in hardware? Redundancy may be a clue to errors, but not always: Rule is shadowed if another rule above it prevents it from ever being triggered. Is this intentional? Overlapping rules match some of the same packets. Do they specify the same action or different ones? In a network with multiple firewalls, do you want to block packets that are already blocked by another firewall?

52 52 Firewall limitations May prevent people from doing their work Try to convince a network admin to open a pinhole for your server Network admins are often reluctant to change firewall policies in case something breaks Makes network diagnostics harder Firewall configuration errors are common Coarse-grained filtering for efficient routing and administration Perimeter defence is ineffective in large networks There are always some compromised nodes inside Potential unfiltered ingress routes that circumvent firewalls: Dial-up modem connections in and out Unauthorized access points Laptops move in and out of the intranet Security of home gateways and other network devices is questionable Most applications now use TCP port 80 or 443, or use other clever tricks to traverse firewalls

53 53 Exercises Why cannot ingress filtering ever stop all IP spoofing attacks? Do you find any mistakes or shortcomings in the firewall policy examples of this lecture? Find out what kind of firewall capabilities your home gateway router/NAT has. Find the firewall configuration of a small network. Try to understand each line of the policy. Have compromises on security been made to achieve better performance, to make management easier, or because of limitations in the router? Write firewall policies for the Network topology example (2) in an earlier slide. What compromises will you have to make if the firewalls are stateless packet filters and do not support filtering based on the input interface. Stateless firewall typically allows all inbound TCP packets with the ACK flag set. On a 1 GB/s network, how difficult is it for external attackers to spoof some TCP packets that match the sequence numbers of an intranet TCP connection?


Download ppt "Network Security: Protocol Analysis, Firewalls Tuomas Aura."

Similar presentations


Ads by Google