[ale] Win security breach by NSA? If so, Linux potentiallygains big.

[jj at spiderentertainment.com]

1) Microsoft has really compromised it's name by making a blind fall over. The
*unix groups should really use this to their advantage.

2) By hoping that no one would find this, they prove that ether Microsoft or the
NSA, or some other power/company are afraid of what people can do with their
computers. Now you will have thousands of programmers (including myself) who
will try to exploit this into a remote possibility. (Come on! with front-page
extensions you can replace almost any file anyway!)

3) The CIA loves this kinda stuff as it allows them to gather information.

4) I though that all the laws on export control are written in public books, are
there any black books ?

5) I know Microsoft makes "dumb" mistakes, but this is not a mistake, this is a
reality, this a proof of control, just like the US, Canada, etc... randomly
record phone conversations, through which AI makes sense.  Almost every company
has something to gain from it.... Who did kill JFK ?

6) I bet Bill Gates at the moment is in a meeting with top sociologist's,
political advisors and his development team, trying to figure out how what
happened, and how to approach to the Media.

Umm ahh, yeah, does not supprise me.


"Keith R. Watson" wrote:

> At 05:14 PM 9/4/99 -0400, you wrote:
> >I received this from a friend. I'm skeptical, particularly about Cryptonym
> >Corp's (if they are even real) motives, but if this is even remotely true
> >about the NSA having a back door into Win products, it strikes me as making
> >another (very) strong case for using an open source OS. Pronto!
> >
> >
> >http://www.cryptonym.com/hottopics/msft-nsa.html
> >
> >Comments by security experts are especially welcomed.
> >
> >Hmm, wouldn't it be most interesting if Cryptonym were actually a bunch of
> >clever open source gurus using Microsoft FUD counter tactics?  :-)
> >
> >
> >Attachment Converted:
> "C:\WINNT\Profiles\kw3\Personal\eudora\ATTACH\Cryptonym - Research.url"
> >
>
> Frank,
>
> I got this from another list I subscribe to. It goes into detail about the
> report. Russ Cooper is a reliable source of information.
>
> keith
>
> =================== begin forward ==============================
>
> Approved-By: Russ.Cooper at RC.ON.CA
> X-Mailer: Internet Mail Service (5.5.1960.3)
> Date:         Fri, 3 Sep 1999 15:57:43 -0400
> Reply-To: Russ <Russ.Cooper at RC.ON.CA>
> Sender: Windows NT BugTraq Mailing List <NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM>
> From: Russ <Russ.Cooper at RC.ON.CA>
> Subject:      Alert: CryptoAPI and _NSAKey issue
> To: NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> This is also available at http://ntbugtraq.ntadvice.com/_nsakey.asp
>
> Whoa horsie...
>
> I had a long chat with Andrew Fernandes this morning, as well as
> another chat with others, and of course I've had a ton of messages
> sent my way with various links to various stories about the issue.
>
> I wanted to get a few things straight before I sent this message, but
> given how quickly things are spreading it makes sent to send something
> interim.
>
> Ok, so here's what I can tell you.
>
> 1. Andrew's speculation about the _NSAKEY being a backdoor for the NSA
> is based on;
>
> a) The variable is called "NSA".
>
> b) Its a second key, not known to exist in Windows previously.
>
> c) What possible purpose would a second key serve?
>
> d) Its presence, arguably, weakens CryptoAPI (Andrew explains this on
> his website at <http://www.cryptonym.com/hottopics/msft-nsa.html>,
> I'll elaborate more later.
>
> 2. Sources close to Microsoft say that the key is a "Backup" key. It
> is owned by Microsoft, and only Microsoft have the private key to it.
> The key was named "_NSAKEY" because the NSA insisted that Microsoft
> include a backup key in their CryptoAPI before the Commerce Department
> would approve its inclusion in NT 4.0.
>
> Editorial
> - ---------
>
> There's a bunch of somewhat understandable furor going on over the
> idea that the NSA might have a backdoor to Windows. Unfortunately,
> however, all of this is based on a variable name. Anyone who programs
> knows that variables might get named anything for a variety of
> reasons. One would expect that they would be named descriptively, but
> alas, not everyone follows such stringent conventions (can you spell
> "Easter Egg"?).
>
> The Conspiracy Theorist's theory goes;
> - -------------------------------------
>
> - - The NSA has a signing key on your box.
>
> - - The NSA can implant a Trojan to replace the module which performs
> encryption on your box with one that doesn't perform encryption, and
> because the failure of signature verification against Microsoft's key
> is silent, they can get their trojan'd app up and running without you
> being any the wiser.
>
> - - The NSA can then sniff your traffic, now being conducted in
> plain-text.
>
> There's obviously a ton of variations possible on this theory, they
> take your private key, they replace your key with another, etc...
>
> They only have to get a Trojan to you and get you to run it, and as
> those same Conspiracy Theorists always say, <speculation>there's
> likely bugs in the OS designed to allow them to do
> this...</speculation>
>
> Yeah, could be true.
>
> My take from Microsoft's Perspective;
> - ------------------------------------
>
> - - We want to have one build of our products that simultaneously
> supports weak or strong encryption functionality.
>
> - - We want to be able to ship this one product world-wide, changing as
> few bits as possible for those that are being shipped outside the U.S.
> and Canada.
>
> - - We'll build an API (good, bad, or otherwise) that allows the
> controlled bits to be inserted into an infrastructure, then get the
> infrastructure approved, and all will be good.
>
> - - Commerce (with advice from lots of people including the NSA),
> agrees, and tells Microsoft they have to sign everything that can use
> the infrastructure. That way, Microsoft can ship its product anywhere,
> and Commerce will know that only those products that have been signed
> by Microsoft will be able to run on the OS.
>
> - - You want to build a Cryptographic Service Provider (CSP), the module
> that performs the encryption, you gotta get Microsoft to sign it for
> it to run. Microsoft doesn't sign anything that doesn't have the
> appropriate Commerce Department Export approvals first.
>
> Wonderful, life's good, Microsoft doesn't have to manage multiple
> versions based on Crypto-strength, folks can implement whatever crypto
> they want (assuming its Commerce approved).
>
> Oh, the second key, I almost forgot;
> - -----------------------------------
>
> I'm told the NSA insisted there had to be a backup. No explanation as
> to why yet, that's what I've been told. One theory that made a lot of
> sense to me was the simple idea of;
>
> What happens if Microsoft's key is ever compromised? Well, they'd
> simply revoke it, right? Yeah, but the problem is that you'd have no
> way of telling a Microsoft system that there's a new key. You'd have
> to rely on the old one to tell it about the new one. But if there's a
> backup key, and they're kept separate, you could use the Backup to
> verify the new key to replace the primary.
>
> That's only meaningful to Microsoft since there's no revocation lookup
> being done on the primary anyway. Microsoft would have a way to
> salvage its name by using a new key. In practice, this would be near
> impossible to deploy, but hey, at least there's a way to do it
> securely.
>
> BUT!!!
> - ------
>
> Andrew's discovery goes beyond this NSA stuff. There's a real issue
> here. Andrew has found that by replacing the _NSAKEY with one of your
> own, you are able to add a CSP to the system signed only by you. This
> by-passes Microsoft's signing controls (the ones Commerce needed to be
> in place to allow Microsoft to ship its products world-wide).
>
> As Andrew says, "Export controll is effectively dead for Windows."
>
> More importantly, it means you can add a CSP that does whatever you
> want it to do, and then modify existing Windows .dlls that call
> CryptoAPI such that they are signed by you instead of Microsoft. This
> will cause them to fail the Microsoft signature verification, but
> they'll pass verification against your own signature. Windows will
> silently let them run and do whatever it is you want them to with the
> CryptoAPI environment.
>
> In theory, you create your own CSP to replace Microsoft's supplied CSP
> (implementing whatever you wanted in it, say boosting 40-bit to
> 128-bit), modify the second key to one of your own, install your CSP
> over Microsoft's, and fire up any application that uses CryptoAPI. The
> signature will fail Microsoft's verification, pass yours, and
> everything should work as if you had a U.S./Canadian version.
>
> Fortify <http://www.fortify.net/> for Windows NT (I'd sure love to see
> that implemented, anyone up for the challenge?)
>
> It also means the encryption you use on your system could be
> compromised in the same fashion, assuming it relies on CryptoAPI
> (hasn't this been called for by the U.S. President's commission?)
>
> Andrew's demonstration program effectively proves most of this;
>
> http://www.cryptonym.com/hottopics/msft-nsa/ReplaceNsaKey.zip
>
> On the other hand;
> - -----------------
>
> If there were only one key present in the system, Andrew acknowledges,
> then this wouldn't be possible. However, it would still be possible to
> subvert the export controls by trojanning all of the necessary .dlls
> used with CryptoAPI with ones signed by your key, and then replacing
> the Microsoft key with your own. Its a lot more work, but it would
> still achieve the same results.
>
> Nobody is suggesting that any of this is a Remote Exploit, or
> something you have to worry about receiving in Email. Sure, Andrew's
> program demonstrates that a running application can subvert the second
> key and implement its own CSP...in memory...which is possible but
> unreliable.
>
> Bottom-line:
> - ------------
>
> I think the NSA thing is being over-hyped. Sure, its possible, and we
> need Microsoft to make their official statement about it to have it on
> the record. Once they do, if anyone can prove its not their key I will
> happily help them. I doubt anyone will...although I also doubt that
> people will readily accept that it is a second Microsoft key (who
> killed JFK?)...maybe Microsoft can sign something with the second key
> so we could verify it somehow??
>
> Meanwhile, the risk of your system's cryptographic methods being
> exploited is limited while folks figure out how it could be done
> effectively. I'm looking at how you could audit access or
> manipulation, but what's really needed is a TripWire-like
> functionality (http://www.tripwiresecurity.com/). Alternatively,
> Microsoft should build-in some additional mechanism to verify that
> something that should be Microsoft signed, really is Microsoft signed,
> and not a blind failover to the second key.
>
> As to the issues of a third key in W2K, I have no information
> regarding this beyond what Andrew has said.
>
> More as information becomes available.
>
> Cheers,
> Russ - NTBugtraq Editor
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.0.2
>
> iQCVAwUBN9AoOBBh2Kw/l7p5AQEArgQApuinKKbm2VgQ3etb6mm4MPu2IPiO4Orr
> lhhzz3yYNqCJW0kgubSiPcZoOyHvD3VU2IXLk4CKRqeIhQEz1UXJhJWF11qYF888
> pJQpo08ejP3aozx7AB4+37O7gWkLGcH+wAC8siMpOMMUjgHJUhkzOZ0Fa+tbXxt3
> ntSOJU8kXus=
> =Ihd3
> -----END PGP SIGNATURE-----
>
> =================== end forward ==============================
> -------------
>
> Keith R. Watson                        GTRI/AIST
> Computer Services Specialist IV        Georgia Institute of Technology
> keith.watson at gtri.gatech.edu           Atlanta, GA  30332-0816
> 404-894-0836