[DShield] betaplace.com - not betaplace.microsoft.com, PKI issues
Erik van Straten
emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl
Sat Dec 6 17:36:10 GMT 2003
I am telling local users NOT to trust emails from support at microsoft.com
with patches attached, paypal scams etc. and to be careful where they
send mail to (e.g. *.tudelft.nl vs. *.tudelft.com).
I am telling local users NOT to visit websites with strange/unfamiliar
names or those that *look* like ebay, or have alternate TLD's (e.g.
whitehouse). And in particular, NOT to enter any sensitive data on
webpages unless they are convinced that the page really belongs to a
trustworthy company (hopefully DNS is not lying and qhosts missed them)
AND an SSL connection is used, AND the certificate is okay.
Regarding www.betaplace.com: besides that the name is confusing, it
also convenient to demonstrate some (social?) security issues in MSIE6
SP1 (fully patched). The behavior below was observed on 20031126 and
First, browse to https://www.betaplace.com - if you have all warnings
enabled, first it says "You are about to view pages over a secure
connection" (click OK), then it says "You are about to leave a secure
Internet connection" (click Yes), then it again says "You are about to
view pages over a secure connection" (click OK). Now the lock icon
appears in the status bar. However, the warnings are confusing. Is this
really a secure connection?
Regardless, to make sure that it is actually a Microsoft site, edit the
URL into https://www.betaplace.microsoft.com and press enter.
In the box labeled "Security Alert", note the text "there is a problem
with the site's security certificate". Also note that the lock icon is
still visible in the statusbar.
Now click "View Certificate", and in the new box, click the
"Certification Path" tab. It says: "This certificate is OK." I can
imagine what causes this, but how to explain this ordinary users?
Worse, close the 2 boxes: make sure to click No on the Security Alert.
The lock does not go away. F5 doesn't cause it to go away. Ctrl-F5
doesn't cause it to go away. Double-click the lock icon. It says: "This
type of document does not have a security certificate". Note that the
URL displaye din MSIE is still https://www.betaplace.microsoft.com.
BUG: what is actually causing this, is that the URL is not changed back
into the old one (it works when coming from ANY valid https site), and
IMO the lock icon should also have disappeared (because clicking on it
reveals that it is not backed by a certificate). I noticed this problem
on 20031126 but had not time to research it better before. Possibly
these issues can be exploited through social engineering, or perhaps
otherwise. Note: if you would have looked closely, in the status bar
you'll notice IE downloading content from www.betaplace.com and from
www.passportimages.com (yet another stupid sitename), but it's a common
trick to hide this information in the statusbar.
Anyway, can Microsoft explain to me why I, or local users, or anyone
else, should trust anything from sites called www.betaplace.com or
iexbeta.com, and worse, why those sites ask me to provide my passport
data (yet another we-own-dot-com named site: www.passport.com )?
Please don't give me the rubbish story on SSL. Unfortunately it is a
common misconception that signed objects (or connections) are always
safe (or transport trustworthy information).
PKI (with or without encryption of the object), provided that it has
been correctly implemented, is quite good in protecting objects *after*
they have been signed, but provides no proof regarding the author, nor
the reliability or validity of those objects (a couple of months ago an
idiot tried to push a "cnsmin" ActiveX to me that was signed by
Verisign; if you don't know what cnsmin is, ask Google). You may also
recall "tshoot.ocx". It is signed but has an unchecked buffer that may
permit an attacker to do anything on your PC that you can do, just by
opening a webpage or an email.
Side note: even if the vulnerable tshoot.ocx is not on your PC, an
attacker could push it to you if you open his webpage. It is a signed
ActiveX but that doesn't make it safe. If you've applied the latest MS
patches it will not run because it has been kill-bitted (it took MS an
extra month to figure out that they had to do this on PC's without the
bitch installed, even though this has been repeatedly pointed out to
them by security experts in the past).
The IE lock icon bottom-right, if I'm correct, is supposed to indicate
that the connection is secure, the server certificate that was just
sent to me has not expired, and the hostname (from the URL I think I'm
visiting) matches the one on the certificate; and, for what it's worth,
a CA root-certificate that happens to be installed in my browser
confirms the validity of the server's certificate.
However, this assumes blind faith in DNS, and the server can be located
anywhere in the world. Furthermore, history shows that there have been
many implementation errors and plain stupidities (with, IMHO, MS01-017
being the worst of them all, and it wasn't even a Microsoft mistake).
Check the list of published fixes at the end of this message (multiple
unpublished fixes have been included in service packs and cumulative
monthly IE updates, and perhaps "you aint't seen nothing yet"). Note
that products from other companies, and open source products, have also
suffered from implementation errors, some of them quite severe. Each of
them is devastating for the general trust in PKI.
Maybe I would be prepared to participate in Microsoft's W9X-update-CD
beta program. However I don't have a passport account and I don't want
one, because I don't trust Microsoft and IE to handle sensitive data
from me (probably MS already knows lots about me; enough is enough).
Some reasons are mentioned above, and here's another historical reason:
The assumption that the .com domain, unless specified otherwise,
belongs to Microsoft is a mistake. If Microsoft is REALLY willing to
regain any of the trust in them that they have successfully destroyed
in the last couple of years, IMO one thing they should do is return to
using *.microsoft.com names for *all* of their sites (if they're
interested in my opinion: I know a lot more things they should do).
Erik van Straten
A number of published Microsoft PKI related security issues:
Vulnerability in Authenticode Verification Could Allow Remote Code
Flaw in how Outlook 2002 handles V1 Exchange Server Security
Certificates could lead to Information Disclosure (812262)
Certificate Validation Flaw Could Enable Identity Spoofing (Q329115)
Flaw in Certificate Enrollment Control Could Allow Deletion of Digital
Flaws in Web Server Certificate Validation Could Enable Spoofing
Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard
SSL Certificate Validation Vulnerabilities
Windows Multithreaded SSL ISAPI Filter Vulnerability
More information about the list