THP Wisec USH DigitalBullets TheHackersPlace network
The WIse SECurity
.italian
.english
Wisec Home SecSearch Projects Papers Security Thoughts
 
News Search on Wisec
Google

Security Thoughts

[ Back ]

Monday, December 03, 2007, 21:21

ExploitMe Tools - A Little Warning

Few days ago two interesting new tools were released and donated to the sec-community, XSSMe and SQLiMe by Security Compass.
From securitcompass.com site:


XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site Scripting (XSS) vulnerabilities.
What is Exploit-Me?
A suite of Firefox web application security testing tools.
Exploit-Me tools are designed to be lightweight and easy to use.
Instead of using proxy tools like many web application testing tools, Exploit-Me integrates directly
with Firefox.

Ok. This is the good tale about it.

The problem is that XSSMe attack patterns use as external source www.securitycompass .com:

<SCRIPT a=">'>" SRC="http://www.securitycompass.com/xss.js">
</SCRIPT>

and this should not happen, or, at least XssMe should ask the user to change www.securitycompass.com to a custom server.
Why? Because if you're doing some Ethical Hacking activity using XssMe for automated testing, whenever the victim host would have a Xss, www.securitycompass.com web server would get a request like the following:

GET /xss.js HTTP/1.1
Host: www.securitycompass.com
User-Agent: Firefox/2.0.0.11
Connection: keep-alive
Referer: http://vi.ct.im/flawedPage.jsp

Do you see? The referrer header is a great resource for statistics, and supposing you're doing the testing under some NDA you're almost screwed.

So in order to resolve this issue, i exported the xss attacks to xml, replaced to my local server, deleted every pattern from the option dialog and imported the replaced xss.xml.
Even though I really think this was due to an oversight, if anyone intends to use XssMe, fix it by yourself, or use it at your own risk!

FAQ:
Q: Did you reported this issue to Security Compass?
A: Yes. They added a known issues link with the description of the problem.

Comments:

kuza55, Monday, December 03, 2007, 23:27

Yeah, I get paranoid about that, and unless its breaking a site I simply have referers disabled, just in case.

Have you played with the tool yet? I personally haven't had a chance to so I'm unsure how useful it is, so I have no view on it yet, but maybe you do?

 

Stefano, Monday, December 03, 2007, 23:59

Yes, disabling referrers could be a good choice, until sites check for them.
Paranoia is a virtue and everyone who understand information security has some level of it :)
My concern was more about people with a small quantity of paranoia. Just to tell them the story before it's too late ;)

I played a bit with it on a local scapegoat site and I think that XssMe could be a good start for this kind of tools/addon.
It's a bit slow, as it opens a new tab for each request, but considering that there's no FF extension for checking Xss I think it's worth trying it. Anyway I will keep using my standard armoury still for a while. :P

 

kuza55, Tuesday, December 04, 2007, 23:22

Ouch, 1 tab per request.....

I would have thought they'd just use the internal XHR object, and then just write it to an iframe or something similar if they wanted to do it by running the code.

On one hand, they shouldn't get any false positives, on the other I wonder how many "almost" XSS's it misses due to that, that were exploitable, but not with the exact strings the tool used.

 

Stefano, Wednesday, December 05, 2007, 00:11

agree, probably using iframe could get some false positive as it shares the same sandbox because of same origin policy.
But I think the solution would be easy:
just add a counter for each iframe and set/call a variable/function like varname_counter/xssed(counter).

> I wonder how many "almost" XSS's it misses due to that,
> that were exploitable, but not with the exact strings the tool used

:) yeh, the "almost" Xss are difficult to catch in an automated context. I would think about implementing one of all those similarity matching algorithms.

 

dan sinclair, Friday, December 07, 2007, 18:37

With the release of XSS-Me 0.2.1 we have corrected this issue of securitycompass.com being referenced in the default XSS string list.

For new installs of XSS-Me there will be no references to securitycompass.com in the XSS strings. (Installing an update or removing and re-installing won't remove the current strings as their remembered but fresh installs won't have the issue).

We have also provided an extended XSS string list on the website which has the strings that reference securitycompass.com. These can either be imported or edited and imported depending on your privacy requirements.

As to the suggestion to use an IFrame, the reason that multiple tabs was used was to make sure there weren't any 'not quite a browser' or funky JS/target attribute (which breaks the site out of frames) issues. The use of tabs costs more CPU and memory but avoids these types of issues.

 
Comments are disabled

Admin login | This weblog is from www.mylittlehomepage.net

Wisec is brought to you by...

Wisec is written and mantained by Stefano Di Paola.

Wisec uses open standards, including XHTML, CSS2, and XML-RPC.

All Rights Reserved 2004
All hosted messages and metadata are owned by their respective authors.