PDF-based polyglots through SVG images (CVE-2015-5092)

Many vulnerabilities in Adobe Reader were recently patched in APSB15-15; the security update addresses a vulnerability (CVE-2015-5092) that we responsibly reported to Adobe PSIRT in April 2015. 

The vulnerability consists in a bypass to the PDF content smuggling countermeasure, which Adobe introduced in January 2013 to address PDF-based polyglots. In fact, it was possible to craft PDF-SVG Polyglots which were correctly read both by Adobe Reader (as a PDF document) and by SVG interpreters (as an image).
Such technique could be useful when facing some very specific scenarios, such as: 

• Web application allowing SVG images uploads and validating them through a robust (SVG-)XSS filter 
• Web application allowing SVG images uploads and relying only on Content Security Policy for protecting against XSS

In both the cases, we are assuming that genuine PDF files uploads are prohibited; in the second scenario we are considering the presence of a server-side SVG parser which verifies that the supplied image is at least well-formed.
Although we all know that allowing SVG files uploads is sufficient for being vulnerable to Stored XSS, this should not be correct in presence of a robust (SVG-)XSS filter, validating untrusted images. In such circumstance, uploading a PDF-based polyglot would permit to bypass the SVG filtering procedure and steal private data by abusing same-origin requests, carried out from the PDF context.
In case of XSS protection achieved through CSP instead, inline JavaScript execution is disabled by default; however, this assumption was not observed in some browsers, when accessing polyglots which evaluated JavaScript code from the PDF context, instead of the SVG one.

Although some limitations are in place when dealing with such vulnerability, it is worth sharing since it turns out quite fascinating from a security research perspective. 

First, the vulnerability introduces a potential bypass in tight SVG filters, which accept comments without inspecting their content; moreover, the issue proves destructive when compared with the efforts required for building and testing filters; consider for instance the case of MediaWiki which progressively built a robust filtering procedure against user supplied SVG images. 

Secondly, polyglots get interesting when dealing with Content Security Policy, especially in case of missing explicit policy directives, by blindly trusting default-src. 

Here follows the related paper containing all the details and proof of concepts.

PDF-based polyglots through SVG images from mindedsecurity

At this point it is important to consider that default installations of Firefox, Chrome and Opera do not use Adobe Reader for rendering PDF files; therefore, potentially affected users are the ones who modified their browser settings in order to use Adobe Reader instead of the default built-in reader. In addition, note that Chrome is going to disable NPAPI support. 

Eventually, this issue makes us consider again the risks involved in file uploads, and more generally in content hosting; content sanitization proves insufficient, therefore the usage of sandboxed domains is obviously the suggested design choice to operate the expected isolation and mitigate all the involved risks. However, since SVG images can be deployed in many different ways, further observations should be made on this basis.

Users are recommended to update Adobe Reader to version 11.0.12; in addition, blacklisting %PDF- in SVG filtering procedures would be a plus for protecting users using older Reader versions. From the CSP perspective, instead, setting object-src and plugin-types to 'none' would probably be helpful for protecting against similar polyglot-based attacks.

Multiple security issues discovered in Concrete5 - Part 1

About a month ago we performed a Secure Code Review of Concrete5 version 5.7.3.1, the latest stable release at that time, and discovered multiple security issues within it. In particular we found the following vulnerabilities:

• A Remote Code Execution
• Multiple Reflected Cross Site Scripting
• A SQL Injection
• ...others not fixed yet

These issues have been reported to the Concrete5 team through HackerOne, since they have a bug bounty program in place. Some of them were promptly fixed in the next releases of the software, while others still have to be solved.

This is the reason why this post will be in two parts: in this first part we are going to cover the issues already fixed and publicly disclosed on the HackerOne website, while the remainings will be illustrated in the second part.

Concrete5 CMS

Concrete5 is one of the most used open source Content Management System (CMS) on the web. A recent infographic published by CodeGuard places Concrete5 as one of the most popular CMS after WordPress, Joomla and Drupal:

Concrete5, a CMS written in PHP, was launched in 2003 as Concrete CMS. It was rebranded as Concrete5 and launched fully open source under the MIT license in 2008. According to the official website, Concrete5 powers more than 580,000 sites and has a community with over 230,000 members.

The Issues

