Hi DTV, Aha. Thanks for the catch !
In that case, i dont understand why the "victim" will NOT generate a new LSA with LS sequence number one past the received LS sequence number. I see that the new attack tries to do something by updating the sequence number and the checksum -- did not spend too much time on trying to understand what exactly its doing there. However, OSPF also has provisions to get around that, and i wrote about this many years ago here: https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determining-the-newer-lsa/ So i have the same question as Acee -- why will the natural fight-back mechanism not work here? Cheers, Manav On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV < [email protected]> wrote: > Hi Manav, > > Thank you for your comments. > > Gabi has published multiple attacks against OSPF. > > The attack we are targeting is published in > > @inproceedings{nakibly2012persistent, > title={Persistent OSPF Attacks.}, > author={Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh, > Dan}, > booktitle={NDSS}, > year={2012} > } > > This attack indeed depends on predictability of sequence numbers. > On a side note, we even verified that fact with Gabi Nakibly himself > over a private mail. > > The attack you are discussing in your article is a different attack. > It was described by Gabi in great detail in a different paper: > > @inproceedings{nakibly2014ospf, > title={OSPF vulnerability to persistent poisoning attacks: a systematic > analysis}, > author={Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waizel, > Ariel and Elovici, Yuval}, > booktitle={Proceedings of the 30th Annual Computer Security Applications > Conference}, > pages={336--345}, > year={2014}, > organization={ACM} > } > > As you rightly mentioned, this attack does not depend upon sequence number > predictability. But our draft is *not* targeting *this* attack. > > Thanks and regards, > Ramakrishna DTV. > > > > ------------------------------ > *From:* Manav Bhatia <[email protected]> > *Sent:* Thursday, May 12, 2016 9:16 AM > *To:* Ramakrishna DTV > *Cc:* Acee Lindem (acee); Manjul Khandelwal; [email protected] > *Subject:* Re: [OSPF] Fw: New Version Notification for > draft-manjuldtv-ospf-sequence-number-00.txt > > Hi DTV, > > I dont agree to your assessment of how the attack evades the "natural > fight-back mechanism" in OSPF. > > Its got *nothing* to do with the sequence numbers being predictable, etc. > I have explained in depth how the Gaby attack works here: > > > https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/ > How bad is the OSPF vulnerability exposed by Black Hat ... > <https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/> > routingfreak.wordpress.com > I was asked a few weeks ago by our field engineers to provide a fix for > the OSPF vulnerability exposed by Black Hat last month. Prima facie there > appeared ... > > > Clipped from the blog: > > "This attack exploits a potential omission (or a bug if you will) in the > standard where it does not mandate that the receiving router verifies that > the Link State ID and the Advertising Router fields in the Router LSA are > the exact same value. > > This attack sends malacious Router LSAs with two different values in the > LS header. The Link State ID carries the Router ID of the router that is > being attacked (the victim) and the Advertising Router is set to some > different (any) value. > > When the victim receives the malacious Router LSA, it does not refresh > this LSA as it doesnt recognize this as its own self generated LSA. This is > because the OSPF spec clearly says in Sec 13.4 that “A self-originated LSA > is detected when either 1) The LSA’s Advertising Router is equal to the > router’s own Router ID or 2) the LSA is a network LSA .. “. > > This means that OSPF’s natural fight back mechanism is NOT triggered by > the victim router as long as the field ‘Advertising Router’ of a LSA is NOT > equal to the victim’s Router ID. This is true even if the ‘Link State ID’ > of that LSA is equal to the victim’s Router ID. Going further it means no > LSA refresh is triggered even if the malacious LSA claims to describe the > links of the victim router!" > > I describe further in the blog that not all router implementations are > susceptible to the attack. Its dependent on how the LSA is picked up from > the LSDB. > > Cheers, Manav > > On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV < > [email protected]> wrote: > >> Hi Acee, >> >> We currently provided the following description of this attack in the >> draft: >> >> "The paper refers to the attack as "Disguised LSA" and is of >> persistent nature. This attack is launched from a compromised router >> inside a routing domain. In this attack, the compromised router >> alters the LSA of an uncompromised router (victim). Normally, such >> an attempt does not have persistence because the victim generates a >> new LSA when it sees such self-originated LSAs (referred to as >> "fight-back" mechanism in the paper). But the paper makes disguised >> LSA persistent because all the fields { LS sequence number, checksum} >> are predictable. It alters the existing LSA of victim to suit its >> needs but sets the sequence number to +1 of the existing LSA and >> alters the LSA so that checksum matches with checksum that would be >> generated by the victim when it generates the new LSA. When this >> disguised LSA reaches the victim, it does not fight back because it >> compares only the fields { LS sequence number, checksum, age} to >> check for duplicates and not the actual content of LSA. >> >> This attack enables an insider attacker to fully control the entire >> content of an LSA. We think this attack is powerful." >> >> These details are currently present in Section 4, which is titled >> "Implementation advice". >> We can probably move it to a different section (e.g., "Introduction") to >> make it clear. >> >> If you think even more additional details about the attack are useful to >> the working group, >> please let us know. We will add. >> >> Thank you. >> >> Regards, >> Ramakrishna DTV. >> >> >> ________________________________________ >> From: Acee Lindem (acee) <[email protected]> >> Sent: Wednesday, May 11, 2016 8:49 PM >> To: Manjul Khandelwal; [email protected] >> Cc: Ramakrishna DTV >> Subject: Re: [OSPF] Fw: New Version Notification for >> draft-manjuldtv-ospf-sequence-number-00.txt >> >> Hi Manjul, >> >> Would it be possible to succinctly describe these “certain security >> attacks” in the draft rather than expecting everyone to read the >> referenced paper? >> >> Thanks, >> Acee >> >> On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi, >> > >> >We have recently submitted a draft which deals with OSPF LS sequence >> >number >> >generation mechanism. >> > >> >Abstract of the draft: >> > The mechanism for LS sequence number generation as specified in RFC >> > 2328 and RFC 5340 is completely predictable. This makes it prone to >> > certain security attacks which exploit the predictable nature of LS >> > sequence numbers. This draft updates the RFC 2328 to make LS >> > sequence number generation an implementation choice rather than a >> > fixed increment by 1 for successive LSAs. >> > >> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >> > >> >We solicit feedback/comments on the draft and request for adoption by the >> >OSPF working group. >> > >> >Regards, >> >Manjul Khandelwal >> >DTV Ramakrishna Rao >> >________________________________________ >> >From: [email protected] <[email protected]> >> >Sent: Monday, May 9, 2016 7:22 PM >> >To: Manjul Khandelwal; Ramakrishna DTV >> >Subject: New Version Notification for >> >draft-manjuldtv-ospf-sequence-number-00.txt >> > >> >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >> >has been successfully submitted by Manjul Khandelwal and posted to the >> >IETF repository. >> > >> >Name: draft-manjuldtv-ospf-sequence-number >> >Revision: 00 >> >Title: OSPF LSA sequence number generation >> >Document date: 2016-05-09 >> >Group: Individual Submission >> >Pages: 10 >> >URL: >> > >> https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number- >> >00.txt >> >Status: >> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >> >Htmlized: >> >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 >> > >> > >> >Abstract: >> > The mechanism for LS sequence number generation as specified in RFC >> > 2328 and RFC 5340 is completely predictable. This makes it prone to >> > certain security attacks which exploit the predictable nature of LS >> > sequence numbers. This draft updates the RFC 2328 to make LS >> > sequence number generation an implementation choice rather than a >> > fixed increment by 1 for successive LSAs. >> > >> > >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >The IETF Secretariat >> > >> >_______________________________________________ >> >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
