Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

Acee Lindem <acee@lindem.com> Thu, 12 September 2013 15:00 UTC

Return-Path: <acee@lindem.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E811E8260 for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 08:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPJMuQaOSFHG for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 08:00:17 -0700 (PDT)
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id BA64A21E80F0 for <ospf@ietf.org>; Thu, 12 Sep 2013 07:59:35 -0700 (PDT)
X-Authority-Analysis: v=2.0 cv=PogRnnw3 c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=cv6AbCrYKhYA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=kg5FYR9m7LsA:10 a=tJDDVEC1AAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=TQmXhA5hi5FoVrpQDuUA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117
X-Cloudmark-Score: 0
X-Authenticated-User:
X-Originating-IP: 65.190.0.120
Received: from [65.190.0.120] ([65.190.0.120:51337] helo=[192.168.1.106]) by cdptpa-oedge02.mail.rr.com (envelope-from <acee@lindem.com>) (ecelerity 2.2.3.46 r()) with ESMTP id 24/DC-02184-1D6D1325; Thu, 12 Sep 2013 14:59:29 +0000
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Acee Lindem <acee@lindem.com>
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Date: Thu, 12 Sep 2013 10:59:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com>
References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <DC74E46E9699A84EB0E1183B90FD160928F2C192@xmb-aln-x11.cisco.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1085)
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2013 15:00:58 -0000

Manav - 


On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote:

> Anton,
> 
> I understand that once the attacker can insert LSAs in the flooding domain then there are several things that can be done. However, in most cases the attacks can be easily identified and a corrective action can be easily taken. In this particular case, the attack is a little more insidious and its not straight forward catching the erring LSA.
> 
> Since its something that's missing in rfc 2328 we will keep having newer implementations that will carry this bug. A short one page RFC that updates 2328 imo would do no harm. Do you see any issue in publishing such an RFC?

There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will be advertised with the same Router-ID for both the LSID and the Advertising router. I don't think it is productive to write "short" RFCs for every attack and believe the CERT Alert is a better and swifter mechanism for disseminating information on attacks. 
Note that my implementation was not susceptible to this attack as the vulnerability was identified in a packet mutation suite many years back.

I spoke to Gabi offline about authoring an informational RFC that discusses classes of OSPF attacks and possible mechanisms to thwart them. 

Thanks,
Acee

> 
> I have written a short post on what the issue in 2328 is and how it can be exploited to launch an attack.
> http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/
> 
> Cheers, Manav
> 
>> -----Original Message-----
>> From: Anton Smirnov [mailto:asmirnov@cisco.com] 
>> Sent: Thursday, September 12, 2013 4:46 PM
>> To: Bhatia, Manav (Manav)
>> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org
>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - 
>> Owning the Routing Table Attack)
>> 
>>    If attacker has joined flooding domain and can inject an 
>> LSA into LSDB then it can screw up routing in the domain. 
>> Methods such as pretending being an ABR/ASBR and advertise 
>> destinations with good metric are almost impossible to combat 
>> once authentication barrier is penetrated.
>>    This particular vulnerability allows attacker to bring 
>> network down in style but if this vulnerability is not 
>> present in the particular network then attacker will simply 
>> resort to other numerous possibilities to affect routing via 
>> LSA injection. If attacker can inject LSA into LSDB then your 
>> network is at his mercy. Give or take one particular method 
>> is a detail.
>>    So IMO we don't need a draft on this particular 
>> vulnerability. It might be of some limited interest to 
>> document all known methods to exploit LSA injection which 
>> would include this vulnerability but what value would this 
>> RFC bring? Such methods are regularly published in academic 
>> literature since 90-th.
>> 
>>    IMO we need good (reliable, secure, manageable etc) 
>> methods of authenticating adjacencies. KARP group is working 
>> on that. We *might* benefit from a work on mechanism to 
>> prevent any router to originate reachable LSA on behalf of 
>> any other router (kind of LSA signing). But work on what will 
>> go wrong when intended security barriers are broken IMO is not needed.
>> 
>> Anton
>> 
>> 
>> 
>> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote:
>>> 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
>>> 
>> 
>> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf