After starting a one-man movement :-) to clarify the muddy waters created by Steve Gibson, I was relieved to find that I'm not alone in my opinion. The central site gathering all the information was grcsucks.com, the domain registration of which expired somewhere around June 2007, and since than you can only find a domain parking page.
Fortunately, the Internet Archive has a copy of the site, and I will be republishing here parts of it (with added commentary where I feel that it is necessary) to make sure that it doesn't get lost. Enjoy!
The first one is rather long. The original text can be found at blue-labs.org, which GRCSucks mirrored, and now I'm mirroring it. It clearly shows that while we would like to think that the Internet is the "ultimate meritocracy", marketing has the final word (or maybe it is a meritocracy, just that it uses other merits than knowledge and information :-().
It focuses a little too much on the nomenclature for my taste (it starts with the age-old hacker vs. cracker debate), it does point out many technical, objective errors in Steve Gibson's writeups. Unfortunately it is very rare (in fact I've never seen it, but maybe it exists just like the Lock Ness monster) for Steve Gibson to react to technical criticisms with coherent, technical arguments.
GRC dissected
by David
Ford <[email protected]>
I have extrapolated
a number of statements and opinions that have been voiced and summarized
or rewritten for clarity. The meanings remain intact and some
are purely mine. The term *nix is used to generically represent
operating systems such as UNIX, Solaris, Linux, OpenBSD, and the like.
The term m$ is generically used to represent operating systems
provided by Microsoft Windows. [(c) and (r) where appropriate]
In preliminary, some responses to statements made.
- prove it or shut
up. It's already been done by numerous people
- prove that you
are not or shut up. Read below.
- sheep. It
entered your mind, not mine.
As to putting myself
on display, such activities are silly. I'm not a marketing droid
with big buzz words and flashy lights. There are numerous very
good security related sites that I support, we don't need yet another
web site trying to elbow it's way to the front. As to GRC polarizing
the world...ahh, oh-kay. Laugh of the day? If I had but
a pinch of the derogatory diatribe said about me that is said about
him, I would crawl under a rock and die. He is likened to the
blind leading the blind with plastic tools in an industrial plant.
I would dare you to stand up at a convention such as DefCon
and say you support GRC. Remind me to bring ear plugs to soften
the laughter.
My ego is certainly not in front here. It isn't hard for neophytes
to compare to GRC. His grandiose crys of Wolf! are for the media
and...well, I'll sleep in while he claims the world is ending.
For those of you who are interested in learning the non-colored facts
and getting the story straight I suggest visiting some websites like
securityfocus.com and securityportal.com. Another handy site
that coders like to visit is packetstorm and securify.
One should also take note that even with no supporting clarification
or facts backing up statements, the outpouring of laughter and derision
alone should make you think twice.
As to supporting statements regarding bots being used for attacks
and history, all one need do is a few quick clicks at their favorite
search engine, perhaps browsing the eggdrop scripts archives, perhaps
searching for IRC and bots and abuse...the number of hits should be
quite a-plenty.
For the newbies, when there is such a negative aspersion cast, there
is more than likely good reason for it. The effort of making
awareness is a great idea, but it'd sure be nice if the facts were
right and there wasn't grandstanding with molehills and mountains.
P1. Why
does it seem that all the people attacking GRC come from UNIX with hacker
mentalities?
Succintly in aside, hackers are not
malicious, crackers are. Your common *nix hacker knows
a good deal about the inner workings of everything and deals in facts,
not pandering. He is often more interested in accuracy than social
diplomacy and will be quick to make it known when there is inaccuracy.
A quote from GRC's Letter to the Internet's Hackers:
It
is my intention to carefully and completely explain, to the entire
world, exactly why there is no defense against the sorts
of clever Internet attacks you guys can create.
- He should have
correctly stated 'Crackers', not 'Hackers'.
- There are numerous
defenses
- These attacks
he has listed are no more clever than using his friends to egg your
house until it's a huge puddle. Indeed, in later words he
turns completely around on this.
*nix users, often
referred to as hackers tend to have a strong working knowledge if
not in depth knowledge of how things work. They also tend to
possess skill which easily distinguish them from a neophyte. m$
users are often cast in negative light because they rarely have dealt
with the underlying structure of networking. They understand
buzz words and marketing hype but can't explain what an OSI layer
really is or how data is classified in it. Your m$ user typically
will be completely lost looking at a stream of hex output when decoding
a packet. Your *nix hacker is likely to lose you with the fast
flowing verbal notage as he jumps from number to number.
A *nix hacker's perspective is to figure out why something is doing
what it's doing and fix it often without interrupting anything else.
By far and large and with a ratio that towers over others, the
most common first response on a m$ problem is to reboot and see if
it does it again. A joke that's gone around the world many times
comparing your vehicle to m$, if it doesn't start, everyone get out
of the car and get back in and try again. Your *nix person will
run a most likely checklist and be quick to point out that you're
out of gas.
*nix people have given something to the world. They just haven't
wrapped it with a Marketing droid. The differences between *nix
and m$ are like a battleship that has been hardened over time and
the fancy cruise 40ft'r that keeps breaking down with every bump,
squall, and snaggle of seaweed simply because it wasn't designed for
the environment it's in. m$ has a long history of incredibly
dumb bugs. That's my opinion, but even GRC maintains the flaws
of m$ and who might I be to argue with that...
There are a LOT of resources on the net, in print, etc. *nix
gurus don't need to hold your hand for you to take a step.
P2:
Truth in advertising, misrepresentation of facts,
and blatant media pandering.
Read this
letter, http://grc.com/dos/openletter.htm
. What can a person do about an attack? First, analyze
what kind of attack it is then the most blunt form of response is
to filter that particular packet type by source, port, or type and
if your link cannot handle it, make the request from your upstream.
Every respectable upstream provider will happily put up such
a simple filter on their ingress ports because it is likely affecting
them and/or their other customers. There is nothing about these
DoS attacks that are professional. Such attacks are disgraceful
and show a lack of maturity.
Let's take a look
at another GRC page : http://grc.com/dos/PacketRouting.htm
Notice carefully
how GRC has constructed a pretty graphic with void definition and
uses it to say how it obscures the mechanisms used by malicious hackers
to evade responsibility and detection. Does anyone not catch
the media specific wording and the lack of attributed value? Read
on. GRC inaccurately explains how a TTL is used with packets
and routers. Routers do not make a supervisory packet when the TTL
reaches 0 and the packet ICMP type that is returned is not "unreachable
destination". Routers utilize an Internet Control Message Protocol
(ICMP) packet to notify the source IP that the TTL expired. The
ICMP code used is ICMP_TIME_EXCEEDED. It is an altogether different
response that indicates a destination is unreachable, some types are
listed for your perusal.
#define ICMP_NET_UNREACH 0
/* Network Unreachable
*/
#define ICMP_HOST_UNREACH 1
/* Host Unreachable
*/
#define ICMP_PROT_UNREACH 2
/* Protocol Unreachable
*/
#define ICMP_PORT_UNREACH 3
/* Port Unreachable
*/
A few statements more we read the following:
Today, it is generally true that an Internet data packet may be generated
by any computer connected to the Internet, may enter the network
at any location, and will be immediately routed to any destination
machine specified. Only the Destination IP address is examined —
no concern is given to the packet's Source IP address — and no record
of the packet's route of travel across the Internet is retained.
The packet's Source IP is the only statement of the packet's origin.
If an Internet
data packet were carrying an incorrect Source IP, no router or system
on the Internet would know or care until the packet arrived at its
destination.
Since the inception
of the Smurf attack years ago, the ability to spoof source addresses
in packets and insert them into the network from any point has become
much harder. It is very common these days to find that your
upstream provider blocks any packets with a source IP that does not
belong to their IP pool.
Let's cover a few random notes through GRC's various pages for the
moment. GRC makes a distinction between IP masquerading and
NAT. NAT is network address translation. It comes in three
forms. 1:1, 1:many, and many:many. IP masquerading is
most commonly associated with the 1:many form; there is no distinction.
MAC addresses according to GRC are absolutely unique and unchangeable.
Incorrect, every common PCI card on the market today allows
you to set the MAC address in soft mode (it will be reset upon power
restart) and many of them allow you to permanently change the MAC
address.
GRC is quick to say that "but in this case
every existing machine with a network adapter — regardless of processor
— has already lost its anonymity!" Which
is quite misrepresenting the facts. There is only one specific
vendor's OS whose packet traffic 'normally' provides this information.
m$.
About bindings and network protocols. GRC goes into great detail
on how you can make your system incredibly more secure by arranging
bindings in a particular structure. Let me point out here that
TCP/IP is the language spoken on the internet, NetBEUI and IPX/SPX
cannot transit the internet without encapsulation. In other
words, much ado over with little to gain.
In his test of security by probing your machine, I'll drop my firewall
and make all ports available; note that I have also enabled well known
security weak services.
| |
Attempting connection to your computer. . .
Shields UP! is now attempting
to contact the Hidden Internet Server within your PC. It
is likely that no one has told you that your own personal computer
may now be functioning as an Internet Server with neither
your knowledge nor your permission. And that it may be serving
up all or many of your personal files for reading, writing, modification
and even deletion by anyone, anywhere, on the Internet!
Please Note: On highly secure systems this may take up to one
minute . . . |
| |
Your Internet port 139 does not appear to exist!
One or more ports on this system
are operating in FULL STEALTH MODE! Standard Internet behavior
requires port connection attempts to be answered with a success
or refusal response. Therefore, only an attempt to connect to
a nonexistent computer results in no response of either kind.
But YOUR computer has DELIBERATELY CHOSEN NOT TO RESPOND
(that's very cool!) which represents advanced computer and port
stealthing capabilities. A machine configured in this fashion
is well hardened to Internet NetBIOS attack and intrusion. |
| |
Unable to connect with NetBIOS to your computer.
All attempts to get any information
from your computer have FAILED. (This is very uncommon
for a Windows networking-based PC.) Relative to vulnerabilities
from Windows networking, this computer appears to be VERY SECURE
since it is NOT exposing ANY of its internal NetBIOS networking
protocol over the Internet. |
Hmm. Dare I say that until I put my firewall back up and shut down the
hazardous services, I am certainly not highly secure nor do I have any
advanced computer port stealthing capabilities. Port 139 packets
simply got a reset packet in response to the probe. Nothing is
firewalled and there are no stealhing capabilities engaged. I
continue with a standard GRC port probe. Again I am not very surprised
when the response is inaccurate. I don't have any stealth ports
as is reported to me and the recommendation that I shut down
About
the nanoprobes :
Our NanoProbes
are tiny, hand crafted, intention-directed packets consisting of just
224, 320 or 352 binary bits:
A
Typical NanoProbe
This is a schematic of a functional 224-bit NanoProbe.
If this particular probe were
to be dropped into the Internet, it would route itself
to the machine at IP address
[ 208.47.125.33 ] which is the United States
NSA (National Security Agency). This
NanoProbe asks the machine to verify its existence on
the Internet. Interestingly,
although we know a machine exists there, no response has
ever been received.... |
|
How does one assign
intention in a packet? If anyone has taken the time to take this
apart, it doesn't match up. Possibly this is only data from the
packet body. More interestingly, a response is received. ICMP
message of 'destination unreachable'. Probably firewalled is my
guess, wouldn't you?
P3: Naivety
Let's take this statement from GRC and reflect on it. " ... I was walking
back to my office with a fresh cup of coffee, thinking about the immensity
of this Windows security problem. That's when it hit me: I could determine
the IP address of someone browsing the pages of my web server ..."
Hmmm.
I'll skip the retort but suffice to say, if your server doesn't
know the IP address of the requestor, how could it return the requested
data.
" A firewall ABSOLUTELY
ISOLATES your computer from the Internet using a "wall of code" that
inspects each individual "packet" of data as it arrives at either side
of the firewall — inbound to or outbound from your computer — to determine
whether it should be allowed to pass or be blocked. "
A firewall does nothing
without having been properly configured. He goes on to say that
someday firewalls will be standard equipment on all {PCs}. Note
that I make editorial corrections. Firewalls have been available
on personal computers for over ten years.
Later in this discussion about firewalls, GRC muddles the definitions
what bits are associated with what types of packets. He appears
to only be aware of TCP packets and not aware that UDP is stateless,
not requiring acknoledgement packets or session setup. There is
nothing wrong about being naive, only that you misrepresent yourself
as an expert and pander to the media as such.
| |
I think my system is already infected by a Trojan
horse program.
Will a firewall help me? |
| |
Sure, absolutely. Since a firewall checks, scans,
and blocks traffic flowing both ways through it, both into
and out of your computer, you should be able to easily prevent
unauthorized communication by a Trojan horse program. Note, though,
that you should also really consider removing that suspected Trojan
from your machine. It's just not safe having a bad program running
inside your machine. You can never know for sure what it might
do! |
Again he postures that
a firewall is an absolute help. A firewall is useless without
being properly configured, even worse a misconfigured firewall can represent
a greater security risk.
| |
Is a software firewall running on a machine
less secure than a completely separate hardware firewall
peripheral? |
| |
In an "absolute" sense I suppose that no software
solution could be as safe as having a separate "appliance" acting
only as a firewall. However the least expensive of those costs
about $350 US, whereas there are extremely effective software
firewalls that are completely free.
If you're asking whether software firewalls can be in some fashion
"penetrated" or compromised by external software, the answer is
absolutely not. Due to the way these packages operate they
are invulnerable to external attack and they are more easily updated
as new types of attacks are discovered.
|
Sadly he again perpetuates
absolutes where he is "absolutely" wrong. All firewall devices
that I'm aware of use software...and I've seen far too many security
updates on firewall products to allow for any accuracy in his statement.
| |
I'm using NAT (Network Address Translation). Doesn't
this means that I'm pretty safe? |
| |
Yes. Network Address Translation such as the Internet
Connection Sharing (ICS) built into the second edition of Windows
98, allows multiple computers to share a single Internet connection.
This is accomplished by assigning "private" IP addresses to the
sharing machines. Since the external Internet sees only the single
IP address of the NAT translating computer, there's absolutely
no way for external Internet scanners to reach past the translating
computer. This creates a high degree of security for the machines
"behind" the main NAT computer. |
Apparently he is not aware of methods some of the smarter hackers can
use to blindly sleuth out routing and get seemingly insipid data past
a NAT device. NAT may hide things very well but it is not a perfect
solution.
I
again believe that I'm writing about and discussing something that's
in the very early stages of BECOMING A HUGE PROBLEM for all
Internet-connected Windows users. The following pages describe highly
effective proactive measures that anyone can take to "raise their
shields" against the forthcoming onslaught. But first, you need to
know about the "Password Crackers" so please read on . . .
If anyone cares to
enlighten Mr. Gibson, we need to step back many years to point out the
beginnings of security problems.
Let's talk about the DoS page he put up :
It is impossible for an application
running under
any version of Windows 3.x/95/98/ME or NT
to "spoof" its source IP or generate malicious
TCP packets such as SYN or ACK floods.
Do I need to point
to the numerous emails that have already proven how easy it is to roll
your own and go? Again, naivety is ok but making bold statements
purporting fact such as this is more damaging than supportive. His
next statement clarifies this slightly but he again takes the stage
saying that modified operating systems are irrelevant. I'm sorry
to say that the typical windows user has had more than one virus infection
which has modified system files. This is certainly a relevant
factor.
Why
Windows XP will be the
Denial of Service
Exploitation Tool of Choice
for Internet Hackers Everywhere
Any credible cracker
or hacker has long since recognized that he has much more power and
capability in *nix systems. *nix gives you the ability to do nearly
anything you can dream up in bit land. Even that may be an understatement.
Spoofarino, a grandios name with much hoopla. Hundreds of programs
have been written for years that forge spoofed packets. 'tis like
getting excited over color TV. His page http://grc.com/dos/winxp.htm#egress
has numerous comments about how difficult it is to properly filter.
This filtering and ability to locate bad traffic at an ISP should
be very easy...frankly, if you don't know how to do this, you shouldn't
be wearing the Network Engineer hat. Your journeyman apprentice
should have learned how to do these things his first year.
As to raw socket support, the operating system itself certainly does
have the support. The API layers in between the wire and the userland
program may not be fully connected but that doesn't mean it doesn't
exist. Think about it for a moment and you'll realize that somewhere
"deep in the kernel", a socket is created out of nothingness and values
are filled in. All network devices must be capable of this support.
Accessing this support is a matter of choosing your tool.
Note:
I am FULLY aware that full raw socket-style access can be created
by modifying any standard Windows operating systems through the addition
of third-party device drivers. I have been a user of such tools for
years. However, as I demonstrate below, aftermarket operating system
modifications have proven to be irrelevant to the purposes of malicious
hackers.
Hmm. Why does
he ramble on for (long) page after page about the incredible and amazing
dangers of raw socket support in XP AND goes on and on about how insecure
m$ is and that files can be accessed and replaced with the utmost of
ease.....and he turns right around and says that it is irrelevant?
Are there two kinds of crackers here, one puts trojans on your system
but he refuses to install support for raw sockets, and one who installs
support for the raw sockets but only on his personal machine? GRC
panders to the media with flashy graphics and show business words. His
content is often refuting itself and often misleading altogether.
If "Junior" and his XP gang (also taken from the winxp page) wanted
to spoof packets without much skill in stack support, I'm quite sure
they would have acquired a form of *nix long before this future dramatical
story of WinXP will take place.
His calculations for a SYN packet size are incorrect and can certainly
be different. Depending on the target system it will react very
different from a SYN flood. I can sit and watch a *nix server
handle a syn flood with deference. All this noise about raw sockets
in XP is like making a big fuss that you're getting wet from a drizzle
when the dam just broke five miles up from you.
The huge number of Windows
XP machines will motivate
hackers to find new ways into those machines — AND
THEY WILL. Then users of Windows XP machines will
become the most sought-after target for penetration.
Here he calls this
a corollary. Part of this is certinaly true. Along with
the plethura of any new toy comes the desire to play with it. However
I fully disagree with the last sentence, I do not doubt that *nix
systems are a much more appetizing treat due to their powerful abilities.
When those insecure and maliciously potent Windows XP
machines are mated to high-bandwidth Internet connections,
we are going to experience an escalation of Internet
terrorism the likes of which has never been seen before.
Hmm, my adrenaline
hasn't jumped. Actually this is getting boring. Rarely do
I like taking m$'s side but here I must. m$ has been doing an
admirable job cleaning up their code. Unfortunately they started
repairing and redesigning the house long after the house was built.
They have a long ways to go. I sincerely believe that XP
will not be the horror that GRC is grandstanding about.
Continuing on...
From Jargon File
(4.2.3, 23 NOV 2000) :
zombie n. [Unix] A process that has died but has not yet
relinquished its process table slot (because the parent process hasn't
executed a `wait(2)' for it yet). These can be seen in `ps(1)' listings
occasionally. Compare orphan.
Having misrepresented
the proper names again, GRC calls the DoS bots Zombies. Background
processes are more commonly referred to as daemons or...background processes!
There is no relation to a zombie process for m$ in the available
dictionaries.
However,
the hackers were apparently watching our success at blocking their attacks.
So two hours later the attack resumed, this time aimed at one of the
two T1 interfaces of our Cisco router. This again knocked us off the
Internet because malicious traffic was again crossing our bandwidth-limited
T1's to our local router. Back on the phone to Verio, we decided to
completely shut down that T1. GRC.COM limped back onto the Internet
running on a single T1.
Here I feel the need
to point out that it's a simple and wise consideration that many network
engineers take; use unnumbered interfaces or use private IP space numbering
when connecting interlink devices. Had the routers been properly
configured with 10.0.0.x/24 for example, the attack could never have
happened in the first place unless the attack originated within Verio's
network space. And if that happened, there are much more alarming
things to worry about.
12,248,097
The attacking Windows
machines generate maximum-size 64k byte UDP packets, but only the first
1500 byte "fragment" of each packet carries the packet's port "666"
destination. Therefore, for every identified "666" packet blocked, approximately
43 additional maximum-size "packet fragments" were also blocked. We
therefore estimate that our filters running in Verio's router blocked
at least 538,916,268 malicious packets that night.
Hmmm. Let's do the math again. Cisco's don't magically record
the first frag packet and invisibly drop the rest. Either it was
all counted or the majority of the attack got through and seeing how
he states that GRC was still online, I'll take the first.
I
wanted these attacks to stop, but I was certainly in no position to
make any "parental" demands of "Wicked". While we were essentially
functional, hiding behind our router filters, we could not remain
behind them forever. We were unable to send and receive "ping", "trace
route" and UDP fragments — all crucial requirements for full Internet
function. In the long term this would pose serious problems for the
delivery of GRC's Internet security testing services.
It's very easy to selectively
grant packet travel and also easy to allow traffic based on given rules,
session establishments, and a variety of methodologies. A cisco
router is nothing but a computer specifically designed to route packets.
You can use a variety of firewalls such as those that exist on
Linux and *BSD that have a fast path design to handle the load and you
can weather a heavy packet storm without worry. A heavy use router
shouldn't be acting as a firewall in the first place. Firewalls
are firewalls and routers are routers.
On an off note here, I'll comment that GRC goes to length to say how
@home is a haven for abuse. I'd like to point out that in my neck
of the woods, rr.com is both knowledgable and responsive regarding security.
I'll also say with a bit of a dour note that my professional experience
with the FBI has led me to "wince and bear it" while doing a job. Sometimes
you can get an agent that has a clue but it isn't often.
This next section made me smile, I'll post it then comment :
While
I was watching this sad drama, suddenly and with no warning everything
went crazy: The packet sniffer's packet display became a blur
as its scrollbar "thumb" rapidly shrunk to its minimum size. Thousands
of packets were being logged per second! Since I was nervous during
this first incursion into hacker territory, my first thought was that
I had somehow already been discovered, and my little "Sitting Duck"
laptop was under attack.
But
the cable-modem I was using to guarantee my anonymity revealed the
truth: The RECEIVE light was dark, but the TRANSMIT light was ON
SOLID!
I
immediately shut down the Zombie-infected PC and scrolled the packet
log back before the beginning of the attack. I found the command that
the Zombie running in my laptop had received just before all hell
broke loose . . .
My laptop had participated
in an all-out Denial
of Service attack against a machine in Finland!
Yikes!
This was unacceptable. I wanted to keep active Zombies running here
so that I could study their behavior, but I could not have them participating
in Internet Denial of Service attacks. So I hacked the Zombie to kill
its ability to send damaging packets.
>From that point on I
ran only
"Attack-Neutered Mutant Zombies"
Woah. The light dawns on the era of bots. (Actually it's been
on for years.) A cable modem guarantees anonymity. That's a new
one. Any responsible investigator would have placed a firewall
in the middle and logically decoded the program before running it.
Pulling the plug on your machine simply because you find that port 113
is being listened to is..well, humorous. Please, know more about
what you're doing and why and how you are reacting.
To anyone who is still stubborn enough
to insist that BlackICE Defender is actually good for something:
PLEASE do not write to me. I don't want to hear it. I'm a scientist
who will not find your mystic beliefs to be compelling. I respect your
right to your own opinions, no matter how blatantly they fly in the
face of logic and reality. That is, after all, the nature of faith.
Happy computing. I suggest prayer.
Hmm. Might I
suggest he entertain his own self with prayers. We have now some
examples where his logic refutes itself within his own website. He
writes letters to the internet's hackers soothing their egos about their
cleverness then turns around and state the attacks had no finesse, no
cleverness. He uses terminology in mixed ways, calling a widget
X at one time and Y at another time. He has pulled "hacker words"
and used grandiose highlighting to bring attention to statements that
have no sharpness to them.
In short, this attack can be summarized into the following: grc.com
was hit by several DoS attacks on <dates> using icmp and udp floods.
these floods are typical of the particular irc flood bot <insert
short description blurb>.
The summary can be fleshed out with facts but it is hardly worth the
huge media hyping and pandering. If an omniscient being could
tally up for us on a web page the number of DoS attacks related to IRC
alone, I'm sure you'd lose interest after the first dozen lines. IRC
related DoS attacks are frequent and if we were to count EFNet alone,
we would measure thousands per day. All one need do is find a source
of information and keep their mouth shut and they'll soon realize that
it's a nasty world out on the internet.
Now you've had a long read with no shouting matches going on. Go
forth and learn.
David
hype-free
Subscribe via e-mail
