Subject: [OSPF] OSPF - Owning the Routing Table Attack

From: Glen Kent <[email-masked]>
Date: Fri, 2 Aug 2013 22:11:01 +0530

Hi,

Does anybody have details on what this OSPF vulnerability is?

https://www.blackhat.com/us-13/briefings.html#Nakibly

Glen

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Aug 2013 17:19:23 +0000

Remembered comments about this in SAAG.

If authentication shared secrets are compromised (insider attack) you can envision all sorts of issues.

If this is still considered serious consider changing keys or use a key management protocol (hope there will be one defined) to do this periodically!

--
Uma C.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Kent
Sent: Friday, August 02, 2013 9:41 AM
To: [email-masked]
Subject: [OSPF] OSPF - Owning the Routing Table Attack

Hi,

Glen

---

From: Michael Barnes <[email-masked]>
Date: Fri, 02 Aug 2013 10:56:23 -0700

I don't think he has discovered anything revolutionary. It has been 
widely known for many years that if someone has control of a router, or 
links which are not protected by authentication, that there are many 
forms of mischief (e.g. insider attacks).

I found this slide from an IETF presentation in 1998 which lists a 
number of previous papers:
https://www.ietf.org/proceedings/46/slides/ospf-sec/tsld003.htm

Some of the following slides explain a few possible exploits, all of 
which are "insider" attacks.

There is a well known IETF document which lists a number of OSPF 
vulnerabilities, however it is not a complete list:
http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt

So I don't find this "briefing" very interesting. What would be 
interesting to me, would be a way to attack OSPF when SHA-256 
authentication is deployed, beyond the known replay attacks.

Regards,
Michael

On 08/02/2013 09:41 AM, Glen Kent wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Aug 2013 18:06:09 +0000

>>What would be interesting to me, would be a way to attack OSPF when 
>>SHA-256 authentication is deployed, beyond the known replay attacks.

Doesn't matter what auth algo is used for their work; if same key is used 
on all interfaces and it is compromised/got access some how (insider) 
- It's not hard to create the issues the posting documented.

$0.02
--
Uma C.

---

From: Orhan Ergün <[email-masked]>
Date: Fri, 2 Aug 2013 21:47:55 +0300

İ totaly agree wit Michael its well known and this attack even can be done from several hops away . 

Best Regards,
Orhan ERGUN

On 2 Ağu 2013, at 20:56, Michael Barnes <[email-masked]> wrote:

> I don't think he has discovered anything revolutionary. It has been widely known for many years that if someone has control of a router, or links which are not protected by authentication, that there are many forms of mischief (e.g. insider attacks).
> 
> I found this slide from an IETF presentation in 1998 which lists a number of previous papers:
> Some of the following slides explain a few possible exploits, all of which are "insider" attacks.
> 
> There is a well known IETF document which lists a number of OSPF vulnerabilities, however it is not a complete list:
> So I don't find this "briefing" very interesting. What would be interesting to me, would be a way to attack OSPF when SHA-256 authentication is deployed, beyond the known replay attacks.
> 
> Regards,
> Michael
>

---

From: Michael Barnes <[email-masked]>
Date: Fri, 02 Aug 2013 12:05:33 -0700

> - It's not hard to create the issues the posting documented.

If the key is compromised then what's the difference if no key is used? 
The reason I mentioned SHA-256 is that it is currently recommended 
algorithm to use. But you're right, it really doesn't matter what the 
algorithm is. I should have stated it differently.

Anyway, I think we agree that a new insider attack is not interesting 
because it's just one more of a known list.

-M

---

From: David Lamparter <[email-masked]>
Date: Sun, 4 Aug 2013 15:06:03 +0200

> https://www.blackhat.com/us-13/briefings.html#Nakibly

As people may have noticed by now (the embargo on providing details has
expired as the talk was presented), this issue consists of Router LSAs
where the Router ID is different from the Link State ID.  As such, this
attack is implementable from any router in an OSPF area against any
other router in the OSPF.

(Quite honestly, IMHO this is seriously far fetched.  If your control
plane got compromised this far you have other problems.)

While Quagga is unaffected by this, we've implemented a warning.  We're
also considering dropping the LSA outright, but I'm somewhat split on
that (tilted towards dropping).  I'd be interested if the WG has
comments on that?

-David

---

From: Acee Lindem <[email-masked]>
Date: Mon, 5 Aug 2013 02:28:19 +0000

>plane got compromised this far you have other problems.)

I agree that once the OSPF control plane is open, you are susceptible to
many attacks. However, this attack is a bit more insidious than most since
the actual OSPF router corresponding to the link state ID will most likely
not recognize the LSA as self-originated and re-originate a more recent
version when the malformed one is received. Hence, the malicious LSA will
remain in the routing domain and, depending upon the OSPF implementation,
could result in traffic being redirected.

>that (tilted towards dropping).  I'd be interested if the WG has

I can't speak for the WG but my implementation will skip the LSA in the
Link-State Update packet.

Thanks,
Acee

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 5 Aug 2013 14:03:55 -0700 (PDT)

