Impersonation isn't dangerous

Una discussione interessante dell'impersonation

Lorenzo Barbieri @ UGIblogs! — Mon, 26 Mar 2007 07:34:11 GMT

re: Impersonation isn't dangerous

Andrew Royal — Mon, 26 Mar 2007 11:17:38 GMT

Impersonation could be dangerous enough. http://www.gentlesecurity.com/adv04302006.html

By default Windows has at least one service (RPC) run as 'Netwrok Service' that accepts and impersonate LocalSystem clients. That means any other service that run as 'Netwrok Service' can easily elevate up to LocalSystem. And if such service (any that run as Network Service) is hacked, then an attacker gets LocalSystem.

As a result Network Service is neraly the same as LocalSystem, due to:

1) impersonation

2) unreasonable defaults, configuration where RPC service would run as LocalSystem is more secure in fact. That is impersonation paradox.

No need admin connection, you have LocalSystem already who connects and impersonated.

Network Service is just a most obvious case. There are other conditions when impersonation is dangerous. Impersonation poses a sufficient risk, and the risk must be clearly understood/communicated not mitigated.

re: Impersonation isn't dangerous

david_leblanc — Mon, 26 Mar 2007 19:56:02 GMT

As I was saying, the flaw would be in the local system service for allowing a less privileged server to impersonate it. The ideal way for a service to handle such things would be to first try to impersonate, then drop to identify, and for the higher level service not to allow impersonation.

Let's also examine the alternative - if you confine impersonation to local system, then you have all the services that need it running with most privilege, not least.

Another note - it's true that having all the services running under the same 3 accounts is a problem. This offers a lot of opportunity for services to work against one another, but there's some cool new stuff in Vista that helps a lot. More on that later, or you can read it in detail in WSCV.

I also don't completely agree with the analysis in the URL above, but there's not time this morning to go into detail, except that to say again that if a localsystem service allows itself to be impersonated, it has a problem. SQL 2000 had such a problem, and IIRC, it has been fixed for quite a while.

re: Impersonation isn't dangerous

Andrew Royal — Mon, 26 Mar 2007 21:55:30 GMT

OK, but what about particular example of rpcss? It is used by many privileged services and still run as Network Service account. Mircosoft actively suggest to use Network Service as a replacement for LocalSystem. Indeed it makes sense as an additional measure, but the value of this measure is misleading at least in official description. There is a note that Network Service is an ordinal unprivileged user account which is true. However, there is no any note that Network Service is used to run critical service such as rpcss. I assume it would be quite difficult to run such service “unprivileged” due to its nature. And for the rpcss it really weakened overall configuration. An alternative to run rpcss as LocalSystem is more secure because of two reasons:

- Rpcss services many privileged requests and if an attacker managed to break into it then Network Service will not help anyway. So it doesn’t provide claimed attack surface reduction if a target is rpcss.

- Those who follow using Network Service advice would not be vulnerable to privilege elevation to LocalSystem.

Why not to fix this problem for rcpss?

Regarding the SQL server, no need to agree. You may try a demo for this provided by the advisory authors. I can confirm it works on w2k3 R2, SQL2000 SP4. The same issue is present for IIS6 as runs ‘Worker Process’ as Network Service by default.

re: Impersonation isn't dangerous

Andrew Royal — Mon, 26 Mar 2007 22:26:12 GMT

David, just to clarify the problem is not in SQL/ISS etc. there is nothing to fix there. The problem is that they use Network Service which can be easily elevated up to LocalSystem. The path:

Open rpcss process -> Break into impersonation negotiations/get tokens handles/etc. ->token handle of LocalSystem -> impersonate to LocalSyetm

rpcss must impersonate LocalSystem and impersonation makes it useless to run as unprivileged account. In this case makes it even worth as there are other services run as this unprivileged account.

re: Impersonation isn't dangerous

david_leblanc — Mon, 26 Mar 2007 22:57:05 GMT

You'd prefer that rpcss be running with reduced privileges, even if imperfect - it's listening directly to the network. It is also typically doing enough stuff that trying to have a very controlled exploit that could sit around and wait until a localsystem process connected would likely be unreliable. Something else that I'm honestly not sure about is whether that service is normally doing the impersonation, or hands that off to the processes that actually serve up the RPC endpoint.

Reviewing the services as shipped with Vista, it looks like network service is used much less often than local service, and it is used for some fairly sensitive services - for example, if you could compromise the terminal services service, you could swipe credentials without any further ado. That's assuming that the exploit didn't corrupt it to the point it would fail to run properly. Because of this, and the fact network service can authenticate as that system across the network, don't write services to run as that account unless you have a need to do so.

Stuff like this always gets fixed in stages - up until XP, we had local system or plain users, with the accompanying password managment issues. People had to do a ton of work to get things to run as network service or local service, and while this isn't perfect, it's a lot better than having everything running as localsystem. It also allows you to get to the next level.

In Vista, there's a new thing called a service SID that allows you to ACL resources directly to your service, and keeps other services from being able to access your stuff.

Something else - it's not nearly as easy to hop from one service to another in Vista as it was previously - check out the process ACL - the service has a unique logon ID SID, and access is granted to that logon ID and administrators. But what about the service configuration - seems that's locked down, too. So if you could take over rpcss and do so in a way that kept it stable, you could probably eventually EoP. This is still better than the alternative, which is running as full localsystem. But what you can't do, that you could do before is to easily hop from one network service process to another. That's a significant level of hardening.

The other thing to check out in Vista is the SID type configuration - this is complicated and took a couple pages to explain, so I'll blog about that soon.

Does this get us as far as I'd like? No - even with all the great new stuff, it isn't perfect, only a lot better. I can say we are thinking about ways to improve this in future releases, but obviously can't go into details, especially since it hasn't even been coded yet.

Anyway, thanks for the feedback - you've given me some more things to blog about!

re: Impersonation isn't dangerous

Andrew Royal — Mon, 26 Mar 2007 23:49:31 GMT

AFAIC, the exploit is quite simple and reliable in this case, no hooks or waiting for LocalSystem are required. Rpcss always has a number of LocalSystem token handles with impersonation level = SecurityImpersonation (not just SecurityIdentification). You can check it by ProcessExplorer for example. What is required is enumeration of the handles, selecting those with LocalSystem token handles and duplicating them.

Vista indeed fixes the issue by making unique ID as token’s owner. That is good step forward, just waiting when we get it available in server platform. BTW, would Longhorn Server have some additional measures in this area (I mean least privileges) in comparison to Vista?

I hope, I have inspired a topic on Vista’s “least privileges” options :-)

Thanks, please keep posting!

re: Impersonation isn't dangerous

david_leblanc — Tue, 27 Mar 2007 07:36:04 GMT

It's a pretty fair bet that anything in Vista (in terms of infrastructure) will show up in later releases. What will be added is something I don't know, and can't really talk about now if I did know. I wouldn't expect a whole lot - we usually use the extra time to test the server-only features. The real speculation is around what goes in the next version, since we're in the process of figuring that out about now.

Thanks for the good feedback!

And BTW, that exploit is going to be a little harder to write, since the core Windows components are all ASLR, NX, and SafeSEH. Kind of brings up the question of given all that, what's still exploitable? I'm sure some things are, but fewer than you'd have without all those countermeasures.

re: Impersonation isn't dangerous

Karthik — Thu, 29 Mar 2007 10:32:07 GMT

You might want to look at http://www.microsoft.com/whdc/system/vista/Vista_Services.mspx to get an overview of the Service SID support in Vista.

re: Impersonation isn't dangerous

Good Point — Tue, 21 Aug 2007 22:59:04 GMT

I was looking passing the correct impersonation bits to CreateFile() and ran into this: http://msdn2.microsoft.com/en-us/library/aa378832.aspx

It says:

When the named pipe, RPC, or DDE connection is remote, the flags passed to CreateFile to set the impersonation level are ignored. In this case, the impersonation level of the client is determined by the impersonation levels enabled by the server, which is set by a flag on the server's account in the directory service. For example, if the server is enabled for delegation, the client's impersonation level will also be set to delegation even if the flags passed to CreateFile specify the identification impersonation level.

Is this correct?

[dcl] Sure - at the end of the day, the server is going to create a token for you, and the best assumption is that the server is completely controlled by that server's admin. You are thus at their mercy with respect to their own server. What the server is allowed to do with your identity on the rest of the network depends on what the domain lets it do.

BTW, the advice we gave about setting the security QOS, while correct at the time, is a little outdated - on current XP and later, impersonation is a privilege, and only admins and services have it by default. In general, you don't have to worry about impersonation attacks on systems like that. Getting tricked into opening a pipe is mostly only a problem on Win2k, which is starting to get really old (though I'm sure there are many instances running).

Threat Modeling Again, Threat Modeling Rules of Thumb

Larry Osterman's WebLog — Fri, 21 Sep 2007 20:20:55 GMT

I wrote this piece up for our group as we entered the most recent round of threat models. I've cleaned

Threat Modeling Again, Threat Modeling Rules of Thumb

Noticias externas — Fri, 21 Sep 2007 20:35:44 GMT

I wrote this piece up for our group as we entered the most recent round of threat models. I've cleaned