Hackers target Microsoft Windows XP support system

Hello All!

People might find this interesting

Hackers target Microsoft Windows XP support system
Thursday, 1 July 2010 10:17 UK

The bug affects well-established Windows XP operating system .
Hi-tech criminals are "escalating" attacks on an unpatched bug in the
Windows XP help and support system.

http://news.bbc.co.uk/2/hi/technology/10473495.stm


--


James Silverton
Potomac, Maryland

Email, with obvious alterations:
not.jim.silverton.at.verizon.not

James Silverton wrote:

Hello All!

People might find this interesting

Hackers target Microsoft Windows XP support system
Thursday, 1 July 2010 10:17 UK

The bug affects well-established Windows XP operating system .
Hi-tech criminals are "escalating" attacks on an unpatched bug in the
Windows XP help and support system.

http://news.bbc.co.uk/2/hi/technology/10473495.stm

That article is so vague as to be worthless. It never mentions any
technical articles that actually describe the vulnerability. It doesn't
even bother to provide a link to the Fix-It page. As such, it smacks of
sensationalism to scare their readers. It's not even a "news" article.
It's some joker's blog who doesn't even bother to identify themself.

http://www.microsoft.com/technet/sec...y/2219475.mspx
http://support.microsoft.com/kb/2219475

The solution is a really old one: don't web browse while logged on as an
admin-level user. Either logon under a limited account when web surfing
or run your web browser under a LUA (limited user account) token to
reduce its privileges. Windows XP already provides SRPs (software
restriction policies) that will let you run a program under a "Basic"
(LUA) account; however, you need to perform a registry hack to get Basic
listed as a policy mode (by default, it only lists Allowed and Blocked).

Security experts usually recommend that users log into a limited user
account (LUA) to more securely surf the web. When logged under a LUA,
privileges are reduced on the web browser will severely curtails the
damage that malware can perform when the web browser is the infection
vector into your computer. Under a limited account, the user cannot
install software. This all sounds nice except that users often need the
privileges of an admin-level account to run their applications, plus
they cannot install updates to Windows when using the web browser to
visit the Windows Update site (after all, the web browser has limited
privileges so it can't install anything). So how does the user that
wants to log under an admin-level account make sure their web browser is
running under limited privileges to afford the extra security that it
offers but also occasionally run the web browser with unrestricted
privileges so they can perform software installs when they so choose?
Some choices are shown below. The last one involving Software
Restriction Policies (SRPs) uses the power to exercise access control
within Windows itself and doesn't require the installation of any
additional security software (or can be used to augment security
software that doesn't provide the option of running the web browser
under a LUA token).

You could use the 'runas' command to specify that the web browser runs
on another account which is a limited account. That's a pain in the
ass. Everytime you use 'runas' (interactively or with a shortcut), you
will get prompted for the password of that limited account. This won't
work if that limited account has no password (it is blank) or you have
no limited accounts (i.e., they're all admin accounts).

Windows XP, and later, has its Fast User Switching (FUS) feature which
lets you stay logged in under your current account while simultaneously
logging under another account. So you could log under your limited
account to do most of your everyday tasks there including your casual
web browsing. When you need admin-level privileges on your programs,
use FUS to login and switch to your admin-level account and run your web
browser and installs over there. Window Vista's UAC (User Access
Control) eliminates having to do this switching back and forth between
limited and admin accounts; however, many users disable UAC soon after
getting acquainted with Vista because they consider it a nuisance.
Using FUS to switch between limited and admin accounts (which can remain
logged in) might be more comfortable for these users.

There are utilities that will load a program under a LUA token. The
process gets the same privileges as the token. Since the LUA token has
reduced privileges so does the process loaded under a LUA token, and so
are all child processes of that parent LUA-tokened process forced to run
under reduced privileges. An old utility that allowed you to run a
program under a LUA token was DropMyRights. An alternative is
SysInternals' psexec utility (with its -l command-line parameter). The
problem with this method is that only the program started by
DropMyRights or psexec would have its privileges reduced by running
under an LUA token. It does not handle when the program is started as a
child process of another program, like when you click on a URL in a
message in your e-mail client that loads the web browser. The shortcut
that runs DropMyRights or psexec to run the web browser under an LUA
token has no effect when the web browser is started by some other
program. You can define shortcuts that use DropMyRights or psexec to
reduce privileges on the program that they load but you can still have
instances of that program started that will run with unrestricted
privileges (i.e., they get the same privileges as the program that
loaded them which probably will be the privileges of your admin-level
account that you logged into).

There are security programs that let you run a program under reduced
privileges. For example, there is Tall Emu's Online Armor (firewall
with HIPS [Host Intrusion Protection System] which has rules to govern
what applications can load and/or obtain network connections). It has
the Run Safer option which will ensure that the program always gets
loaded under a LUA token no matter who or what started that program. So
whether you clicked on a shortcut to load the web browser or you clicked
a URL link in a message in your e-mail client, the web browser will
still run under a LUA token. Comodo's firewall (v4) has a
pseudo-sandbox feature (it has some virtualization but is not a full
sandbox, like Sandboxie). You can add a program to the "Programs in the
Sandbox" list which means they will always get sandboxed. This will run
that program in Comodo's isolated environment and also runs the program
with reduced privileges. There are problems when running programs
within a sandbox due to trying to isolate that program. Here we are
only discussing how to reduce privileges on a process to restrict what
it or any child processes started by it can do. In Comodo's sandbox,
you can disable file (and registry) virtualization and the program will
not be sandboxed but it will run under a LUA token. If you are looking
to add a firewall+HIPS security product then one that affords you to
configure a program to force it to always run under a LUA token is a
good choice. Both OA and Comodo let you quickly disable their Program
Guard or sandbox by right-click on their tray icon. That way, when you
need unrestricted (admin) privileges for the web browser, like when
getting updates from the Windows Update site, you can quickly turn off
the protection, start a new instance of the web browser to do your
thing, unload that instance of the web browser, and then re-enable the
protection.

