[isapros] Re: FW: FWENGMON issue for the brain trust
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 7 Jul 2006 08:37:55 -0700
..and anyone with the capability to use the tool also has the ability to remove
any event logging it might create.
It's a debugging tool.
It can only be used by someone with local-logon, admin rights to the ISA.
If you have a malicious person of this caliber functioning on the ISA itself,
the use of this tool or the APIs that can't be reached without it (or the
aforementioned skillset) are irrelevant.
Neither the tool nor the APIs it uses are available "by accident".
The fact is; anyone attaining the access required to uses this tool can cause
far more damage using much simpler techniques, like "diskpart".
-------------------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
-------------------------------------------------------
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Young, Gerald G
Sent: Friday, July 07, 2006 07:04
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: FW: FWENGMON issue for the brain trust
Hmmm...
I'm afraid to voice my opinion because I certainly don't want to be shunned
but...
Would it be that hard to add the event log and auditing features to the tool or
the APIs? I mean, that would be an "improvement", wouldn't it?
And there are different levels of abuse this tool or APIs could potentially
allow. Suppose an unethical admin out there used it to create a bypass to a
questionable website or something. Does the bypass mean that ISA wouldn't even
log the traffic? Or, reverse that and suppose the unethical admin is working
with an outside source and he creates an incoming bypass. If you can't see the
bypass, chances are inbound traffic won't be noticed unless it's pervasive or
something else brings attention back to the firewall.
And keep in mind that someone could create another utility that makes use of
those APIs by playing with ISA on their own and then publish that utility once
they figure out what those APIs are.
In my opinion, if adding that functionality to the tool or APIs helps to
minimize those kinds of risks, it makes sense to me to add it.
Cordially yours,
Jerry G. Young II
MCSE (4.0/W2K)
Atlanta EES Implementation Team Lead
ECNS Microsoft Engineering
Unisys
11493 Sunset Hills Rd.
Reston, VA 20190
Office: 703-579-2727
Cell: 703-625-1468
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Friday, July 07, 2006 1:12 AM
To: isapros@xxxxxxxxxxxxx
Subject: RE: [isapros] FW: FWENGMON issue for the brain trust
I do, but Danny made me wait until I stopped spitting expletives.
I agree with message #2 - if the app isn't there, the functionality isn't
available.
Granted, the Mark Russonovich's or Tim Mullens could probably sniff out the
APIs and create all manner of H&D, but so what - anyone of that skill level
that has direct local-admin access to your box just got themselves a free
server anyway.
If the app isn't left on the box and the attacker doesn't have local-logon,
admin rights (oh damn; game over), then WTF cares what APIs may exist that you
can't get to without prior knowledge (and not-insignificant programming skills)
or a product-team-provided debugging tool? IOW, if they're all that worried
about who can do what when they log onto the ISA locally as an ISA admin,
they've already lost the war.
This guy has way too much time on his hands if this is the sort of thing he
gets wound up about. Was this Andy?
We now return you to your regularly scheduled profanity-filled retorts.
________________________________
From: isapros-bounce@xxxxxxxxxxxxx on behalf of Thomas W Shinder
Sent: Thu 7/6/2006 2:22 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] FW: FWENGMON issue for the brain trust
No one gots no opinion on this one?
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Wednesday, July 05, 2006 9:10 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] FWENGMON issue for the brain trust
Hey folks,
There was a discussion on the beta newsgroup that I thought would be
interesting to put in front of the brain trust. There's nothing NDA here, so
it's cool. My impression is that the person who was concerned about the
fwengmon /allow option is akin to the IPv6 issue -- if the admin is
incompetent, malicious or both, then of course the fwengmon /all option can be
abused. But the same incompetent and malicious admins can hork any other kind
of firewall.
The example of the SBSer reading e-mail on the box is archetypal for
the idiot admin who goes out of his way to subvert firewall security, so how is
this different from creating an "allow all from everyone to everywhere" which
you can do on any firewall, including the ISA firewall?
Wondering if customers really need to get their undies in a bunch about
this or its is calling "fire" at a weenie roast?
===========================
Message 1:
In my personal opinion, the interface method which "fwengmon.exe /allow"
calls should not exist; there should be no such bypass-the-firewall method,
even if it is handy for troubleshooting.
If it can't be removed, then there should at least be an Event Log message
whenever it's invoked, and the fwengmon.exe tool should be able to display
whether or not there are any bypasses currently configured so that it can be
audited (the "/noallow" switch will turn any bypasses off, but it doesn't
indicate whether it did anything or what the IP addresses were in the cancelled
bypass).
I'm sure the ISA development team uses the bypass feature constantly, but
that's development/debug code, and it wouldn't have to exist when the final
product ships. Whenever I show others the "/allow" switch and its invisibility
of operation, the response is always very negative.
Message 2:
Yes, but you have to get the file on the box. If I can place files on the
firewall without your knowledge, the game is already over, isn't it?
Message 3:
I agree it's a bit paranoid, but I think the even greater threat comes from
external buffer overflow attacks that call that method or malware that does the
same when invoked by an interactively-logged on administrator who browses the
net or reads e-mail as admin while at the ISA box (which will probably be
running SBS, yet it will be ISA that gets the blame for it when the
vulnerability is published). In these cases, fwengmon.exe wouldn't even have
to be on the local drive. At a minimum, it would be nice if invoking that
method --whatever it is-- at least wrote a message to an Event Log.
(I
also don't like how "lockdown mode" does not drop all existing connections and
still allows new outbound connections, but that's another story and easy enough
to fix with a custom panic script.)
On a purely marketing level, too, ISA has lots of prejudice to overcome, so
I've encountered anti-Microsoft sysadmins who jump all over this "invisible
hole feature" to undermine ISA as a trustworthy firewall (and then this can
sway the fence-sitters in the room to lean to the negative side). I'd still
prefer it if this firewall-bypass functionality didn't exist at all...
======================
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> MVP -- ISA Firewalls
All mail to and from this domain is GFI-scanned.
Other related posts:
