Black Hat: Routers using OSPF open to attacks

Panzer919

I thought this was a decent read so I decided to share.

OSPF Vulnerability found


Now the site Shortest path first has issued a statement about this article. It seems to mirror some of our opinions about the original article.

Here it is

MrBrian

Quote from the article: "The exploit also requires that the phantom router is connected to the network"

Seems like it's a common thing that if you can get a suspect router/switch into a network, you can compromise the network and at the minimum cause some DOS attacks.. It's acting as if this guy found an unknown vulnerability, by getting a suspect ospf router into a network and sending out false LSA's with higher sequence numbers. Is that really an unknown vulnerability??

But then it does say "Nakibly described how to falsify all of these and to overcome the protocol's defense mechanism called fightback that floods accurate LSAs in the face of false ones." I'm not really aware of the fightback defensive mechanism though, either, so can't really speak on that... Pretty interesting stuff though, thanks for the link man!

QHalo

God, I keep thinking this dude's name is Narbik. I could barely read that article without having to constantly remind myself its not Kocharians.

Forsaken_GA

I was wondering when this would pop up here.

Long story short, this is a non issue unless you're stupid. If you're using ospf authentication, they have to compromise a router first in order to life the encryption keys to be able to form an adjacency. If you have a compromised router, they pretty much don't need to use this exploit to screw with your routing information anymore.

As well, if you're any good at this network game, any end user facing interfaces that are participating in OSPF are going to be passive-interface'd, so you could *give* them the crypto keys and they still wouldn't be able to screw with your routing tabes.

This is a total media FUD issue.

Forsaken_GA

MrBrian wrote: »

Seems like it's a common thing that if you can get a suspect router/switch into a network, you can compromise the network and at the minimum cause some DOS attacks.. It's acting as if this guy found an unknown vulnerability, by getting a suspect ospf router into a network and sending out false LSA's with higher sequence numbers. Is that really an unknown vulnerability??

You don't need an actual router. You could do it by crafting the proper packets from an end host using something like scapy.

Bl8ckr0uter

Wouldn't a decent IDS monitoring the lan take notice that a LSA being sent? And authentication on the routing protocol....


EDIT: 4saken....

Panzer919

Forsaken_GA wrote: »

Long story short, this is a non issue unless you're stupid.

Stupid is as stupid does Mr.Forsaken_GA

mattlee09

Forsaken_GA wrote: »

Long story short, this is a non issue unless you're stupid.

This is a total media FUD issue.

"The only remedies are using another protocol such as RIP or IS-IS or changing OSPF to close the vulnerability,"

Looks like the Onion has some competition now

shodown

I work in plenty of networks for SMB where things like authentication and telnet and cisco/cisco passwords are the norm. I could easily see this being a problem there. When I worked large networks we even had to have crypto and OSPF/BGP authenticaiton on everything, but they had the budget and manpower to make it happen.

Forsaken_GA

Bl8ckr0uter wrote: »

Wouldn't a decent IDS monitoring the lan take notice that a LSA being sent? And authentication on the routing protocol....


EDIT: 4saken....

If you're monitoring for it, yes. For the same reasons, it's also a good idea to monitor for STP BPDU's, EIGRP packets, CDP, DTP, and any other packet type that should not be seen on the LAN.

Users crafting packets to fake pieces of network gear is absolutely nothing new or groundbreaking. That's why there are a plethora of edge security mechanisms.

Forsaken_GA

shodown wrote: »

I work in plenty of networks for SMB where things like authentication and telnet and cisco/cisco passwords are the norm. I could easily see this being a problem there. When I worked large networks we even had to have crypto and OSPF/BGP authenticaiton on everything, but they had the budget and manpower to make it happen.

And I'll bet those same SMB's are susceptible to something like an MITM ARP spoofing attack as well. An OSPF flaw is hardly going to be the straw that breaks the camel's back when your security posture has more holes than the Denver Bronco's defense.

Forsaken_GA

mattlee09 wrote: »

"The only remedies are using another protocol such as RIP or IS-IS or changing OSPF to close the vulnerability,"

Looks like the Onion has some competition now

Oh, when I saw that, I was filled with nerd rage. It makes the assumption that the reader is an idiot, and that the network admin is as well. Properly configured OSPF isn't vulnerable to this in the first place!

Security researcher has to make a name for himself somehow, I suppose.

wastedtime

Forsaken_GA wrote:

This is a total media FUD issue.

Yep, and this isn't even new..

Forsaken_GA wrote: »

You don't need an actual router. You could do it by crafting the proper packets from an end host using something like scapy.

Or Loki (It seems a bit flaky but when it works it is great)

Bl8ckr0uter wrote:

Wouldn't a decent IDS monitoring the lan take notice that a LSA being sent? And authentication on the routing protocol....

Just doing log monitoring of your routers would detect it.

Just remember your routing protocols should not be running over user subnets as Forsaken said, with making sure those interfaces are passive. I would still use authentication for a bit of added protection though.

chrisone

Forsaken_GA wrote: »

I was wondering when this would pop up here.

Long story short, this is a non issue unless you're stupid. If you're using ospf authentication, they have to compromise a router first in order to life the encryption keys to be able to form an adjacency. If you have a compromised router, they pretty much don't need to use this exploit to screw with your routing information anymore.

As well, if you're any good at this network game, any end user facing interfaces that are participating in OSPF are going to be passive-interface'd, so you could *give* them the crypto keys and they still wouldn't be able to screw with your routing tabes.

This is a total media FUD issue.

Exactly OSPF adjacency authentication will pretty much null this activity. Plus your network design must be shitty if someone could get a router into the LAN.

1. Your physical security must be garbage if anyone can walk in and plug in a router.

2. Who leaves ports with the VLAN the routing network (control, data, management planes) are on? Hosts ports would never ever have this VLAN, so one would actually have to leave a port or more on the control, data, management planes on a switch, for some douche to plug in a router!

3. I think you purposely have to help the attacker to get this compromise to work lol!

Forsaken_GA

chrisone wrote: »

2. Who leaves ports with the VLAN the routing network (control, data, management planes) are on? Hosts ports would never ever have this VLAN, so one would actually have to leave a port or more on the control, data, management planes on a switch, for some douche to plug in a router!

Well, that depends largely on your routing design. In order for the LAN subnets to get out, the network has to be in the routing table somehow. So unless you're doing a static route and redistributing that into OSPF, or redistributing connected interfaces (with all of the design implications that external routes in OSPF carry with it), you've probably got the interface that's functioning as the gateway for the LAN participating in the OSPF routing domain, and that means users have the potential to form an adjacency with it.

This is why one of the first commands I issue when setting up anything that's going to participate in the IGP is passive-interface default. It ensures that no adjacency is going to come up until I explicitly issue no passive-interface {ifname}, which I do one at a time, making sure the adjacencies I want formed come up before I move on to the next one.

chrisone

Yeah i see what your saying, this would be if you terminate your networks behind the router. I am more secure centric when I create my designs and my networks are behind dual ASA failover with a layer 3 connection to local edge routers. On my edge routers is where the routing protocols are placed for the enterprise routing, so if LANs need to talk to remote sites the ASA's push that traffic to he edge routers. Any communications within VLANs are handled by the ASA.

I dont know if your CCDP is from the newer material but if you remember this is the more modular cisco enterprise network design. I work in the finance industry so a lot of security is heavily enforced. We have your basic tri-tier designs (core, distro, Access) however we do it in a modularity design like so.



This is why i am like "woah" no way should your routing and the LAN users be in the same vicinity. Well i studied in this manner with the CCDP exam recently and it looks like the CCNP Security is heading in the same direction, especialy when you build the LANs behind an ASA then you push off your routing to core edge routers or you can do the routing with your ASAs if you want, but i prefer routers.

There is more than way one way to skin a cat as they say, i am just following what i study from Cisco which i love doing

Forsaken_GA

chrisone wrote: »

This is why i am like "woah" no way should your routing and the LAN users be in the same vicinity. Well i studied in this manner with the CCDP exam recently and it looks like the CCNP Security is heading in the same direction, especialy when you build the LANs behind an ASA then you push off your routing to core edge routers or you can do the routing with your ASAs if you want, but i prefer routers.

There is more than way one way to skin a cat as they say, i am just following what i study from Cisco which i love doing

Ok, well, let me ask you this question - How is the ASA sending the traffic up? Is it just defaulting up, or are you using static routes, or is it participating in the IGP?

