> A little clarity amongst the panic might be in order.
There is no panic.
> A wonderfully engineered .DLL
> would not be able to SNARFF anything unless that .DLL replaced the log on
> .DLL and completely replicated the functionality of that process
This is a bit of a red herring, because I didn't talk about using the
default services account... but are you sure the log-on DLL doesn't call
*any* other DLLs that could be compromised?
But leaving that aside, if it can read the executable files (EXE and DLL)
and data files of applications, it can (if suitably primed) extract any
passwords used by those applications to authenticate themselves. Even if
the passwords are in the registry it can extract them.
These passwords can not be irreversibly encrypted, and must be recoverable
at the time the application is started so it can run under that account.
Finally, they are not generally changed even if there is a mechanism
provided to allow that to be done.
And you don't need to be able to create an account to take advantage of this
hole. You just need to be able to install files in %systemroot%, and write
over some DLL any application like this uses. Now the Sommar Software NT
security page explains how you can prevent this in most cases, but the
standard NT installation doesn't.
> Meanwhile, as it is with UNIX, if
> you are going to add a service to NT you have to give it either access to
> your entire system (System Account), or let NT store the password for the
> account in its Service Startup "Logon as" area.
I'm sorry, but this is just not true. You do not need to ever store any
password on a UNIX system in an unencrypted or reversibly encrypted form
to allow a daemon (service) to run as a user. UNIX security is based on
processes passing on subsets of their privileges (account, groups, limits)
to child processes... not through authentication tokens. This has both
advantages and disadvantages, to be sure, but it means that for this
specific class of attack (extracting non-expiring authentication tokens)
UNIX is is immune, and the standard NT installation is particularly
exposed.
> Fact is, the InocuLan account is no more or less secure than the
> Administrator account in NT, with the sole exception that the password does
> not expire.
The administrator password is stored in a reversibly encrypted form somewhere
in the system? I wan't aware of that.
> In other words, the "left
> NT open" fear is baseless and based on perception rather than knowledge.
You haven't said anything that changes my belief.
> - The System Account does not have a password
> - The Service (in this case InocuLan) does not store the password
> - Only the System Account can access Service Startup "Log on as" parameters
Based on my experience with NT, I make the following claims:
Any account that has or can boost backup privileges can access them as well.
NT systems that are not *very* carefully set up are exposed to the
installation of trojan horse DLLs that can temporarily borrow accounts that
can access reversibly encrypted passwords, either directly or through
privilege boosting.
Once it has these passwords, it can deliver them to third parties who can
attack the system at their leisure at a later date.
If this is not true, how am I supposed to restore a trashed NT system?
If I can't restore a trashed NT system, let me know so I can take suitable
measures instead of relying on the backups I have been religiously making.
References:
|
|
