Comments on: How to let standard users configure the TCP/IP settings

By: phil

phil — Tue, 16 Mar 2010 22:16:49 +0000

I can not even get a standard user(on a Windows 7 Pro box) who is made part of the Network Configuration Operators Group to be able to modify network settings. Am I missing something? It is said above that this should work but does it or is this the reason for tools such as Steel Runas being popular.

By: Jump Firewalls in a Single Bound With Proxy Servers | Unlock Everything

Jump Firewalls in a Single Bound With Proxy Servers | Unlock Everything — Fri, 27 Feb 2009 13:29:22 +0000

[...] How to let standard users configure the TCP/IP settings [...]

By: Michael Pietroforte

Michael Pietroforte — Fri, 27 Feb 2009 02:01:47 +0000

Ah ok. I got you now. I know how & works, but I didn’t know that it also works when entered at an input prompt. Interesting. Thanks.

By: Michael Pietroforte

Michael Pietroforte — Fri, 27 Feb 2009 01:50:10 +0000

The question is where they would enter cmd.exe? They can’t enter any commands.

By: JohnB

JohnB — Fri, 27 Feb 2009 01:45:36 +0000

The “&” is the command separator and combined with the “cmd.exe” it will cause a new shell to start. The root problem is that there is no validation/escaping harmful characters of the user input; this problem manifests itself in many other fields, but a really good example of it is a SQL injection attack.

Try it yourself, just use runas on your first script to simulate running under the (unelevated) admin credentials and enter &cmd.exe when it prompts for the IP/Gateway. From there you can run “elevate cmd.exe” to get an elevated command shell.

By: Michael Pietroforte

Michael Pietroforte — Fri, 27 Feb 2009 01:33:59 +0000

The interesting question how they would get access to the shell in the first place. They can just enter IP addresses with the script.

By: JohnB

JohnB — Fri, 27 Feb 2009 01:30:26 +0000

I haven’t tried it out with Steel RunAs but I don’t think it matters that the first shell they get isn’t elevated. The shell would still be running under whatever account was running the batch file and they can elevate from there with no username/password prompt.

I agree that setting the credentials to Net Cfg Ops would largely mitigate this problem.

By: Michael Pietroforte

Michael Pietroforte — Thu, 26 Feb 2009 11:41:34 +0000

John, I don’t think that it is that easy to get an elevated shell. On Vista only the netsh command is elevated in this example not the shell itself. Also, users can’t easily end the script to get a command prompt. CTRL+C doesn’t work, for example. But it is probably better to execute the script not as administrator. You can just use a member of the Network Configuration Operators group. I added this hint to the text. Thanks.

In my opinion, the Microsoft’s solution is not good. Most users are not even able to find the network settings under Vista because Microsoft hided them deeply in the Control Panel. I think it is better to offer users a little program where they can just enter the IP and can’t do anything else. Most users would start messing around with the network settings if problems occur. It is the “first law of administration”: Never give an end user more rights or options than are needed to get the job done.

By: JohnB

JohnB — Thu, 26 Feb 2009 07:41:54 +0000

You’re leaving yourself open to easy privilege elevation if you go with this solution. All the user has to do is enter “& cmd.exe” at one of the prompts and they have a command shell with elevated admin rights.

Not that the average user will know to do this, but it still seems more secure to me to stick to how the system was designed to be used (adding them to Net. Cfg. Ops) rather than trying to do an end-run around the security measures.