RE: User downgraded from Administrator to User retains the ability to list other user's running tasks

["Eitan Caspi" <eitan_c () 012 net il>]

Hello John,

1. Yes, the downgrading process is made by the "master" admin while the
test user is completely logged off and don't have any current local
login session.
Please read the reproduction steps to follow.

The test user is logged off to make sure its profile has completely and
correctly saved and to avoid any problems of changing the user's role /
rights while it is logged on.

2. As you can see in step #3 - the whole procedure is related to FUS,
since it is currently the only way to have 2 (or more) users logged on
locally at the same time.



Regarding you note about the fact that MS has made the FUS available
only in a workgroup scenario:

You're note has also made it into MS response.

I must say I don't accept this as a dismissing reason and attitude for
several reasons:

1. It is clear to me that this great feature (FUS) will be later
implemented in a domain scenario as well - since it is a great way to
better utilize PC resources and companies LOVE to "utilize" (meaning:
save...).

So, we have to look forward and alert of problems ASAP.


2. As I noted at the end of my first email: There may be some corporate
scenarios which will use the OS in a workgroup environment. Not many, I
agree, but we can't afford to overlook this - especially in a scenario
where PCs are used to connect to the internet.


3. You can't claim that an OS is "very secured", but then state that a
feature of it is not "meant to be secured" and "the company's meaning
for this feature was that it will be used only at home".
If FUS is "home oriented" - than why it is included in the XP "Pro"
version?

If you design something to be secured - then every part of it must be
designed securely. You can't give yourself a discount when it is
comfortable for you.

My opinion is that MS response is evading responsibility.


Regards,

Eitan Caspi
Israel

-----Original Message-----
From: John Tolmachofft [mailto:sflist-bugtraq () reliance net] 
Sent: Friday, November 29, 2002 6:41 PM
To: eitan_c () 012 net il
Cc: bugtraq () securityfocus com
Subject: RE: User downgraded from Administrator to User retains the
ability to list other user's running tasks 

Does the user completely log off after being downgraded from the Admin
role,
or was this tested by using the FUS?

BTW, FUS is only available in a work group environment. It is not
available
if the computer is a member of a domain.

John Tolmachoff MCSE, CSSA
IT Manager, Network Engineer
RelianceSoft, Inc.
Fullerton, CA  92835
www.reliancesoft.com


-----Original Message-----
From: Eitan Caspi [mailto:eitan_c () 012 net il] 
Sent: Thursday, November 28, 2002 10:57 PM
To: bugtraq () securityfocus com
Subject: User downgraded from Administrator to User retains the ability
to
list other user's running tasks 

Summary:


Windows XP presents a new option called "Fast User Switching" (FUS).
This option enables multiple users to be logged on locally to the same
PC at the same time, although only one user at a time can work at the
station's GUI. This option is a variant of the Terminal services (which
you will be able to see in the services list).


I have found that if a user is downgraded from an administrator role to
a user role, and at the time of downgrading ? the "show processes from
all users" check box in the "processes" tab of the task manager
application was check on for him ? this ability is retained for him
(probably in its profile), although he should not have this right since
he is not a member of the administrators group anymore.


I could not perform any DIRECT harmful actions at other user's processes
(such as killing them). The vulnerability looks like it is mostly a
disclosure of a general user's activities like: which application they
are running (which can be counted as a form of surveillance and lack of
privacy) and maybe (I not sure if this is true) - for how long they are
logged on (by the "cpu time" value of "explorer.exe" for a user).


Maybe (I didn't try) it will be possible to use application like
"kill.exe" (a windows 2000 resource kit utility that kills processes by
name or PID (Process ID, as shown in task manager)) via tempting the
local victim to:
1.      Run a local batch / script / shortcut which uses this
application
2.      Open an incoming email using this utility (less possible due to
security enhancements in the newer MS email clients)
3.      Visit web site that will use a script or a locally directed link


This vulnerability was not tested in a windows 2000 "classic" terminal
server service due to lack of domestic resources (?), but it will be
interesting to know if this environment is effected as well, since it is
much more "business oriented / sensitive" than a local XP.





Affected software: Windows XP Professional with SP1


Reproduction:


(Note: Directions are referred to a system with the XP start menu style,
NOT the classic start menu style)


1.      Log on to windows XP as a user with administrative rights.
2.      Click start -> control panel -> user accounts -> change the way
the users log on or off
3.      Make sure both check boxes are enabled ("use the Welcome screen"
and "Use Fast User Switching") and click "Apply Options". Close the
"User Accounts" form.
4.      Click start -> administrative tools -> computer management
5.      Open the branches: system tools -> local users and groups ->
users
6.      Create a new test user and place it in the local administrators
group. Click "create" to enable the user.
7.      Log off
8.      Log on as the test user
9.      Open the task manager application (ctrl+shift+esc) -> select
the "processes" tab -> enable the "show processes from all users" check
box -> close task manager.
10.     Log off the test user
11.     Log on as a user with administrative rights (but NOT as the test
user!)
12.     Click start -> administrative tools -> computer management
13.     Open the branches: system tools -> local users and groups ->
users
14.     Open the test user's properties and remove it from the local
administrative group, and add it to the local users group
15.     Perform a "switch user" action ( by clicking start -> log off ->
switch user  or by clicking "windows logo keyboard button"+ L ). The
user's interface is locked and the welcome screen appears.
16.     Log on as the test user
17.     Open the task manger -> open the "processes" tab.
you will see all the process of other logged on users (in our case ? the
user with administrative rights that was logged before and locked its
interface). Note that the "show processes from all users" check box is
NOT selected and even dimmed so you can't change its status.





Reproduction Cleanup:
1.      Log off the test user
2.      Log on back to the "already logged" administrator account
3.      Click start -> administrative tools -> computer management
4.      Open the branches: system tools -> local users and groups ->
users
5.      Select the test user and delete it.
6.      Close the "computer management" application
7.      Click start -> control panel -> system -> "advanced" tab -> user
profiles settings -> choose the test user's profile ? click delete and
confirm the deletion.





Exploit Programs:
There is no exploit programs necessary.





Workarounds:


1.      Don't work in a "Fast User Switching" mode. This will force the
system to have only ONE user logged on at a time, and thus ? the
currently logged on user will not be able to see other user's process
since there will be no other users logged on at the same time?


2.      A friendlier workaround that enables you to keep the "Fast User
Switching" mode and eliminate the problem:
Since this ability looks as it kept in the user's profile:
a.      As a local administrator - add the user back to the local
administrators group
b.      Log on as the problem user
c.      Open "task manager" and un-check / disable the "show processes
from all users" check box. Close "task manager"
d.      Log off the problem user
e.      As a local administrator - remove the user from the local
administrators group


This will reset things back to normal.





Vendor Notification:


Microsoft was alerted about this.
I think that attaching their response will give a good idea of their
concept:


"My understanding is that FUS (Fast User Switching) is a consumer
oriented feature - http://www.microsoft.com/windowsxp/home/evaluation/
overviews/sharing.asp .
It's only available in Windows XP Home, or Pro when explicitly enabled
AND when in a workgroup only. As such it's not a corporate focused
feature. Since it is aimed at the home space, the thread profile is
different - FUS is aimed at making it easy for multiple users to share
the same machine whilst maintaining their own settings. It's focus is on
this separation of settings to provide personalization, it is not
explicitly designed to provide complete security separation of users. It
does not make any promises about explicitly keeping sessions secure from
each other.


The classic usage scenario for FUS is in the home, where several members
of the same family share the same computer. Using FUS, different
individuals can maintain separate e-mail accounts, Instant Messenger
profiles etc without interfering with each other's settings. This of
course means that each individual has access to the computer, in which
case, the 3rd Immutable law of security applies:
http://www.microsoft.com/ technet/treeview/default.asp?
url=echnet/columns/security/essays/10imlaws.asp .


However, given the consumer oriented usage scenario for FUS, it is
likely that there is a very high degree of trust between each user, as
they will be part of the same household etc.


Whilst the scenarios you describe below are of course technically
correct, they are unlikely. They suggest that one member of the
household may decide to hack another, or deny service to another.
Specifically, lets' look at the denial of service scenario, where one
user would enumerate the processes of the other and then craft an e-mail
that called "kill.exe" to kill the other user's processes. There are a
number of flaws here. If the users are using Outlook Express, then OE
6.0 is the default on XP, which blocks executable attachments. If the
users are using the full Outlook client, then there is a high
probability that it is one of the later versions of Outlook, that again
block attachments.


Secondly, under the default FUS settings, no passwords are set on the
accounts, so one user can switch into another user's session. Again this
is because the primary objective of FUS is user personalization, not
security separation. Thirdly, if the user has the ability to logon, then
they by default will have the ability to shut the machine down (even as
a limited user). This is just as effective a denial of service than
having to enumerate PID's, craft e-mails etc, or altering the paths to
shortcuts.


Ultimately, with FUS, the 10 Immutable laws of security apply - if I
have physical access to the machine, I can do what I want. Given however
the consumer oriented usage of FUS, the degree of trust that is likely
between users on the same FUS enabled machine, and the fact that the
primary purpose of FUS is user separation for personalization reasons
and not security reasons, I think the threat rating for this style of
attack is very low.


Thanks for taking the time to bring this to us"


Just one note by me: They did not mention a possibility of using FUS in
a business to share a PC resource among shift workers and / or using it
as a shared internet station.


Credit:
Eitan Caspi
Israel
Email: eitancaspi () yahoo com