A fortnight ago I posted a message exposing a number of weaknesses in the way
various Microsoft security products handle users private keys. A few days
before I was due to vanish for a security conference (where it was very
difficult to contact me), the article started getting a bit of attention. This
is a general response which clarifies several issues relating to the original
message.
First, Russ Cooper (moderator of the NT Bugtraq mailing list) made some wildly
inaccurate claims about the article. I've had a bit of feedback which
indicated that it wasn't even worth dignifying this stuff with a response but
I've written one anyway, at least for the original NT Bugtraq messages he
posted (the stuff he put on a web page is just more of the same). You can find
it at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms2.txt (even if you
don't want to plough through the whole thing, you might want to read the last
two paragraphs for a giggle).
After this, Microsofts spin doctors leaped into action and posted a response to
the article. I've replied to this one in a bit more detail, since it raises
several important issues.
Comments on Microsofts Response
-------------------------------
>Microsoft's Response to Recent Questions on the Recovery of Private Keys from
>various Microsoft Products
>[...]
>With the exception of the details about a possible PKCS-12 attack, all the
>issues raised in the recent discussions are specifically aimed at Microsoft's
>base CSPs, not at CryptoAPI. The base CSPs are the royalty-free,
>software-based CSPs provided with Windows NT 4.0, Windows 95, and Internet
>Explorer. These attacks do not apply in general to other CryptoAPI CSPs and do
>not indicate any fundamental concerns with the security of the CryptoAPI
>architecture or applications built upon it.
This statement is mere obfuscation. As Microsoft have said, every single
(recent) copy of Windows NT, Windows'95, and MSIE (and, presumably, other
products like IIS and Outlook, which rely on them) ship with these CSP's,
therefore every recent system comes with this security hole installed by
default.
In addition, the CryptExportKey() function is a standard CryptAPI function,
which is described by Microsoft with the text "The CryptExportKey function is
used to export cryptographic keys out of a cryptographic service provider in a
secure manner" (obviously some new use of the term "secure" with which I wasn't
previously familiar). There's nothing in there that says "Only the Microsoft
CSP's support this" (some may not support it, but by Microsofts own admission
the default used on any recent system does indeed exhibit this flaw).
>Microsoft products do not "store" private key material using PKCS-12, contrary
>to recent descriptions on the Internet.
I was unfortunately somewhat unclear in my article, I've fixed up the online
version at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt. To
summarise, if you want to get at an exported key stored on disk, you can use
the pre-4.0 key file/PKCS #12 key file flaws. If you want to get at the
current users key, you can use the CryptExportKey() flaw.
>The example of breaking a PKCS-12 data blob, which was given in discussion on
>the Internet, is not an attack on the "weak" cryptography of PKCS-12. Rather,
>it is simply a dictionary attack (long known and well understood in
>cryptography),
This statement is accurate. As Microsoft have said, dictionary attacks have
been known to the computer industry for a long, long time (several decades).
For example the Unix password encryption uses 25 iterations of DES to protect
users passwords from dictionary attacks (this is rather inadequate now, but was
appropriate more than two decades ago when it was introduced).
If this is a well-known flaw which the entire industry has known about for
decades, why are Microsoft's very latest "security" products so extremely
vulnerable to it? As I mentioned in my writeup, I published an attack on the
exact format used in older MS products more than 1 1/2 years ago, but Microsoft
made no attempt to fix this problem at the time. It wasn't until I published
the current writeup that they finally addressed it.
>One statement by the original poster argues that Microsoft managed to design a
>security format that actually makes it easier to break into the protected
>data. As stated above, a number of well respected companies were involved
>extensively in the design and review of PKCS-12 before it became a standard.
The problem is that Microsoft ignored the other companies recommendations for
increasing security. I'll refer people back to the original writeup for
mention of the various security features which were added to PKCS #12 and
subsequently ignored by Microsoft. PKCS #12 is just a basic modification of
PFX, which was a purely Microsoft invention, and Microsofts implementation of
PKCS #12 does indeed make it very easy to perform the attack I described (you'd
have to read my writeup for the full technical details in which I describe each
individual flaw which, as each is exploited in turn, make it progressively
easier and easier to recover a users private key).
In addition (as I mentioned in my original message), Microsoft use RC2/40 to
encrypt the private keys, which means that no matter how good a password you
choose, the default PKCS #12 format private key produced by MSIE can be
recovered in a few days with fairly modest computing power. There already
exists a Windows screen saver which will recover RC2/40 keys for S/MIME
messages, and the prize of an RSA private key is a much higher motivating
factor than the "Hello, how are you?" typically found in an S/MIME message. As
Microsoft point out, Netscape can indeed handle RC2/40-encrypted files, however
they usually use triple DES and not RC2/40 (they encrypt the private key
components - the really valuable part of the PKCS #12 payload - with triple DES
and the other odds and ends with RC2/40). Since Netscape also iterate the
password and MAC processing, they aren't vulnerable to the attacks which the
Microsoft software is vulnerable to, even though both are based on the same
PKCS #12 standard.
>Exploiting Internet Explorer
>
>One of the fundamental requirements to perform any possible cryptographic
>attack discussed in the recent postings is the assumption that a malicious
>entity could somehow access to data on a user's computer system, without the
>permission or knowledge of the user. This is a large leap of faith.
>
>Users that are using Public Key Certificates today are generally sophisticated
>and savvy users,
Bwahahahahaha!
Sorry, I guess I should explain that in more precise terms. Now I'm not trying
to claim that the average Win95 user isn't as sophisticated and savvy as
Microsoft seem to think, or that relying entirely on the sophistication of the
average Win95 user for security is a dangerous move. However these statements
do seem to completely ignore the reality of the situation. Let me go into the
background of the weaknesses a bit further.
When I tested the weaknesses, I asked some "guinea pig" users to send me their
exported keys, with the promise that I'd destroy the keys and not keep any
record of where the keys came from and so on. Because of this I can't give
exact figures, however here are a few data points:
- More than half the keys (I can't remember the exact figure) were in the
older, pre-4.x format. This indicates that the majority of users (or at
least of the crypto-using guinea pigs) are still running old versions of MSIE
which contain a number of widely-publicised problems, including precisely the
weaknesses required to run arbitrary code on the machine or read files off
the machine. One of the respondents commented that the key was "the key I
use with Outlook", I'm not sure what that says about the origins of the key.
Another key was one used with IIS for a web site which runs an online
commerce service that processes credit-card based orders. This must have
been an older version of IIS since the key was in the pre-4.x format.
- When I asked two of the people why they were still using an old version, the
responses were "It came installed with the machine when we bought it" and "It
does what I want, so I haven't upgraded". I expect most users of the older
version would have a similar reason for using it.
In a company of 20 people (some of whom participated in this test), only two
were running 4.x. These people are all highly competent software developers
(presumably this includes them in the group of "sophisticated and savvy
users" which MS were referring to), however none of the remaining 18 wanted
to risk installing MSIE 4 because of the extent with which it messed with
their system, possibly jeopardising their development work. Therefore most
of these "sophisticated and savvy users" were still running old, insecure
versions of MSIE, and weren't going to upgrade any time soon.
- For the two remaining 4.x users in the company, both are still using
straight, unpatched 4.0 because they considered it painful enough to download
all of 4.0 and they didn't want to bother with an upgrade just yet. This
makes them vulnerable to the bug pointed out in the l0pht advisory.
- When I informed one of the guinea pigs of the recovered password, his
response was "Now I'll have to change my login password" (the others
generally restricted themselves to some variation of "Oops"). This comment
confirms that users do indeed sometimes use their login password to protect
their private keys, so that a successful attack recovers not only their
private keys but their login password as well.
- One respondent commented that most of the code they downloaded from the net
was unsigned, but they ran it anyway. This is probably typical of the
average user.
Although I've only been back for two days, I haven't yet managed to find anyone
who has applied all the latest patches and kludges to their system which makes
them immune to these problems. This includes at least one person who has a
code signing key which could be used to sign malicious ActiveX controls.
Therefore all of the guinea pigs could in theory have their private keys
stolen.
>Attacks against Authenticode signing keys
>
>[...]
>
>However, it is extremely unlikely anyone could be successful with a simplistic
>strategy for stealing Authenticode signing keys and then using them.
See my comments about about this. I could, right now, obtain at least one
Authenticode signing key with which I could create a malicious ActiveX control.
I'm sure that if I were serious about this I could obtain a number of others.
>Second, anyone signing code using Authenticode technology is extremely
>unlikely to leave their key material sitting on an end user machine routinely
>used for browsing the Internet.
I see no basis for this claim. Every developer I know uses the same machine
for both code development and web browsing (in fact a number of users keep a
copy of MSIE or Netscape permantly running on their machine so that they'll
have something to do between compiles). Microsoft's statement seems to imply
that users will be running two machines, one dedicated entirely to web browsing
and the other to code signing. I find this extremely unlikely.
>Attacks on Encrypted Key material
>
>There is some confusion over the algorithms and methods that Microsoft uses to
>provide protection of encrypted key material in Internet Explorer when using
>the standard Microsoft base CSPs. There were changes between Internet Explorer
>3.0x and Internet Explorer 4.x specifically to address any possible concern.
And the astounding thing was that, despite a complete rewrite of the code, the
newer version offers no extra security at all, as my article points out. Both
are equally weak, you just need to attack them in slightly different ways.
>Key export attacks
>
>The original Internet posting raises concern about the CryptoAPI interface
>CryptExportKey(). This function is fully documented and does indeed export
>private key material in an encrypted format.
The statement from Microsoft omits one important point here. Myself and
another security researcher have been trying to tell Microsoft for more than
four months (probably a lot longer, I didn't log the earlier mail) that this is
a very serious security flaw. In all cases Microsoft's response was some
variation of "We don't see this as a flaw". It wasn't until my warning was
published that they finally addressed the problem, and even in this case (the
program to set the CRYPT_USER_PROTECTED flag) it's only a quick hack to plaster
over the cracks and allow them to declare the problem fixed. In fact it
doesn't fix the problem at all. I'll post details in a fortnight or so when
I've had time to test things, please don't ask me about this until then.
>The presence of the CryptExportKey() function is to support functionality such
>as migrating key material between machines for a user or creating a backup
>copy of a key. It should be noted however, that many CSPs, including most
>hardware based CSPs, do not allow exportable private keys and will return and
>error in response to a CryptExportKey() request.
However the CSP's installed by default on every recent system do allow the
export. The fact that there may exist, somewhere, an implementation which
doesn't exhibit this flaw really doesn't help the majority of users.
>The posting also asserts that an ActiveX control could be downloaded from a
>web page, simply ask for the current users key, ship the key off for
>collection by an unscrupulous person, and then delete itself without a trace.
>
>If users run unsigned code, or code from an unknown origin, a number of
>unpleasant things can happen. This could indeed occur if the key as been
>marked exportable and the CRYPT_USER_PROTECTED flag is not set.
Which was, until my warning, the automatic default action for Verisign, and is
still the automatic default for many other CA's. This means that keys
generated right up until a few days ago (and in some cases keys being generated
right now) have, by default, no protection whatsoever. In addition I've just
been sent mail to say that CRYPT_USER_PROTECTED still isn't the default with
Verisign, you have to click a box asking for extra security or you get the
usual default of no protection.
To add to the confusion, a lot of documentation (including the Microsoft
Developer Network (MSDN) online documentation on Microsofts web site) describes
the CRYPT_USER_PROTECTED flag with "The Microsoft RSA Base Provider ignores
this flag", which can cause programmers to leave it out when it is *essential*
it is always included. Incidentally, MSDN also claims that Microsoft are
"supporting" PFX, which is in direct contrast with the claims in their press
release.
>There was also discussion of 16 dialog boxes appearing to the user for their
>password if the CRYPT_USER_PROTECTED flag is set. Certainly asking the user
>too many times would be better than too few times, however in our tests, under
>extreme (and uncommon cases), a user might be asked for their password at most
>four times when a key is used with the Microsoft base CSPs. Perhaps the claim
>came from an early beta release.
The 16 dialog boxes problem was present in 4.0, and it's been confirmed as
still being present in 4.01. This was apparently verified on Microsoft's own
CryptoAPI mailing list (the claimed "beta" version was actually MSIE 4.0
final).
>Microsoft is constantly working to improve the security of our products.
Myself and another person had been trying to convince Microsoft for more than
four months that things like CryptExportKey() are a major security hole. Their
response each time has been some variation of "We don't see this as a problem".
It simply wasn't possible to get them to acknowledge these flaws, therefore my
posting of the details wasn't "irresponsible" (as some have claimed) but a
necessity in order to get them fixed. When I pointed out several months ago
that Microsoft were using, in their pre-4.x products, an exported key format
which was identical to the one which I broke more than 1 1/2 years ago, their
response was "What's the problem with this?". I would have liked to have
included URL's for the CryptoAPI mailing list archives to prove that Microsoft
were warned of these problems some time ago, but the CryptoAPI archive seems to
be temporarily offline.
Risks of a Private Key Compromise
---------------------------------
One or two respondents have tried to play down the seriousness of a private key
compromise, saying that I exaggerated the dangers in my original message. What
I wanted to point out was how extremely valuable a users private key is, and
how disappointingly little concern Microsoft seem to have for protecting this
valuable resource. For example Garfinkel and Spaffords "Web Security and
Commerce" (O'Reilly, 1997) contains the warning:
"Today's PC's are no better at storing private keys once they have been
generated. Even though both Navigator and Internet Explorer can store keys
encrypted, they have to be decrypted to be used. All an attacker has to do
is write a program that manages to get itself run on the users computer (for
example by using [...] Microsoft's ActiveX technology), waits for the key to
be decrypted, and then sends the key out over the network" (p.120).
Including a function like CryptExportKey() (which hands over a users private
key) makes this very attack possible. The potential damage which can be caused
with a misappropriated private key is enormous. Consider the relative risks in
the compromise of a logon password and a private key. With a logon password,
the worst an attacker can do (apart from stealing possibly valuable data) is to
trash the victims hard drive, which involves reinstalling the operating system
(an action which many users are intimately familiar with). In contrast an
attacker who obtains a private key can potentially drain the victims credit
card, clean out their bank account (if the victim uses one of the emerging
online banking services), sign documents in their name, and so on.
The implications of that last point can be quite serious. Take for example the
Utah digital signature act, which was used as a model by a number of other
states who implemented or are implementing digital signature legislation.
Under the Utah act, digitally signed documents are given the same evidentiary
weight as notarised documents, and someone trying to overcome this has to
provide "clear and convincing evidence" that the document is fraudulent, which
is difficult since it bears a valid signature from the users key (this fact has
been used in the past to criticise digital signature laws based on this act).
In addition, under the Utah act and derived acts, anyone who loses their
private key bears unlimited liability for the loss (in contrast, consumer
liability for credit card loss is limited to $50). This leads to the spectre
of a malicious attacker who has the ability to issue notarised documents in
your name for which you carry unlimited liability. This is a lot more
important than someone reformatting your hard drive, or stealing last months
sales figures.
Peter.