[Full-disclosure] XSS with UTF-7 in yahoo.com

[HASEGAWA Yosuke]

XSS with UTF-7 in yahoo.com

Abstract:
XSS with UTF-7 was found in yahoo.com (already fixed).
Although charset was specified in HTTP response header, but
charset-name was incorrect so XSS occurred.


PoC:
http://search.yahoo.com/search?p=%2BADw-/title%2BAD4-%2BADw-script%2BAD4-alert(document.cookie)%2BADw-/script%2BAD4-&fr=yfp-t-501&toggle=1&cop=mss&ei=UTF-8&eo=euc

Details:
The "euc" is specified for output charset with "eo" parameter,
so responded HTTP header from Yahoo is like as:
--
Content-Type: text/html; charset=EUC
--

"euc" is not registered as correct charset name for IE.
IE recognizes only charset names Hardocorded in MLang.dll
like as "EUC-JP", "EUC-KR", "UTF-8" and so on.

Therefore, an automatic detection function for encoding works,
and detect as "UTF-7".

Typical incorrect charset name in japanese web pages are followings:

utf8 - Idiomatic expression of "UTF-8" hyphen falls out.
euc - Idiomatic expression of "EUC-JP"
jis - Idiomatic expression of "ISO-2022-JP"
MS932 / MS932 / CP942C - Comparable encodings to Shift_JIS on Java
Windows-31J - IANA registered name for Codepage 932, but not
registered in Windows.

Status:
Nov 16 2007 reported to Yahoo and was fixed immediately.

-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] XSS with UTF-7 in Google

[HASEGAWA Yosuke]

XSS with UTF-7 in Google

XSS with UTF-7 was found in www.google.com (already fixed).
Although charset was specified in HTTP response header, but
charset-name was incorrect so XSS occurred.

PoC:
  http://www.google.com/search?hl=en&oe=cp932&q=%2BADw-script%2BAD4-alert(
  document.cookie)%2BADsAPA-/script%2BAD4-%2BACI-

The "cp932" is specified for output charset with "oe" parameter,
so responded HTTP header and  in HTML from Google are like as:
--
Content-Type: text/html; charset=CP932
--

--

"cp932" is the similar name of the Shift_JIS encoding,
but it is not registered as correct charset name for IE.
IE recognizes only charset names hardocorded in MLang.dll
like as "Shift_JIS", "EUC-JP", "EUC-KR", "UTF-8" and so on.

Therefore, an automatic detection function for encoding works,
and detect as "UTF-7".

Typical incorrect charset name in japanese web pages are followings:

utf8 - Idiomatic expression of "UTF-8" hyphen falls out.
euc - Idiomatic expression of "EUC-JP"
jis - Idiomatic expression of "ISO-2022-JP"
MS932 / MS932 / CP942C - Comparable encodings to Shift_JIS on Java
Windows-31J - IANA registered name for Codepage 932, but not
registered in Windows.

Status:
Apr 17 2007
 Reported to Google via IPA/ISEC 
Dec 26 2007
 Received reply it fixed from Google via IPA/ISEC.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] MS07-034: Executing arbitrary script with mhtml: protocol handler

[HASEGAWA Yosuke]

MS07-034: Executing arbitrary script with mhtml: protocol handler

Author:Yosuke HASEGAWA 
Date: Wed, 21 Jun 2007
CVE: CVE-2007-2225, CVE-2007-2227

Original advisory:
http://openmya.hacker.jp/hasegawa/security/ms07-034.txt
http://archive.openmya.devnull.jp/2007.06/msg00060.html

Abstract:
In Internet Explorer, with mhtml: protocol handler and using Outlook
Express's feature, arbitrary resources (such as HTML, image, application
file and so on) can opened as MHTML formatted file and Content-Type: is
disregarded.

It is possible to treat by text/html including JavaScript encoded base64
or Quoted-Printable in MHTML format.
Therefore, it was possible to have bypassed filtering of the dangerous
character (or string) usually carried out in the Web application of the
large range, and to have execute arbitrary scripts.

Tested version:
Outlook Express 6 / Internet Explorer 6 / Internet Explorer 7

Details:
In IE, When the prefix of "mhtml" is given to the URL and it accesses
a resource, the function of OE is used( mhtml protocol handler is called),
and IE deals with that resource as a MHTML(RFC2557) formatted document.

The behavior of IE is peculiar as follows when a document is opened as
a MHTML form through mhtml: protocol handler.

- Content-Type: HTTP response header is ignored.
- It doesn't depend on the setting "Open files based on content, not
  file extension", and "MHTML" is always forced as a file type for the
  resource.
- In the MHTML document, Separated from the MHTML header by a MHTML body
  by the CR/LF in HTTP response body.
- In the MHTML document, encoding by base64 or Quoted-Printable can be
  used for the MHTML body part by specifying it with a MHTML header.
- In the MHTML document, text/html document type can be used for the
  MHTML body part by specifying it with a MHTML header and can be
  included script in the body part.
- "Content-Disposition: attachment" HTTP response header is ignored,
   and the resource is opened without user's confirmation.

Therefore, even if it was it to the Web application that it coped with
it suitably, script was put in the form encoded with base64 and Quoted-
Printable inside, and it was possible that XSS was made to occur.

For example,

--


Subject: test
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: base64

PGh0bWw+DQo8c2NyaXB0PmFsZXJ0KGRvY3VtZW50LmxvY2F0aW9uKTs8L3NjcmlwdD4NCjwv
aHRtbD4NCg==


--

Open this HTML file through the mhtml: protocol handler such as
http://example.com/test.html>,
IE/OE assumed the file as MHTML, not HTML, including script encoded by
base64. The script is encoded by base64, Because it is being encoded
with base64, script passes through the web application's filter, and it
is possible that XSS is made to occur.
In order to ignore Content-Type: header completely, includes the MHTML
contents, it was possible even in XML, images, application fille like
as *.doc, and the like not only HTML to execute the script.

Background:
May 2004
 The publication by the first discoverer (probably). (Japanese contents)
 
http://web.archive.org/web/20040607114853/www2.sala.or.jp/~uuu/security/jpeg1.html
Jul 2004
 Article of Slashdot Japan "Many Unmeasures vulnerability discoverd in Japan"
 is published. (Japanese contents)
 http://slashdot.jp/security/article.pl?sid=04/07/29/0635211
Feb 2005
 [Full-Disclosure] Possible XSS issue on Windows XPSP2 IE6 via MIME
 Encapsulation of Aggregate HTML
 http://lists.grok.org.uk/pipermail/full-disclosure/2005-February/032058.html
Sep 2006
 Ask to grasp it as a vulnerability in Microsoft about this.
Oct 2006
 Response from Microsoft, "Behavior by design of IE".
Oct 2006
 Report to Microsoft that the XSS is made to occur and can steel Cookie by
 using this behavior on  on search.microsoft.com / search.live.com /
search.msn.com.
Oct 2006
 Report to Microsoft via IPA/ISEC as the vulnerability of Web application
 that the XSS is made to occur and can steel Cookie by
 using this behavior on  on spaces.live.com / msn.co.jp.
Oct 2006
 Report to Microsoft via IPA/ISEC as the vulnerability of IE, about the
 "Content-Disposition: attachment" header is ignored via mhtml:
protocol handler.
Dec 2006
 Received the contact to deal with handling this case as a vulnerability
 of OE from Microsoft via IPA/ISEC.
Jun 2007
 Security fix for OE released as MS07-034.

Acknowledgment:
 I appreciate  deeply hoshikuzu|star_dust who told me the problem that
 it is introduced to the public in 2004 existing for 2006 years even in
 the moment, the offer of PoC,  and various information.

-- 
HASEGAWA Yosuke
yosuke.hasegawa at gmail.com
Microsoft MVP for Windows - Security (Oct 2005 - Sep 2007)

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] UTF reverse-writing WYSINWG "feature"

[HASEGAWA Yosuke]

Hi.

On 8/28/07, Tonu Samuel <[EMAIL PROTECTED]> wrote:
> But by concerns are related to security. For example even looking title
> of this digg.com page with Firefox or Konqueror and you see that browser
> name is reversed! I looked into source code with Firefox and lot of
> things are reversed too!

In Japan, this trick -- Visual camouflage usgin
Unicode Bidi -- is already known since 2005.
By including RLO(U+202E) in the a file name, Visual spoofing
of the extension is possible.

For example, create a file named such as:
 "this-(U+202E)txt.exe"
And when this file is indicated over theExplorer.exe,
it is visible in "this-exe.txt", like as a TEXT file.
Although this file is visible to txt file seemingly, but, of
course, it operates as exe file.

Here is the sample image on Japanese edition of Windows.
<http://openmya.hacker.jp/hasegawa/public/20061209/momiji9.png>

In Japan, it is already said that the malware which used this
trick is distributed through a Winny the most famous P2P
software in Japan - network.

Execution of malware by this trick can be prevented by
restricting execution of the file which contains RLO in
a filename,using group (or local) policy.


-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] XSS using Atom feed in www.ibm.com

[HASEGAWA Yosuke]

