Manav breaks down the OSPF vulnerability from Black Hat 2013 and confirms that it practical and viable failure of the OSPF protocol.
So it was with certain skepticism that i started looking at yet another OSPF vulnerability exposed by Gabi, again at Black Hat. Its only when i started delving deep into the attack vector that the real scale of the attack dawned on me. This attack evades OSPF’s natural fight back mechanism against malacious LSAs which makes it a bit more insidious than the other attacks reported so far.
I’ve had this article in by browser for quite some time, I’ve re-read it a few times before I feel like I understand it well enough. But the conclusion seems clear:
In the attack that Gabi described, the victim router does not recognize the malacious LSA as its own and thus never attempts at refreshing it. As a result the malicious LSA remains stealthily hidden in the routing domain and can go undetected for a really long time. Thus by controlling a single router inside an AS the one that will flood the malacious LSA, an attacker can gain control over the entire routing domain. In fact, an attacker need not even gain control of an entire router inside the AS. Its enough if it can somehow inject the malacious LSAs over a link such that one of the OSPF routers in the network accept this.
You should read the article which explains that it’s somewhat straightforward to permanently compromise an OSPF routing table with a route or perform a denial of service. As I read it, there is no workaround unless the OSPF device either adds new validation to the LSA validation ( you do not permit OSPF neighbours across untrusted boundaries. Which would be best practice. Route filtering or ACLs will not prevent this attack.
Vendors security advisories suggest that this problem is likely to have been solved.