[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

Hi all,

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 
today, 20031206.

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
Execution (823182)

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 
Certificates (Q323172)

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 mailing list