XSS using Atom feed in www.ibm.com

Abstract:
A XSS using Atom feed was in www.ibm.com (already fixed).
This XSS technique appears only by IE6, not appears on IE7 and Firefox.

Poc:
  http://www.ibm.com/fscripts/search/opensearch/search.fcgi/a.html?
  q=%2BADw-/title%2BAD4-%2BADw-script%2bAD4-alert(document.location)
  %2BADw-/script%2BAD4-&v=16&en=utf&lang=ja&cc=en&format=atom&startIndex=1

  When it accesses this URL over IE6, the script operates.

Details:
By adding the "format=atom" parameter, "Content-Type: application/atom+xml"
is returned as a response header.

Note that the charset is not given. This becomes the first step to the attack.

Next, IE6 cannot understand "application/atom+xml" as Content-Type.
This is the second step.

The third step, the original search URL in ibm.com is following:
  http://www.ibm.com/fscripts/search/opensearch/search.fcgi?q=
Even if PATH_INFO is added as follows, it operates.
  http://www.ibm.com/fscripts/search/opensearch/search.fcgi/a.html?q=
And IE6 judges the file type to be HTML by adding PATH_INFO  with
Content-Type cannot judged.

Therefore, IE6 interprets contents as a HTML encoded with UTF-7 and
the script included in the parameter can be operated.

Solution:
Now, Charset is added to content-type in this CGI like
as "Content-Type: application/atom+xml; charset=utf-8" and
moreover, "%3c" in "q" parameter is encoded to "<".
As a result, injecting the script by UTF-7 is impossible.

There is another solution as follows.

When Content-Type cannot be understood, IE6 starts deciding
file type by the Content-Disposition header.
Then, it can be prevented from being judged file type as HTML
by PATH_INFO with adding Content-Disposition header such as:
"Content-Disposition: inline; filename=a.xml"

-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] IE7 is a Source of Problem - Secunia IE7 Release Incident of October 2006

[HASEGAWA Yosuke]

Hi.

On 10/27/06, LIUDIEYU dot COM <[EMAIL PROTECTED]> wrote:
> Upon IE7 release, Secunia published SA22477 titled `Internet Explorer
> 7 "mhtml:" Redirection Information Disclosure`.

It seems to be able to make redirecting with mhtml fail by returning
the response by 201 or 202.
There for, It is possible for this to prevent trying to steal the
contents of your server via mhtml redirection.

-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Backdooring Image Files - security notice

[HASEGAWA Yosuke]

Hi.

On 12/15/06, pdp (architect) <[EMAIL PROTECTED]> wrote:
> I will be brief. There is a rather lame/concerning technique, most of
> you know about, that allows JavaScript to be executed upon visiting an
> image file. This issue is not due to some browser error, although
> clearly IE has some issues with it, but it is due to web applications
> not sanitizing user supplied content in a form of links.

On Windows server, FindMimeFromData function can be used IE to
know what kind of file type it is determine with on the server side.
http://msdn.microsoft.com/workshop/networking/moniker/reference/functions/findmimefromdata.asp

Of course, a result may become  mismatch by the browser and
server side.

Or, adding "Content-Disposition: attachment" for response header,
It can be used to prevent executing script on browser directly.

-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[HASEGAWA Yosuke]

Hi,

As the server side solution, force rewriting fragment identifiers in URI by
redirecion responce can be considered.

Disallow the directoly access to PDF on the server and return response such as:
--
Location: http://example.com/one-shot-url.pdf#top
--

As a result, fragment identifiers in URI is rewritten and executing
malicious script
can be prevented.
"one-shot-url" must be unpredictable  disposable address by attacker.

Regards,

On 1/3/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
> I will be very quick and just point to links where you can read about
> this issue.
>
> It seams that PDF documents can execute JavaScript code for no
> apparent reason by using the following template:
>
> 
> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
>
> You must understand that the attacker doesn't need to have write
> access to the specified PDF document. In order to get an XSS vector
> working you need to have a PDF file hosted on the target and that's
> all about it. The rest is just a matter of your abilities and desires.
>
> This finding was originally mentioned by Sven Vetsch, on his blog.
> This is a very good and quite interesting. Good work.
>
> There is a POC I composed:
>
> http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);
>
> More on the matter can be found here:
>
> http://www.gnucitizen.org/blog/danger-danger-danger/
> http://www.disenchant.ch/blog/hacking-with-browser-plugins/34
>
> --
> pdp (architect) | petko d. petkov
> http://www.gnucitizen.org
>
> 
> The Web Security Mailing List:
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>


-- 
HASEGAWA Yosuke
[EMAIL PROTECTED]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/