[DShield] betaplace.com - not betaplace.microsoft.com, PKI issues
WMAVT at aol.com
Sun Dec 7 20:23:15 GMT 2003
Thanks of the great info, YOU are RIGHT Not to trust M$, it is my belief
that "They" know of all the security holes, They made them, why? Why did the
come up with "Passport', They want to control the world. Info on people =
Now as you surely know more than me about M$ patches and how to
figure out what is Really happening PLEASE check this crazy one out.
I do not use auto updates for any program, I went to the real M$
site and picked the updates I felt that I needed about 2 months ago. Then the
shit hit the fan. First most programs started and ran slower, Second I, at
this time am using a dial up connection. I use Zone Alarm on any type of
connection and after M$ updates I noticed and increase in Hits, 100 to 200 per hour.
I did some research on slow programs after M$ updates, and found 2
lines of though First the M$ patch 811493 (MS03-013) had been reported to
cause my problem, I uninstalled it and programs acted better but not as they did
before, so I tried the Second possible solution, R/click main Network
connection, click properties, D/click Internet Protocol (TCP/IP) click Advance, click
WINS tab and REMOVE the check mark "Enable LMHOSTS,"
Poof all programs ran as they use to. NOW The Big Question. Why
have the Firewall Hits dropped from over 100 per hour to, well in the last 2 hrs
I have had 4 hits. I check the firewall at Steve Gibsons site all is well with
ZA. There seems to me to be Something Big here but I do not have the
knowledge to figure it out.
Thanks in advance for any help
Subj: [DShield] betaplace.com - not betaplace.microsoft.com, PKI issues
Date: 12/6/2003 10:49:59 AM Mountain Standard Time
From: emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl (Erik van Straten)
Sender: list-bounces at dshield.org
Reply-to: <A HREF="mailto:list at dshield.org">list at dshield.org</A> (General DShield Discussion List)
To: list at dshield.org
CC: bpsup at microsoft.com, secure at microsoft.com
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
list mailing list
list at dshield.org
To change your subscription options (or unsubscribe), see:
----------------------- Headers --------------------------------
Return-Path: <list-bounces at dshield.org>
Received: from rly-xh02.mx.aol.com (rly-xh02.mail.aol.com [172.20.115.231])
by air-xh04.mail.aol.com (v97.10) with ESMTP id MAILINXH41-48b3fd216b51a1;
Sat, 06 Dec 2003 12:49:59 -0500
Received: from mail1.giac.net (mail1.giac.net [220.127.116.11]) by
rly-xh02.mx.aol.com (v97.10) with ESMTP id MAILRELAYINXH23-48b3fd216b51a1; Sat, 06 Dec
2003 12:49:41 -0500
Received: (qmail 12122 invoked from network); 6 Dec 2003 17:49:40 -0000
Received: from mail1.giac.net (HELO dshield.com) (18.104.22.168)
by 0 with SMTP; 6 Dec 2003 17:49:40 -0000
Received: from maverick12.sans.org (localhost.localdomain [127.0.0.1])
by dshield.com (8.11.6/8.11.6) with ESMTP id hB6HlXk00956;
Sat, 6 Dec 2003 17:47:33 GMT
Received: from mail1.giac.net (iceman1 [22.214.171.124])
by dshield.com (8.11.6/8.11.6) with SMTP id hB6Hd5k00778
for <list at maverick12.sans.org>; Sat, 6 Dec 2003 17:39:05 GMT
Received: (qmail 8985 invoked from network); 6 Dec 2003 17:39:04 -0000
Received: from mail1.giac.net (HELO dshield.org) (126.96.36.199)
by 0 with SMTP; 6 Dec 2003 17:39:04 -0000
Received: (qmail 7372 invoked from network); 6 Dec 2003 17:36:49 -0000
Received: from mail2.giac.net (HELO iceman.incidents.org) (188.8.131.52)
by 0 with SMTP; 6 Dec 2003 17:36:49 -0000
Received: (qmail 28978 invoked from network); 6 Dec 2003 17:36:49 -0000
Received: from cpo.tn.tudelft.nl (184.108.40.206)
by 0 with SMTP; 6 Dec 2003 17:36:49 -0000
Received: from x080097 (x080097.tnw-m.tudelft.nl [220.127.116.11])
by cpo.tn.tudelft.nl (Postfix) with SMTP
id 6FFE297B44; Sat, 6 Dec 2003 18:36:45 +0100 (CET)
From: "Erik van Straten" <emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl>
Organization: Charged Particle Optics group - TU Delft
To: list at dshield.org
Date: Sat, 6 Dec 2003 18:36:10 +0100
Content-type: text/plain; charset=US-ASCII
Subject: [DShield] betaplace.com - not betaplace.microsoft.com, PKI issues
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <20031206173645.6FFE297B44 at cpo.tn.tudelft.nl>
Old-X-Envelope-To: list at dshield.org
X-Seen-By: bob list
X-Mailman-Approved-At: Sat, 06 Dec 2003 17:40:12 +0000
Cc: bpsup at microsoft.com, secure at microsoft.com
X-BeenThere: list at dshield.org
Reply-To: General DShield Discussion List <list at dshield.org>
List-Id: General DShield Discussion List <list.dshield.org>
<mailto:list-request at dshield.org?subject=unsubscribe>
List-Post: <mailto:list at dshield.org>
List-Help: <mailto:list-request at dshield.org?subject=help>
<mailto:list-request at dshield.org?subject=subscribe>
Sender: list-bounces at dshield.org
Errors-To: list-bounces at dshield.org
More information about the list