OSPF association not working with VyOS routers (latest nightly build) + potential fix

[Abyss-W4tcher]

Hi, I was trying to associate with a VyOS OSPF router in my lab, but couldn't get things to work (stuck in "2-WAY" state).

After some time searching, I checked the vyos logs (cat /var/log/messages | grep ospf), and found this after the Loki hello packets :

T-bit on, drop it.

Looking on Google gave absolutely no result, so I had to compare manually an hello packet forwarded by VyOS with the one sent by Loki.

I noticed that the VyOS ones didn't have the Multi-Topology Routing bit set, in contrary to Loki. I am not an OSPF expert, and cannot explain exactly what it is doing, so here is the doc : https://sites.google.com/site/amitsciscozone/ospf/multi-topology-routing-in-ospf

After exploring the Loki code, I located the line where this bit is set :

OPTION_TOS_CAPABILITY = 0x1

As a simple fix, I put this value to 0 :

sed -i 's:OPTION_TOS_CAPABILITY = 0x1:OPTION_TOS_CAPABILITY = 0x0:g' /usr/share/loki/modules/module_ospf.py

And now it works, I have a "FULL" state to my VyOS router !

I don't know if this bit is only used by a certain type of routers (e.g. Cisco), but it definitely made Loki unable to associate. My VyOS had the simplest config possible, so it may be possible to enable this feature (although I can't seem to find how in the doc).

I look forward to hear about a possible fix, like an auto detection for example (or if you are already aware of this behaviour).

edit : After spending a bit of time looking at the code, I noticed that there can't be a simple fix for this, as a lot of configuration differences (hello interval, dead interval) on remote router makes the pair process impossible.

[Raizo62]

Hi

But, your patch ("OPTION_TOS_CAPABILITY = 0x1") does it block the hack of the others OSPF routers ? if not, we can set it to this value.

[Abyss-W4tcher]

Response

Hi @Raizo62 , I can't test for other routers now... So it may be a useful information to keep for now I guess.

Additional observations

Also, I checked the ospf module code and noticed that a lot of things could be rethinked, are they any plans to make a rework ?

For example, there is a comment saying #send update to neigh to remove route entry !!!, which is a feature not implemented. After a route injection, it is stuck in my VYoS router. I'm trying to patch the code a bit, by sending a dummy LSU packet to "flush" the router table before injecting another routes (does not seem to work for now, 'cause of fight back mechanism).

The differences between urw and gtk (we cannot inject ospf routes with urw natively, although I managed to make it work), are also restraining.

There is a lot of potential to make something really adaptive and "cleaner" (I speak for OSPF) though, for example if the router dead interval and hello interval are custom in the remote router, there will be a mismatch.

However, the work already achieved is huge, and I can't find anything like that anywhere else !

edit : I have found the way to remove injected routes from remote router, but I don't know where to find the data needed in the code. For removing a route, we send an LSU with LS_AGE =1 and SEQ_NUM += 1. However, I can't find the SEQ_NUM variable. There is the "seq" variable, but it does not keep the incrementation after a Loki restart :/

[Raizo62]

are they any plans to make a rework ?

Not really. I am looking for a way to use Python3 instead of Python2.7. And I like to remove dependencies with unmaintained packages.
Unfortunately, I'm not a Python developer, but C/C++

I don't remember having trouble to remove a route. But I use the gtk version. You may be talking about urw ?

I can't find anything like that anywhere else !

There is also https://github.com/sensepost/routopsy. It uses a real ospf router (so the protocol is respected), but it has no gui :-(

[Raizo62]

@Abyss-W4tcher , in /usr/share/loki/modules/module_ospf.py, (line 253), could you replace OPTION_TOS_CAPABILITY = 0x1 by OPTION_TOS_CAPABILITY = 0x0 and test ?

[Abyss-W4tcher]

@Abyss-W4tcher , in /usr/share/loki/modules/module_ospf.py, (line 253), could you replace OPTION_TOS_CAPABILITY = 0x1 by OPTION_TOS_CAPABILITY = 0x0 and test ?

Hi, this is what I already did : sed -i 's:OPTION_TOS_CAPABILITY = 0x1:OPTION_TOS_CAPABILITY = 0x0:g' /usr/share/loki/modules/module_ospf.py

#7

I checked out routopsy, it's working well. Except that it's injecting routes as "external routes", where Loki is capable to replace a route directly connected to a router. It also needs to set the "--privileged" flag to docker container, where Loki only needs "CAP_NET_ADMIN" (I was running Loki in a docker).

Loki OSPF should be rewritten, the GUI idea is great, but with the scapy.contrib.ospf python modules that could help remove a lot of protocol code and focus on attacks

[Raizo62]

@Abyss-W4tcher , in /usr/share/loki/modules/module_ospf.py, (line 253), could you replace OPTION_TOS_CAPABILITY = 0x1 by OPTION_TOS_CAPABILITY = 0x0 and test ?

Hi, this is what I already did : sed -i 's:OPTION_TOS_CAPABILITY = 0x1:OPTION_TOS_CAPABILITY = 0x0:g' /usr/share/loki/modules/module_ospf.py

#7

Oh ?!! You are right. I am needing holidays and rest. Sorry.
At least we came to the same conclusion :-)

I believe that i have see an other error with the length option in packets.

I don't know if this bit is only used by a certain type of routers (e.g. Cisco), but it definitely made Loki unable to associate. My VyOS had the simplest config possible, so it may be possible to enable this feature (although I can't seem to find how in the doc).

FRRouting seems to drop automatically packets with this option : FFRouting OSPF Code

Loki OSPF should be rewritten, the GUI idea is great, but with the scapy.contrib.ospf python modules that could help remove a lot of protocol code and focus on attacks

Yes. It is a good idea, but before we must use python3 instead of python2.7 and other unmaintained packages.

[Abyss-W4tcher]

No problem x). There is the tool 2to3 that can help and make a huge part of the work.

However, Loki should copy every property in the Hello Packet for the one he will sent, so that everything will match !

[Raizo62]

• With sed -i 's/self.csum, 20/self.csum, 28' /usr/share/loki/modules/module_ospf.py i can remove a warning of Wireshark :

  • LS Acknowledge[Malformed Packet] : [Expert Info (Error/Malformed): Invalid LSA length (24) for type Network-LSA, expected >= (28)]
  • and from FRRouting : ospf_packet_examin: malformed Link State Acknowledgment packet

• But, i can't remove this other warning from Wireshark :
  DB Description[Malformed Packet] : [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]

And i don't know if this patch is only with my test network

And if i check "Master", i stay on "2Way" (with or without this patch). And i don't see error or warnings in FRRrouting's log or wireshark.

There is the tool 2to3 that can help and make a huge part of the work.

The problem is for example with python-glade2 : "there are no python3 versions and there will never be. Instead gnome has replaced this library with gobject-introspection. That means things which were written for glade need to be rewritten or ported." (source). And certainly with other packages

[Abyss-W4tcher]

I also noticed those malformed packets in Wireshark, although it wasn't a problem for association.

"Master" is for selecting the "DR" router ?

Ah yes, like using this for the GUI https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html ?

I don't know how the tool work at its core (fake interface, traffic capture etc.) but I guess with new libraries a huge part of the code could be removed ?

Simulating a real router with FRR is cool, but I like the way Loki works. The attackers need something that works with the least possible privileges, to run on a compromised machine (only in CTF contexts etc. don't get me wrong x).

[Raizo62]

I updated the repository with the patch.
Thank you for your help :-)