IOS exploit: please disclose vehicle, not mechanism
Bill Johnston
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
--
Bill Johnston
Johnston Network Consulting Services
14758 Chisholm Landing Way
Gaithersburg, MD 20878
301-717-8894
wdj-net...@consultant.com
jankemi(remove)
> [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.
>
IP Protocols, not 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.
>
Cisco's alert was revised last week to include specific ACL's that will
stop the attack. Our ACL's went in last Thursday evening.
[snip]
> "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
The information exists in Cisco's announcment.
--Mike
Amazing
whine, you could have carefully read the advisory and took steps to mitigate
the chances of being affected by this vulnerability.
"Bill Johnston" <wdj-net...@consultant.com> wrote in message
news:Xns93C1BACF3C55Awd...@206.127.4.25...
asrap
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-net...@consultant.com> wrote in message news:<Xns93C1BACF3C55Awd...@206.127.4.25>...
Jeff C
$wk6....@rwcrnsc52.ops.asp.att.net:
Mike,
Like you we placed the access-lists up nearly immeadately and as we have
to opportunity to upgrade IOS we can remove them. One thing that I
noticed is that I didn't get any hits. Have you noticed any hits on
yours?
Thanks,
-Jeff C
Adrian Jensen
[snip]
>
> Like you we placed the access-lists up nearly immeadately and as we have
> to opportunity to upgrade IOS we can remove them. One thing that I
> noticed is that I didn't get any hits. Have you noticed any hits on
> yours?
>
I've got an administrator friend at a local hosting company here.
Talking to him the other day, he is seeing 2 or 3 attempted exploits
(seemingly random atttacks) a day in their IP space.
As for the exploit code itself. I've seen it, downloaded it, compiled
it. It works as advertised, just a simple command line utility. Give it
the IP to attack and the proper TTL, you have to be just slightly
smarter than a script kiddie to use it.
Adrian
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Bill Johnston
news:3F1FF243...@hotmail.com:
> As for the exploit code itself. I've seen it, downloaded it, compiled
> it. It works as advertised, just a simple command line utility. Give
> it the IP to attack and the proper TTL, you have to be just slightly
> smarter than a script kiddie to use it.
Thank you. This is a helpful response.
The "vehicle", at present, is therefore not yet
something that is likely to be plonked surreptiously
onto clueless users' desktops inside private networks.
Knowing this *is* useful for Cisco admins who have
to prioritize their response among many boxes, both
at the public edge and at the core of the network.
Bill Johnston
"jankemi(remove)" <"jankemi(remove)"@mail.com> wrote in news:LqFTa.116237
$wk6....@rwcrnsc52.ops.asp.att.net:
> Bill Johnston wrote:
>> [...] certain well-known TCP ports.
> IP Protocols, not TCP ports.
Whoa! Perhaps you should alert the IANA
as well. It is almost as if we've all been
using the same terminology for the past
twenty-five years and we all know what
we mean by it. Perhaps it's a conspiracy?
> Cisco's alert was revised last week to include specific ACL's that will
> stop the attack. Our ACL's went in last Thursday evening.
The problem with these ACLs - "Transit ACLs",
to be precise, is that when applied to edge
routers earlier than 75xx or 12xxx series,
the recommended line:
access list ### 101 deny 53 any any
means that DNS requests get blocked, with no
workaround available. If you happen to be an
organization that handles its own external DNS,
this is ungood. Cisco acks this fact in the
advisory:
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
by noting in italics that:
"ACLs can have performance impact on certain platforms,
so care should be taken when applying the recommended
workarounds."
Further to this, they hint (barely) that the one of the
solutions to the problem I cite above is to create
something called "Receive ACLs", which are described in:
http://www.cisco.com/warp/public/707/racl.html
The problem with racls, which could in principle
catch and allow DNS traffic (as well as 55,77, and
103) to be handled before this IOS flaw apparently
rears its ugly head, is that racls are currently
supported on very few platforms (75xx and 12xxx)
for only certain IOS versions.
So once again, merely applying the Transit ACLs
given in the Cisco advisory referenced by CERT
and SANS is not a sufficient solution for an
enterprise network.
> The information exists in Cisco's announcment.
Not the information that I was asking for, Mike.
The reason that I ask for information on the
Usenet is because I know that I am not the
world's greatest expert on networking. But
in addition in asking questions on the net,
I have been answering them since 1988.
Politely, my young man.
fugi
> [posted and mailed]
> "jankemi(remove)" <"jankemi(remove)"@mail.com> wrote in news:LqFTa.116237
> $wk6....@rwcrnsc52.ops.asp.att.net:
>> Bill Johnston wrote:
>>> [...] certain well-known TCP ports.
>
>> IP Protocols, not TCP ports.
> Whoa! Perhaps you should alert the IANA
> as well. It is almost as if we've all been
> using the same terminology for the past
> twenty-five years and we all know what
> we mean by it. Perhaps it's a conspiracy?
>
>> Cisco's alert was revised last week to include specific ACL's that will
>> stop the attack. Our ACL's went in last Thursday evening.
> The problem with these ACLs - "Transit ACLs",
> to be precise, is that when applied to edge
> routers earlier than 75xx or 12xxx series,
> the recommended line:
> access list ### 101 deny 53 any any
> means that DNS requests get blocked, with no
> workaround available. If you happen to be an
> organization that handles its own external DNS,
> this is ungood. Cisco acks this fact in the
> advisory:
no that specifies the protocol. not the port.
> http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
> http://www.cisco.com/warp/public/707/racl.html
> Politely, my young man.
--
The complexity of a weapon is inversely proportional to the IQ of
the weapon's operator.
John C. Ring, Jr.
>access list ### 101 deny 53 any any
>
>means that DNS requests get blocked, with no
>workaround available.
access-list 101 deny udp any any eq domain
access-list 101 deny tcp any any eq domain
would block DNS service. "deny 53 any any" denies IP protocol 53, not access
to udp/tcp port 53.
fugi
> Jeff C wrote:
> [snip]
>>
>> Like you we placed the access-lists up nearly immeadately and as we have
>> to opportunity to upgrade IOS we can remove them. One thing that I
>> noticed is that I didn't get any hits. Have you noticed any hits on
>> yours?
>>
> I've got an administrator friend at a local hosting company here.
> Talking to him the other day, he is seeing 2 or 3 attempted exploits
> (seemingly random atttacks) a day in their IP space.
> As for the exploit code itself. I've seen it, downloaded it, compiled
> it. It works as advertised, just a simple command line utility. Give it
> the IP to attack and the proper TTL, you have to be just slightly
> smarter than a script kiddie to use it.
> Adrian
no it doesn't, my code I posted on the day the advisory came out
at 11:30pm was abused by someone who got it from a friend that
wasn't supposed to give it away. hence the sending via PGP and the
sentence "don't distribute this". mine calculated the ttl to send
in the packet with a traceroute, and there was a field for "ttl
padding". a number that represented a negative and positive offset
to add accountability for the oops factor. that's what I get for
writing user friendly code.
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
--
Chris
> to be precise, is that when applied to edge
> routers earlier than 75xx or 12xxx series,
> the recommended line:
>
> access list ### 101 deny 53 any any
>
> means that DNS requests get blocked, with no
> workaround available. If you happen to be an
> organization that handles its own external DNS,
> this is ungood. Cisco acks this fact in the
> advisory:
>
> http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
>
IP Protocol 53 -- SWIPE -- a network-layer encrypted encapsulation protocol
for IP; pre-dates IPsec and seems not to have been widely implemented
For someone who works for a Network Consulting Services company you really
aren't paying much attention to the details are you? Know the difference
between an IP protocol and a TCP/UDP port!
Chris.
Jim Kirby
>
> Mike,
>
> Like you we placed the access-lists up nearly immeadately and as we have
> to opportunity to upgrade IOS we can remove them. One thing that I
> noticed is that I didn't get any hits. Have you noticed any hits on
> yours?
>
> Thanks,
> -Jeff C
I'm not Mike, but no, we've not seen any hits on the ACL either and
ours too have been in place for nearly a week. Granted, we are a
somewhat non-target, but it appears to me that the "exploit" was a non
starter.
jk
Beavis
> [posted and mailed]
>
> "jankemi(remove)" <"jankemi(remove)"@mail.com> wrote in news:LqFTa.116237
> $wk6....@rwcrnsc52.ops.asp.att.net:
>
> > Bill Johnston wrote:
>
> >> [...] certain well-known TCP ports.
>
> > IP Protocols, not TCP ports.
>
> Whoa! Perhaps you should alert the IANA
> as well. It is almost as if we've all been
> using the same terminology for the past
> twenty-five years and we all know what
> we mean by it. Perhaps it's a conspiracy?
>
IP protocols and TCP ports are not the same thing. I don't think IANA
will need to be alerted to this fact.
> > Cisco's alert was revised last week to include specific ACL's that will
> > stop the attack. Our ACL's went in last Thursday evening.
>
> The problem with these ACLs - "Transit ACLs",
> to be precise, is that when applied to edge
> routers earlier than 75xx or 12xxx series,
> the recommended line:
>
> access list ### 101 deny 53 any any
>
> means that DNS requests get blocked, with no
> workaround available. If you happen to be an
> organization that handles its own external DNS,
> this is ungood. Cisco acks this fact in the
> advisory:
>
> http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
>
> by noting in italics that:
>
> "ACLs can have performance impact on certain platforms,
> so care should be taken when applying the recommended
> workarounds."
>
> <<SNIP>>
This does not affect DNS in any manner whatsoever. If we were talking
TCP ports, then yes, it would. But we are talking about IP protocols
here, and 53 does not correspond to DNS. What Cisco acknowledges in
the above quote is that access lists can have performance impacts
because all packets must be compared to them, not because there was
anything related to DNS.
Bill Johnston
> IP Protocol 53 -- SWIPE -- a network-layer encrypted encapsulation
> protocol for IP; pre-dates IPsec and seems not to have been widely
> implemented
Now that is a good answer. Thank you, Chris. I see
now that the premise of my previous article and questions
were wrong. That's a GOOD thing, because I'll bet
that I am not the only fool on the planet that read
an access list containing the number 53 and associated
it with DNS. I should have caught my own error, because
I did indeed check and and notice the mismatch between
the description of IANA TCP port number 103, and the
reference that Cisco's alert doc made to the PIM IP
multi-cast related protocol before I posted even the
first article yesterday.
So if I had had my thinking cap on, my first question
should have been "please help me understand this,
kind readers".
> Know the difference between an IP protocol and a TCP/UDP port!
Clearly, I don't and I didn't. My bad.
Now, please understand that the rest of this article is
a followup to the thread, and is not meant to reflect on
Chris, who has just done me the courtesy of providing an
answer that educated me, rather than merely squeaked that
I was an idiot and then hid behind the bushes again.
So please understand that none of the rest of this article
is directed at "Chris <never@work>".
My ignorance on the meaning of the number in router ACLs
could stem from the fact that I spent more time diddling
my clients' PIX boxes, on which port blocking and port
redirection (PAT) is a major concern. To be sure, this
use of port numbers typically occurs in the "conduit"
command lines, but those are ones that often get the
most work and rework as a new firewall is set up.
Like many engineers, I keep a library of old configs,
and it turns out that the most complex router acl that
I have on file doesn't specifically cite any IP protocols
by number; there were 8 acls that primarily served as
ingress and egress filters to be applied to certain
interfaces for certain internal address blocks.
One tends to learn concepts according to technical
necessity. Unlike many who "lurk" on the net, I have
never minded asking a "dumb" question, or in this case,
making a suggestion that could potentially expose
ignorance on my part. In such cases, the followups
usually turn out to be educational, both for me,
and I daresay for a few other folks out there who,
like me, have never had occasion to need write a
router ACL citing an explicit IP protocol.
So thanks again of behalf of my fellow ignorami
and lurkers.
For the rest of y'all, please remember that the
purpose of Usenet groups is the asking and answering
of questions, efficient dissemination of information
to "BoF", and the discussing of ideas.
If you'll recall, both the title and the main point
of my original post was to suggest that we'd all
benefit by knowing how this particular exploit
was being launched - the "vehicle", if you will.
NO ONE took serious exception to this main idea,
or at least, no one did so cogently. Instead,
various members of the peanut gallery sniped
that the question wasn't necessary because the
acls provided by Cisco mitigated the problem.
Well, for those of you who are not capable of
extrapolation or abstraction, the core issue
here concerns the very high level of secrecy
that now surrounds security announcements from
the likes of CERT, SANS, and vendors. Sometimes
it makes sense; often it does not. This time
it did not, REGARDLESS of whether Cisco's fix
mitigated the problem, and REGARDLESS of whether
my missing the distinction between IP protocol
and TCP or UDP port number within Cisco acl
syntax meant that I had over-estimated the
seriousness of the threat posed by this latest
IOS flaw.
My topic dealt with the policy issue of information
control. For those of you who were in the business
pre-9/11/98, say (note the year, will ya?) by which
time we all agreed that information security was
important and some were starting to declare that
immediate full disclosure wasn't ALWAYS, AUTOMATICALLY
the right thing to do, which is what we'd believed
in the past ... we now frequently have to deal with
the flip side of the coin. Believe it or not, it
is still legal in this country to want more info
than your vendor is willing to provide.
So, in this case, one fellow was kind enough to
provide a useful answer to my "vehicle" question.
At least one other was interested enough in that
gentleman's post to follow up on the same topic.
> For someone who works for a Network Consulting Services company you
> really aren't paying much attention to the details are you?
Please note the company name in the .sig, below. As a one-man
shop, I don't get the chance to configure enterprise gear
as often you might think, though I still dutifully provide
information to my old clients because *I* built their networks
and *I* stand by my work even after the companies I worked for
bite the dust. Now I did get the play with the big toys at my
last "real" job, working as a CCNA/DA-level engineer for Verizon
(Cisco Gold) before they shrank their network integration business
to just letting union guys install pre-configured edge routers
whenever the telco guys sell a new circuit. Prior to that,
I did enterprise Cisco and MS design and billable consulting
work for a very successful Cisco Silver that unfortunately
got sold to Bell Atlantic pre-Verizon. And while I was WAY
far from being their top dog - even as a 200-seat company
they had plenty of CCNPs and two CCIEs - I WAS their
"detail man". I wrote the contracts, the SOWs, did
the designs, and then handed the jobs off to younger
engineers for implementation.
These days I'm more likely to be found on my hands
and knees vacuuming out a sh*tty PC in a doctor's
office that they insist on calling a "server",
and trying to persuade them to invest in a UPS
and a tape backup system. Laugh all you want,
but YOU folks go out and try setting up your
own accounting systems, soliciting your own
customers, and collecting on your own past-due
invoices. Try dealing with a clueless client
who threatens to sue YOU for something he doesn't
understand, even though YOU just fixed his problem
yanked HIS nuts out of the fire.
Sure, I'd give my left nut to get back into full-time
Cisco work, but there's been a bit of a shortage of that
in the DC area for guys without Active Secret tickets
since the dot-bombs went bust. Anyone interested in
working with an honest engineer with Cisco and MS certs,
plus six years in the systems integration biz? I've
sent resumes to companies offering positions as low
as PC support, and offered to take any job on the
totem pole to get back in the door with former clients
whose networks I designed, built, and implemented, even
though I made six figures in my last two years at VZ.
I've freely offered to work for less than half of that,
to sign a stay-on contract at a fixed salary for X years,
and even do the first month or so as an unpaid volunteer.
That's the state of the job market in DC, unless you're
eligible for cleared security work.
Lastly, as for those who are feel the need to complain
about long posts to the Usenet, may I ask just who exactly
is forcing you to read this? Killfile me if you feel the
need. If you have access to really old usenet archives and
grep for john...@me.udel.edu in gnu.* groups circa '88-'91
(pre-Linux) through '94 or so, you'll see that I've paid
my dues many times over here in never-never land, answering
far more questions than I've asked, and contributing my
share in the freeware and patch department.
And for those of you who post hiding behind unreachable
or non-existent email addresses, sniping only at the
edges of the some of the points I've made in my "long",
"whiny" posts, well, have a look at my .sig. Never
once in my life have I posted to the net without
including my real name, address, phone number, and
email address.
And my current IP addy is 68.50.36.39. ;-)
Have at it, kiddies.
jankemi(remove)
>
> Like you we placed the access-lists up nearly immeadately and as we have
> to opportunity to upgrade IOS we can remove them. One thing that I
> noticed is that I didn't get any hits. Have you noticed any hits on
> yours?
>
> Thanks,
> -Jeff C
None - but I'm pretty sure that our upsteam ISP is blocking those
protocols also.
--Mike
jankemi(remove)
>
> by noting in italics that:
>
> "ACLs can have performance impact on certain platforms,
> so care should be taken when applying the recommended
> workarounds."
>
We have input ACL's on our edge routers anyway, to block RFC1918
addresses & various other unwanted protocols. We added 3-4 more lines to
those lists. I've always assumed that most organizations already have
some kind of ingress ACL. Maybe not though?
Our experience has been that ACL processing is not a major problem on
our platforms (72xx's, 36xx's and 26xx's).
> Not the information that I was asking for, Mike.
You asked for the vehicle. I though that 'Multiple IPv4 packets with
specific protocol fields sent directly to the device' was the vehicle.
Perhaps you consider that the mechanism?
>
> Politely, my young man.
>
I'm not intending to be rude. If I'm short it's because I'm too lazy to
type long messages.
> - Bill
jankemi(remove)
>
> Well, for those of you who are not capable of
> extrapolation or abstraction, the core issue
> here concerns the very high level of secrecy
> that now surrounds security announcements from
> the likes of CERT, SANS, and vendors. Sometimes
> it makes sense; often it does not. This time
> it did not, REGARDLESS of whether Cisco's fix
> mitigated the problem, .......
I thought that in this case Cisco did what was reasonable. After
dicovery of the flaw they warned me & told me to upgrade all IOS devices
but witheld the information I'd need to write an exploit. As soon as
exploit code was publicly available they advised me to mitigate with
ACL's until the upgrades were complete.
What should they have done differently? Disclosed more information sooner?
--Mike
Walter Roberson
Bill Johnston <wdj-net...@consultant.com> wrote:
:My ignorance on the meaning of the number in router ACLs
:my clients' PIX boxes, on which port blocking and port
:redirection (PAT) is a major concern. To be sure, this
:use of port numbers typically occurs in the "conduit"
:command lines, but those are ones that often get the
:most work and rework as a new firewall is set up.
I would interpret that paragraph as indicating that you
do not do any IPSec work, and that you are working primarily
on old PIX boxes -- probably PIX 4.2 boxes that haven't been upgraded
much past 5.2.
If you were working with IPSec, then you would very likely have run
into issues of getting IPSec working through a filter or firewall,
which would have led you to references to AH, ESP, or GRE, and you
would likely have encountered the numeric protocol specification
syntax.
If you were working with newer PIXes from scratch or PIXes that
were being kept up to date into the 6.x era, you would be using
ACLs instead of conduits. Also, 6.x especially tends to work with
port names instead of port numbers [but accepts numbers still].
My inference would be that your PIX skills are not really up to date.
If you can afford it, I would suggest that you invest in a PIX 501
for learning purposes. [Someone suggested recently that the 501E will be
out soon; I don't know anything about that.]
--
Look out, there are llamas!
Adrian Jensen
[snip]
>
> no it doesn't, my code I posted on the day the advisory came out
> at 11:30pm was abused by someone who got it from a friend that
> wasn't supposed to give it away. hence the sending via PGP and the
> sentence "don't distribute this". mine calculated the ttl to send
> in the packet with a traceroute, and there was a field for "ttl
> padding". a number that represented a negative and positive offset
> to add accountability for the oops factor. that's what I get for
> writing user friendly code.
>
>
Oh yah? Your "[L0cK]"??? Your description doesn;t match the code I saw,
it was not PGP signed, did not have a "do not distribute" message, and
you have to calculate the TTL (with a ping according to the comment), it
doesn't do it for you.
Adrian
Adrian Jensen
[snip]
> The "vehicle", at present, is therefore not yet
> something that is likely to be plonked surreptiously
> onto clueless users' desktops inside private networks.
>
There has been a lot of talk on various admin lists about the posibility
of someone integrating the code into a Kleez/BugBear/etc. virus and
creating a massive distributed DOS attack network. As of yet, I haven't
seen anything rummored to be in existance, just lots of speculation.
Seems kind of silly to worry about to me, there are already so many
other exploits and zombie/DOS type of tools out there.
fugi
> [snip]
>>
>> no it doesn't, my code I posted on the day the advisory came out
>> at 11:30pm was abused by someone who got it from a friend that
>> wasn't supposed to give it away. hence the sending via PGP and the
>> sentence "don't distribute this". mine calculated the ttl to send
>> in the packet with a traceroute, and there was a field for "ttl
>> padding". a number that represented a negative and positive offset
>> to add accountability for the oops factor. that's what I get for
>> writing user friendly code.
>>
>>
> Oh yah? Your "[L0cK]"??? Your description doesn;t match the code I saw,
> it was not PGP signed, did not have a "do not distribute" message, and
> you have to calculate the TTL (with a ping according to the comment), it
> doesn't do it for you.
> Adrian
no I'm not. you do realize there were like 20 different people who
posted code for it. and for the TTL setting... ok I think even a
script kiddie can do a traceroute. however they may pound a router
for an hour with it looping because it's not going down because
they never checked to see if the route was filtered. otherwise,
hping,sendip,packet, and other system tools are good for script
kiddies too. not all that complicated...
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
--