[isapros] Re: FW: FWENGMON issue for the brain trust
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 7 Jul 2006 10:13:41 -0500
Hi Jerry,
But once again, if the box is already owned to the extent where the
malicious user can leverage the tool, then the game is already over.
It's the same sort of specious argument that the "the ISA firewall
should never be a domain member" hardware horksters and complience
clipboard know-nothings promulagate with unfortunate abandon.
If I get admin rights on any other firewall and can do the same damage.
Tom
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
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Young, Gerald G
Sent: Friday, July 07, 2006 9:04 AM
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
Other related posts:
