posted 12-12-2003 08:57 PM                    

quote:

---

New considerable IE flaw allows dangerous URL spoofing

Clint, one of the Masters of the Agora, gave heads up of a new and very dangerous exploit for Internet Explorer. If you've been around the block long enough, you've seen the URL trick that involves spoofing legitimate domain names by using user authentication to make a URL look valid at its root. For example, you might see a URL like this:

http://microsoft.com:windows@129.79.xxx.xxx/files/report.html

The above is hypothetical, but you get the point. The @ is actually a signal that you're logging into the site after the @, that is, 129.79.xxx.xxx. Your username is microsoft.com and your password is windows. It's not hard to see why this fools many people: they think it's a URL to Microsoft. This is one of the most popular ways scammers trick people into giving out all kinds of sensitive information. Well, it just got worse. An Internet Explorer URL Spoofing Vulnerability has been found that can actually mask the URL that you're at and replace it with something arbitrary. You can test IE right here. Even though the HTML points to http://www.microsoft.com%01%00@secunia.com/internet_explorer_address_bar_spoofing_test/ , IE will follow that link but http://microsoft.com is what you'll see in your address bar. As Clint said, get ready for a deluge of spam exploiting this. Get the word out (Send to a friend below should work) to minimize this baddy.

---

quote:

---

Internet Explorer URL Spoofing Vulnerability

Secunia Advisory:
SA10395
Release Date:
2003-12-09
Last Update:
2003-12-11

Critical:
Moderately critical
Impact:
ID Spoofing
Where:
From remote

Software:
Microsoft Internet Explorer 6

Description:

A vulnerability has been identified in Internet Explorer, which can be exploited by malicious people to display a fake URL in the address and status bars.

The vulnerability is caused due to an input validation error, which can be exploited by including the "%01" and "%00" URL encoded representations after the username and right before the "@" character in an URL.

Successful exploitation allows a malicious person to display an arbitrary FQDN (Fully Qualified Domain Name) in the address and status bars, which is different from the actual location of the page.

This can be exploited to trick users into divulging sensitive information or download and execute malware on their systems, because they trust the faked domain in the two bars.

Example displaying only "http://www.trusted_site.com" in the two bars when the real domain is "malicious_site.com":
http://www.trusted_site.com%01%00@malicious_site.com/malicious.html

A test is available at:
http://www.secunia.com/internet_explorer_address_bar_spoofing_test/

The vulnerability has been confirmed in version 6.0. However, prior versions may also be affected.

Solution:

Filter malicious characters and character sequences in a proxy server or firewall with URL filtering capabilities.

Don't follow links from untrusted sources.

Reported by / credits:

Originally discovered by:
Zap The Dingbat

Status bar variant reported by:
Chris Hall

Changelog:

2003-12-11: Linked to test. Added information regarding variant, which makes it possible to spoof URL in the status bar as well.

---

posted 12-13-2003 09:51 AM                       

quote:

---

GreyMagic Security Advisory GM#002-OP
By GreyMagic Software, Israel.

04 Feb 2003. Topic: Opera's Security Model is Highly Vulnerable.

Discovery date: 14 Nov 2002.
Affected applications: Opera 7 (final).
Introduction: Opera recently released a new version of its browser.

Version 7 brings many long-awaited features such as proper DOM support and an improved rendering engine. However, Opera seems to have neglected one of the most important aspects in any browser today, its default cross-domain security model.
Discussion: All browsers with Javascript support deploy a cross-domain security model, which, in essence, attempts to prevent documents from one domain to access other documents in different domains.

Opera 7 deployed a fundamentally different approach to cross-domain security, a caller-based model, rather than the origin-based model deployed in other browsers. The vulnerability is comprised of three different flaws in that model:

Functions in different domains can be accessed and executed.

Functions are being executed under the caller's domain credentials and not in their originating domain.

It is possible to override properties and methods (both native and user-defined) in other windows.

The first flaw means that a window in one domain is able to execute functions in a window that's in a different domain. This flaw in itself is not a big threat because of the second flaw, which means that even if a function in the victim window is executed, it is executed with the attacker's credentials, and therefore unable to access the victim's document.

The second flaw means that if the attacker can get the victim to execute a function, it will run under the victim's credentials. And because of the first flaw, the victim will have no problems accessing a malicious function created by the attacker.

The third, and most devastating flaw means that the attacker is able to trojanize native methods in the victim window with his own code and simply wait for the victim to execute it.

With these three flaws combined, it becomes extremely easy to exploit any document that uses some scripting, including local resources in the file:// protocol. Being able to access local resources in Opera means that the attacker would be able to:

Read any file on the user's file system.

Read the contents of directories on the user's file system.

Read emails written or received by M2, Opera's mail program.

And more...

Exploit: A perfect candidate for exploitation is Opera's own Javascript console, which arrives in the form of three separate files in Opera's installation directory.

The file console.html makes a very early call to the native method setInterval, which can be overridden by an attacking window. This scenario does not require any user interaction.

<s cript language= jscript >
var oWin=open( file://localhost/console.html , , );
oWin.setInterval=function () {
alert( Access to local resource achieved: +oWin.document.location.href);
}
</s cript>

The file://localhost/ URL appearing in this sample is a convenient method provided by Opera in order to access the selected directory (Opera's home by default).

Demonstration: We put together two proof-of-concept demonstrations:

Simple: Reads cookies from a few well-known sites and demonstrates access to a local resource.
GreyMagic Opera Disk Explorer: Browse your entire file system using this explorer-like tool, which takes advantage of this vulnerability in order to access local resources.

Solution: Opera was notified of a variation of this issue on 14-Nov-2002, but appareantly failed to understand the core issues and only patched one symptom of the problem (it was possible for foreign windows to simply set event handlers in Beta 1).
In the meantime, until a patch becomes available, disable Javascript by going to: File -> Preferences -> Multimedia, and uncheck the Enable JavaScript item.

Credits: Many thanks to Tom Gilder for his excellent help in researching this vulnerability.

Tested on: Opera 7 NT4.
Opera 7 Win98.
Opera 7 Win2000.
Opera 7 WinXP.

Disclaimer: The information in this advisory and any of its demonstrations is provided as is without warranty of any kind.
GreyMagic Software is not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.

---

quote:

---

[Full-Disclosure] Opera Skinned : Arbitrary File Dropping And Execution (Advisory)
S G Masood sgmasood@yahoo.com
Wed, 12 Nov 2003 02:18:34 -0800 (PST)

Previous message: [Full-Disclosure] MS03-049 checking tool ?
Next message: [Full-Disclosure] RE: MS03-049 checking tool ?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--------------------------------------------------------------------------------

Opera Skinned : Arbitrary File Dropping And Execution
======================================================

I ABSTRACT:

Like other browsers, Opera Web Browser supports many
standard MIME types and also a few

Opera-specific MIME types. Of the Opera-specific
types, the implementation of the various browser

skin and browser configuration MIME types(listed
below) has a design flaw that allows the remote

dropping of an arbitrary file with an arbitrary name
and type in a known location. This is

triggered when the victim accesses a URL.

Exploitation becomes easier when this vulnerability is
combined with the other Directory

Traversal vulnerability described in the attached
advisory.

II VERSIONS AFFECTED:

All versions upto and including 7.21 that support the
flawed MIME types are vulnerable. Version

7.22 contains the fix.

III. IMPACT:

By using this flaw, an attacker may:

i. Drop arbitrary files with arbitrary names on a
victim's hard disk.
ii. Run scripts with higher privileges.
iii. Read the contents of the directories on a
victim's hard disk.
iv. Read any file.
v. Read M2 emails (Built-in Opera mail client).

IV. TECHNICAL DETAILS:

We will consider the application/x-opera-skin MIME
type first for the sake of clarity. The

issues are the same for the other five flawed MIME
types. Their specifics are mentioned in a

later section below.

1. Skinning Opera with application/x-opera-skin :

According to the functionality that Opera provides, a
user can install a new skin just by

clicking on a link. Opera automatically downloads and
applies the skin without confirmation from

the user. For this to work, the MIME type of the skin
file has to be set to

application/x-opera-skin on the web server. The file
type of an Opera skin file is *.zip . The

Opera skin file specification [2] says-

8<---------

An Opera 7 skin file is a zipped file with extension
.zip that contains a skin.ini file at

root level and a bunch of images making up the skin.
The skin.ini file contains the whole skin
specification. All other files in the zip file are

pointed to by the specification in skin.ini . [2]

8<----------

Skins files are downloaded to C:\Program
Files\Opera7\profile\Skin\<filename.ext> (if the

install directory is C:\Program Files\Opera7\ . It is
*not* necessary for a remote attacker to

know the install path of Opera for exploitation.)

Skin files that do not have *.zip extensions but are
valid skin files are automatically

downloaded and applied by Opera if the correct MIME is
set on the httpd. They are downloaded to

the default skin file folder. However, these skins are
not shown in the file>preferences>skin

menu. Only skins with *.zip ext., are shown in the
list.

The security problem here is that even invalid,
corrupt skin files with any extension (including

exe,com, et al) are downloaded to the default skin
file location. The victim doesn't necessarily

have to know that he is downloading a skin. He just
clicks a malicious link and he is given a

harmless looking dialog box prompt saying that the
skin file is incompatible with the current

version of Opera *after the file is downloaded*. User
may click OK or CANCEL but it has no

effect on the download behaviour. The file is still
present in the skin file folder and it is not

deleted.

This means that an attacker can comfortably drop an
arbitrary file with an arbitrary name & type

on a victims hard disk in a known location by making
him access a simple, not-specially crafted

URL. Using an exploitation method detailed elsewhere,
the arbitrary file can be executed.

For instance, if a victim clicks on a link
http://foo.com/foobar.exe where the MIME type of

foobar.exe is set as application/x-opera-skin ,
foobar.exe is downloaded automatically to the

skin file folder. The name foobar.exe is preserved.
So, for a default install of Opera, the file

is dropped in and as C:\Program
Files\Opera7\profile\Skin\foobar.exe .

IV EXPLOITATION SCENARIOS & EXPLOIT:

According to my investigation, files can only be
dropped in the default folders mentioned above.

Using directory traversal techniques to drop the file
in other locations does not seem to be

feasible.

Although any file can be dropped on a victim's
computer, the highest compromise that can be

accomplished seems to be the running of scripts with
higher privileges. Files other than the file

types handled by Opera cannot be executed. This means
file types like exe, bat, etc., cannot be

executed although they may be dropped and file types
like html, txt, gif, etc., can be executed.

Nevertheless, the executable files dropped using this
vulnerability can be executed by using

other vulnerabilities(possibly in other software).

This flaw can be exploited alone but, if Opera is not
installed in the default path, a 'blind'

exploit will not work. Nevertheless, when this flaw is
combined with the Directory Traversal

vulnerability (detailed in the advisory Opera Web
Browser Directory Traversal in Internal URI

Protocol published by me, attached to this one),
'blind' exploitation, i.e., exploitation

without knowledge of the install path becomes
possible.

A proof of concept exploit is attached with this
advisory.

V. VENDOR RESPONSE & SOLUTION:

The vendor, Opera Software, deserves special mention
here. I had previously read about Opera

Soft's promptness in resolving security
vulnerabilities in their products. My experience with

them is one of the best I ever had with any vendor. I
hope they continue to maintain their good

record even with future security issues.

An updated version with a fix (7.22) is available from
the site - http://www.opera.com/download/

VI. CREDIT:

S.G.Masood (sgmasood@yahoo.com)

Hyderabad,
India.

VII. DISCLAIMER:

This advisory is meant only for the dissemination of
information, alerting the general public

about a security issue. Use this information at your
own discretion.

In brief, the author is not responsible for any use,
misuse, abuse of this information. Also,

this information is provided as is without any
warranty of any kind.

*PHEW*

EOF

---