Net user add bypasses GPO?

How far did you test this? Did you try to log in as the user w/ no password? Then did you try a gpupdate /force and see what happened?

Curious!

well, I followed these steps:

1.- Ran GPUpdate /force
2.- Net user /add test /passwordreq:no

These commands were successful and I could verify that the new user test appeared in the local machine.

I did a RSP for my computer and my domain and the "password must meet complex req" was enabled from domain policy.

As you suggested, I tried a RUN AS but I could not login with the new user (no password error).

Still, this worries me... the account was created with no password!

.... mmmm ..... mmmmm .....

mastercorm

this might be a stupid question, since i'm fairly new to this, but you mention the domain GPO was set for complex passwords. the user you added was local, so what was the local password policy? Was there a difference between trying to log into the domain versus logging onto the local machine?

Well, according to GPO inheritance, the domain password policies apply to the local workstation too, even if the local policy specifies the contrary.

Still, I did a RSP and view de local GPO and it was overriden by the domain GPO.

Now: I did try the same on a DC, and... it worked. I created a user with the same procedure on a domain controller with the GPO requesting complex passwords.

... mmm .... mmmm ....

There must be a reason...

mastercorm

oh, ok. that seems like an odd security loophole though. there must be more to it.

Well if you couldn't log in as the new user I think it is not a true security risk. Interesting, yes. I'm going to PM "Mr. Security" himself, aka Keatron, and see if he'll post his take on this.

Great post agustinchernitsky!

Well, it is interesting... It does allow you to create the user without pass, but it doesn't allow you to create a user if you do specify a weak password and the /passwordreq:no option (the GPO does apply here).

I tried to login using the RUNAS command, and it didn't work... still, an interactive logon does. The GPO denys a network logon for users without password... but it does allow interactive. There is "some" mitigation here... from the network threat, but not for local console.

My opinion: The tool shouldn´t allow you to create a user without password with the "Complex Password" GPO enabled.

I see a couple of ways to mitigate this, which I do use on my network, though I hadn't thought of using these in terms of our subject issue here.

1. Use Restricted Groups - populate the Users Group with "domain\domain users". This will cause any newly created users to be removed at each refresh interval of Group Policy (90 minutes + up to 30 minutes)

2. Require a Smart Card for interactive logon.

Actually, if you notice in the local security policy, there is a setting under security options "Accounts: Limit local account use of blank passwords to console logon only". This alone would seem to indicate that the GP setting requiring complex passwords really only applies to domain accounts. I have set the Local Security Policy to require complex passwords as well and am unable to create a user account using the passwordreq:no option.

C:\WINDOWS\SYSTEM32>net user joe /add passwordreq:no
The password does not meet the password policy requirements. Check the minimum p
assword length, password complexity and password history requirements.

More help is available by typing NET HELPMSG 2245.


C:\WINDOWS\SYSTEM32>net user joe CoMpLexPW565$! /add
The command completed successfully.

mastercorm

interesting, does that mean i was right about local security policy having an effect?

http://www.techexams.net/forums/viewtopic.php?t=20733

mastercorm wrote:

interesting, does that mean i was right about local security policy having an effect?

Sure looks like it. I should have guessed from the first though. This is that old topic of the Password Policy, in which there can be only 1 Password Policy for a domain, and it is set at the domain level, and any other password policies applied below that (OU's) affect local accounts only, while the One Domain Password Policy affects only domain accounts.

turkken

In our domain we ocassionally give someone a local log\pass that they want to be easy - like Finance\Finance. We don't like to do it but occasionally make an exception for a presentation laptop. I used to always add the accounts before joining the domain to avoid our domain policy requiring complexity requirements (accounts done before getting the policy still work locally).

Recently I did it on a PC already on the domain - I just went in to local policy and changed everything I needed then added the log\pass. When you reboot I'm sure the domain policy re-applies and filters down to local policy, but until a reboot\refresh\Gpupdate, ect on the domain you have changed the policy and can do anything you want with accounts.

I'm not sure if this really relates to the topic, but something I noticed...

turkken wrote:

In our domain we ocassionally give someone a local log\pass that they want to be easy - like Finance\Finance. We don't like to do it but occasionally make an exception for a presentation laptop. I used to always add the accounts before joining the domain to avoid our domain policy requiring complexity requirements (accounts done before getting the policy still work locally).

Recently I did it on a PC already on the domain - I just went in to local policy and changed everything I needed then added the log\pass. When you reboot I'm sure the domain policy re-applies and filters down to local policy, but until a reboot\refresh\Gpupdate, ect on the domain you have changed the policy and can do anything you want with accounts.

I'm not sure if this really relates to the topic, but something I noticed...

The key here again is that the Domain Policy only applies to Domain Accounts. A local user account created on a computer will use the local password policy of the computer, not the domain password policy.

sprkymrk wrote:

turkken wrote:

In our domain we ocassionally give someone a local log\pass that they want to be easy - like Finance\Finance. We don't like to do it but occasionally make an exception for a presentation laptop. I used to always add the accounts before joining the domain to avoid our domain policy requiring complexity requirements (accounts done before getting the policy still work locally).

Recently I did it on a PC already on the domain - I just went in to local policy and changed everything I needed then added the log\pass. When you reboot I'm sure the domain policy re-applies and filters down to local policy, but until a reboot\refresh\Gpupdate, ect on the domain you have changed the policy and can do anything you want with accounts.

I'm not sure if this really relates to the topic, but something I noticed...

The key here again is that the Domain Policy only applies to Domain Accounts. A local user account created on a computer will use the local password policy of the computer, not the domain password policy.

This is correct. And it's for the longest been one of the biggest security loop holes with Windows X hosts. The first thing an attacker usually does as soon as he has command line access to the target is NET USE ********. which usually ends up being some arbitrary or easy to miss local account like g_uest or adminstrator (spelled incorrectly on purpose). I would suggest running the gpresult command and seeing exactly what policies are applied and how they are applied. In penetration testing, one of the most common holes I find is conflicting GPO's canceling each other out. Or GPO's configured with the wrong permissions assigned to them. Also keep in mind that when you run net use commands (which are system commands), these commands are being ran with the SYSTEM account, which has the equal of local admin privileges (that cannot be removed easily by the way, and even if you do remove them, things break). Another GOTCHA from Microsoft.

Good points Keatron. Here is another detail to consider:

In order to run the "net user" command you need administrative priveledges to start with (unless your name is Keatron

). This alone makes it a lot less of a security risk than it originally looked like.

sprkymrk wrote:

Good points Keatron. Here is another detail to consider:

In order to run the "net user" command you need administrative priveledges to start with (unless your name is Keatron ). This alone makes it a lot less of a security risk than it originally looked like.

Yep. The problem is many admins don't know how to properly protect a system against null sessions. By simply typing net use \\IP ADDRESS\IPC$ "" /u:"" you can connect to a Windows box without any credentials. After you've succesfully done this, you can use any number of tools to exploit the heck out of it and get all kinds of information about the target system. One of my favorite tools for exploiting this???????? The one and only Windows 2003 Resource Kit CD.

There was at least a half way serious effort to fix this in XP and 2003, but if you dig deep (hint hint), you will find remnants of this flaw and still exploit it. If you're running a Windows 2003 server that acts as a domain controller, it's almost guaranteed to allow this. Don't believe me, try it.

The problem is hard coded pipes like \pipe\lsarpc, \pipe\samr, \pipe\netlogon, and \pipe\browser (Use sysinternals pipelist to enumerate these pipes). In Windows XP (yes even SP2), the "restrict anonymous" key value for \pipe\browser, is set to 0 by default!!!!!!. You can use the RPC interface to reach other RPC interfaces buried in the same svchost.exe service (you can use sysinternals process explorer to see what services are running as "children" of the 5 or 6 svchost.exe services running on your box (like wkssvc and srvsvc). Mind you, in 2003 wkssvc and srvsvc are set to "allow anonymous" by default, and I don't think we need to explain the implications there. In 2003 SP1 this was kinda fixed, BUT.....the same rule still applies for the \pipe\browser pipe and these services can still be accessed through it. And again I'll point out the fact that if we're talking about a domain controller, then it's almost certainly not protected against null sessions.

The only way to truly protect against this is disabling SMB support by disabling Netbios over TCP/IP support and disabling the lanmanserver service. BUT, be prepared for the demise of some of your network based apps. Yes you guessed it, another GOTCHA. I only bring this all up to get you guys thinking of your devices in terms of operating on abstract layers. By enumerating pipes you're are doing the equivalent of getting past a multi layered military security gate by digging a tunnel under it. I stopped thinking of Group Policy as a serious security solution eons ago. It's great, and it's certainly the way to go as far as policy enforcement (for end users), and some level of access and resource management. Keep in mind it's still Windows software that empowers group policy, and "the key is in the kernel". So if someone busts your box via a buffer overflow, then they WILL be connected to the root of your c drive with SYSTEM privileges, regardless of what GPO's are rolled out. This is by design. The SYSTEM account is by default the account that's "closest" to the kernel.

Keatron.

keatron wrote:

If you're running a Windows 2003 server that acts as a domain controller, it's almost guaranteed to allow this.

So is one answer here IPSec policies?

keatron wrote:

And again I'll point out the fact that if we're talking about a domain controller, then it's almost certainly not protected against null sessions.

And really it can't be, and still work correctly, can it? I'm thinking of things like joining new computers to the domain, or someone logging into a machine locally and then trying to connect to a share using their domain account, and any number of common tasks.

keatron wrote:

The only way to truly protect against this is disabling SMB support by disabling Netbios over TCP/IP support and disabling the lanmanserver service. BUT, be prepared for the demise of some of your network based apps. Yes you guessed it, another GOTCHA.

Doing this kills a lot of standard domain functionality too, doesn't it?

keatron wrote:

I stopped thinking of Group Policy as a serious security solution eons ago.

That's probably a safe assumption. I'll have to adopt that train of thought too. This is one reason why I have a locked down/hardened image of workstations and servers to start with. Group Policy can be bypassed (temporarily or in whole) by a number of different methods of which you would know more than me.

keatron wrote:

Keep in mind it's still Windows software that empowers group policy, and "the key is in the kernel". So if someone busts your box via a buffer overflow, then they WILL be connected to the root of your c drive with SYSTEM privileges, regardless of what GPO's are rolled out. This is by design. The SYSTEM account is by default the account that's "closest" to the kernel.

Keatron.

Thanks for the great information Keatron!

@agustinchernitsky:
I know this thread detoured a little from your original post, but you made a great point and I'm glad you shared your issue with us here. I find that I learn stuff every day on this site.

sprkymrk wrote:

Actually, if you notice in the local security policy, there is a setting under security options "Accounts: Limit local account use of blank passwords to console logon only". This alone would seem to indicate that the GP setting requiring complex passwords really only applies to domain accounts. I have set the Local Security Policy to require complex passwords as well and am unable to create a user account using the passwordreq:no option.

This GPO, according to MS:

If enabled, then local accounts that are not password protected will only be able to log on at the computer's keyboard

This would explain why we can login without a password from the console.

Remember that I did test this on a DC and I could add a user without password and login thru the console. Now, if the domain policy specifies complex passwords, your local PC should adopt those settings.

sprkymrk wrote:

mastercorm wrote:

interesting, does that mean i was right about local security policy having an effect?

Sure looks like it. I should have guessed from the first though. This is that old topic of the Password Policy, in which there can be only 1 Password Policy for a domain, and it is set at the domain level, and any other password policies applied below that (OU's) affect local accounts only, while the One Domain Password Policy affects only domain accounts.

http://www.techexams.net/forums/viewtopic.php?t=20733

You are absolutely right... Still, the bug persists since it also works con DCs. I also ran RSP on the local user (on workstation), and "complex passwords req" is enabled... so net user cmd shouldn't allow blank passwords.

I also ran RSP for the domain user, and the domain GPO requiering complex passwords was applied too.

Don't over estimate the importance of logging on. Just because you can't logon with an account doesn't mean you can't use it via a shell to perform actions.