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:
|
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 :
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.
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.
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.
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 . . .
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.
"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
No comments:
Post a Comment