Hello there,
Today a new security alert about VTP (Vlan Trunking Protocol) was disclosed. In a Bisounours(Care Bears) world, people follow security best practices and the security work is done. Sometimes, things overcome best practices paper.
Please take a chair, sit down and put on Telemann music.
The vulnerability do a denial of service on the VTP process which leads to reload in most cases. Pre-requisite are trunk port and VTP client or server. The attack can works even if the attacker doesn’t know the VTP password.
For the sake of the positive best practice deviation god, don’t forget (config)# vtp mode transparent command in your layer 2 network as soon as VTP is activated on at least one switch.
I got it but what can I do client/server switches? Education! and best practices by limiting exposure with disabling DTP.
Reminds me a story about Catalyst 4500’s with VTP enabled and static switchport mode trunk on all ports…Yalla!
novembre 5th, 2008
This past week I felt the need to learn other stuff than networking related topics. As you may know (or not), I’m not only a TCP/IP fanatic. Too, you can speak me about everything tricky and hacky, reverse engineering, operating systems internals or all sort of stuff including MicroVAX exploits development and shellcodes 
Continue Reading octobre 11th, 2008
Well, do you think your routing protocols are secure when you enable neighbor cryptography MAC (Message Authentication Code) ?
Hahahaha! At the end of the article, I wish your vision will turnover!
In this article I will show you how to break OSPF adjacencies on an Ethernet segment with cryptography checks enabled. In many litteratures (like Cisco hacking exposed book), the workaround to OSPF flaws is to enable MD5 authentication. In the first attack (majority of this article) we will blackhole OSPF routes learned by a md5ized victim router. The second attack is not very interesting (Like 2 lines in the end of the article). My testbed is 2 Cisco routers (2500 and 2600) and 1 GNU/Linux Debian.
Update 08/23/08: You will find packets capture at the end of the article
Assuming this, let’s see what happens when we break the stuff.
Step zero: Example of an IOS configuration that I’ll break:
interface Ethernet0
ip address 192.168.0.101 255.255.255.0
no ip directed-broadcast
no ip route-cache
ip ospf authentication message-digest
ip ospf authentication-key cisco
ip ospf message-digest-key 1 md5 cisco
router ospf 1
router-id 192.168.0.101
network 172.16.0.1 0.0.0.0 area 0
network 192.168.0.101 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
network 192.168.1.5 0.0.0.0 area 0
network 192.168.4.1 0.0.0.0 area 0
First step but the harder (in a production network). But it would not be so hard if you are good at Social Engineering. You have to kill OSPF adjacencies to get a hello message with an empty neighbor list (active neighbor in wireshark).
As you may known, OSPF crypto is applied on OSPF header, hello and other OSPF messages EXCEPT on IP header. So ask you the following question which seems simple at first sight. How to breaka connection between 2 hosts ? Basically the Ethernet killer guy should say : Let’s go hacking ARP and sends 192.168.0.100 packets to 192.168.0.101 redirected to a blackhole!! (with the ettercap isolate plugin by example) Well, It could works if packets exchanges were between those two hosts. But OSPF works with Multicast (224.0.0.5) so an ARP attack will not works. So how can we do in order to make Snowy’s thinking that Tintin is dead and fortunately clear the OSPF adjacency between themselves ? humm, sadly I haven’t find a better way to break the connection with unplug the RJ45 
Trying to hack IP layer within our OSPF packet will be useless as our goal is to get a valid and processed IP layer and the OSPF payload even if it’s not incorporated in the OSPF MAC algorithm. Anyway, why focus on OSPF hello packet as an interface can eat a lot of valid/malformed attacks^wpackets ? Keep in head that your goal is to reset the interface which receives OSPF packets: “There is more than one way to do it”.
Hello packet when bidirectional communication has already been established:
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0×02 (E)
0… …. = DN: DN-bit is NOT set
.0.. …. = O: O-bit is NOT set
..0. …. = DC: Demand circuits are NOT supported
…0 …. = L: The packet does NOT contain LLS data block
…. 0… = NP: Nssa is NOT supported
…. .0.. = MC: NOT multicast capable
…. ..1. = E: ExternalRoutingCapability
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 192.168.0.101
Backup Designated Router: 192.168.0.100
Active Neighbor: 192.168.0.101
Second step: Wait for the dead interval (which is 40 seconds by default). While capturing, wait for the next packet after the dead interval: The Tintin’s router (192.168.0.101) should be no more present in the active neighbor list. Nice, you’ve captured the OSPF killer packet!
Notice in the following packet that 192.168.0.101 no more present in Active neighbor field nor in the DR/BDR elected routers.
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0×02 (E)
0… …. = DN: DN-bit is NOT set
.0.. …. = O: O-bit is NOT set
..0. …. = DC: Demand circuits are NOT supported
…0 …. = L: The packet does NOT contain LLS data block
…. 0… = NP: Nssa is NOT supported
…. .0.. = MC: NOT multicast capable
…. ..1. = E: ExternalRoutingCapability
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 192.168.0.100 (.101 was the DR)
Backup Designated Router: 0.0.0.0
In the IOS debug command we got this message (ourself is 192.168.0.101):
06:18:36: OSPF: Cannot see ourself in hello from 192.168.0.100 on Ethernet0, state INIT
In the best scenario, you should capture the OSPF hello packet when it had a high authentication cryptography sequence number (like 0×48ac79cb) and before it rollover to 0×0. Replay the unique packet on the network then observe OSPF neighbor adjacencies:
BEFORE #sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.0.100 1 FULL/DROTHER 00:00:31 192.168.0.100 Ethernet0
192.168.0.1 1 FULL/DR 00:00:34 192.168.0.1 Ethernet0
AFTER #sh ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
192.168.0.100 1 INIT/DROTHER 00:00:39 192.168.0.100 Ethernet0
192.168.0.1 1 FULL/DR 00:00:35 192.168.0.1 Ethernet0
There is two things to notice. First, the dead timer is refreshed each time the router receive our packet. It means that the neighbor router isn’t flagged like DOWN but stille active and ready to exchange DBD (Database Descriptors) packets but will never go into the 2WAY state which requires bidirectional communication. Our attack deny this happening. Secondly the STATE of the adjacency. 192.168.0.100 is now stuck in the INIT state. We observe that we lost routes learned from OSPF routing process from 192.168.0.100 :
192.168.4.0/30 is subnetted, 1 subnets
C 192.168.4.0 is directly connected, Loopback2
192.168.7.0/32 is subnetted, 1 subnets
O 192.168.7.1 [110/11] via 192.168.0.1, 00:00:45, Ethernet0 (We haven’t attacked the 192.168.0.1 router)
C 192.168.0.0/24 is directly connected, Ethernet0
192.168.1.0/30 is subnetted, 2 subnets
C 192.168.1.0 is directly connected, Loopback0
C 192.168.1.4 is directly connected, Loopback1
Then when we stopped the attack adjacencies becomes OK in a few seconds until the next true HELLO packet get processed by the OSPF Hello process :
#sh ip os neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.0.100 1 FULL/DROTHER 00:00:38 192.168.0.100 Ethernet0
192.168.0.1 1 FULL/DR 00:00:36 192.168.0.1 Ethernet0
perhaps you are asking you if the attack use a lot of CPU ? The answer is no. Look the show process cpu output by yourself :
2 29944 18069 1657 1.80% 1.12% 0.43% 0 OSPF Hello
And show memory summary give us 2kbytes of memory (7 blocks aka approximately 7 arrays of 312 chars) :
0×33868A2 312 7 2184 OSPF Hello
Secure yourself from these threats :
The pello’s tricky method: Frequently changes your router ID.
It will end like this until the hacker capture a fresh OSPF neighbor DOWN event :
Neighbor ID Pri State Dead Time Address Interface
192.168.0.100 1 INIT/DROTHER 00:00:39 192.168.0.100 Ethernet0
192.168.5.1 1 FULL/DROTHER 00:00:38 192.168.0.100 Ethernet0
192.168.0.1 1 FULL/DR 00:00:29 192.168.0.1 Ethernet0
And OSPF from 192.168.0.100’s router still in the global IP routing table :
192.168.4.0/30 is subnetted, 1 subnets
C 192.168.4.0 is directly connected, Loopback2
192.168.5.0/32 is subnetted, 1 subnets
O 192.168.5.1 [110/11] via 192.168.0.100, 02:10:05, Ethernet0
192.168.7.0/32 is subnetted, 1 subnets
O 192.168.7.1 [110/11] via 192.168.0.1, 02:10:05, Ethernet0
C 192.168.0.0/24 is directly connected, Ethernet0
192.168.1.0/30 is subnetted, 2 subnets
C 192.168.1.0 is directly connected, Loopback0
C 192.168.1.4 is directly connected, Loopback1
The second attack in OSPF with cryptography enabled is the ability to replay any OSPF packet in the hello timer frame window because the authentication cryptography sequence number is incremented each 10 seconds (default hello timer). It could lead to a DoS attack.
You can download packets of the post blog here : http://blog.packetfault.org/ospf-attack-md5-fropert.zip
There is 3 pcap files in the ZIP archive: The replayed packet while the wire unplugging, isolated replayed packet and behavior of ospf during the attack.
Thanks to Russel White from Cisco to have spoke with me by e-mail about this OSPF issue.
août 20th, 2008
