SChannel Shenanigans

[Nytro]

# I need a good doxbin onion back!

Software SUCKS! Calling out "SChannel Shenanigans"

Part one of the in depth story of MS14-666 / CVE-2014-6321

So, about those "SChannel Shenanigans"... Sit down and let me set the record straight!

This is the story of the most under-played Patch Tuesday update ever delivered. The "SChannel Shenanigans" bug is a once in a lifetime type of vulnerability, and Microsoft is mis-representing the scope and severity of this defect.

This is also the story of an opportunity lost by indecision; Learn from my fail!

And while software sucks, you can mitigate harsh reality with defense in depth and consistent care.

Yes, this vulnerability must be called "SChannel Shenanigans" or the wrath of "The Exploit" be upon you and your house!

Some background to understand this discussion:

def Lsa...() {

}

^- This is easy code like for a "Function or Method Definition",

or said another way, 'the instructions the computer carries out'. From here simply called "Methods".

Attack surface and call graph describes how complicated, and how frequently a particular function may be called. The more complicated or prominently used the code, the larger the attack surface is.

The more frequently a function is called, the larger the risk it carries if compromised. From here simply called "Surface".

Privileges and capabilities are the "keys" the vulnerable process carries, which in turn can be stolen and used for more attacks if that process is compromised.

These privileges, as held by Operating System and Platform Services processes and methods, are what give you access to everything: data stored, transmitted, remote service or networks, everything. From here simply referred to as "Privs" for short.

What makes "SChannel Shenanigans" so dangerous?

A number of things, combined, make this defect exceptionally dangerous to everyone running Windows 2000 and newer. As hinted at with first vulnerable version, the code affected is very old and very complicated.

Old code with very large Surface explains the first aspect of risk. Next is the remote exposure of the huge Surface to attackers who may remain anonymous. This impact at a distance before verifying credentials or permitting access is the second aspect of risk.

Finally, the frequent and pervasive use of the vulnerable Lsa Methods in all versions of affected Windows mean there are many avenues to 100% success of SYSTEM Privs. Sometimes called "God Mode" exploits when utilized to take over systems.

It is as if our story code had been written like:

< inside vulnerable SYSTEM Services >

.

def SYSTEM/AdministratorMainLoop() {

while always {

runService();

handleEvents();

}

}

def runService() {

while always {

contactRemoteServiceMaybe(); // calls vulnerable Lsa Method

handleLocalRequestMaybe(); // calls vulnerable Lsa Method

}

}

def handleEvents() {

while always {

acceptShadyInputsFromStrangers(); // calls vulnerable Lsa Method

passThroughShadyToOthers(); // calls vulnerable Lsa Method

}

}

.

.

.

< inside vulnerable applications >

.

def insideEveryApplicationOnWindows() {

doAnyCryptoStuff(); // calls vulnerable Lsa Method may be sandbox/restricted - doChain();

}

.

Exploits through remote services like RDP, IIS, ActiveDirectoy(LDAP), MSSQL, are pivots to rest of your critical infrastructure. Exploits through event handling yield Privs. Exploits through least privileged sand boxed processes can in turn incur Lsa Method calls in processes with Privs, including guest virtual machines on Windows host running VMWare or VirtualBox. In every way, this was one of those rare vulnerabilities in just the right place, giving a "God Mode" so effective you begin to question your own sanity.

Thus when tracing through a confirmed exploitable call to the vulnerable Lsa Method, and another, and another, it begins to dawn on me just how dangerous this exploit is. It cannot be sold, without falling into wrong hands. It cannot be Full Disclosure'd, without creating pandemonium. It cannot be used without the utmost caution, lest it be stolen by an observer. In fact, talking about it makes me nervous, so let's just call it "The Exploit" and you are sworn to secrecy until we... Well, what the hell do we do with it?

Sadly, this is as far as we'll get in the background portion of the first part of our tale.

To sum up each amplifying risk factor for "SChannel Shenanigans":

a.) Before authentication. Methods called early on in many, many applications and libraries and services. Surface exposed to any attackers, and early.

