Worms and File Privilages Under Windows XP Professional

[Myron Johnson]

I'm wondering about the permissions that worms, viruses, etc. have
under Windows XP Professional.

Let's say that I accidentally installed a worm or virus on my PC. Do
my user priviliges automatically transfer to the worm or virus program
that is running?

If I have access rights to another PC (running Win WinXP-Pro) in the
network, do my access priviliges allow the worm or virus the same
priviliges? Can the worm "log" on to another PC and write to
"protected" directories because it has inherited access rights from
me?

Thanks for any insight. Myron

 

[Mal]

I'm wondering about the permissions that worms, viruses, etc. have
under Windows XP Professional.

Let's say that I accidentally installed a worm or virus on my PC. Do
my user priviliges automatically transfer to the worm or virus program
that is running?

Yes, In most cases. However if it uses an exploit to increase it's
priviliges then it will run in the context of the increased priviliges.

If I have access rights to another PC (running Win WinXP-Pro) in the
network, do my access priviliges allow the worm or virus the same
priviliges? Can the worm "log" on to another PC and write to
"protected" directories because it has inherited access rights from
me?

Normally they use already mapped shares etc. Might be some which grab
your username/password and try to enumerate shares on other machines.

 

[Duane Arnold]

(e-mail address removed) (Myron Johnson) wrote in

I'm wondering about the permissions that worms, viruses, etc. have
under Windows XP Professional.

Let's say that I accidentally installed a worm or virus on my PC. Do
my user priviliges automatically transfer to the worm or virus program
that is running?

Any program running on the machine such as a worm has the same security
context/rights as the user who is logged on the machine at that time.

If I have access rights to another PC (running Win WinXP-Pro) in the
network, do my access priviliges allow the worm or virus the same
priviliges? Can the worm "log" on to another PC and write to
"protected" directories because it has inherited access rights from
me?

If your account has Admin rights on one machine and you logon to another
machine with the same user account, but your account only has User rights
on that machine, then your user account security context on that machine
is User rights only.

Your account rights logging into a NT based O/S machine is based on the
account rights that has been created for that account on that machine.

On a MS network with a MS DOMAIN Controller computer on the network, a
user who has Domain Admin rights can login to any machine on the network
and will have Admin rights to the machine and doesn't have to have an
user account with Admin rights created on the machine.

Duane

 

[David]

This isn't true. When you log onto a machine the initial shell is run under
the logged-in user context. Any programs that are started within that shell
will also have the same user context. This can be overridden of course with
the RunAs mechanism in which you would supply the appropriate password for
the user account you choose to use. Services on the other hand are run under
the account they are configured to run with. Usually this is the local
system account, unless they are changed from the default where possible. If
a worm comes in via a service it will run under the user context for which
it gained access. For example with IIS this would be IUSR_MachineName if it
gained access with anonymous access. If the worm then takes advantage of a
buffer overrun exploit, it basically overwrites code in the memory space of
the program it is exploiting and would then be running with the rights of
that program. If you look at some of the IIS exploits for example, they
overwrite code into the memory space of the initial IIS process which
effectively gives them local system rights. This is why much of the malware
written leverages buffer overrun vulnerabilities.

Any program running on the machine such as a worm has the same security
context/rights as the user who is logged on the machine at that time.

You have to look at each piece of malware individually. Some go after buffer
overuns which will generally give them the rights under which the service is
run. Some propagate via network shares in which they may or may not try
using the user the account and password they are currently running under,
and/or may or may not enumerate user accounts and shares and try to guess
passwords for enumerated accounts and/or shares, and/or may simply guess
passwords while using the default administrator account and default
administrative shares. And so on and so forth.
This is not really true. When you join a machine to a domain the Domain
Admin group is added to the local machines Administrators group. You can
take the group out or move it to a different local machine group if you
wish. There are also changes made to the local computers user right
assignments which again you can modify. You could for example deny Domain
administrators the right to log on locally however allow remote access, or
deny both local and network access.

 

[Duane Arnold]

This isn't true. When you log onto a machine the initial shell is run
under the logged-in user context. Any programs that are started within
that shell will also have the same user context.

I don't know about that and I'll tell you why. I set up accounts on two
Win 2K machines. The account on one machine was setup as Admin and the
same user account name and PSW was created on the second machine with
User rights.

I have a share I use to XFER files between machines. On the second
machine share, I removed all accounts from that share and setup my test
account to only have read access on the share.

Then I logged on the other machine with the test account with Admin
rights on the machine. I then accessed the share on the other machine and
I could see the files. But I could do nothing else on the share like
delete, rename or create a folder.

Based on that, I would think that if a program was started on the other
machine that had the test account Admin rights and mapped a drive to the
share, it could only read the files and do nothing else based on the
security context for the same account on the other machine.

Also, I think that if an account such as Systems, Services, Everyone,
Guest, Authenticated Users etc., etc are not present on the share or
restricted, then whatever security context the user and/or the program
had inherited from the one machine would not apply to the share being
accessed on the other machine.

This can be> overridden of course with the RunAs mechanism in which you would
supply the appropriate password for the user account you choose to
use. Services on the other hand are run under the account they are
configured to run with. Usually this is the local system account,
unless they are changed from the default where possible. If a worm
comes in via a service it will run under the user context for which
it gained access. For example with IIS this would be IUSR_MachineName
if it gained access with anonymous access. If the worm then takes
advantage of a buffer overrun exploit, it basically overwrites code in
the memory space of the program it is exploiting and would then be
running with the rights of that program. If you look at some of the
IIS exploits for example, they overwrite code into the memory space of
the initial IIS process which effectively gives them local system
rights. This is why much of the malware written leverages buffer
overrun vulnerabilities.

I'll have to defer to you on this one as I don't have the security
knowledge and expertise on this. I'll agree that if the accounts are
present, then they can be exploited, even using NTFS. If the machine is
using FAT32, then it can be exploited period.

You have to look at each piece of malware individually. Some go after
buffer overuns which will generally give them the rights under which
the service is run. Some propagate via network shares in which they
may or may not try using the user the account and password they are
currently running under, and/or may or may not enumerate user accounts
and shares and try to guess passwords for enumerated accounts and/or
shares, and/or may simply guess passwords while using the default
administrator account and default administrative shares. And so on and
so forth.

This is not really true. When you join a machine to a domain the
Domain Admin group is added to the local machines Administrators
group. You can take the group out or move it to a different local
machine group if you wish. There are also changes made to the local
computers user right assignments which again you can modify. You could
for example deny Domain administrators the right to log on locally
however allow remote access, or deny both local and network access.

To be honest here, I didn't know that. What I do know is that when I was
given Domain Admin rights on the network, I could go to any machine and
login and would have Admin access rights to the machine.

Duane

 

[David]

When I stated "logging on to a machine and getting a shell" I am talking
about logging on to a machine locally. This would also apply to things like
SSH and terminal server, but that is because they are running programs
remotely as opposed to file sharing in which you are only reading and
writing files.
When you access file sharing over a network you are not running a
shell(explorer) on the remote machine. Think of windows filesharing in the
same terms as an ftp server or P2P file sharing. Read permissions allow you
to download. Write permissions allow you to upload.

This isn't true. When you log onto a machine the initial shell is run
under the logged-in user context. Any programs that are started within
that shell will also have the same user context.

Local machine user accounts with the same name on two different machines are
different accounts.The security context is set up and negotiated with the
unique SID's and not account names. So if I use the same username and
passwords on machine A and B, if I log into machine B from machine A then I
am actually logged into machine B as the user account provided by machine B.
They are two different accounts.

I don't know about that and I'll tell you why. I set up accounts on two
Win 2K machines. The account on one machine was setup as Admin and the
same user account name and PSW was created on the second machine with
User rights.