Sendmail Remote Code Execution Vulnerability

Official Advisory: 
https://www.mindedsecurity.com/index.php/research/advisories/msa110615-1  

Risk: High

Cause: Lack of input validation

Impact: Arbitrary PHP Code Execution on the server

One of the most critical issues we discovered is a Remote Code Execution (RCE) vulnerability affecting Concrete5 websites which use sendmail as mail server. This vulnerability is due to an incorrect validation of an input parameter used to store a setting related to the sender's address of a registration notification email.

The attack can be carried out in two steps:

1. The sender's email address setting is modified to alter the sendmail command line in order to add specific parameters which allow to log all the email traffic into an arbitrary file;
2. The attacker will send a specially crafted request to register a new account and will put some malicious PHP code after its email address. This will be written into the log file chosen during the first step, so in case it's a .php file arbitrary PHP code execution may be achieved (using the same technique described here).

Even though the sender's address parameter can be modified by administrator users only, an attacker might be able to exploit the bug leveraging a Cross-Site Request Forgery (CSRF) vulnerability affecting the related setting feature.

A detailed description of the vulnerability and a sample attack workflow are described in the following PDF:

- Disclosure Timeline:

[05/05/2015] - Vulnerability details sent through HackerOne

[05/05/2015] - Vendor said a patch has been committed and will be available in the next version

[05/07/2015] - Version 5.7.4 released along with the patch for this vulnerability

[06/06/2015] - Vulnerability publicly disclosed on HackerOne

Multiple Reflected Cross Site Scripting Vulnerabilities

Official Advisory: 
https://www.mindedsecurity.com/index.php/research/advisories/msa110615-2

Risk: Medium

Cause: Lack of input validation

Impact: Unauthorized access to the victim's browser data

During our code review activity we found out that several input parameters are used to generate some HTML output without a proper encoding. This can be exploited to carry out Reflected Cross Site Scripting (XSS) attacks.

The following PDF describes the discovered XSS vulnerabilities and provides Proof of Concept (PoC) web pages for them:

- Disclosure Timeline:

[05/05/2015] - Vulnerabilities details sent through HackerOne

[05/05/2015] - Vendor said that 2 out of 6 reported vulnerabilities were already fixed in development

[05/07/2015] - Version 5.7.4 released along with patches for all the 6 vulnerabilities

[06/06/2015] - Vulnerabilities publicly disclosed on HackerOne

SQL Injection Vulnerability

Official Advisory: 
https://www.mindedsecurity.com/index.php/research/advisories/msa110615-3

Risk: Medium

Cause: Lack of input validation

Impact: Unauthorized access to the data stored into the database

Furthermore we found the presence of a SQL injection vulnerability, which is due to certain user input being used to construct a SQL query without a proper validation. This can be exploited to carry out SQL injection attacks leading to unauthorized access to the data stored into the database.

However, the vulnerability is not critical because it is mitigated by the fact that can be exploited only by authenticated users with privileges to edit page permissions.

The following PDF describes the detail of the vulnerability and how to exploit it:

- Disclosure Timeline:

[05/05/2015] - Vulnerability details sent through HackerOne

[05/08/2015] - Vendor said a patch has been committed and will be available in the next version

[05/12/2015] - Version 5.7.4.1 released along with the patch for this vulnerability

[06/11/2015] - Vulnerability publicly disclosed on HackerOne

Stay tuned for the second part!

Comparing DOM based XSS Identification Tools on a Real World Vulnerability

Due to the lack of literature about DOM Based XSS identification tools awareness, we decided to write a paper that took the actual tools that are stated to be able to identify DOM Based XSS and test their capabilities when dealing with a real world DOM XSS issue.

"..
Minded Security has been the first company to launch a commercial tool aimed to identify DOM Based XSS  with a runtime approach: DOMinatorPro.
In 2012, as a result of our research on DOM XSS, we released the tainting engine on github.com as an open source project and created a commercial version that let users easily identify several kind of JavaScript vulnerabilities with a pretty high rate of accuracy .

Since then, some tools, open source and commercial, have been developed and awareness on this very topic grew among application security experts.

The following paper will try to give an unbiased study supported by objective facts about precision and accuracy of existing tools that are stated to identify DOM Based XSS vulnerabilities.
..."

Pdf here
Every feedback is really welcome!

