Exploding Windows 7 interactive sessions

I always wondered if Windows 7, supposedly having the same core than it's server counterpart, was somehow capable of supporting more than one interactive session. I'd speculate whether Microsoft had changed it's core not to limit functionality but to present to the end user a lighter kernel, faster and less resource demanding.

I was wrong. This post presents the proof that more than one interactive session is indeed possible within Windows 7.

Considering this, I remembered the many times I needed to login interactively into a client machine while the user was logged in. How many reasons where there? How many helpdesk calls, tests, validations, etc. without having to lock or logoff the user? How many times have I prayed for some way to bypass this limitation? Hundred of times. Particularly for the server editions when the 2 remote sessions limit (plus 1 for the console) was hit. What was more annoying? Killing remote sessions or be killed by someone else that also needed to enter?

But the most important point I'd like to raise with this post, is that my hack targets Winlogon, opposing the traditional and obvious target that aims to Remote Desktop service (termsrv.dll). Winlogon has become the master in this domain. Isn't this an error? Should Winlogon have such power? This seems contrary to Microsoft modular policy.

So, the figure shows you the target as Windows 7 Professional, and I’ve got two active sessions opened, one in console and the other remote.

What are the possibilities then? Well, as usually said, your imagination is the limit. In fact your memory is, but this approach allows for theoretically unlimited usage of terminal interactive sessions.

To use the tool, you need to connect thru RDP or the console and establish a second session. Before logging in, identify the new opened session and remember the PID of the newly created winlogon.exe process. Run the tool as this:

You can login now and as you’ll see, you’ll be in a newly fresh interactive session.
No error messages, no one being killed or locked.
I'm not going to delve more in the subject, nor will I be sharing the tool I built like in the other posts because I don't want to get in trouble with Microsoft, but for those willing to send me an email requesting the tool, I'll share it with you.

PS: being a PoC the tool only works on Windows 7 (yeh!) SP1 32 bits.

Patchguard red flags

Having a 64bit machine for a month now, and in need to perform some tests on Windows x64 kernel, I decided it was time to take on Patchguard(PG). I started by searching the Internet for ways to disable it, and to my suprise there was almost nothing up to date on the subject.
I did found one working patch on PG by Fyyre. Pretty awesome work, I'd say. Basically he says to look for cross references of InitSafeBootMode and patch the one he points as critical. I found it pretty simple to follow, and wondered how a multi-billion dollar product can be broken so easily.
So, I started looking for tips in code that could denounce PG hot paths, and I found one:

Looking for cross references of KdDebuggerNotPresent. There are a bunch of them, but restricting the search to the following operations you get the critical path that enables PG:
1. cmp operations,
2. followed by conditional jump,
3. followed by a unconditional jump to the it's own location, locking the cpu.

The only two functions that relate to this, are KiFilterFiberContext and KiEnablePatchGuard.
It is as Microsoft didn't want us to enter this functions with a debugger, which is understandable as that could compromise PG, but they should at least not leave this red flags behind.

Session wide shut

Or why you shouldn't leave your sessions hanging around. After having read about Pass the Pass, I decided to investigate it, to evaluate how deep my passwords could be compromised.
When I logon into a machine, Windows usually receives my user login and corresponding password.
Now, Windows has my credentials, and must validate them. As there are many authentication services out there, the folks at Microsoft decided, and very well (Linux also), make it a modular approach.
They ended up with a concept of an Authentication Module, who's responsible for establishing a secure connection with the server side of the authentication service, validate the provided credentials, and returning the result to the authenticator manager, performed by Lsass.exe process.
So far so good, what's the problem then? Well, besides validating the user, Windows also adopted some standards with the purpose to ease thing on users, like not having to carry around dozens of passwords, and not being constantly popped by login windows requesting for us to reenter those passwords.
Meet SSPI, or Secure Support Provider Interface, as Microsoft discribes it "allows an application to use various security models available on a computer or network without changing the interface to the security system. SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system."
With SSPI, Windows can log you in any service across your realm. It's sort of a universal security package that transparently crosses Authentication mechanisms without you noticing.
The hell begins, when Microsoft begins to provide support for protocols that need clear text passwords to properly operate, like Digests and Terminal services, WDigest and TsPkg security packages.
Lets begin by the user logging in then. Lsass.exe receives credentials by SspiSrv module and SspirLogonUser function. This function iterates all the registered authentication packages, maintained in pPackageControlList:

dc lsasrv!pPackageControlList
7537a484 0031af00 00000010 00000009 0031b020 ..1......... .1.

At 7537a484 we've got a list pointer to all the packages, and at 7537a484+4 the count of packages available.

dc 0031af00
0031af00 00300238 00300618 00301128 00316378 8.0...0.(.0.xc1.
0031af10 0031d5d0 0031d6ac 0031e428 00321580 ..1...1.(.1...2.
0031af20 003216e0 003217e0 00000000 00000000 ..2...2.........

dc 00300238
00300238 00000000 00000000 00000014 00083bb3 .............;..
00300248 00000009 00000001 00002fe0 00000000 ........./......
00300258 00000000 00000000 00140012 002f6398 .............c/.
00300268 003a0038 002f3b20 00300220 00300320 8.:. ;/. .0. .0.

dc 00300618
00300618 00000001 00000000 00000016 00113913 .............9..
00300628 0000001e 00000001 00002ee0 00000000 ................
00300638 00000000 00000000 001a0018 002ff9f0 ............../.
00300648 003c003a 002f3c88 00300600 00000000 :.<..

ddu 00300220
...
0030022c 002f3a48 "C:\Windows\system32\lsasrv.dll"
...
00300264 002f6398 "Negotiate"
00300268 003a0038 ""
0030026c 002f3b20 "Microsoft Package Negotiator"

ddu poi(poi(0031af00+1c)+38)
...
00321574 0031ade0 "C:\Windows\system32\tspkg.DLL"
...
003215ac 0031e998 "TSSSP"
...
003215b4 00306180 "TS Service Security Package"
...
003215cc 0031ae28 "C:\Windows\SysWOW64\TsPkg.DLL"

As it goes thru all the packages, it passes the credentials to them, one by one. The security package has now the opportunity to do whatever it wants with the credentials, and as I said before, some of them decide to keep a copy of it. The interface provided is SpAcceptCredentials. Analyzing it's parameters:

dc esp
00bcef04 752a77e0 00000002 00bcefcc 0032b830 .w*u........0.2.
00bcef14 00bcef44 00000000 00bcf0c8 003ae2e0 D.............:.

dc 00bcef44
00bcef44 001ffcf2 00000000 001a001a 00362218 ............."6.
00bcef54 000a000a 00385b30 00160016 003a6bc0 ....0[8......k:.
00bcef64 00000000 00000000 00362538 0a000001 ........8%6.....

dc 00362218
00362218 00640041 0069006d 0069006e 00740073 A.d.m.i.n.i.s.t.
00362228 00610072 006f0074 00000072 00000000 r.a.t.o.r.......
00362238 363df430 88000000 00000000 00321f48 0.=6........H.2.

dc 00385b30
00385b30 006d0076 00300030 00000031 00000007 v.m.0.0.1.......
00385b40 363c3c1f 8c000220 006d0076 00300030 .<<6 ...v.
00385b50 00000031 00000000 363c3c1c 8a000074 1........<&lt

dc 003a6bc0
003a6bc0 00XX00XX 00XX00XX 00XX00XX 00XX00XX X.X.X.X.X.X.X.X.
003a6bd0 00XX00XX 00000021 36eb697c 88000000 X.X.X...i.6....
003a6be0 004b0050 00530043 00370020 00440020 P.K.C.S. .7. .D.

We've got the login, the domain and password. Truth be told that, at least, the credentials don't lay around in the clear, they are protected by usage of the known LsaProtectMemory. But this "protection" becomes just an obfuscation technique.

Pass the Pass, the name given to the extraction process of user passwords, shares the same roots as it's homologous, Pass the Hash.
Pass the Hash uses the LM an NTLM hashes retained by the msv1_0 security package module.
These hashes are used as authentication tokens to any other machine that recognizes them as valid mappings to authenticated entities.
As Pass the Hash is around for many years now, so will be Pass the Pass.
So, the problem as I see it is unsolvable, except if SSPI is accepted as a optional feature, and the user is given the chance do disable it.

But not all are bad news, the credentials are there but only for the lifetime of the opened session. Shutdown your sessions as soon as possible and you won't be having passwords lingering around.

Theory of conspiracy, secret codes in .NET exceptions

Ever noticed those weird values in .Net exceptions that get into RaiseException native call?
There's 0xE0434352 for CLR4 and 0xE0434F4D for CLR2.

.formats 0xE0434F4D
Evaluate expression:
Chars:   .COM

.formats 0xE0434352
Evaluate expression:
Chars:   .CCR

.COM? They really have a sense of humor.