Re: More before-the-fact advice for 2K and XP?

From: Gordon Fecyk (gordonf_at_pan-am.ca)
Date: 12/19/04 

Date: Sun, 19 Dec 2004 13:18:06 -0600

> Unless I'm mistaken, neither ActiveX nor BHO require Admin permissions to
> install.

I'd like to see an example of this.

> Also, a good portion of commercial spyware and adware may use
> activeX controls or BHO, but viruses rarely do. In either case, running
as
> non-admin does little to prevent any of this from getting on the machine.
> Some people say running as non-admin reduces the amount of spyware and
> adware that gets installed on the machine; however, I find this hard to
> believe, given that non-admins have a significant amount of control over
IE
> settings and the HKCU registry hive.

How about a hundred users from two different clients not getting a single
bit of spyware over two years? Without traditional AV software installed?
I haven't had to lift a finger to remove spyware from these machines in all
this time.

Limited users never see the: "Would you like to install the (blah blah)
control?" prompt.

Now what I _have_ seen is what brought me to the whole default ACL question
in the first place. I've seen applications installed using "Only for
myself" settings (supported by Windows Installer), and items appearing in
the user's Startup group through Javascript. Also, new desktop icons, home
page changes, automatic manipulation of Trusted Sites, disabling the HTTPS
requirement for Trusted Sites - these are all things that don't break the
_machine_. I can always erase a user profile to correct the worst of these
problems.

> Last, note that if you're running as power user, you're not much safer
than
> if you were running as admin.

I know. I never recommend "power user" access. Sometimes that means
swapping Quickbooks for Simply Accounting. Or foregoing the latest 3D
shooter.

> > White-lising executables doesn't work for long. Nothing stops a user
from
> > downloading "unauthdapp.exe" and renaming it "iexplore.exe".
>
> Untrue. White listing is usually done using file hashes, not file names.
> Any solution that doesn't do this is not a good solution.

That was pre-2K anyway.

Roger brought up how file hashes take a lot of CPU time. I can throw more
hardware at the problem but that's a LOT of binaries to hash (all those DLLs
in Office 2000 - ick).

> > And nothing
> > stops the app writer from signing it.
>
> This means nothing. With executable white listing, the app doesn't just
> need to be signed, but you must have approved the app. White listing
> doesn't usually rely on whether or not the app is signed.

hm... this could work then. Are 16-bit apps hashable?

> As I said, I don't think you can do what you're trying to do without
either
> SRP or third party software. This is pretty much true of any advanced
> security countermeasures. You have to choose what's more important to
you:
> using these countermeasures, or avoiding third party software.

As long as the third-party software WORKS, that's fine. Conventional AV
software DOESN'T WORK anymore. Neither do most spyware removers. Limited
user accounts seem to stop all spyware today - not to say it will continue
to do so, but I'd like to prevent that possibility before they start abusing
limited user access regularly.

> You're interested in using NTFS file ACLs and GP ACL templates to prevent
> execution of apps. I'm pretty sure this can be done. Have you tried
> changing the ACLs on the Documents and Settings\Default User folder and
the
> HKEY_USERS\.DEFAULT registry key? Or search for a hardened GP template
that
> someone else has provided that does the same things?

"Default User" inherits its permissions from \Documents and Settings (read
and execute for limited users). Those permissions are completely ignored
when Win2K creates a new profile - they are copied from there into a new
folder that the user, the Administrators group and the SYSTEM user get Full
Control for. NTUSER.DAT (HKEY_CURRENT_USER) gets copied verbatim and its
internal permissions reassigned.

>
http://www.google.com/search?q=default-user+profile+acl+documents+settings+execute
> http://www.google.com/search?q=default-user+profile+acl

I did these searches and others. Lots of documentation on what the defaults
are, but nothing on how to change them. Not even in Group Policy. There
are security templates for changing the default ACLs for everything else,
however. Unfortunately I can't specify %userprofile% the same way I specify
%systemroot% for instance, because the template editor goes and swaps
%userprofile% with whatever that variable happens to point to at the time.

Maybe I could hand-hack a security template to actually insert %userprofile%
there, but I didn't see a way to also specify the user as a variable
(%username%) I'll give that a try. Some time ago someone suggested a login
script entry that would adjust permissions on the fly (cacls %userprofile%
/E etc etc) which could work but it would lengthen the logon process
considerably, and it didn't seem to have all of the granular settings the
GUI has.

> Do note that those ACLs don't do anything to prevent running executables
> from a floppy, CD, pen drive or added hard drive, so you would also want
to
> consider using other means to disable these drives.

Already considered. Most client machines don't have floppy drives or CD-ROM
drives, have removable devices disabled (no USB sticks), and CD-ROMs first
evaluated before use. Canada's PIPEDA act (enforced starting January 2004)
proved a good reason to do all of this.

> Nor do these prevent
> running, say, VBA macros in Word documents, buffer overflows in image
files
> or PDF files, etc.

Oh hell no, I didn't say changing ACLs was THE only thing to do. It's just
one thing that's part of a much larger security solution:

* Signed macro requirements in MS Office apps (aren't macro viruses dead
tech nowadays thanks to this?)
* E-mail attachment security in Outlook (Bye-bye Melissa and all her
sisters)
* Hardware firewalls (Blaster? Feh. Didn't phase us.)
* ACL changes where appropriate (exploits don't work if they can't run)
* Limited Users (for when buffer overflows etc DO happen)
* Mail filtering at the gateway (Messagelabs, though this is more for saving
bandwidth)
* Regular updates (not panicked updates whenever the Media decides to play
Chicken Little)

> Changing ACLs are helpful in locking down a workstation
> to the level you are trying to do, but only as long as you realize that 1)
> these things only help so much and 2) hardening ACLs to a very strict
level
> can cause a fair amount of frustration and things breaking.

I test things, and I test things some more. My clients are part of the
testing process (Would you come down to my testing lab and try some stuff
out?) Each thing I do only helps so much, but all of those things working
in concert helps a LOT. What's more is no one's more important than the
client - I need to fulfill their needs and that sometimes includes using
security practices I would balk at. Though I try my best to minimize
potential problems (hey, that's what I get paid for!) 

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>

Relevant Pages

  • Re: XP and the I875 ( IC7-G in this case)
    ... There is a way to provide drivers that are newer than ... when XP shipped into the install, but it is not a cake-walk. ... if the account in use does not have permissions ... >>greyed in the app and unable to make the change directly ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Visual Basic executable file
    ... I have developed an application with VB6 that does not require an install ... that the application uses is the web browser control. ... Everything else the app does is either coded ...
    (microsoft.public.vb.general.discussion)
  • Re: Design Guidelines for Non-Power Users?
    ... Non-Power Users and Admins will not be able to install your app. ... You can get whatever this folder happens to be by ... If they don't have write permissions, ...
    (microsoft.public.vb.general.discussion)
  • Re: Design Guidelines for Non-Power Users?
    ... Non-Power Users and Admins will not be able to install your app. ... You can get whatever this folder happens to be by ... If they don't have write permissions, ...
    (microsoft.public.vb.winapi)
  • Re: Different ActiveX versions
    ... release of the ActiveX, and i install it on a computer. ... the old App version stops working because ... give the new control a different CLSID and make it possible to ...
    (microsoft.public.win32.programmer.ole)