DOMinatorPro Fuzzer finds a DOM XSS on Google.com

Introduction a.k.a. tl;dr

A quite simple DOM Based XSS was found on https://www.google.com/ context using DOMinatorPro.
What I think it's interesting here, is to show how DOMinatorPro works in this real world case.

In order to give a more detailed description, i recorded a video (HD) to show how DOMinatorPro can help in finding those particular kind of issues.

Some Details

DOMinatorPro is a runtime JavaScript DOM XSS analyzer, which means it can check for complex filters and help in finding debug and/or unreferenced parameters during JavaScript execution.

In order to do that, DOMinatorPro exposes a fuzzer button which fuzzes the URL query string and html input elements that have keyboard events attached to them as shown in the youtube video.
By using that feature I found that the code in

http://www.googleadservices.com/pagead/landing.js

uses unvalidated input to build the argument for two document.write call.

This javascript is used, among others, by:

http://www.google.com/toolbar/ie/index.html

and

https://www.google.com/toolbar/ie/index.html

which means that one more time a (almost) 3rd party script introduces a flaw in the context of an unaware domain.

Source Analysis

From http://www.googleadservices.com/pagead/landing.js (which has now been removed) the following lines do not escape user input:

Line 53:

    if (w.google_conversion_ad) {
      url = url + "&gad=" + w.google_conversion_ad;
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" + w.google_conversion_key;
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" + w.google_conversion_mtc;
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" + w.google_conversion_raw;
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" + w.google_conversion_domain;
    }

   
And those values are taken by using :

function google_get_param(url, param) {
var i;
var val;
if ((i = url.indexOf("?" + param + "=")) > -1 ||
(i = url.indexOf("?" + param.toUpperCase() + "=")) > -1 ||
(i = url.indexOf("&" + param + "=")) > -1 ||
(i = url.indexOf("&" + param.toUpperCase() + "=")) > -1) {
val = url.substring(i + param.length + 2, url.length);
if ((i = val.indexOf("&")) > -1) {
val = val.substring(0, i);
}
}
return val;
}

...

google_conversion_ad = google_get_param(url, "gad");
if (window.google_conversion_ad) {
(google_conversion_key = google_get_param(url, "gkw")) ||
(google_conversion_key = google_get_param(url, "ovkey"));
google_conversion_mtc = google_get_param(url, "ovmtc");
google_conversion_raw = google_get_param(url, "ovraw");
}
}

After the previous code, the url variable is used on line 91:

document.write('' name="google_conversion_frame"' +
' width="' + width + '"' +
' height="' + height + '"' +
' src="' + url + '"' +
' frameborder="0"' +
' marginwidth="0"' +
' marginheight="0"' +
' vspace="0"' +
' hspace="0"' +
' allowtransparency="true"' +
' scrolling="no">');

and line 103:

document.write(''src="' + url + '&ifr' + 'ame=0"' +
' />');

so the offending url (which can be found with DOMinatorPro fuzzer), is:

http://www.google.com/toolbar/ie/index.html?&gad=bbbb&gkw=yyyy&ovkey=10101010&ovmtc=14141414&ovraw=18181818&

and on any of those parameters can be added an attack payload like:

AAAA"onload="alert(document.domain)"

Remediation

I suggested that the use of encodeURIComponent on user data

    if (w.google_conversion_ad) {
      url = url + "&gad=" + encodeURIComponent(w.google_conversion_ad);
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" +
encodeURIComponent(w.google_conversion_key);
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" +
encodeURIComponent(w.google_conversion_mtc);
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" +
encodeURIComponent(w.google_conversion_raw);
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" +
encodeURIComponent(w.google_conversion_domain);
    }

would have solved the problem.

Anyway, Google fixed that by removing that script for good, which is a solution as well! :)

Conclusions 

As already said in my previous post, I still see DOM based XSS all around with little awareness and difficulties by all actors in SDLC in identifying them.
DOMinatorPro can really help in finding DOM based XSS and it does that by helping testers, developers or QA users by trying to give the information they need by adapting to the knowledge they have.

Give DOMinatorPro a Try

Do you still trust all those 3rd party JavaScripts embedded in your pages ?
Just browse your site with DOMinatorPro or fuzz your pages and see what happens. :)
In case you need help, check out our professional services or just ask for a contact.

Analysis of Dom Xss vulnerability in a Facebook Like Button implementation

Note: The following vulnerability is now patched. Thanks to Matt, Charlie and to the Addthis.com team that released a patch yesterday after receiving our advisory.

Description

I like very much facebook, and I like clicking on facebook like buttons like the one below. Addthis.com has its own implementation of Facebook Like Button and is very used among internet websites. They estimate that unique websites around the world are several millions.

A Facebook Like Button in a Share Widget Bar:

You can find some background information already in one of our previous posts:

•    http://blog.mindedsecurity.com/2012/09/temporary-patch-for-dom-xss-0day-in.html

Proof of Concept

http://www.website-with-addthis-widget.con/#"></fb:like><img/src="aaa"/onerror="alert('DomXss Found!')

Note: This reflected dombased cross site scripting (before the patch) was present in a tremendous number of websites

Vulnerable Code

if (F.href === _1) {
d = _8.util.clone(E.share.url_transforms || {});
d.defrag = 1;
F.href = _8.track.mgu(E.share.url, d);//-- Location
}
for (A in F) {
B += " " + A + "=\"" + F[A] + "\"";//-- Attribute Set
}
if (!E.share.xid) {
E.share.xid = _8.util.cuid();
}
f[F.href] = {};
for (A in E.share) {
f[F.href][A] = E.share[A];  
}
G.innerHTML = "<fb:like br="br" 
ref="\">_8.share.gcp(E.share, E.conf,".like").replace(",", "_") 
+ "\" " + B + "</fb:like>"; //-- DomXss
p(G);

Analysis and discovery with DOMinatorPro

Even if to the reader this issue seems like a common cross site scripting, finding such kind of security issues in Javascript code (aka DomXss) is an extremely complex task.

This is why our Advanced Research team developed DOMinatorPro. DOMinatorPro can be downloaded from the following dedicated website: http://dominator.mindedsecurity.com.

DOMinatorPro is a Free Opensource Project with Commercial Extensions. Commercial extensions have a 15 days Free Trial Period.

The vulnerability was in ONE of the scripts loaded by the “addthis_widget.js”  script available online at “http://s7.addthis.com/js/300/addthis_widget.js”. As you can see multiple scripts are loaded and the scripts are compressed and obfuscated , giving to human security reviewers a painful and a very long and time comsuming task to accomplish.

Note: The following part is taken from the DOMinatorPro user manual and shows a similar vulnerability in a demo context. In DOMinatorPro user manual you can find sample cases to help you understand the cause of the vulnerability for producing solid Javascript patches.

By the way, when browsing to a website with a vulnerable “Facebook - Like Button” with DOMinatorPro tool you will see in a couple of seconds the following alert:

From the previous screenshot the very interesting information is that you got an HTML Injection (e.g. Cross Site Scripting) from the location.href (e.g. the URL).
Important Note: Sink describes where the vulnerability is and the Source is where the controllable input comes from.
 
Summary of the issue: HTML injection vulnerability coming from a user supplied input location.href (URL). 

 Source History

Next step is to check where this issue has been found. This is easy, looking at the source history:

Exact location of the issue is: 

• http://www.vulnerablewebsite.con/webpage.aspx?menuid=3#injectedstring<>”’

Source history is a simplified call stack that shows the content of controllable strings.
Location.href can be controlled and the value is showed up in light green, after this string is concatenated with another string by left and by right.
As it is possible to see from the above picture, it’s also possible to check if there are validator functions in place by injecting HTML patterns after the # (hash); in this case I injected the pattern #injectedstring<>”’ after the vulnerable URL. Using the “Hash” sign is important because anything coming after it will not be sent to the server.
It’s possible to see from the last line that #injectedstring<>"' is not encoded (typical encoded string is in the form of: #injectedstring%3c%22%27).
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected DOM cross site scripting attack:
 
Standard HTML Injection Payload: 

• <img/src="aaa"/onerror="alert('DomXss Found!')">

Important Note: Thanks to DOMinatorPro Browser emulation feature we can mimic different browser insecure behaviors. This permits to show developers the vulnerability inside DOMinatorPro/Firefox, even if the previous exploit works only under Internet Explorer.

Call Stack 

Now for a developer it is time to open the “Call Stack”:

The Call Stack interactively shows where the vulnerability is with the correct line. It is possible to see “document.location.href” is not escaped properly.
It’s very important to output encode the value before it is displayed.

Fixing

Correct fixing at line 116:
•    Use the “encodeURIComponent()” function.

Temporary Patch for a Dom Xss 0day in Addthis.com Widgets

Note: Addthis.com fixed this issue yesterday 26/09/12 thanks to Addthis.com team for fixing it so rapidly!


Including a Javascript code in your homepage from another Website is a very common practice.

"Third party scripts are a hidden-potential security threat"

Addthis.com for example provides very useful scripts to help enhancing a website with the most used social media networks. From Wikipedia: “ AddThis is a widely used social bookmarking service that can be integrated into a website with the use of a web widget. Once it is added, visitors to the website can bookmark an item using a variety of services, such as Facebook, MySpace, Google Bookmarks, Pinterest, and Twitter.[2]”.

AddThis social plugins and analytics are used by "over 14 million sites worldwide” (2007).

You just need to “add this”:

There are many advantages in doing this:
•    code will be updated by the maintainer
•    bugs will be fixed silently
•    … many others

Unfortunately it also hides several drawbacks:

•    Security vulnerabilities in referenced scripts will affect your website

During the past year we analyzed many Javascript codes belonging to tracking cookies. Some of those analysis have been pretty interesting. During 2011 we reported for example several issues in Omniture Catalyst Javascript code, with documented proof of concept code (http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html)

The DomXss Vulnerability

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

More information about DomXss vulnerabilities can be found here:
•    https://www.owasp.org/index.php/DOM_Based_XSS
•    http://code.google.com/p/domxsswiki/wiki/Introduction

DomXss in Addthis.com Widgets

Details of the vulnerability have been temporarily omitted because the number of affected websites is huge. We did this for giving enough time to the vendor for fixing the issues (full details have been sent to support@addthis.com).

Note from 26/09: Investigating further, it seems that vulnerability is not always triggered; this may depends from the templates used
Note from 27/09: Details about the issue can be found here

• http://blog.mindedsecurity.com/2012/09/analysis-of-dom-xss-vulnerability-in.html

Vulnerability has been found using DominatorPro, our DomXss Analyzer. Dominator is an opensource project with several extensions (some of these are commercial) and can be downloaded for free at

• http://dominator.mindedsecurity.com

A temporary patch

You can make this temporary patch by configuration for protecting your website in the meantime that the vulnerable code will be fixed. Note: this patch is not for the vulnerability itself but will prevent it from being easily exploited.

To patch a vulnerable AddThis.com Widget manually populate the following property:

•    addthis:url

For more information visit:

• http://support.addthis.com/customer/portal/articles/381242-url-title

 

Example:

 
...
<div addthis:url="http://example.com" class="addthis_toolbox addthis_default_style" nbsp="nbsp"> 
...

If you don’t add this, you are potentially vulnerable. 

A Twitter DomXss, a wrong fix and something more

A Twitter DOM Xss

It seems that twitter new site, introduced some issue resulting in a worm exploiting a stored Xss.
They also added some new JavaScript in their pages which I casually saw while searching in the html for the worm payload.

The code was the following :

//<![CDATA[
(function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a;}})(window);
//]]>


Do you spot the issue?
It search for "#!" in the Url and assign the content after that to the window.location object. And it is present in (almost?) every page on twitter.com main site.

According to DOM Xss Wiki the location object is one of the first objects identified for being dangerous as it is both a source and a sink.

In fact the DOM Based Xss will be triggered by simply going to:

http://twitter.com/#!javascript:alert(document.domain);

as shown in the following screenshot:


Very simple and effective.
After spotting the issue, I sent an email to twitter warning them about it but not without apologizing for finding it in the middle of worm spreading.

The response was quite funny because, even if the issue was very straightforward, they cannot reproduce it because of safari antiXss filter.

Obviously I checked on every browser but Safari ... and guess what ? Safari blocked it! We'll talk about it later.

So I told them that it worked on Firefox, Chrome and Opera and after that they confirmed the issue, thanked me and so long. No more mails.

A Wrong Fix (To Replace or not to Replace )
Thanks Gaz for the title.

After some hours, I found the following fix:


var c = location.href.split("#!")[1];
if (c) {
window.location = c.replace(":", "");
} else {
return true;
}


What's wrong with that?

1. Data Validation. 'c' is not validated as directed, that means every character but ":" is allowed. Data validation is about limiting the set of every possible input to an expected subset. Question is do we need to allow everything but one char?
   
2. BlackListing. It is widely known that blacklisting could lead to bypasses if it is done loosely.
   
3. No output encoding is applied. Since location assignment calls the URL Parser the context is quite known and have it's own metacharacters and structure. encoding in the URLParser context is also known as URLEncoding.
   
4. The use of replace ... let's see the doc (ECMA Specification):

[...]
String.prototype.replace (searchValue, replaceValue)
[...]
If searchValue is not a regular expression, let searchString be ToString(searchValue) and search
string for the first occurrence of searchString. Let m be 0.
[...]

The analysis tells that the fix is wrong, and in fact is possible to bypass the replace by doubling the colon ':' char.

http://twitter.com/#!javascript::alert(document.domain);

See the '::' ?
The replace just deletes the first occurrence of ':' so we just add two ':'.
It has also the drawback to bypass several client side filters, Safari included.

So I wrote again to twitter:

Hey,
that is not correct!

(function(g){var
a=location.href.split("#!")[1];if(a){g.location=g.HBR=a.replace(":","");}})(window);

will allow:

twitter.com/#!javascript::alert(1)

see the :: ?
I'd suggest you to urlencode a
or
if it breaks things use a whitelist of allowed chars before going to assign a to the location.

Another fix could be using:
location.pathname=a
or
location.search=a

which at least let you stay on the same domain (not sure it works on every browser), but I don't know if it's ok for twitter.

It's not a easy task, as usual :)

Also, please, send me an email when the fix is done, cause I don't want to set a cron job to get when the fix is deployed.
...

This morning I found the following fix (no email from them though):

(function(g){
var a=location.href.split("#!")[1];
if(a){
g.location=g.HBR=a.replace(":","","g");
}
})(window);


Which resolves the multiple colons attack, but, IMHO, it is not really correct because of what I've said previously.


The Safari Filter Bypass (the something more part)

As a side consequence of the twitter DOM Xss I found myself playing with the Safari anti Xss filter.
It seems that it tries to find a match between the payload used in the assignment to location and the values in the Url in browser location bar.
After checking a bit in order to understand the behavior of the filter, I figured out that it urldecode the Url and then search for the pattern.
The problem comes because of that.
In fact since the + is replaced to a space character, then

twitter.com?#!javascript:1+alert(1)


becomes:

twitter.com?#!javascript:1 alert(1)

which obviously won't ever match the needle:

"javascript:1+alert(1)"


And there you have the bypass.


Update (24/09/2010)

Twitter finally set a working patch to the second wrong fix (see comments).

(function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a.replace(/:/gi,"");}})(window);


Still not the best,IMHO, but at least it works...well, until there will be a bypass.
Also, since the patch just blocks ':' still remains an arbitrary redirect issue.

twitter.com#!//attacker.ltd/with/a/page/similar/to/twitterlogin/page

Update (25/09/2010)

As it was to be expected, there is a bypass (already public) which works on IE8 (~26% market share).
I found it yesterday independently by Gareth Heyes and Yusuke Hasegawa and reported to Twitter security team.
The bypass takes advantage of the html entity version of ':' which is &#58; or &#x3a;.
Internet Explorer 8, unlikely other browsers, when finds an entity converts it to its original value when it is assigned to the location object.

location="&x#58;"

will let the browser to go to ':' and not to literally "&x58;"
So, when the patch tries to replace ':' to an empty value, it won't find it, but the assignment to the location will convert it again to a colon.


twitter.com#!javascript&x58;alert(1)

is still valid (not in blacklist).

Finally, after writing a new mail to twitter security team, they came with a good defensive patch:

(function(g){var a=location.href.split("#!")[1];if(a){window.location.hash = "";g.location.pathname = g.HBR = a;}})(window);

As I suggested in my first email.
What happens here is that the assignment is performed on the correct attribute (the pathname) so that it is parsed in the right context with no possible bypasses to force a new URI scheme.
Now everything *should* be really ok... well, if all browsers will behave in the right way!