----- Original Message -----
From: "Derek Martin" <[EMAIL PROTECTED]>
To: "Rich Cloutier" <[EMAIL PROTECTED]>
Cc: "gnhlug" <[EMAIL PROTECTED]>
Sent: Sunday, July 08, 2001 7:40 PM
Subject: Re: grc.com Ddos analysis
> On Sun, Jul 08, 2001 at 01:33:00PM -0000, Rich Cloutier wrote:
>
> >> They need to be compromised first. My point was that it is
> >> trivially easy to compromise a Win9X machine. Once the system is
> >> compromised, the attacker can do anything he or she wants.
> >
> > You're confusing the issue. We are discussing (or at least I am) a
"stock"
> > Win9x machine being compromised by a virus, and being incapable of
source IP
> > address spoofing, versus a "stock" WinXP machine being compromised by a
> > virus, that IS capable of source IP address spoofing.
>
> Ben's point is that there is NO difference. Once one of either is
> compromised, the attacker has sufficient control over the machine to
> either begin forging packets immediately, or to first install a tool
> kit which allows it, if the system is incapable by default. Since the
> attack is generally automated, one need only have access to such a
> tool kit, and the difference between the two cases is inconsequential.
> The amount of time to add that functionality to the Win 9x machine
> that doesn't have it is inconsequential. The only real question is
> whether or not the person who engineered the attack cares enough to
> bother. Obviously, in the majority of cases to date, the answer to
> that question is "no."
Oh, but there IS a difference. The standard bot that perpetrated the attack
on grc.com is of limited functionality. It does not give the malicious
hacker complete control over the system, as a root kit for Linux would do.
It simply accepts commands from an IRC channel to begin sending the types of
packets the attacker wants, and to report its online status. Whether other
types of bots do provide this capability, I don't know.
>
>
> >>> Win 2k DOES have a raw sockets API.
> >>
> >> I'm confused. I thought Steve Gibson was up in arms because WinXP
> >> included a raw sockets API for the first time. Is he wrong, or am
> >> I?
> >
> > Win2K is the first MS OS to include a raw sockets API. Gibson states he
is
> > not concerned too much with Win2K machines because they are limited in
> > number compared with user machines, and usually are in the hands of more
> > security-conscious people.
>
> I would agree that there are, as yet, reletively few instances of
> W2k. Eventually I would expect that to change, as Microsoft phases
> out support for NT4 and Win9x products. Then, the majority of
> platforms running Windows will be W2k and WinXP systems. One can only
> speculate as to the mix, but it's hardly relevant. Since both of
> these product lines will have the API, it's obviously something
> Microsoft feels its products need, which is almost certainly because
> it's been requested by their customers.
>
> I would not agree that the people running W2k tend to be more security
> concious. My personal experience is quite the contrary. In fact, I
> do not know of anyone, other than one of the SANS Institute's
> instructors, who is running W2k that I would consider security
> conscious (though I certainly may know people who are both, but be
> unaware of that fact). But my statistical sample is admittely far too
> small to make any kind of conclusion based on that.
Then that is Gibson's miscalculation, isn't it? At least Win2K has a
slightly better security model than XP, AFAIK.
>
> In my experience, people I know who run Win2k do so because a) it came
> on the computer that they purchased, and/or b) because it's the
> newest, coolest thing from Microsoft. Not because they're security
> concious.
>
> >>> If it were truly trivial, I would think it would be done more.
> >>
> >> You're not a malicious hacker. Neither am I. I do not know what
> >> might motivate such a person; all I can do is suppose. I can only
> >> guess that right now, such people (I use the term advisedly) find
> >> it more fun to go after unsecured Linux systems, because the tools
> >> are already present.
> >
> > Most of these people do not have the skills to develop or even fully use
> > most of these tools themselves. They download them, receive brief
> > instruction from the developer of the tool, or from a more knowledgable
> > cracker, and they're off and running. The vast majority couldn't create
a
> > hack themselves if their lives depended on it. This situation applies to
> > tools developed on open source Linux systems or using Microsoft's closed
> > source APIs and a pirated copy of Visual Studio.
>
> Exactly. So these people are dependent upon the developer of an
> exploit to provide this functionality. One can imagine several
> reasons for the developer of the exploit not providing that
> functionality, such as being too lazy, unwilling to spend the money to
> buy such a tool kit, or just not interested. It's not unreasonable to
> think that they won't even use the exploit themselves. Most people
> who write exploits don't. They provide them as a "proof of concept"
> to the software industry, as incentive to get off their collective
> duff and fix the problems. They're (largely) not written to evade
> detection. They're written to make a point. And then used by bored
> teenagers to wreak havoc on unsuspecting users who are either unaware
> of the fixes or too lazy or too busy to use them.
Good points. This may be one answer my question.
>
>
> > If these malicious hackers could indeed trivially include patches to
> > enable source IP spoofing, I'm sure they would do it as a matter of
> > course.
>
> I've just given several good reasons why this might not be true.
> Another might be that someone who is crafting a malicious attack wants
> to do it fairly quickly. In the interest of haste, they may not want
> to take the time adding the extra features to their little hack.
These are not custom hacks whipped up on the spur of the moment to do each
attack. The bots are developed and improved over time, going through
revisions and "release cycles" as new features are added. They are sent out
as viruses, and each malicious hacker has his own army of them, responding
only to his password, and rallying on his chosen IRC channel, waiting to do
his bidding. They use the size of their armies, and the proportion of bots
on high speed channels like DSL and cable, as status symbols, just like
investment bankers use their BMWs. If there were a feature that would enable
these bots to avoid detection and removal, I'm sure it would be included to
prevent attrition within the bot army.
> Their main goal (after the compromise itself, of course) would not be
> to prevent the detection of systems used in their attack, but to
> prevent detection of their identity. They can accomplish this in
> other ways...
>
>
> > know why it isn't done more, like I said; there must be some
> > limiting factor that I am not aware of, and that makes Windows XP
> > such an anticipated arrival by these malicious hackers.
>
> You're assuming that Steve Gibson is correct; I rather think that the
> malicious hackers largely just don't care about the raw socket API one
> way or the other. If they did, I think they'd just target Unix and
> Linux systems, of which there are plenty enough on the Internet which
> are vulnerable and capable of acting in such a role. Last I'd
> checked, Apache running on some form of Unix was still the leader for
> web servers (though this may have changed recently). Vast numbers of
> mail servers run Unix, and Linux is running on an estimated 30 million
> computers worldwide, many of which are at Universities (both in dorms
> and in labs) with big fat pipes. It's just not reasonable to argue
> that there aren't enough machines with this capability for attackers
> to use in a DDoS, nor that they're all too well secured to be
> vulnerable. All you need is a couple of hundred or so machines...
> probably a lot less to take down many sites with smaller pipes.
This is true. Maybe there are several "hacker philosophies" regarding which
operating system to use in attacks, along with the requisite flame wars on
the hacker news groups! ;o)
>
> >>> The point is that this capability will be present BY DEFAULT on
> >>> Windows XP machines.
> >>
> >> Any computer capable of performing useful tasks on a network (by
> >> default or otherwise) is capable of performing malicious tasks.
> >> Getting upset over one specific instance is silly.
> >
> > Gibson's point is that for an OS that is available to the masses to have
a
> > raw sockets API provides increased capability for malicious activity
while
> > it DOES NO GOOD for the user of the system.
>
> This is simply not true. There are lots of reasons why you might want
> to create raw sockets. For example, development of a new network
> protocol. Another is to generate specific traffic for testing network
> devices. I'm sure the people on this list could enumerate at least a
> dozen more...
None of which the average email sending, web surfing, online shopping user
needs to have.
The point is, the peole who really need it can get it. Why deliver it to
those who DON'T need it, when it will probably only be used for Bad Things?
>
> It's probably true that the AVERAGE user of such a system has no use
> to do these things, but remember that Microsoft wants EVERYONE to use
> their OS, and there are LOTS of people with a need to do this sort of
thing.
So let it be part of the MSDN or network SDK. And I take issue with your use
of the term LOTS. Relatively, I think there is a small percentage of total
Windows users who NEED this sort of capability.
>
> > > Steve Gibson actually comes close when he talks about accountability
and
> > > awareness: What needs to be done is people need to be made aware of
the
> > > security issues inherent in any public network, they need to be made
aware
> > > that *everyone* needs to worry, and they need to be held accountable
for
> > doing
> > > so.
> >
> > True. And the malicious hackers need to be held accountable for their
> > actions too. Taking away a kid's computer for two years is not a strong
> > statement of how serious an offense it is to break into
computers--having
> > him make license plates IS.
>
> Ah, but now you're talking about changing our entire criminal justice
> system. The crime committed here is usually little more than the
> equivalent of vandalism, and the reality is that a juvenile is likely
> to get less of a punishment than that, if found guilty of such a
> crime. One thing we do NOT need is punishments that do not fit the
> crime, or that are inconsistent with the severity of punishments for
> similar crimes...
Most of these kids just want a little recognition and fame anyway. They
obviously can't get it from their parents or peers, so they get it from
others in their hacker community. Most of the big-time malicious hackers who
got caught now have prestigious security jobs, or write for trade journals.
THEY accomplished their goal. A slap on the wrist will not stop this type of
"vandalism," IMHO.
>
> That said, I'm all for holding crackers accountable (as well as their
> non-techie vandal counterparts). IF you can find them, that is. An
> oft-overlooked point is that these attacks often originate in
> countries where what they've done ISN'T a crime, such as in Russia or
> China. Sorry, but you're just not going to get to these people. I've
> even heard that at some Universities in other countries, hacking a
> U.S. computer system is a requirement for the computer corriculum.
I don't know about that, but you're right that the rules are much more lax
in foreign countries. I wonder if network admins could block ALL traffic
from rogue countries or especially security-indifferent domains?
>
> I'm much more interested in holding the software companies accountable
> for their inaction. THIS might get you somewhere. I also feel that
> the ISPs should have a responsibility to inform their customers about
> the risks they're undertaking by connecting to the Internet. They
> won't do that voluntarily though, because you don't sell Internet service
> that way.
Some ISPs are more security conscious than others. Some just want to get
users, and they realize that a large portion of their customer base are
"fringe" users who do things they couldn't get away with on other providers.
If network admins could block traffic from these "bad" domains, the good
users would find other ISPs, or the ISPs would modify their policies.
>
>
> > > > If someone INTENTIONALLY installs a raw sockets capability ...
> > >
> > > How many people "intentionally" install a virus?
> >
> > How is this relevant? My point was that a raw sockets capability
> > "intentionally" installed by someone who really needs it and is aware of
its
> > capabilities and security issues is much better than having it there by
> > default in a machine whose user is unaware of its presence, or the
problems
> > it can cause.
>
> How is it any different from having MS-Outlook on a system by default,
> when the user is unaware of the problems it can cause?
Because the program itself is useful to the user--sending and receiving
email.
>
>
> > > > This doesn't stop trojans from being developed or deployed for
Windows
> > > > machines. This doesn't stop vulerabilities from being found in
email
> > > > programs to allow these programs to spread.
> > >
> > > Which is it? Either the lack of a tool hinders attack, or it does
not.
> > On
> > > one hand, you are saying the addition of a raw sockets API will make
> > attacks
> > > more common. On the other, you are saying the lack of tools doesn't
stop
> > > trojans from being developed. You can't have it both ways.
> >
> > No, I am saying (actually, Gibson is saying,) that having a raw sockets
API
> > will make compromised machines harder to find. YOU stated that because
Linux
> > offers source code and free tools, it is a better platform for malicious
> > hackers. In fact, it may be a better platform for doing SOME things, but
if
> > you want to develop tools to compromise an Windows machine, you are
better
> > off developing them on a Windows machine.
>
> That's not necessarily true. Lots of tools for compromising Windows
> machines are developed on Unix machines. Often it's much easier for
> an attacker to develop on a non-windows platform. The reasons are
> varied, ranging from more familiarity with a given platform to better
> capabilities.
But you still need to generate code that will run on a Windows OS, so you
need a Windows compiler and a system to test on, at least.
>
>
> > > > Linux systems are not the best systems for DDOS attacks because
there is
> > > > not a high enough population of them yet.
> > >
> > > DDoS attacks do not need packet spoofing to succeed. Indeed,
spoofed
> > > packets make a DDoS attack easier to detect.
> >
> > Not necessarily. If the address is changed to something WILD from
outside
> > the ISP's domain, then yes, you are right. But if the address is changed
to
> > another address within the ISP's domain, the packet will just appear to
come
> > from another computer on the network.
>
> While we're talking about this, it should be pointed out that it can
> not be determined to a certainty that the machines which Steve says
> are the ones which attacked him actually WERE... It may in fact be
> that the DDoS originated from a bunch of Linux systems spoofing random
> (or carefully chosen, for that matter) IP addresses in the 216.*.*.*
> range. I'll agree that, based on the rest of the analysis, that's not
> likely; but it IS possible.
Possible yes, but not too likely, since many of the top offenders have been
fixed by the owners already, implying that they WERE the ones that were
compromised.
>
> > > >> Anti-virus protection is a multi-million dollar market segment.
> > Millions
> > > >> and millions of dollars spent every year just because Microsoft
can't
> > > >> design a secure OS.
> > > >
> > > > It's not that they can't, it's that they don't hold it as a
priority.
> > >
> > > Fair enough. Unable or unwilling; the end result is the same.
> >
> > And now since Linux machines have been shown to be just as vulnerable to
> > viruses,
>
> It has? Can you provide some documentation to that effect? Can you
> point out a single case where there has been a wide-spread infection
> of Linux systems?
>
> >> This is not necessarily true. If you strip a general-purpose OS like
> >> Linux
> >> down to nothing but the kernel, you can secure it as well as any
embedded
> >> firewall box.
> >
> > And how much more useful for everyday computing is that stripped down
system
> > than the embedded firewall?
>
> Not at all. But it isn't meant to be. It DOES, however, provide the
> advantage that it's still more flexible, configurable, and probably
> upgradable than the vast majority of appliance firewalls. And, as
> evidence of the fact that dedicated firewalls are not necessarily more
> secure than a general purpose OS (properly configured for the task),
I never said that a dedicated firewall was more or less secure than a
general purpose OS stripped down and configured for the task. What I DID say
was that a dedicated firewall (whether a preconfigured appliance or a
specially configured system like Coyote) is more secure than a general
purpose system with many services and applications running on it.
> I
> will direct you to Security Focus. The Cisco PIX has 6
> vulnerabilities reported in the last 2 1/2 years. Watchguard Firebox
> has 5. WinRoute has 3. Netscreen has 2. Alcatel has 2. You can bet
> that there are a lot more than these, which have simply gone
> undiscovered. And all these products do is firewalling. Linux
> systems certainly have had a lot more reported vulnerabilities, but
> almost all of these were in subsystems that are not needed for
> firewalling (and therefore should not be installed on a firewall
> machine).
Again I did not state that dedicated firewall appliances were more secure
than a Linux box that was configured as a firewall. Your statement of
vulnerabilities in other subsystems illustrates my point above
though...thanks! :o)
>
> Does this mean that you shouldn't use the appliances? Absolutely
> not. But it does mean that you are no less responsible for staying on
> top of their vulnerabilities as with Linux, if you want to keep your
> systems secured.
You are absolutely right!
>
>
> > > The embedded box runs software, too. That software can be
> > > compromised, just like any other software. It happens often enough.
> >
> > The embedded firewall only runs a very limited software set, and that
set
> > usually can't be compromised (runs out of a write protected floppy, or
even
> > firmware. The only way to compromise these systems is to change the
> > configuration (which can be reversed on a reboot) or to gain physical
access
> > to the media to change it (getting the user to download an "update" from
an
> > untrustworthy source would be an example.)
>
> I've just shown that appliances are not impervious to attack. An
> attacker COULD modify the firmware, on upgradable appliances, once
> they got in. And you'd probably never know it. As for the rest of
> these points, Linux has the same abilities. You can boot a Linux
> firewall from a write-protected floppy, requiring no hard disk at all.
> See the Linux Router Project for an easy way to do this.
Yes, but I never said Linux couldn't fulfill this role.
>
> >
> > >
> > > The real increased risk comes when you start running additional
services
> > on
> > > the firewall. Running services on the same system as the firewall
mean a
> > > service vulnerability leading to root compromise can further open your
> > network
> > > to attack. A separate service host means the attacker is limited to
what
> > he
> > > can do through the service host. If the service host is in a DMZ,
that
> > might
> > > be very little.
> >
> > My point exactly.
>
> So, don't run services on your firewall.
Duh. Hence the term "dedicated" firewall. It does not necessarily mean
"prepackaged" firewall.
>
> The point here is not that one solution is inherently better than
> another. It's that each comes with its own foibles that must be
> managed. You can't simply plug in a box and "be secure." Even after
> a solution is in place, you must manage your security, regardless of
> how you chose to go about providing it. You want the freedom that the
> Internet offers... In the words of Thomas Jefferson, "The price of
> freedom is eternal vigilance."
>
Or, "keep an eye on your logs."
Or, as I used to say, (as a joke, of course,) "Systems that do no error
reporting always run error free."
Rich Cloutier
SYSTEM SUPPORT SERVICES
www.sysupport.com
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
