Re: registry hacked under XP limited account
From: Knox (thornNOSPAM99_at_hotmail.com)
Date: Mon, 30 May 2005 13:13:39 -0400
The security templates are actually in %windir%\Security\Templates.
I haven't ever used these templates. Looking at them, they don't seem to
deal with software restrictions which I would think are one of the best ways
of preventing malware from creating problems by preventing the execution to
begin with. You touch on some recommendations for software restrictions, is
there a "best practices" template for those?
"Stefan Kanthak" <firstname.lastname@example.org> wrote in message
> "Karl Levinson, mvp" <email@example.com> wrote:
>> "lecter" <firstname.lastname@example.org> wrote in message
>> > I have a computer run under winxp system. And one day I found that
>> > the registry was modified and I couldn't run any .exe file! (the
>> > problem have been solved by input a registry key.)
>> > The thing I want to know is that the registry can be modified
>> > under winXP limited account?
>> Very very easily. Running as limited account does VERY LITTLE to stop
>> viruses. Anyone who tells you any different is mistaken. Even
>> people at Microsoft have this misconception.
> Right so far: EVERY piece of code that comes to execution (intentionally
> or not) has exactly the same rights/privileges as you. It can trash ALL
> your files (remember: on NTFS the owner has full access; on FAT: forget
> ANYTHING about security then) and write garbage everywhere you are
> allowed to write to. This specifically includes your userprofile (your
> registry hive beeing a part of) and your home directory.
> BUT: as long as your account has no administrative rights and NO debug
> privilege logging out will terminate all processes you started.
> AND: running with administrative rights is a VERY BAD HABIT.
> Multiuser operating systems are about 50 years old, Unix about 30 years,
> and one of the first rules a novice system administrator will learn is:
> NEVER work with administrative rights if you don't do administrative
> tasks! You get your own limited account and use it for your daily work.
> This will LIMIT any damage: just try an RMDIR /S /Q %SystemDrive% with
> your limited account and then with administrative rights.
>> Running as limited user does prevent much spyware and adware today, but
>> because the authors of that malware see no need to make their programs
>> as limited users. This tactic will NOT be effective against future
> WRONG: running as limited or restricted user on a properly setup XP or
> 2K system prevents malware from infecting or compromising the system
> itself or other user accounts.
> Malware can do anything you are allowed to do on your account, but cant
> compromise other accounts or write itself to %ProgramFiles%, %SystemDrive%
> or %SystemRoot% and beyond. It can do anything with [HKCU], but nothing
> in [HKLM] and the registry hives of other users.
> ... except when using a (not yet fixed) security hole.
> Up to now I don't know malware that used a (remote) exploit before the
> fix was available.
> If you're in doubt how to setup a system properly: Microsoft, the
> No Such Agency, the NIST and some others published detailed guides how
> to "harden" a system. Have a look at the (high) security templates in
> %SystemRoot%\System32\Security\Templates\ and use them (carefully).
> If you have XP home: turn OFF that dumb "simple file sharing" and
> answer the question whether the user profiles should be secured from
> other access with YES!
> If you don't know how to properly setup a system: go and hire someone
> who is able to do this right (but beware).
> BUT: when you have a window displayed on your desktop that runs in a
> higher privileged process (MOST, if not ALL of those pseudo^Wpersonal
> firewalls and some virus scanners do so) then it's possible to attack
> that process and perform a privilege escalation.
> That's a PRINCIPAL problem of Windows and well known as shatter attack
> and should BY ALL MEANS be avoided (don't use such software, and don't
> buy such crap).
>> Malware running as limited user can do anything that you can do. If you
>> were able to change the registry and fix the problem while logged in as a
>> limited user, then malware would have the same permissions. You can see
>> permissions of that registry value by clicking Start, Run and typing
> Correct. But since you are owner of [HKCU] you have full access to any
> of your registry entries (or can get it), so this advice ain't so very
>> Also, many viruses use buffer overflows or could theoretically
>> use other exploits like local privilege escalation to gain full System
>> privileges, regardless of the permissions of the currently logged-in
>> If the registry value you fixed did not give Write permission to your
>> limited account [or to the Users or Everyone groups], then I would go to
>> http://windowsupdate.microsoft.com to check to make sure your system has
>> its critical Windows patches to prevent remote buffer overflow viruses.
> TOTALLY RIGHT.
> The least you can and should do is to patch your system timely. Up to now
> the exploits came all after the fixes...
>> If you have multiple user accounts sharing one machine, logging in as a
>> limited user may prevent malware from loading and running when other
>> log in. If you are the only user of your machine, however, that
>> means absolutely nothing. Even if multiple people use the same system,
>> can all become infected if they all happen to run a shared infected file,
>> for example.
> But then that infected file must have been written (itself?) to a
> location where all other users will execute it. In a properly setup XP
> (Home: turn off "simple file sharing") or 2K the ACLs prevent this.
>> What running as limited user does primarily is prevent the user from
>> changing the system configuration too much, mainly to implement change
>> control within an enterprise. It also makes it harder for malware
>> under your account to do some things like create new login accounts.
>> also a security best practice, but not really because of viruses or
>> Running as limited user does not prevent you from becoming infected,
>> out infected emails or packets, infecting other systems, deleting all
>> data, searching your data for credit card numbers and passwords, running
>> listening service, etc.
> Totally right.
>> Note also that "Power User" is really not a very limited user. It is
>> to escalate privileges to Administrator. Also, most accounts in the
>> group are not as limited by default as you might think.
>> RUNNING AS LIMITED USER DOES LITTLE OR NOTHING AGAINST VIRUSES. Spread
> But it limits the damage to your own user profile and home directory!
> It's therefore possible to clean the infection without reinstallation
> of the system: login as another user with administrative rights (you
> might prefer "secure mode" so that most autostart mechanisms wont be
> triggered) and erase the user profile and the home directory of the
> user account where the malware was executed.
> Here the typical home user with just one PC has an advantage above the
> office user in a companies' network: the latter must be cleaned at all
> places where the compromised user account had write access!
> AND: if you really do it right then use software restriction policies
> and deny the execution of ANY file except beneath %SystemRoot% and
> %ProgramFiles%. Since restricted users aren't allowed to write there
> they can't run arbitrary code, but only the programs the administrator
> (or a power user) installed.
> If that's to restrictive: you should AT LEAST deny execution in %TEMP%,
> ?:\RECYCLE?\, ?:\System Volume Information\, the caches of your browser
> and mailer, all removable drives.
> ALSO: if you use your PC standalone at home you SHOULD turn off the
> whole "Windows network", i.e. file and printer sharing, NetBIOS, RPC,
> DirectSMB and so on. You'll need TCP/IP and nothing more to surf the
> net and communicate per mail and news and "ICQ" and whatever you like.
> Have a look at http://home.arcor.de/skanthak/harden.html and see the
> HARDEN2K.INF linked there: this will lock down 2K as far as possible.