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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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 / aleph1@dfw.net 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 To: BUGTRAQ@netspace.org 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 / aleph1@dfw.net 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Alert: IE 4.0 Security Zone compromise Sune Hansen, Webmaster of , discovered a security problem which affects Trust Zones within Internet Explorer 4.0+. Basically, if you provide IE with , 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 To: BUGTRAQ@netspace.org 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