`Subject: [ISN] New IE bug "No Dots Bug"
http://www.msnbc.com/news/206992.asp#BODY
IE can treat Internet sites as if they were on intranet
By Bruce Brown
BUGNET
Oct. 20 ^× Posters on a Danish newsgroup have discovered a new security
hole in Microsoft Internet Explorer. Microsoft has confirmed the potential
security breach, dubbed the ^ÓLook Ma, No Dots^Ô bug.
^ÓTHE BUG MAKES IT possible to circumvent the higher security levels
that can be set in Internet Explorer for Internet sites (as opposed to
intranet sites) by a simple calculation based on the site^Òs IP address,^Ô
according to Jakob Paikin, one of the bug^Òs Danish discoverers.
While Internet addresses are normally expressed in their DNS form
of recognizable words (e.g., www.bugnet.com), every named URL address on
the Web can be translated into a numerical IP address. Normally IP
addresses are displayed as four numbers separated by dots (e.g.,
207.158.205.117).
A site can be accessed by either the name or the IP address. So,
for example, both http://www.bugnet.com and http://207.158.205.117 display
the main BugNet free page. But every IP address can also be recalculated
to a single number. Here^Òs how. Multiply the first part by 256 cubed (256
to the third power), multiply the second by 256 squared, multiply the
third by 256, multiply the fourth by 1 ^× and now add all the values
together.
Recalculating the address for BugNet in this manner yields
3483290997. And in fact, clicking http://3483290997 will take you to the
same BugNet page. Try it. (Note: If you are accessing the Internet
through a proxy server, you will most likely get a ^Ósite not found^Ô error.
Most proxies automatically append a default domain to addresses not
containing dots.)
The problem for Internet Explorer 4 comes from the fact that
Microsoft^Òs browser assumes that any address not containing dots is an
intranet address, and applies security accordingly.
^ÓSince intranet security is often set lower than for Internet
sites, the user may unknowingly allow an Internet site to operate at an
intranet security level,^Ô according to Paikin.
The bug poses a problem in the following scenario:
[*] 1) The user has set a lower security level for the intranet Security
Zone.
[*] 2) The user accesses a Web site that contains a ^Ómalicious^Ô ActiveX
component or Java applet).
[*] 3) The malicious Web site is accessed via a link that uses the
compressed format like http://3483290997.
It is worth noting that the user would have to modify IE4^Òs default
intranet Security Zone settings to be affected. Also, many corporate users
with access to both the Internet and an intranet are served by proxy
servers, which would most likely block the hole, according to Bob Minor of
CyberMill in St. Louis.
A Microsoft spokesman in Denmark told PC World Denmark that ^Óour
developers are currently working to address this issue. In the meantime,
users can protect themselves by returning their intranet zone to the
default settings and if prompted to download content from the Internet, it
is important for users to use safe computing practices.^Ô
The problem apparently affects only Internet Explorer 4 for
Windows. Netscape and Internet Explorer on the Mac are not affected.
---------------------------------------------------------
Date: Tue, 20 Oct 1998 10:48:29 -0500
From: Aleph One <[email protected]>
To: [email protected]
Subject: Re: Alert: IE 4.0 Security Zone compromise
Its not quite as simple Russ. In the Medium security setting User
Authentication has been set to "Automatic logon only in Intranet zone".
This means a rougue web site can steal username/password hash pairs just
like in the old days of IE and NTLM authentication.
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
Date: Tue, 20 Oct 1998 11:06:13 -0500
From: Aleph One <[email protected]>
To: [email protected]
Subject: Alert: IE 4.0 Security Zone compromise
New Internet Explorer vulnerability. As opposed to what Russ states below
there is a new risk created by this vulnerability. The default setting for
authentication in IE for the Medium security setting is to automatically
logon to machines in the Intranet zone when the web server requests user
authentication without prompting the user. Nice way for someone to go
finishing for passwords by posting some message with an embedded URL in a
newsgroup or mass emailing some corporation.
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
---------- Forwarded message ----------
Date: Mon, 19 Oct 1998 21:06:16 -0400
>From: Russ <[email protected]>
To: [email protected]
Subject: Alert: IE 4.0 Security Zone compromise
Sune Hansen, Webmaster of <http://www.WorldWideWait.com>, discovered a
security problem which affects Trust Zones within Internet Explorer
4.0+.
Basically, if you provide IE with <http://3475932041>, you'll arrive at
Microsoft's web site. However, it will be listed, and treated, as part
of your Local Intranet Zone when in fact it should be part of any other
zone.
For anyone who has made no modifications to their zones (i.e. using the
defaults supplied with IE), there is no difference since both Local
Intranet Zone and Internet Zone are set to "Medium" security.
If, however, modifications have been made to the zone security
configuration such that, for example, the Internet Zone is more
restrictive than the Local Intranet Zone, then the fact such 32-bit URLs
end up being seen by IE as trusted can create a problem.
IE appears to assume that anything it sees without a period in the URL
should be treated as part of the Local Intranet Zone. Winsock then takes
the address and properly translates it to a reachable IP address (you
could just as easily use PING or some other utility with such an
address).
Sune tested this on Windows '98, and I've tested it on NT 4.0 SP4 RC2
with IE 4.0 (SP1;2735 - 4.72.3110.8), and both caused the same problem.
Essentially the problem exists within IE, and not NT, but since Sune is
franticly seeking out media outlets to report the story, I figured it
was worth a note here. Microsoft did receive a brief message from Sune
on Sunday morning, although they were made more aware of the issues by
the media trying to verify Sune's claims.
I'm not trying to downplay the problem. Anyone who is using Trust Zones
should understand that they, alone, will not prevent a site from placing
a URL in the above fashion and causing a site to be viewed as a Local
Intranet Zone site. Proxies, and Firewalls, however, are not affected by
this and will properly enforce restrictions if so configured. The
problem appears to reside entirely within the mechanism that IE uses to
determine if something is part of the Local Intranet Zone when no
servers are configured in that zone.
My conversations with Microsoft indicate we will hear more when they
have more fully investigated the ramifications of the issue.
Cheers,
Russ
-----------------------------------------------------------------
Date: Wed, 21 Oct 1998 11:35:02 +0200
From: Norbert Luckhardt <[email protected]>
To: [email protected]
Subject: Re: Alert: IE 4.0 Security Zone compromise
-----BEGIN PGP SIGNED MESSAGE-----
Hi there,
At 21:06 19.10.98 -0400, you wrote:
>IE appears to assume that anything it sees without a period in the URL
>should be treated as part of the Local Intranet Zone.
as I tested on IE 4.0 (4.72.3110.1 german version w/ win98) the bug seems to
rely on the option "add all local sites which are not listed in another
zone" (or however the english text for that will be) - when You uncheck this
option (internet options/security; choose "local intranet zone"/add sites)
the 32bit-URLs will be treated correctly as internet zone sites
so as a workaround it should do to add all local sites manually to the
intranet list with the "advanced" option
have fun, Shalom,
NOrbert
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
Comment: c't Krypto-Kampagne http://www.heise.de/ct/pgpCA/
iQCVAwUBNix84jYMsgdcZ8mpAQGr9wP9Gk1vGys1hazYQ7W/D86WtlJeygQWgMsr
mtU1bpkU/evKZBC3O2zzeNGKAk72VMMBzsHBCUCFKAfgiEn5u1XCYz4skPkld7Yy
bJFJ+/Ieg6YcxRjOwu1aWZ+wMbhq6Fp99apOh/kQr3/7EjMbZxgzfTU4zqtGsYQK
rYF13anQuJs=
=rfXH
-----END PGP SIGNATURE-----
--
Norbert Luckhardt http://www.heise.de/ct/Redaktion/nl/
Redaktion c't Tel.: +49 511 5352 - 300 Fax: +49 511 5352 - 417
Helstorfer Str. 7 D-30625 Hannover BBS: +49 511 5352 - 301
`
Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation