Lucene search
K

msie.4.0-no.dots.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 41 Views

New Internet Explorer bug allows internet sites to bypass security levels using IP addresses.

Code
`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