Re: reporting local security problems for WinNT (Re: Escalation of privileges)

[David LeBlanc <dleblanc () MINDSPRING COM>]

At 01:42 PM 8/8/00 +0400, Vladimir Dubrovin wrote:

> Another example: AVP users can easily obtain Control Center privileges
> (Local  System  by  default  -  this  are  admin  privs)  by trojaning
> "C:\Program  Files\AntiViral  Toolkit  Pro\avpcc.exe"  -  this program
> starts  as a service. It's also possible to operate in kernel mode via
> C:\Program Files\AntiViral Toolkit Pro\FSAVP.SYS

> According  to MS recommendations only Administrators group should have
> Write  permission  for  Program Files and WINNT directories. Otherwise
> user can easily trojan any executable, including system services. This
> problem  is  not  NAV  specific,  and  this  is  a  problem  of  poor
> configuration, not a bug.

The general issue here is that any file that is going to be run as a
service really must be secured. IMNSHO, it is the responsibility of the
person writing the install routine to verify that the directory where the
files will be placed is secure, and if the default for that directory isn't
appropriate, then set the permissions upon creating the directory. Same
thing for registry permissions.

An important note is that "C:\Program Files" may be the default install
point with certain inherited permissions, but many other possibilities
exist - for example, the system drive may have limited disk space, so the
admin chooses a new directory on a freshly formatted volume - default
permissions on a freshly formatted volume are everyone:F. My personal
practice as an admin is to immediately change that to admins:F, everyone:R.
At any rate, if I choose to install some application into a new directory
on a new drive, and it doesn't set permissions for me, then I could very
easily end up with something people can trojan.

As admins (of any system, not just NT), it is also smart to double-check
permissions of installed applications, as the writer of the install routine
might not be as security conscious as one would like.

Unfortunately, I don't think the install applications make it very easy to
set permissions (at least they didn't last time I worked with one - could
have changed), so you have to write your own app to do this for you, and
call it from inside the install app.

While thinking about this, it seemed handy to have a perl script you could
use to check this out - note that it requires sc.exe from the resource kit.
If you want only running services (seemed better to me to get them all),
remove the 'state= all' argument from the first line. If you have a lot of
services on the machine, the bufsize arg might need to be increased.

Output should look like:
[c:\temp]perl CheckSvcPerms.pl
Alerter
C:\WINNT\System32\SERVICES.EXE NT AUTHORITY\SYSTEM:F
                               BUILTIN\Administrators:F
                               BUILTIN\Users:R

and so on
=============CheckSvcPerms.pl==================
open(QUERY, "sc query state= all bufsize= 4096|");

while(<QUERY>)
{
  if(m/SERVICE_NAME:/)
  {
    s/SERVICE_NAME: //;
    chop;
    $svc = $_;
    printf("%s\n", $svc);
    $cmd = "sc qc ".$svc."|";
    open(CONFIG, $cmd);
    while(<CONFIG>)
    {
      if(m/BINARY_PATH_NAME/)
      {
        s/\s+BINARY_PATH_NAME\s+://;
        $cmd = "cacls ".$_."|";
        open(CACLS, $cmd);
        while(<CACLS>){print;}
        close(CACLS);
      }
    }
    close(CONFIG);
  }
}
close(QUERY);
=======================end script=============================
David LeBlanc
dleblanc () mindspring com