Re: [sbs list] FW: Last Word On The BlackAttacker.vbs Question
- From: "Jim Harrison" <jim@xxxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>, <sbs2k@xxxxxxxxxxxxxxx>
- Date: Sat, 25 Sep 2004 17:19:56 -0700
Hi Tony (et al),
I'm including the isalist because the "BlockAttacker" discussion is also
occuring there in a slightly different form.
I was going to address your response point by point until I finished reading it
(yes, I'm willing to give anyone benefit of doubt
for a reasonable time). I'm up for a good technical discussion as much as the
next guy, but this is painfully absurd.
My understanding is that as a rule, you have much to offer the SBS community.
If so, this discussion saddens me because this is
clearly not one of your shining moments.
You haven't produced a proof-of-concept for the "exploits" because clearly, you
can't. You have been challenged time after time to
do exactly that and time after time, you merely regurgitate your own
statements. You clearly lack the knowledge or skills to fully
understand, much less reproduce your theories in the physical world. This fact
is blazingly clear to anyone with a modicum of
networking knowledge.
Unfortunately, you also choose to use the SBS forum to voice your uninformed
theories, causing undue concern for those who consider
you a source of good information. This behavior is nothing short of extreme
social and professional irrisponsibility (grc.com) and
I publicly challenge you once and for all to either produce proof of concept or
drop it entirely.
Since you claim that the "SMTP vulnerability" only exists when the SBS machine
is configured to server-publish the SMTP service
instead of using packet filtering (as is the default configuration), why do you
advise folks to do configure the server this way?
If I were a mean-spirited person, my inclination would be to publicly accuse
you of trying to generate "hero" business for your
consulting business. It's a good thing I'm not mean, huh?
On a consistency point, I find this statement most interesting of all (your
point 5):
"Have you ever wondered why you see all those 127.0.0.1 dropped packets by ISA?
It's likely a very large number of those are this
SMTP loopback address attack being sprayed across the Internet.".
Here, you readily admit that ISA drops packets sourced from 127/8 and yet you
also spend the majority of your dissertation claiming
that SBS server admins who choose to follow your advise and server-publish SMTP
are vulnerable to this same "attack". You can't
have it both ways; since ISA drops the traffic regardless of publishing
technique, there is no threat.
Also, you offer nothing more than a source IP address to validate your theory.
How about the details of the packet? ISA can log a
LOT of data regarding dropped packets. When have you ever examined the logs to
determine what sort of "attack" is being visited
upon the server that rejects them out-of-hand?
Another point I would ask you to respond to:
Why are you not advising folks who see 127/8 or RFC-1918 addresses on their
external interface to talk to their ISP? I repeat; it's
a good thing I'm not a mean person.
Any beginning router admin knows how to create a basic set of ACLs that
disallow traffic sourced from 127/8 and RFC-1918 addresses
(10/8, 169/16, 172/12, 192/16) and outbound traffic that is sourced from
addresses not in the known "internal" subnets, including
127/8.
Basically, I challenge you to "Make up your mind."
Yours,
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
On Thu, 23 Sep 2004 21:31:08 -0700
"Tony Su" <TonySu@xxxxxxxxxxxxxxxxx> wrote:
Hi Jim,
Thanks for your comments.
This is long, so
1. 2 paragraphs acknowledge your message's points.
2. General description of loopback vulnerability and how it has been
observed for many years by people associated with SBS
3. Offer to show the vulnerability to you on my server
4. Technical points about the SMTP open relay exploit in the wild that
exploits this vulnerability
5. A far worse closely related likely vulnerability than what is easily
proved
6. Instructions for setting up your own test
1.
Agreed about the hacking psyche. So, that is why I myself will never
install Blockattacker in a situation where a machine goes down. But,
consider this. To the typical hacker, he won't know what happened unless
he had prior knowledge he was attacking an ISA. As long as the attacker
doesn't know he's attacking an ISA or the use of BlockAttacker on ISA
becomes common enough for someone to invest in the effort to write the
exploit (admittedly wouldn't take more than a few seconds or minutes to
modify code he already may have), it's still "under the radar" and using
Blockattacker to automatically create blocks can be a big timesaver.
Granted, the act of creating blocks is woefully inefficient but think of
the time saved to generate the 30 or so blocks created automatically on
my machine compared to picking through logfiles, analyzing and then
creating them one at a time. Still, as you say any use of Blockattacker
<must> recognize the potential downside and I wouldn't have it running
in any critical situation. This is why I suggested that someone should
take a good, hard look at how Blockattacker can be implemented properly
because there <are> tremendous time and cost savings associated with its
use which can make it very attractive despite the risks.
I don't know what happened that I referenced the LAT, that's incorrect
as you say and I know better.
2.
As for the Localhost issue. For the longest time I was referencing an
anti-spam tool which was taken down awhile back when the company went
out of business. Since I messaged you on this before, DNSREPORT.COM has
re-deployed a test that proves this hack.
Tom was also very surprised on our List and this latest discussion
thread was because as you state, there has been no known vulnerability
the ISA community has recognized.
Before responding to Tom, I ran the DNSREPORT.COM open relay test and it
<did> indicate an open relay when 127.0.0.1 was permitted to relay by
the Exchange SMTP Virtual server. Removing the address, the relay test
reported the vulnerability closed.
This is an easily reproducible vulnerability on any version of SBS
running ISA. By all appearances it should probably not be restricted to
SBS and should be a vulnerability anytime ISA and Exchange are deployed
on the same box.
Also, SBS users have been verifying that my analysis is exactly
correct... Anytime they've Server Published Exchange (following general
ISA instructions) but with the default IP addresses permitted to relay
(includes 127.0.0.1), the machine was turned into an open relay every
time, mail queues filled within 2-3hrs and on spam blacklists within a
day. Tom opined that Server Publishing Exchange would be considered
"Operator Error" and not "Software Error" but IMO as long as the
instructions for Server Publishing Exchange exist and it's considered
"General Proper Procedure" I find it difficult to say "But you should
have known better than to follow general procedures, on an SBS box you
should always use the configuration created by the SBS Dev team and
never vary." Where do you draw the line on something like this? If
that's the general rule that should always be followed that's saying
that nothing else should be modified either?
I also speculate this was observed very early on during initial
development of SBS2K (1999?), but no one understood what was happening
which is the reason why SBS2K was <entirely> packet filtering and <no>
Publishing at all. This psychological approach to building SBS probably
continues to today based on those early not well understood experiences
which is what I've been trying to break, pointing out the virtues of any
kind of Publishing over Packet Filtering whenever possible.
3.
Anyway,
As I offered to Tom, if you want I am willing to have you shadow a TS
session into my SBS to prove the loopback address vulnerability exists,
but as I said this is very simple to re-produce on <any> SBS box.
4.
Also, from a technical point of view I posted a follow-up probably few
people understood but you might find interesting is what has to happen
for the SMTP open relay exploit to succeed against this vulnerability...
Namely...
- Win2K/Win2K3 ISN (Initial Sequence Numbering) is busted. It's also the
basis for what ISA calls Circuit Layer Packet Filtering (of course, not
the same as ordinary Packet Filters). Is a similar issue that happened
to Cisco high bandwidth routers discovered late last year but revealed
publicly only a few months ago. Microsoft just has done a better job
hiding the fact its algorthm is thoroughly hacked and exploitable. This
doesn't mean that ISA is bad, but until MS upgrades its ISN algorithm,
<no> security solution should rely on Circuit Layer Packet Filtering
alone and naked Windows boxes are... Well, exactly that, naked.
- Microsoft implemented a fix to drop packets arriving on an external
interface at a very low layer, my guess is the HAL... Then probably
created upper layer fixes for recognized applications like regular IIS.
This approach is obviously faulty because maybe an unexpected
application like Exchange SMTP isn't similar enough to "IIS only" SMTP,
and the fix doesn't work. One of two things are happening, either ISA is
not plugging into the right component or the fix is too application
specific and isn't covering packets arriving via Exchange SMTP.
- There isn't likely any better security on a Windows box today than
Windows Security itself. If Windows Security is part of the layered
security approach, then no matter whether other methods work as
expected, Windows Security enables the SysAdmin to focus only on
maintaining a good, strong password policy. And, that has been the case
for example when I Server Publish SMTP on SBServer. If anonymous is not
permitted, the hacker must crack a Windows account.
- The SMTP exploit has been around for at least three years, probably a
lot longer. This means that the combination of parameters which create
the conditions for the exploit (ISN, loopback address vulnerability)
have existed for at least that long although maybe not specifically when
using ISA. This is not an attack targeted at some other platform, the
only way the exploit can work is on a Win2K or later platform (maybe
later versions of NT4). If you're personally not aware of this issue, I
can't see how this issue can't be noticed by the highest people in
charge of security at Microsoft. It's just not the kind of thing anyone
likely wants publicized, especially if it might be possible to hide
through patching, ie. Alternative solutions instead of fixing the real
problem.
5.
- I haven't created the exploit and I don't publicize (only discussed in
private conversations), but if all this is true, then <every> SBS2K3
today on the Internet likely has a serious SMTP Open Relay vulnerability
which is just waiting to happen, and this is I repeat, <every> SBS2K3
which has ever been sold and deployed with or without ISA... Besides the
127.0.0.1 address which is exploitable <only> by ISA Server Publishing,
the machine's WAN address is also listed. This means that the widely
seen exploit which targets 127.0.0.1 only has to be modified to target
the machine's WAN address instead and... Yes... It'll probably work, and
be an open relay.
- Have you ever wondered why you see all those 127.0.0.1 dropped packets
by ISA? It's likely a very large number of those are this SMTP loopback
address attack being sprayed across the Internet.
Thanks for your time, Jim... Your work everywhere is the best and
although hard to read for my students I point them to your series of ISA
client articles on isaserver.org as <the> reference on ISA clients.
Tony
6.
Summary for test:
Easy way:
1. Setup an SBS2K box which already has ISA integrated on an address
with a Registered Public Domain MX record.
2. Server Publish Exchange.
3. Configure the Exchange SMTP Virtual Server to include 127.0.0.1 as an
address permitted to relay.
4. Run DNSREPORT.COM against your domain, you will see yourself reported
as an open relay.
5. Delete the 127.0.0.1 entry
6. Rerun DNSREPORT.COM against your domain, and you will see yourself
reported as a closed relay.
Repeat steps 3-6 as often as you wish to prove that is the <only>
changing parameter.
If you want, leave yourself configured as an open relay and see how long
it takes for the SMTP Open Relay attack to find you.
Harder way:
1. Setup an SBS2K3 Standard box.
2. Install ISA2K using the Premium Disk.
Repeat steps 2-6 above, but step 3 will already be part of the default
configuration.
-----Original Message-----
From: Jim Harrison [mailto:jim@xxxxxxxxxxxx]
Sent: Thursday, September 23, 2004 7:44 PM
To: Tony Su
Subject: Re: [sbs list] FW: [isalist] Last Word On The BlackAttacker.vbs
Question
Hi Tony,
Interesting statements, but dangerously misinformed and naive.
- Spoofed packets:
The minute you think you understand what motivates the average
haxor, feel free to alert the authorities. They've been trying to sort
that our for years. It's also the single greatest confounder to Mom and
Pop InternetUser; "why would anyone try to hack me; I'm nothing to
them?" The fact is, the motivation for the average script kiddie is
nothing more than "I did it!", or "see; haxor mentor, I can own any
machine I touch!".
Your statements regarding how ISA determines "spoof status" are
completely incorrect. ISA uses the Windows routing table to determine
if a packet is being received is incorrectly sourced. The LAT is not
part of the decision at all. In fact, ISA (correctly configured)
properly recognizes spoofed traffic from within the LAT as well.
Regarding haxors spoofing their own source IP; that's silly. Why
would they want to "spoof" an IP where they send the traffic from?
Maybe a course in basic TCP/IP is in order here? I wasn't trying to
illustrate what haxor Joe is going to do; just what's possible with
readily available tools, and thus in the hands of the script kiddies.
- Alerts
at least we agree on one point <g>. I've seen many an ISA where
literally ALL of the available alerts were enabled on the basis of "they
created it; it must have a purpose". I agree that the alerts might have
been better explained in the help, but ya gotta ship a product sometime,
and the docs always trail the code...
- Localhost (127.0.0.1)
Nothing stated in the posting that motivated my recent response or
any previous communications we've had on this subject has ever been
"proven"; merely restated in the extreme; "I haven't personally checked
", to quote you. You're rehashing the tired old "blind IP spoofing ISA
SMTP server publishing vulnerability spamming threat and a bag-'o-chips"
that doesn't exist. At no time has any proof of concept been presented
to anyone with whom you've expressed it. So far, it's nothing but a
paper basket full of rocks. You do yourself a grave disservice by
rechewing this old bone in a public forum. If you have anything to
offer that can be demonstrated either in a lab or live environment, then
please forward it to the proper folks. What you choose to believe about
a vulnerability that, by your own admission, is nothing more than theory
is up to you, but until you or someone else does demonstrates this in
the physical world, my well-intentioned advice to you would be to stop
beating a dead (or unborn, to be more precise) horse.
Thx,
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
----- Original Message -----
From: "Tony Su" <TonySu@xxxxxxxxxxxxxxxxx>
To: <sbs2k@xxxxxxxxxxxxxxx>
Cc: <jim@xxxxxxxxxxxx>
Sent: Wednesday, September 22, 2004 14:48
Subject: RE: [sbs list] FW: [isalist] Last Word On The BlackAttacker.vbs
Question
I agree with everything but one point Jim says here,
And his warning about the downsides are all valid.
- I've seen the performance effects of "monkey code" running out of
process. If something like BlockAttacker was turned into a proper
tool/feature, of course it should be compiled code but as it is now it
can and will at times cause heavy loads. And, as some have noted before
(Jim can add this to his list of issues), the execution plan is faulty
because the process that launches BlockAttacker does not check for an
existing block first.
- Spoofed packets is a critical downside, which is why Blockattacker
should not be used anytime Internet Access is critical every second of
every minute of every day. This builds on the known issue that ISA's IP
spoofing detection cannot identify spoofed WAN addresses, it only
compares against the LAT. Still, the current state of hacking <today> is
that typically hackers believe or know that their targets are SysAdmins
who are either stupid or don't care. So, <today> (emphasis again) I
don't think anyone believes that hackers are spoofing their own source
addresses. Yes, if someone knows you are running BlockAttacker and how
it's configured, they can cause you to be blocked from essential network
resources (ie. DNS, DG, others) which probably makes more sense than
blocking the User's IPv4 block.
- As Jim says, what alerts you configure to trigger any action is
essential to what the consequences are, intended or otherwise.
- Jim might want to modify his comments about 127.0.0.1 if he recognized
what we've been saying on this List and has been proven... The
vulnerability might have been addressed in most situations (I haven't
personally checked but to a degree will take the word of others as
valid), but it's faulty. I suspect the Microsoft "fix" is to look
specifically for certain application processes instead of building an
entire layer which would have addressed all <unknown> applications as
well as known at the time it was designed. Regardless, the unexpected
faultiness is actually a benefit because once the vulnerability and
exploit are known, then we as SysAdmins can know to avoid it <and
similar situations>. In other words, am I to believe that the SMTP
exploit is restricted to SMTP only? Of course not. If the fix that's
supposed to work isn't working, anything similar is almost certainly
also potentially exploitable (which should be a real concern because the
practice of publishing Companyweb on port 444 <does> expose a
possibility although the actual ability to exploit and how is not
clear).
Tony Su
-----Original Message-----
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Tuesday, September 21, 2004 8:50 PM
To: sbs2k@xxxxxxxxxxxxxxx
Subject: [sbs list] FW: [isalist] Last Word On The BlackAttacker.vbs
Question
-----Original Message-----
From: Jim Harrison [mailto:jim@xxxxxxxxxxxx]
Sent: Tuesday, September 21, 2004 6:56 PM
To: [ISAserver.org Discussion List]
Cc: [ISAserver.org Discussion List]
Subject: [isalist] Last Word On The BlackAttacker.vbs Question
http://www.ISAserver.org
(if you want me to see your reply from sbs2k@xxxxxxxxx, please 'r' me)
Hi all,
It's come to my attention that the once-proud BlockAttacker script is
once again the subject of deep discussion. This script has been pulled
from isatools.org (it never was on
isaserver.org) and it will not reappear on that site so long as I own /
run it. It is no longer supported by me, Microsoft or anyone
cooperatively associated with either one of us.
This subject (and related script) has been abused, misused and
misunderstood for far too long. It stops here and now.
Contrary to what you might have heard, this script was never intended
for anything more than an example of how to use environment variables in
ISA 2000 alert actions. As with any good deed, it has not gone
unpunished.
If you are using it for automatic "deny" policy creation, consider this:
1 - with the notable exception of SMTP Filter alerts (you're not using
it there, are you? That would be silly in the extreme...), if ISA
generated an alert based on the traffic from the remote host, that
traffic was also blocked. Adding a rule to block traffic that is
already silently dropped is a waste of processor time (redundantly
repetitive).
2 - Every time this script creates a new packet filter for a presumed
"attack on your property":
a - it takes CPU time to create, update and save the changes; if
your script is creating rules as fast as someone can DoS your ISA with
spoofed packets, then your firewall quickly becomes a network brick.
b - you complicate the ISA policy set. Every rule in the ISA engine
takes processing time. The fewer rules you have, the faster your ISA
can process the traffic
IOW, leave this monkey-script in place long enough and your ISA will
crawl to a halt.
3 - ISA can generate "attack" alerts on any number of packets that ISA
deems to be "out of context". Most notably, these include (but are not
limited to):
1 - "late" packets; these are response packets arriving from a
server outside of the time ISA considers traffic from this host to be
"valid".
You'll usually see these when internal clients drop their
session before the server finishes the response stream.
99% of the time, ISA will report these as "scans" and drop them
2 - DHCP traffic from your ISP; even if you use static IPs, it's
very likely that someone in your broadcast subnet uses dynamic IPs.
Will your ISA see these? You betcha.
Will it trigger on them? Maybe; it depends on your
configuration and how many alerts you've enabled.
3 - Real attacks using spoofed source IPs; here's the real danger.
All it takes is one script-kiddie to slam your ISA with spoofed
packets from the entire IP v4 space and your ISA will no longer be
functional in the Internet. If you think this is hard to do, you're
fooling yourself.
4 - There has been some discussion regarding:
a - the value of blocking traffic from 127.0.0.1 and how your
ISA will lie bleeding to death on the floor from the "circle of death"
resulting from such an attack. The fact is, while ISA is properly
configured in Firewall or Integrated mode, this "attack" profile a
non-issue. ISA 2000 in Cache mode has no such self-protection, so you
should use a properly-configured packet-filtering router.
b - the potential for blocking traffic from your own ISA server
is less than zero. Any traffic seen at the external interface with a
source IP of 127.0.0.1 is a spoof packet, period. End
of discussion. You should get mad at your ISP for allowing
this to reach you, not some "think for me" script for not having a
"whitelist".
As always, I'm interested in feedback, but here is the final word:
"BlockAttacker.vbs is not a supported tool for any Microsoft product in
this, or any other lifetime in which I may be a member."
Anyone who wants to offer intelligent discussion on the subject will be
heard, and maybe even responded to in kind (of). Anyone who wants to cry
"foul" (no; wait, that's "spooooon!") will be courteously (or not)
ignored.
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
World of Windows Networking: http://www.windowsnetworking.com Leading
Network Software Directory: http://www.serverfiles.com No.1 Exchange
Server Resource Site: http://www.msexchange.org Windows Security
Resource Site: http://www.windowsecurity.com/ Network Security Library:
http://www.secinf.net/ Windows 2000/NT Fax Solutions:
http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
tshinder@xxxxxxxxxxxxxxxxxx To unsubscribe visit
http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/dpFolB/TM
--------------------------------------------------------------------~->
As well you can find more info at http://groups.yahoo.com/group/sbs2k
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/sbs2k/
<*> To unsubscribe from this group, send an email to:
sbs2k-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Other related posts:
