segunda-feira, 6 de junho de 2011

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.

Sem comentários: