Peter said...
>To put it another way: systems that trust each other are effectively
>the same system.
>
>If any system is in the same trust boundary as your webserver, then if
>the webserver is compromised so is it.
Could we just take a step back a sec here and think about what we're
saying???
Just because you hack my webserver does not translate into access to my
SQL server for anything other than the defined access that the webserver
had, which could quite easily be read-only. Even if the webserver had
write access to the SQL server, this does not translate to the SQL
server being compromised in the sense that you could then magically send
it instructions to do something on the internal network.
Please don't take this the wrong way, but far too many people assume far
too much when they start talking like "and if I can hack your machine, I
can do anything I want". No, Peter, I'm not saying you said that, but
the idea is there in yours, and others statements.
So we've all heard that a Trojan could be placed into an NT registry (a
poorly secured one), and that a file could be transferred to a machine
through an FTP server that allows inbound writes (again, a poorly
secured one), so this means we have some program installed on the NT box
awaiting the next boot. This program will then do what, exactly? What is
the exploit that you are using to discover whether or not that NT box
can access the internal box with any kind of rights that would allow it
to place a copy of itself (or some other files you've previously left on
the external NT box) on the internal box? If its not external, it
probably won't be running FTP, right? So you are now using a share,
assuming you have access to it (i.e. C$). Oh, but then, you are
exploiting the poorly configured NT registry on the internal box again,
once again, with the assumption that you somehow have access to it?
Remember, if the systems are properly configured, the external NT box
can only access the Internal box for SQL, so how do you execute a
program on the webserver that does anything to the internal box? The
external box would be part of its own domain, untrusted from the
internal domain, so accounts that exist on the webserver would not be
valid within the internal domain. Since the external box doesn't have a
copy of the SAM, how are you accessing the internal registry? See, in
NT, unless you are putting things into the registry, you can't remotely
log on to it, you can't get a command prompt. AND ITS EASY TO SECURE THE
REGISTRY, just remove Everybody Read access from the HKEY_LOCAL_SYSTEM
hive, viola, a secure registry that cannot be connected to by anyone
other than Administrators Group (and your entire environment will be
very happy, unless you are running some form of multi-user NT
extension).
I often think that far too many people assume far too much about NT
security, which ends up with them assuming that exploits which have
never been reported become easily done, if you just knew how...
I said it before, and I'll say it again, NetBEUI can be used to create
protocol isolation which does not require encryption to connect an
external Internet NT box to an internal NT box that is also connected to
an internal network. This connection does by-pass a firewall, but it is
a tool that a Firewall administrator can use to effect a solution that
has been thought out and planned, which will also avoid some of the
problems associated with creating such a connection through a Firewall.
Until such time as there is a proper NT proxy for Firewalls, this is the
method I believe has the highest level of assurance.
If you don't think so, then please be specific about the exploits that
could be used against such a connection. Making assumptions about what
you could do if you only had a program to do it skirts the issues and
obscures the security that NT provides. Anyone can speculate to no end
about what an unknown, undefined program could do to such a connection,
without ever having to face the realities of the environment. I fail to
see how this helps anyone, or proves anyone's point.
Cheers,
Russ
Follow-Ups:
|
|