b.) Always results in SYSTEM Privs, local or remote. A "God Mode" exploit with 100% success.

c.) Multiplicity of use and high exposure of flawed code. Huge Surface; everything including Windows 2000 onward is vulnerable.

d.) Legacy code carried onward, forever. This means modern protections that make exploiting Methods more difficult are not applied here. No EMET for you here, foolish Earth Human!

And finally, an ultimatum or two. I did not know what to do with this before, but I do know what to do now given Microsoft's response to these defects.

Microsoft has until the end of day Friday the 14th to change MS14-066 Exploit-ability Assessment to "0- Exploitation Detected". If they do not, I will anonymously distribute "The Exploit".

Microsoft has until this time next month December 16th to release a patch for legacy XP customers also affected by this vulnerability. Additional time is granted given the overhead of build and test for a new platform on short notice.

TL;DR:

- Pre-auth remote exec and local Priv escalate in SChannel by 1 or more from year 2011 onward.

- Every organization should run a Secure Drop for hot defect reports.

- Microsoft owes their customers full disclosure and accurate risk guidance for MS14-066.

- Microsoft owes XP legacy users a proper fix, too. With same four new cipher suites.

- Assume all software is vulnerable, defend with depth and know how to recover. Langsec Coreboot Qubes FTW!

P.S. Some of you may be skeptical; that's fine. I know all about you, my dear #infosec.

The following code cleaned versions of Win2K sources listed are sha256sum hashed and as follows:

private/security/schannel/lsa/bullet.c

private/security/schannel/lsa/callback.c

private/security/schannel/lsa/credapi.c

private/security/schannel/lsa/ctxtapi.c

private/security/schannel/lsa/ctxtattr.c

private/security/schannel/lsa/debug.c

private/security/schannel/lsa/events.c

private/security/schannel/lsa/init.c

private/security/schannel/lsa/libmain.c

private/security/schannel/lsa/mapper.c

private/security/schannel/lsa/package.c

private/security/schannel/lsa/spreg.c

private/security/schannel/lsa/stubs.c

private/security/schannel/lsa/userctxt.c

private/security/schannel/lsa/usermode.c

private/security/schannel/spbase/asn1enc.c

private/security/schannel/spbase/cache.c

private/security/schannel/spbase/capi.c

private/security/schannel/spbase/cert.c

private/security/schannel/spbase/certmap.c

private/security/schannel/spbase/ciphfort.c

private/security/schannel/spbase/cliprot.c

private/security/schannel/spbase/context.c

private/security/schannel/spbase/cred.c

private/security/schannel/spbase/debug.c

private/security/schannel/spbase/defcreds.c

private/security/schannel/spbase/keyxfort.c

private/security/schannel/spbase/keyxmsdh.c

private/security/schannel/spbase/keyxmspk.c

private/security/schannel/spbase/oidenc.c

private/security/schannel/spbase/pct1cli.c

private/security/schannel/spbase/pct1msg.c

private/security/schannel/spbase/pct1pckl.c

private/security/schannel/spbase/pct1srv.c

private/security/schannel/spbase/protutil.c

private/security/schannel/spbase/rng.c

private/security/schannel/spbase/sigfort.c

private/security/schannel/spbase/sigsys.c

private/security/schannel/spbase/specmap.c

private/security/schannel/spbase/srvprot.c

private/security/schannel/spbase/ssl2cli.c

private/security/schannel/spbase/ssl2msg.c

private/security/schannel/spbase/ssl2pkl.c

private/security/schannel/spbase/ssl2srv.c

private/security/schannel/spbase/ssl3.c

private/security/schannel/spbase/ssl3key.c

private/security/schannel/spbase/ssl3msg.c

private/security/schannel/spbase/tls1key.c

private/security/schannel/utillib/enc.c

private/security/schannel/utillib/keys.c

private/security/schannel/utillib/test.c

private/security/schannel/pkiutil/pkialloc.cpp

private/security/schannel/pkiutil/pkiasn1.cpp

Please, for your own sake, don't call my bluff Microsoft!

Sursa: SChannelShenanigans - Pastebin.com