Or, more to the point, how are the routes for the subnets that are behind the ASA making it into the global routing table? Because they have to be there, otherwise you have no return path, and no return path = no communication.

If I had to guess, I'd bet your defaulting the traffic up to your edge routers, and the edge routers have static routes for those subnets pointing back to the ASA's, and then static's are being redistributed into the IGP. Which is a mitigation I mentioned above However, redistribution into OSPF versus native participation does have other design implications, so it may not always be desirable.

What it boils down to is this - If I can talk to the gateway, and the interface that holds the gateway's address is active in the OSPF domain, then I can form an adjacency to it if you haven't properly secured it. If I can form an adjacency, I can screw with your routing.

chrisone

We have a layer 3 connection from our ASAs and our edge routers. They are part of a routing network (VLAN). The LANs terminate on the ASA but in order to reach the outside remote world they traverse the layer 3 connections to the edge routers. You can use a routing protocol or static routes at this point.

We redistribute static routes and a route-map from inside of the routers into the routing protocol. Since our edge routers and LANs are separated for security reasons, there are no direct layer 2 involvement with the local LANs and our routing segment.

So how do the routers know where the local LANs are and to redistribute them in the routing protocol? default route and static routes to the ASA and an ACL/route-map with the local LANs to be used with the redistribute route-map command in the routing protocol. This allows us to control the subnets to be advertised and lets the enterprise remote sites know about the local LANs. So when a remote site sends traffic into the edge routers , the edge routers receive the packets and forward them with the static routes or default route down towards the ASA.

Same thing with the local LANs, how do they know of remote site routes? default route to edge routers.

So yes you are right the redistribute is in play here and you pretty much nailed it right on the spot. It is a complex network but it is highly secure since the layer 2 and layer 3 are literally separated.

Just think layer 3 connections from ASA to Edge routers. You can do the same with L3 switches terminating the LANs there but your routers are seperated by a network and your L3 switch communicates with the routers with a routing protocol or static routes. That is basically the easiest way to describe it. It is basically separating your routing by a network in between your local LANs and the edge routers. Lab it up it is quite interesting when i saw it myself when i first started a couple years back with the current company i work for. Like i said the finance industry doesn't play around lol I hope i didnt confuse you, i sometimes dont know how to explain things as well as i think them lol

Forsaken_GA

chrisone wrote: »

Just think layer 3 connections from ASA to Edge routers. You can do the same with L3 switches terminating the LANs there but your routers are seperated by a network and your L3 switch communicates with the routers with a routing protocol or static routes. That is basically the easiest way to describe it. It is basically separating your routing by a network in between your local LANs and the edge routers. Lab it up it is quite interesting when i saw it myself when i first started a couple years back with the current company i work for. Like i said the finance industry doesn't play around lol I hope i didnt confuse you, i sometimes dont know how to explain things as well as i think them lol

No, I got you, and you're doing what I figured you were - You're not separating your routing, you have to route all the way back to the user edge, otherwise you have no communication, you've just pushed your dynamic routing domain up a level.

I've had to do similar things in the past to segregate colo customers who didn't want to run BGP, and we sure as hell weren't going to let them participate in the IGP. They usually had their own address space, so we just nailed up a static route, pointed it over a /30 to their router interface, and called it a day.

The model you described is perfectly valid, however it's not one I'd choose to implement. In my opinion (and this is solely my opinion, not the Gospel according to Forsaken), no one has ever been able to demonstrate to me that there's an actual security benefit to doing it that way. Nailing up statics and redistributing into the IGP adds complexity, and for me, complexity = additional points of failure. I don't like adding additional points of failure, unless there's a demonstrable gain in doing so.

Since I can disable the end users ability to interact with the IGP completely, I'm perfectly comfortable extending the routing domain down to their gateway interfaces. Blocking the IGP is all part of the same vein as making sure the end users can't send BPDU's to hijack the root switch designation, or use DTP to form trunks and access vlans they shouldn't be on.

linux_anarchist

Anyone who is interested in these kind of attacks owes it to themself to read the book Silence on the Wire by Michael Zalewski. It's full of some really amazing demos of attacks on layer-2 and layer-3 protocols and will make you pray for better config management for your organization. If you work in a corporate environment, most likely there's something on every third page that would totally wreck your day.

Not really protocol vulnerabilities, but attacks on misconfiguration, like the OSPF attack.