The last method doesn't require any additional software if you are using
Windows XP, or higher. It involves using software restriction policies
which are a feature of those operating systems. In Windows Vista and
up, there is a "Basic User" protection level that can be specified in a
SRP rule which will run the specified program under a LUA token. Alas,
this policy level is available but hidden in Windows XP. To add the
"Basic User" policy level to Windows XP, run the following command to
add an entry into the registry:

reg.exe add
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\Co deIdentifiers" /v
"Levels" /t REG_DWORD /d 0x20000

The above line may be wrapped. It is one line that runs reg.exe
(command-line registry editor) with a whole lot of parameters. Then to
see if this policy level got added, run the group policy editor
(gpedit.msc) and navigate to the following node:

Computer Configuration - Windows Settings - Security Settings -
Software Restriction Policies - Security Levels

Note: gpedit may not be available in Home editions of Windows.

You should see the following security levels:

Disallowed: A program with this policy level cannot load.
Unrestricted: A program has all privileges of the account under which it
was loaded.
Basic User: A program runs under the reduced privileges of a limited
account.

Now you can define an SRP path rule to a program that will force that
program to be managed by one of these policy levels. The Disallowed
level can be used to keep programs from loading. You may install a
program that you want but it keeps trying to run another program that
you don't want to let run (like Quicktime that keeps trying to run
qttask.exe or RealPlayers realsched.exe program to check for updates).
To force the web browser to run under the Basic User policy level (so it
has the reduced privileges of the LUA token):

- Go under "Additional Rules" tree node.
- In the right panel listing the rules, right-click and select "New path
rule".
- Browse to the web browser's executable file (e.g., iexplore.exe).
- Select "Basic User" for the security level.
- Add a comment, like "Force web browser to run under reduced
privileges".
- Click OK.

Any currently open instances of the web browser will retain whatever
privileges they had when they loaded. Close them all. Now when you
load the web browser whether directly with a shortcut or indirectly as a
child process, like a URL link in an e-mail, the web browser will run
under the Basic User security policy which reduces privileges on that
process.

Okay, you've now choked the privileges of every instance of your web
browser but you know there are times when you need an unrestricted
instance to, say, apply updates through the web browser to Windows or to
install AX controls into the web browser. Well, remember that the SRP
policy is a *path* rule. It will apply the policy to THAT program that
you specified, not to a file in some other path. So, and using Internet
Explorer as an example, just make another copy of the web browser's
executable file that is in a different path (some, like IE, won't run if
you merely make another copy of iexplore.exe and call it another name,
like iexplore2.exe). Go to the web browser's install folder (C:\Program
Files\Internet Explorer), make a subfolder called, say, NoSRP, and copy
iexplore.exe under that new folder. The SRP policy won't apply to that
copy of the web browser's exectuable file because the path to it is
different. Then create a shortcut to that alternately pathed executable
file and use that for your unrestricted copy of the web browser.

For those that like to add 3rd party security products, some will let
you restrict the privileges on a program, like the web browser, to make
it more secure against attack as an infection vector for malware.
However, for those that don't want all the overhead and headaches of
adding more security software that produces more prompts that the user
may not understand and causes potential conflicts with use of the
programs that you are trying to protect, an SRP policy using the Basic
User security level to run the program under a LUA token that reduces
that program's privileges is just as good as logging under a limited
account and running the program there.