Transcript PPT Version
OSPF Security Vulnerabilities Analysis draft-jones-OSPF-vuln-01.txt [email protected] [email protected] IETF 58 – RPSEC Working Group November 2003 Minneapolis, MN, USA Draft’s Purpose > Provide a complete vulnerability analysis coverage for OSPF > Leverage OSPF vulnerabilities assessment: • • Outline areas of intervention to harden the overall security of OSPF Provide a reference to better mandate requirements for security of future routing protocols Draft’s Approach > The draft is a systematic analysis of all OSPF mechanisms and messages to identify potential security vulnerabilities > The Internet Draft is divided in three sections: • • • > General Vulnerabilities not tied to any specific OSPF message Per-Message Vulnerabilities Resource Consumption (DoS) Vulnerabilities The draft is not intended to encompass implementation specific vulnerabilities although a few pointers to observed critical implementation resources are provided Draft’s Outline > Vulnerabilities due to the design and nature of OSPF – – – – > Vulnerabilities for each of the 5 OSPF messages: – – – – – > Hello Link State Update Link State Request Link State Acknowledge Link State Database Description Vulnerabilities due to Resource Consumption – > Attacker’s Location Disabling of OSPF Fight Back Leveraging Fight Back as intrinsic source for DoS External Routes propagation Vulnerabilities due to Cryptographic Resources Vulnerabilities through other protocols (e.g. IP, Management…) Three Examples from the Draft > Three examples of vulnerabilities presented in the draft and how to exploit them : Vulnerability Outcome ID’s Reference LSA Modification Topology Changes 3.2.4.3-4 “Phantom” LSAs Database Overflow 3.3.5 External LSA Forwarding Data-Traffic Loop 3.2.4.6 Exploit #1 – Topology Changes > Vulnerability: LSA Information Modification [3.2.4.3-4] • Pre-condition: – • Possible Impact: Topology Changes – – • Allow Eavesdropping Starve/Overload a network Expected Outcome: – • Being able to CONSTANTLY inject valid OSPF messages – Weak MD5 key choice/Compromised Router – No Cryptographic Authentication, etc… Highly unstable topology (loops, route-flapping) due to Fight Back of LSAs between attacker and legitimate owner Observed Outcome (as supported by the RFC!) – PERMANENT or SEMI-PERMANENT topology changes due to ineffective Fight Back Fight Back > What is fight back? • > Every LSA that is circulating containing wrong information will be corrected by its owner Papers on OSPF security suggest that • • Fight Back corrects the damage of most attacks Many theoretical attacks are not worth the effort just to cause a brief topology change [ “An Experimental Study of Insider Attacks for the OSPF Routing Protocol”, Vetter et al. “On the Vulnerabilities and Protection of OSPF Routing Protocol”, Wang and Wu ] Disabling Fight Back > OSPF Fight Back can be • • Disabled Heavily Diluted > Attacks on LSA information are then SUCCESFUL > HOW? 1. Periodic Injection > Exploiting an architectural “flaw” in the OSPF flooding algorithm > > 2. MinLSInterval (5 seconds) Prevent information from reaching the router legitimate owner > 3. [ RFC 2328, 13.5 (a) (b) and (f) ] Subverted router that partitions the network Inject information on behalf of non-existing routers Exploit #2 - Resource Consumption > “Phantom LSAs” are Router/Network LSAs sent on behalf of non-existing OSPF peers > These entries are ignored by the Shortest Path First (SPF) algorithm (do not produce topology changes) > “Phantom LSAs” are entered in the Link State Database • • > Each entry is kept for MaxAge (1hour) No fight back is triggered since there is no legitimate owner Exhausting Link-State Database resources will put OSPF in a very delicate state and stress implementation’s robustness Exploit #3 - Creating a Data-Traffic Loop > Vulnerability: Modifying External LSA Forwarding Field [3.2.4.6] • Pre-Condition: – – – • Being able to inject valid OSPF messages – Weak MD5 key choice/Compromised Router – No Cryptographic Authentication, etc… E-Bit Enabled on advertising peer’s Router LSA Change Forwarding Address 0.0.0.0 to a router (host) in any Stub Area Possible Impact: – Data never gets to its destination because it is stuck in a loop. – Outgoing External Traffic forwarded to a Stub Area router (host) will LOOP between the ABR and its next hop towards the forwarding point. [RFC 2328, 3.6] Conclusions > OSPF presents significant security vulnerabilities, which should not be overlooked in future routing protocols (IGP) requirements. > OSPF is generally associated with some misconceptions about the protocol’s security and its intrinsic resilience to attacks: • Lead to a false security threat analysis Next Steps > Would like to receive more feedback from the group > Could this document become a WG item? • Addresses charter item: “Submit I-Ds documenting threats to routing systems for publication as Informational RFC.” for OSPF ? Back up slides Periodic Injection > When a legitimate owner receives a malicious copy of its own LSAs: • SINCE – the malicious LSA has higher sequence number – a copy of the LSA is already present in the LinkStateDB and this copy was not received by flooding but installed by the router itself • THEN Flood the malicious LSA and AFTER check ownership • THEN TRY to update the malicious LSA [RFC 2328, 13, p.143-6] • Why try? – Because a router cannot inject two same LSAs faster than MinLSInterval (5 seconds) BUT it will immediately flood any LSA received. [RFC 2328, 12.4, p.125] • If the attacker is injecting malicious LSAs with a rate higher than MinLSInterval, the legitimate owner will not only NOT fight back but it will ALSO collaborate in the flooding Data-Traffic Loop 123.1.2.0 Attacker is advertising External Route to 123.1.2.0 with Forward to F B A Ext. LSA 123.1.2.0 Forward F is present in LinkStateDB C BACKBONE 1 DATA Traffic Compromised Router TO: 123.1.2.0 D FE ... 123.1.2.0 E 2 D direct F direct 0.0.0.0 D NO Ext. LSAs: 123.1.2.0 is pointed to DEFAULT ROUTE 3 E STUB AREA F G DE F direct 0.0.0.0 E Attacker’s Location > An OSPF router could be attacked from ANYWHERE in the internet if the router’s IP address is known. ATTACKER ATTACKER ATTACKER Telnet or SSH INTERNET Session OSPF Router OSPF Router Physical access to the link Attacker “On the Path” INTERNET OSPF Domain OSPF Router OSPF Router OSPF Domain OSPF Router Access to a router OSPF Router Access to the link’s password • Extremely easy to mount DDoS attacks for outsider attackers. • Extremely difficult to trace back the attacker Remote Attacker Backup “The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10).” RFC 2328, 8.1 Hop-by-hop OSPF’s Security > All OSPF peers (on the same network) share the same secret key. > If the attacker compromises ONE single link it can now attack the entire domain. • > From the compromised link attacker can inject LSAs on behalf of every other OSPF router (even if other links use a different secret!) Security Consequences: • Local Intrusion Global Impact – • Attacker that compromises one link/peer can possibly then attack anywhere in the entire domain Never know which is the compromised/malicious router – Even if an attack/suspicious behaviour is detected, it may not be immediate to identify the malicious router Stub-Area Default Route “One or more of the stub area's area border routers must advertise a default route into the stub area via summary-LSAs. These summary defaults are flooded throughout the stub area, but no further.” “These summary default routes will be used for any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations).” “An area can be configured as a stub when there is a single exit point from the area, or when the choice of exit point need not be made on a per-external-destination basis” RFC 2328, 3.6, pag. 37 “Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router).” RFC 2328, A.4.5, pag. 215