Hi Gabi, [clipped]
> 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. > [clipped] > > I am willing to write a draft describing this mitigation > measure. I would appreciate the list's thoughts on this. I think it's a good idea to write a draft that describes the attack and what implementations MUST do to avoid it. Cheers, Manav > > Gabi > > ----- Original Message ----- > > From: Yi Yang (yiya) <[email protected]> > > To: Gabi Nakibly <[email protected]>; Acee Lindem > > <[email protected]>; David Lamparter > <[email protected]>; Glen > > Kent <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Sent: Friday, August 9, 2013 4:37 AM > > Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the > > Routing Table Attack) > > > > 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 protected]> 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/Per > >> siste > >> ntOSPF.pdf in Section 4.2. > >> > >> I would appreciate your continued feedback on the new attack. > >> > >> Thanks, > >> Gabi > >> > >>> ________________________________ > >>> From: Acee Lindem <[email protected]> > >>> To: David Lamparter <[email protected]>; Glen Kent > >>><[email protected]> > >>> Cc: "[email protected]" <[email protected]> > >>> Sent: Monday, August 5, 2013 5:28 AM > >>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - > Owning the > >>>Routing Table Attack) > >>> > >>> > >>> > >>> > >>> On 8/4/13 6:06 AM, "David Lamparter" > > <[email protected]> wrote: > >>> > >>>> On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote: > >>>>> Does anybody have details on what this OSPF vulnerability is? > >>>>> > >>>>> 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.) > >>> > >>> 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. > >>> > >>>> > >>>> 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? > >>> > >>> I can't speak for the WG but my implementation will skip > the LSA in > > the > >>> Link-State Update packet. > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>>> > >>>> > >>>> -David > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >>> > >>> > >> _______________________________________________ > >> OSPF mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