Hi all,
My name is Gabi. I am the researcher who presented the new attack at Black Hat last week. I have noticed the discussion on the list and I would be happy to try to clarify how the attack is different from known ones. 
Indeed the attack assumes that the attacker is an insider, meaning that the attacker has already gained control of one of the router within the AS. I agree 100% that once an attacker is an insider he can already do all sorts of attacks that can harm the network and indeed a few past works have already reported on this. Nonetheless,  the crux of the new attack, as Acee has already pointed out, is that an attacker is now able to falsify an LSA on behalf of another router while evading the fight-back mechanism. This new capability allows an attacker to *persistently* and *stealthily* subvert the LSA DB of other routers that install the false LSA and thereby altering their routing tables. This gives rise to a new class of attacks that in my opinion have not existed before and, in many times, are more desirable for an attacker (due to their stealth and persistence).
To my best knowledge, no other general technique to stealthily evade fight back is known. The only general attack technique to evade fight back is periodic injection (flooding false LSAs at a rate higher thanone every MinLSInterval)  presented in http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt in Section 4.1.3.1. However,  using such technique the attack is hardly stealthy.

BTW, I have also presented in the past another general technique to evade fight back called 'Disguised LSA'. It is described in https://www.cs.technion.ac.il/people/gnakibly/online-publications/PersistentOSPF.pdf in Section 4.2.

I would appreciate your continued feedback on the new attack.

Thanks,
Gabi

> From: Acee Lindem <[email-masked]>
>To: David Lamparter <[email-masked]>; Glen Kent <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Monday, August 5, 2013 5:28 AM
>Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
> 
>
>
>

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Fri, 9 Aug 2013 01:37:15 +0000

I would think such an attack can be categorized as "overclaiming", as
defined at http://tools.ietf.org/html/rfc4593#section-4.5.1.1. In this
case, an attacker claims a resource (link state ID) which does not belong
to it. 

While it might be challenging to defense overclaiming in some cases, it's
not that hard to recognize the attack in this case. As pointed out by
David and Acee, such LSAs should be considered as malformatted as they
have unmatched Advertising Router and Link State ID and can be dropped. A
more challenging example of overclaiming is the attacker simply advertises
a bunch of prefixes that are not really attached on itself.

Yi 

On 8/5/13 5:03 PM, "Gabi Nakibly" <[email-masked]> wrote:

>Hi all,
>My name is Gabi. I am the researcher who presented the new attack at
>Black Hat last week. I have noticed the discussion on the list and I
>would be happy to try to clarify how the attack is different from known
>ones. 
>Indeed the attack assumes that the attacker is an insider, meaning that
>the attacker has already gained control of one of the router within the
>AS. I agree 100% that once an attacker is an insider he can already do
>all sorts of attacks that can harm the network and indeed a few past
>works have already reported on this. Nonetheless,  the crux of the new
>attack, as Acee has already pointed out, is that an attacker is now able
>to falsify an LSA on behalf of another router while evading the
>fight-back mechanism. This new capability allows an attacker to
>*persistently* and *stealthily* subvert the LSA DB of other routers that
>install the false LSA and thereby altering their routing tables. This
>gives rise to a new class of attacks that in my opinion have not existed
>before and, in many times, are more desirable for an attacker (due to
>their stealth and persistence).
>To my best knowledge, no other general technique to stealthily evade
>fight back is known. The only general attack technique to evade fight
>back is periodic injection (flooding false LSAs at a rate higher thanone
>every MinLSInterval)  presented in
>http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt in Section
>4.1.3.1. However,  using such technique the attack is hardly stealthy.
>
>BTW, I have also presented in the past another general technique to evade
>fight back called 'Disguised LSA'. It is described in
>https://www.cs.technion.ac.il/people/gnakibly/online-publications/Persiste
>ntOSPF.pdf in Section 4.2.
>

---

From: Gabi Nakibly <[email-masked]>
Date: Sun, 11 Aug 2013 12:22:41 -0700 (PDT)

Hi Yi,
Indeed, mitigating the attack cannot be easier, if you look for the right malformed packet. You only need to check that the Link State ID equals the Advertising Router. This measure is now employed by Cisco, Juniper and a few other vendors. Nonetheless, I am sure that there are more OSPF vendors out there that are still vulnerable to the attack and do not check for this. Moreover, since this check is not part of the standard, in most likelihood future OSPF implementations will also be vulnerable.

As RFC 4593 points out, byzantine attacks are possible form of attack against routing protocols and measures should be employed  to "minimize the impact of attacks of this sort". IMHO, since byzantine attacks do occur in practice and the mitigation for this specific attack is easy to deploy, the WG might want to do an effort to advice on the mitigation measures for this attack.

I am willing to write a draft describing this mitigation measure. I would appreciate the list's thoughts on this.

Gabi

----- Original Message -----
> From: Yi Yang (yiya) <[email-masked]>
> To: Gabi Nakibly <[email-masked]>; Acee Lindem <[email-masked]>; David Lamparter <[email-masked]>; Glen Kent <[email-masked]>
> Sent: Friday, August 9, 2013 4:37 AM