🚀 go-pugleaf

It is as per the info in the CERT alert. If you send a number of
packets say 70-100, with the IP protocol set to anyone of (53 55 77
103) and TTL=1 (when the packet reaches the target) then the
router/switch/AP in question running the vulnerable IOS will process
any further traffic from that interface. There are a number of way you
can test this our in your lab, some of these tools are hping, nemesis,
etc.

Bill Johnston <wdj-netconsult@consultant.com> wrote in message news:<Xns93C1BACF3C55Awdjohnstoncomcastnet@206.127.4.25>...
> [posted and mailed]
> 
> I've read the alerts from Cisco, SANS, and CERT
> regarding the latest IOS flaw, which identify 
> only the potential for denial of service attacks
> to be directed at certain well-known TCP ports.
> 
> A SAN "Flash" publication noted that an exploit
> had been observed "in the wild".  Unfortunately,
> it neglected to describe the vehicle for this 
> exploit in even a basic way that could help 
> Cisco admins plan a rational IOS migration 
> strategy.  
> 
> This could be done without disclosing any sensitive 
> and potentially re-exploitable information about 
> the flaw(s) in IOS, how those flaw(s) were 
> originally compromised, or indeed what were the 
> precise technical consequences.  Such sensitive  
> information would indeed be more likely to help 
> a malicious cracker more than an end-user Cisco 
> admin.  (Even though we all crave knowledge of 
> the nitty-gritty and hate to admit that we don't
> always "need to know".)
> 
> At this time, and due to the potential severity 
> and ubiquity of this incident, no harm could 
> come from telling the public certain information
> about the vehicle(s) for any "in-the-wild" exploits
> that are observed.  For example, if merely knowing 
> that we are facing an virus, worm, or trojan horse 
> that runs on platform XYZ can be helpful in planning
> and prioritizing a response.   
> 
> Certainly, the existence of one exploit means 
> that others could come, and no Cisco admin worth 
> a damn would take a preliminary announcement
> and base an entire strategy upon that first piece 
> of data to the exclusion of all others.
> 
> But if I knew RIGHT NOW that the exploit was 
> being delivered in "Dancing Baby"-like Wintoys 
> that are getting schlepped around the net on 
> various instant message systems, that means 
> I can't be content with just upgrading my 
> Internet gateway router to avoid external 
> DDoS attacks.
> 
> It would mean that eventually the Windows 
> machines inside my private LAN will also be
> attacking my internal routers - the 6509 
> that handles my VLANs, and all the dinky 
> routers that talk to my EDI partners and 
> my regional offices, etc.  These routers 
> MUST listen on some the ports that this 
> particular Cisco exploit utilizes, etc.  
> 
> And in the case of the EDI partners and perhaps 
> the frame network to my regional offices as well,
> perhaps we don't even control those boxes, so I 
> need to know NOW if I should start shouting at 
> the service providers so they'll install upgrades.
> 
> Or, if the "wild exploit" is instead something
> akin the old SAdmin/IIS aka CodeRed attack,
> in which compromised Sun boxes fired attacks 
> solely at public IP addresses, before doing 
> the rest of their dirty work, well, then, we 
> can may be able to plan our Cisco update strategy
> by installing the recommended IOS revisions 
> on our Internet facing Cisco gear first, and 
> then await further info from Cisco/SANS/CERT,
> et al, before embarking on the laborious and 
> risky process of testing and migrating other 
> Cisco gear with layer 3 functionality.
> 
> Loose lips sink ships ... sometimes.  In other
> cases, unwarranted secrecy only serves to give
> the enemy more time to develop variations on 
> attack scenarios, while leaving our troops 
> unable to organize and prepare basic defenses.
> 
> "Go upgrade EVERYTHING", just isn't an adequate
> set of marching orders.  Even if that is the 
> ultimate goal, one must have some information 
> if one is to plan, prioritize, and execute a 
> rational response.
> 
> - Bill