Cisco Vulnerability Testing Results
Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... The attack code we used is the same code that was posted to the Full Disclosure list. Compiled on a Redhat Linux 6.2 machine. Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 First attack was to the 2514, ran the program as thus : ./sc 192.168.0.1 1 This produced unexpected results. Cisco indicated that the vulnerability was on the interface specified in the packets. However, after running this, it was actually the INPUT interface that the input queue increased on. In our test, this was Ethernet0, not Ethernet1 as expected. Next attach was to the 2501 : ./sc 192.168.0.2 2 This produced expected results. Input queue did increase on the 2501. Next we tried a pass-through attack : ./sc 192.168.0.2 0 ./sc 192.168.0.2 1 No interfaces on either Cisco were affected. It seems that pass-through attacks are not possible. The attack *must* terminate on an IP on one of the router interfaces. An additional test to both routers using a high TTL value was also run. No interfaces were affected. This is in-line with Cisco's posting. Code was then upgraded on the 2514 to 12.0.27 (non-vulnerable) .. Tests were run again. This time, the 2514 was not affected by any tests. The 2501 was still vulnerable. I will be testing ACL's in a moment, but I wanted to get these results out and see if they were on-par with any testing anyone else has done. -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]
Ok, update to my testing : On Fri, 2003-07-18 at 10:48, Jason Frisvold wrote:
Hi all,
First post.. I hope this is ok ...
We tested the Cisco vulnerability and I wanted to share our results with you ... <SNIP> Testing scenario is this :
Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 <SNIP>
Firstly, HPing (www.hping.org) can craft the packets required for this attack very simply... I won't post the exact command string, but it's not that hard to figure out... And with HPing, you can easily take down an interface in under a second. Now, on to ACL testing... 3 ACL tests just to make sure we had everything correct ... We first tried the any any ACL that Cisco recommends : access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any access-list 101 permit ip any any This produced expected results. When placed on the interface, it prevented the router from being attacked. Next, we tried an ACL with just the interface IP in it : access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 permit ip any any We applied this to the Ethernet0 interface on the 2514. Attacks to that IP were prevented as expected. Attacks through to the 2501 were not blocked, again as expected. And finally, attacks to the ethernet1 interface on the 2514, which passes through the ethernet0 interface, still caused the ethernet0 interface to be attacked. And the last test was an ACL containing all of the IP's on the router: access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 deny 53 any host 192.168.0.1 access-list 101 deny 55 any host 192.168.0.1 access-list 101 deny 77 any host 192.168.0.1 access-list 101 deny 103 any host 192.168.0.1 access-list 101 permit ip any any This blocked all attacks on the 2514 while still allowing attacks through to the 2501.. This is as expected. Also, another note. Loopback interfaces, while not vulnerable themselves, make it much easier to completely take out routers.. (We're assuming that the device is still vulnerable) If the attacker has the loopback of the router, they can run an attack at that interface. Every input interface will be attacked in succession. As each interface goes down and the traffic re-routed, the next interface will fall under attack. Just be sure to add the loopback IP as part of the ACL ... :) -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]
Just a quick credit email.. :) I wanna make sure credit is given to the 2 guys who helped with this testing.. Keith Pachulski and Chrus Kruslicky .. both from PTD.. :) On Fri, 2003-07-18 at 11:34, Jason Frisvold wrote:
Ok, update to my testing :
On Fri, 2003-07-18 at 10:48, Jason Frisvold wrote:
Hi all,
First post.. I hope this is ok ...
We tested the Cisco vulnerability and I wanted to share our results with you ... <SNIP> Testing scenario is this :
Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 <SNIP>
Firstly, HPing (www.hping.org) can craft the packets required for this attack very simply... I won't post the exact command string, but it's not that hard to figure out... And with HPing, you can easily take down an interface in under a second.
Now, on to ACL testing...
3 ACL tests just to make sure we had everything correct ... We first tried the any any ACL that Cisco recommends :
access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any access-list 101 permit ip any any
This produced expected results. When placed on the interface, it prevented the router from being attacked.
Next, we tried an ACL with just the interface IP in it :
access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 permit ip any any
We applied this to the Ethernet0 interface on the 2514. Attacks to that IP were prevented as expected.
Attacks through to the 2501 were not blocked, again as expected.
And finally, attacks to the ethernet1 interface on the 2514, which passes through the ethernet0 interface, still caused the ethernet0 interface to be attacked.
And the last test was an ACL containing all of the IP's on the router:
access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 deny 53 any host 192.168.0.1 access-list 101 deny 55 any host 192.168.0.1 access-list 101 deny 77 any host 192.168.0.1 access-list 101 deny 103 any host 192.168.0.1 access-list 101 permit ip any any
This blocked all attacks on the 2514 while still allowing attacks through to the 2501.. This is as expected.
Also, another note. Loopback interfaces, while not vulnerable themselves, make it much easier to completely take out routers.. (We're assuming that the device is still vulnerable) If the attacker has the loopback of the router, they can run an attack at that interface. Every input interface will be attacked in succession. As each interface goes down and the traffic re-routed, the next interface will fall under attack.
Just be sure to add the loopback IP as part of the ACL ... :) --
Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]
Just for fun we hit an old AGS+ router with 10.2(4) code on it.. Apparently older code is vulnerable too.. So.. everyone running AGS+'s in the core, beware.. *grin* On Fri, 2003-07-18 at 11:34, Jason Frisvold wrote:
Ok, update to my testing :
On Fri, 2003-07-18 at 10:48, Jason Frisvold wrote:
Hi all,
First post.. I hope this is ok ...
We tested the Cisco vulnerability and I wanted to share our results with you ... <SNIP> Testing scenario is this :
Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 <SNIP>
Firstly, HPing (www.hping.org) can craft the packets required for this attack very simply... I won't post the exact command string, but it's not that hard to figure out... And with HPing, you can easily take down an interface in under a second.
Now, on to ACL testing...
3 ACL tests just to make sure we had everything correct ... We first tried the any any ACL that Cisco recommends :
access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any access-list 101 permit ip any any
This produced expected results. When placed on the interface, it prevented the router from being attacked.
Next, we tried an ACL with just the interface IP in it :
access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 permit ip any any
We applied this to the Ethernet0 interface on the 2514. Attacks to that IP were prevented as expected.
Attacks through to the 2501 were not blocked, again as expected.
And finally, attacks to the ethernet1 interface on the 2514, which passes through the ethernet0 interface, still caused the ethernet0 interface to be attacked.
And the last test was an ACL containing all of the IP's on the router:
access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 deny 53 any host 192.168.0.1 access-list 101 deny 55 any host 192.168.0.1 access-list 101 deny 77 any host 192.168.0.1 access-list 101 deny 103 any host 192.168.0.1 access-list 101 permit ip any any
This blocked all attacks on the 2514 while still allowing attacks through to the 2501.. This is as expected.
Also, another note. Loopback interfaces, while not vulnerable themselves, make it much easier to completely take out routers.. (We're assuming that the device is still vulnerable) If the attacker has the loopback of the router, they can run an attack at that interface. Every input interface will be attacked in succession. As each interface goes down and the traffic re-routed, the next interface will fall under attack.
Just be sure to add the loopback IP as part of the ACL ... :) --
Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]
Jason Frisvold writes:
Just for fun we hit an old AGS+ router with 10.2(4) code on it.. Apparently older code is vulnerable too..
You are correct. The vulnerability was introduced back in 1994 in a patch that was integrated into 10.0(6.1) and 10.2(1.6). The vuln is present in any release that follows in those same trains, such as 10.2(4) as you confirmed above, as well as in all of 10.3. All other prior versions of IOS do not contain the software that introduced the vulnerability and are probably not vulnerable, but I will not be able to confirm that by testing it.
So.. everyone running AGS+'s in the core, beware.. *grin*
The workarounds should apply, but not much else. ;-) Jim == Jim Duncan, Critical Infrastructure Assurance Group, Cisco Systems, Inc. jnduncan@cisco.com, +1 919 392 6209, http://www.cisco.com/go/ciag/. PGP: DSS 4096/1024 E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821
All other prior versions of IOS do not contain the software that introduced the vulnerability and are probably not vulnerable, but I will not be able to confirm that by testing it.
So.. everyone running AGS+'s in the core, beware.. *grin*
The workarounds should apply, but not much else. ;-)
"We are C. We never have a fix. We have a patch... after patch.... after patch... after patch... after patch... and at some point there is no more patches, but there is no fix either" I have this brilliantly simple idea that somehow everyone forgets, while they tout all the new "advanced stuff". Do not introduce yet another name for filtering that works only in some cases. Fix the filtering code so we can filter *anything* at *any packet rate* on *any interface* that pass *any traffic* without bringing the router to its knees. Alex
alex@yuriev.com wrote:
I have this brilliantly simple idea that somehow everyone forgets, while they tout all the new "advanced stuff". Do not introduce yet another name for filtering that works only in some cases. Fix the filtering code so we can filter *anything* at *any packet rate* on *any interface* that pass *any traffic* without bringing the router to its knees.
Already done, however, the only prototype source code is still in test mode, in the same facility as the WMD, in Iraq.... David Kelly has been dispatched by Tony Blair, It -=should=- be here any minute now... :\
Alex
participants (5)
-
alex@yuriev.com
-
Jason Frisvold
-
Jim Duncan
-
Peter Galbavy
-
Richard Irving