When you map a drive and read files from it you are actually downloading the
files. So in your case you can read the files. But you can also edit the
files and save them on the local machine. You just can't save them back to
the remote machine because Admin on the remote machine is actually a
different account then Admin on the local machine.

Based on that, I would think that if a program was started on the other
machine that had the test account Admin rights and mapped a drive to the
share, it could only read the files and do nothing else based on the
security context for the same account on the other machine.

It doesn't matter between machines because even if accounts are named the
same they are different because under the covers windows is using the SID's
of the accounts and not the account names. Nothing is inherited from one
machines accounts to another machines because they are seperate distinct
accounts.

Also, I think that if an account such as Systems, Services, Everyone,
Guest, Authenticated Users etc., etc are not present on the share or
restricted, then whatever security context the user and/or the program
had inherited from the one machine would not apply to the share being
accessed on the other machine.

That's simply because things were not changed from the defaults.

 

[Duane Arnold]

When I stated "logging on to a machine and getting a shell" I am
talking about logging on to a machine locally. This would also apply
to things like SSH and terminal server, but that is because they are
running programs remotely as opposed to file sharing in which you are
only reading and writing files.

So what you are telling me is that if I was a remote user and logged on
to the network at a local machine using a NT Domain account running an
application on one of the terminal servers using IE to access the TS
application and I just happened to be using a NT Domain Admin account,
that's trouble, if a worm was on the local machine and riding in on the
connection. It's trouble because the worm inherited the account security
context I had when I logged in on the local machine.

Can I ask you another questions concering VPN and wireless? In using a
VPN protocol does it have to have two end points? I know on my LAN the
Win 2k machines can be using VPN for wireless to wired connection. Where
does the VPN protocol on the router come into play on the LAN, if at all
in that situation?

I know VPN on the router comes into play between my work machine using
AT&T Extarnet Client software and connecting to the company network that
requires a VPN connection.

Will VPN being used on the wirelss machine with the router using VPN
protect the packets between the wireless machine and the router? Is the
router in this case a end point, if the machine is not connecting to an
end point -- just accessing the Internet normally?

Duane

 

[David]

The worm would have to be specifically written to propagate over terminal
server. Worms don't just "ride" on any random connection, they are
programmed to propagate using specific protocols.

So what you are telling me is that if I was a remote user and logged on
to the network at a local machine using a NT Domain account running an
application on one of the terminal servers using IE to access the TS
application and I just happened to be using a NT Domain Admin account,
that's trouble, if a worm was on the local machine and riding in on the
connection. It's trouble because the worm inherited the account security
context I had when I logged in on the local machine.

Every connection needs two endpoints. In general you are either running
your VPN tunnel between two gateways(to connect two LANS together over a WAN
link), or you are running the tunnel between a single client machine and a
remote gateway as in your case.

Can I ask you another questions concerning VPN and wireless? In using a
VPN protocol does it have to have two end points? I know on my LAN the
Win 2k machines can be using VPN for wireless to wired connection. Where
does the VPN protocol on the router come into play on the LAN, if at all
in that situation?

The VPN client software provides the endpoint, your cable/dsl router is
simply passing the tunnel through.

I know VPN on the router comes into play between my work machine using
AT&T Extarnet Client software and connecting to the company network that
requires a VPN connection.

Of course not. Your router is not the endpoint. The vpn client machine is.
If you have traffic with a destination address that corresponds to a machine
on the remote network then the OS's routing table indicates that the traffic
should use the VPN adapter, which is actually just a virtual adapter(sort of
like the loopback but essential indicates that the vpn client program
handles it). The vpn client then takes that traffic encrypts it and adds new
headers using the destination address of the VPN gateway machine on the
other end and a destination port number that corresponds with what the
specific VPN technology uses for the tunnel. The traffic is then sent out
the same physical adapter that is used for the rest of your internet
traffic.

Will VPN being used on the wireless machine with the router using VPN
protect the packets between the wireless machine and the router? Is the >

router in this case a end point, if the machine is not connecting to an