In fact my details got added  while back, however I haven’t had the time to update the blog.

The issue that got me on there was a cross site scripting issue (Self XSS in this case) in the invite functionality of Google Chat.

Google Chat is used throughout differing Google sites and all them looked like they were vulnerable; However upon checking the cookie returned it would seem that the issue lay not in the translation site or IGoogle as first thought but with GoogleUserContent which is not a site eligible for a reward.

I’d like to thank Adam Mein from the Google Security Team for all of his help and patience in the two and throw of helping to confirm and then assist in getting the issue fixed.

As everyone seems to like pictures I’ll link to a couple of them here

XSS 1

XSS 2

As for the arguments for and against paying for bugs. I’ve still not changed my stance, I’m all for it although my reasons have changed.

I have recently found a new bug in Chrome which would allowed an attacker to run injected code (Javascript / HTML / CSS etc read XSS) into any chrome browser upon visiting a site. One thing to note about this new issue is that this is not a site problem which is the case with virtually all normal XSS issues. In this case the issue is with  Chrome. I won’t go into the issue any more just now as it’s not yet fixed. however had I not already built up a relationship with Google I would most likely have gone to Tipping Point or other types of Bug Auction Sites.

So from my point and hopefully Google’s the program is a sucess due to the new relationships it creates between bug reporters and fixers.

Lastly here is a nice document from the Goggle security team talking about the success of the reward program.

Martin Hall

The Test Manager

Symantec 20 XSS issues

I have written a new tool called SubFinder (provisional name subject to change).

It does exactly as the name suggests. It will find Subdomains on any given host. It will do this via a few methods, first it will look in a couple of obvious places and then it will bruteforce the rest.

It will be released in the next couple of days.

I wanted to test it so I ran it against Symantec.com

I got over 200 subdomains found. (not all could be browsed, but loads were)

From the domain list I thought i would check some of them over for XSS issues. The reason that you will find more issues is because firstly these sub domains are usually used to host mini sites, or sub sites. When/If there is a code review then these can be missed.

Also SubDomains are more often than not coded by outsourced suppliers so even if Symantec had great processes in place (which they don’t) , there is a chance that the outsourced suppliers do not.

(1) symantecenterprise XSS

(2) Symantec Connect Search Feature XSS (IE Only?)

(3) https://et.symantec.com XSS (Fixed 17th November 2010?)

(4) http://maillist.entsupport.symantec.com XSS

(5) Bit of a strnge one this, if you go to https://renewalcenter.symantec.com/
and into the email box type
“><</div><script>alert(‘The TestManager SymanTec Xss SubFinderTest’)</script>
you should get an error which states invalid email address entered.
Now change the URL to
https://renewalcenter.symantec.com
and Bingo XSS (is it being stored? making it a sotred XSS
I don’t think so but not 100% sure) (Fixed 17th November 2010?)

(6) http://www.symantec.com/ XSS (IE browsers only?) (Fixed 17th November 2010?)

(7) open redirect to XSS – http://www.messagelabs.co.uk/ XSS – Seems to only work in Firefox?, and not in IE? (Fixed 17th November 2010?)

(8) http://www.symantec.com/ Connect Forward XSS IE only? (Fixed 17th November 2010?)

(9) https://symantecevents XSS
Site development on the above seems to have outsourced to
http://verite.com/our-work/by-client/client-focus/?client_id=2
I’m guessing all of their sites for symantec would be easy targets. (Fixed 17th November 2010?)

(10) http://seer.entsupport.symantec.com/ XSS

(11) http://aka-community.symantec.com

(12) https://careers.symantec.com/ XSS (may need to visit page twice as the
first time sets the cookie)

(13) https://chat.symantec.com XSS

(15) https://www4.symantec.com/ XSS

(16) http://seer.entsupport.symantec.com/ Navbar XSS

(17) Ouch Denial Of Service (DOS) via Bad Param Injection =
http://techcenter.symantec.com redirect to http://techcenter.symantec.com/ecampus/enterprise =
which works fine as do all other URLs on this techcenter subdomain.
However if I now use the url =
http://techcenter.symantec.com/ecampus/enterprise?cat=null&cmd=sc&courseNo=DP6000&EXValue=null&file=null&module&page=null&siteName=sena&type=g_
Then every url on that subdomain gets blown and the server responds with a http 500server error. This creates a Denial of Service on that Subdomain.

(18) http://cybercrimenews.norton.com XSS

(19) Every Symantec customer email address can be grabbed = http://bit.ly/91fZrT just change the id. you could start at 1 and work your way up. This is very easy to automate. looks like over 16 million potential email addresses?.

Nitro Security XSS

Again we come with another (XSS) Cross Site Scripting Bugs on another Security Site.

This time it is on the site of Nitro Security

Now what I find a little bit strange is that Nitro Security states that it has created and sells 3 products which can detect Cross Site Scripting issues on websites.

The issue on there site has been there for a while and one would have thoguht that the company would have run its own tools against its won site to make sure that all is secure.

Unlike other security sites such as Tennable / Nessus etc on Nitro there is no attempt made to protect the site from user created data injections.

And with that I give you Nitro Security XSS Issue.

Nitro Security XSS

The Test Manager Nessus Cross Site Scripting Error

Nessus is a product owned now by Tenable Network Security.

I had originally decided to do a month of Security Site Bugs as most security sites have a higher level of site protection and also they are more of a challenge for a researcher / tester to find bugs on, and lets face it a lot of us  do this for the challenge.

Due to the nature of the security business their sites are usually locked down fairly tight.

However you can still a good few issues here and there.

It would also seem that security sites are just as susceptible to code injections and other types of low hanging fruit.

and with that I give you

Tenable Network Security / Nessus – All your Base are Belong to Us.

Tenable / Nessus All Your Base

Bug Details as follows

Well the security isn’t that bad here, they do block a lot of tags, So this means No Script Tags , No Href tags, No Iframe or Frame Tags, No Img Tags,

So I had to get a little creative and hence you have the popular meme of “all your base”

this is done by firstly a Heading Tag which is not blocked and then I’m allowed to use Div Tags and Object Tags, oh year and I’m also allowed to close the TextArea Tag.

Once I worked out what I could use I put it all together see below for the injection.

</TEXTAREA><div><h1>The Test Manager Month Of Security Site Bugs</h1><object width=”480″ height=”385″><param name=”movie” value=”http://www.youtube.com/v/8fvTxv46ano&amp;hl=en_GB&amp;fs=1″></param><param name=”allowFullScreen” value=”true”></param><param name=”allowscriptaccess” value=”always”></param><embed src=”http://www.youtube.com/v/8fvTxv46ano&amp;hl=en_GB&amp;fs=1″ type=”application/x-shockwave-flash” allowscriptaccess=”always” allowfullscreen=”true” width=”480″ height=”385″></embed></object></div>

Now this is just a bit of fun rather than a fully exploitable bug.  The reason is that I could not get it to work from the URL.

To get the XSS to work you firstly need to have an item in your shopping cart and then checkout.

Then once your on the

https://products.nessus.org/one-page-checkout.asp page

there is a payment information box. Just put your code into that box and checkout. No need to fill in the rest of the form boxes the injection works when the form reloads.

Enjoy.

Martin H

The Test Manager.

I remembered that I had found a similar issue a while back and hadn’t got round to disclosing it to them, so I therefore guess its fine to include in the month of full disclosure.

And with that I give you a new Symantec XSS bug.

Symantec XSS

Notes about the bug are as follows.

the issue is caused by Symantec not checking that html comments cannot be ended via user input. So all I had to do was to close the HMTL comment tag and then insert any code I saw fit. In this case a very simple JavaScript Alert box as is the norm with demonstrating XSS bugs and I also added a little Iframe.

Liggat Authentication Fail

This post will be a disclosure on how to not design and implement a login processes.

Ligatt Security and Gregory Evans the main man behind Ligatt has come under quite a bit of flack recently for doing things like alegedly making threats to other researchers and also for alleged plagiarism .

While all of this Internal Security Industry bickering is beyond me and this post.  I would not trust a company with protecting my data if they can’t even protect their own.

And with that said.  / Month Of Full Disclosure item 3 = Ligatt Security and how not to write an Authentication Process.

Text Version Here

Ligatt Authentication_ByPass

Show me where that PC is

Month Of Full Disclosure

1-Click Retweet/Share/Like Lets users Retweet, Share and Like pages from your site back to their Twitter followers and Facebook friends with just one click. The user experience is similar to Facebook Like button but expanded to Twitter and Facebook Share.
The above WordPress Plugin has multiple Cross Site Scripting (XSS) Bugs due to the “fc” the “fs” and also the “fblname” Parameters not correclty sanitising data input

This was discovered in a routine security check on my own site, where up until yesterday I was like hundreds of other wordpress sites running the above plugin.

The plugin does not integrate whoely with the worpress blog and instead it calls home via an IFrame which is where the XSS hole exists.

Every site which has this plugin would therefore call the vunerable URL however that URL due to being an Iframe exists on the vendors site. (http://www.linksalpha.com)

This mitigates the risk of the WordPress Plugin against the site hosting it. However due to poularity of the plugin, it is deemed still to be a medium risk issue. Plus the fact that there may and most likely are other issues with the plugin which I have not taken the time to research.

See below for the disclosure.

Text Version Here

XSS vulnerability in Links Alpha WordPress Plugin
————————————-
Vulnerability ID: Month Of Full Disclosure = MOFD2
————————————
Product:    1-click Retweet/Share/Like
————————————-
Vendor:    Links Alpha ( http://wordpress.org/extend/plugins/1-click-retweetsharelike/stats/
or http://www.linksalpha.com/)
————————————-
Vulnerable Version:    2.0.1 Which is current version and Probably Prior Versions
————————————-
Vendor Notification:    03 August 2010
Public Disclosure:    03 August 2010
————————————-
Vulnerability Type:    XSS (Cross Site Scripting)
————————————-
Status:    Public Disclosure – Not Fixed, Vendor Alerted,
Awaiting Vendor Response
————————————-
Risk level:    Medium
————————————-
Credit:    Martin Hall – TheTestManager
Site = http://www.thetestmanager.com
twitter = @thetestmanager
Vulnerability Details:
There exists multiple XSS errors in 1-click Retweet/Share/Like WordPress Plugin.
————————————-
Potential Users Affected = minimum = ??? users
It’s a WordPress Plugin which is installed to sites on average 300-400 times a week
————————————-
Dork to find Vulnerable Sites (2)
inurl:http://www.linksalpha.com/social?link=
or
src=”http://www.linksalpha.com/social?link=
Because it loads on sites in an Iframe the dork is not straight forward.
————————————-
Sample URL
http://www.linksalpha.com/social?link=http%3A%2F%2Fsimplestrength.com%2F2010%2F06%2Fwarriors-come-out-to-play%2F&fc=28a2ttm–%22%3E%3Cscript%3Ealert%28%22TheTestManager.com-%20Month%20of%20Full%20disclosure%22%29%3C/script%3E&fs=arial&fblname=like
————————————-
Solution:
Currently I’m not aware of any vendor-supplied patches or other solutions.
If you are aware of more recent information related to this issue please notify me at: martin@hb-help.com

Users are recommended to use NoScript or other XSS mitigating software
Admins are adviced to keep an eye out for an update to the plugin.
(Although as the issues affects code on LinksAlpha Site they should be able to fix the issue without a WordPress Plugin Update)
————————————-
Other Miscellany Information
N/A

The Test Manager

***EDIT***

I received notification from FuseTalk that the below issues should now be fixed on their site. This should mean that patch should be rolled out to customer sites in the near future.

With this in mind I have agreed to their request to remove references to the names of their customers from my post.

***END EDIT***

Fuse Talk is a forum software widely used on the web.

Yesterday I found multiple XSS holes while browsing the ******* Forum site.

******* uses FuseTalk as it’s forum software.

Now there are a few strange things  here.

Firstly ******* is a security firm and you would have thought that they would have picked this up, or at least carried out a review of any software before adding it to their site.  The other strange issue is that the software vendor FuseTalk is not even running the latest version of the software on their own site.

Anyway see below for the disclosure.

Text Version Here

XSS vulnerability in FuseTalk Forums
————————————-
Vulnerability ID: Month Of Full Disclosure 1 = MOFD1
————————————
Product:    FuseTalk
————————————-
Vendor:    FuseTalk Inc

( http://www.fusetalk.com/Company/AboutFuseTalk/tabid/111/Default.aspx )
————————————-
Vulnerable Version:    4.0 Which is current version and Probably Prior Versions
————————————-
Vendor Notification:    02 August 2010
Public Disclosure:    02 August 2010
————————————-
Vulnerability Type:    XSS (Cross Site Scripting)
————————————-
Status:    Public Disclosure – Not Fixed, Vendor Alerted,
Awaiting Vendor Response
————————————-
Risk level:    Medium
————————————-
Credit:    Martin Hall – TheTestManager
Site = http://www.thetestmanager.com
twitter = @thetestmanager
Vulnerability Details:
There exists multiple XSS errors in FuseTalk Forums.
These errors exist even months/years after previous XSS HTML /SQL injection
errors were reported to FuseTalk.
It is time for a full and through source code review guys.
————————————-
Potential Users Affected = minimum = 250,000 users
******* = 5664 Users
FuseTalk forums = 11357 Users
*** = 103488 users
*** **** = 43767 users
******.com = 79718 users
**********.com = 31396 users
********.com = 23033 users
————————————-
Dork to find Vulnerable Sites (1)
fusetalk “users are registered”
Dork to find Vulnerable Sites (2)
© 1999-2010 FuseTalk Inc. All rights reserved.
————————————-
Sample URL’s
http://forums.fusetalk.com/usersearchresults.cfm?keyword=ttm–” ><script>alert(‘TheTestManager.com- Month of Full disclosure’)</script>&FT_ACTION=SearchUsers – (Tested in IE8)

http://supportforums.*******.com/categories.aspx?catid=76&FTVAR_SORT=date&FTVAR_SORTORDER=0017ttm-” style=x:expression(alert(“TheTestManager”)) ttm=” (Tested in IE7)

————————————-
Solution:
Currently I’m not aware of any vendor-supplied patches or other solutions.
If you are aware of more recent information related to this issue please notify me at: martin@hb-help.com

Users are recommended to use NoScript or other XSS mitigating software
Admins are advised to change forum software, or put pressure on FuseTalk to carry out a full source code review.
————————————-
Other Miscellany Information
http://www.fusetalk.com/ProductsServices/FuseTalk/WhosUsingFuseTalk/tabid/72/Default.aspx
Sample URL’s

Month of Full Disclosure

As the main title of this post states, August 2010 will be a full disclosure month.

Normally within a month I may talk to around 20 or so organisations advising them of general bugs and security issues within their products or websites. The number varies as I do this as a hobby and not a full time job.

My main job is as a Systems Test Manager.

So I decided to see what happens if I take a month out from doing things the normal way of disclosing all issues to the site or software house first and only when fixes place advising the users.  So for August only I’ll be advising the public at the same time as advising the site / or software house involved.

All issues discovered before the month of August and any that are currently being discussed with sites or software houses are not included and will remain closed for public consumption until the issue is fixed and even then only if the company involves gives permission.

I doubt if any humdingers will come out but you never know

If any issues are found which could affect a very high number of users data at risk then I will revert to responsible disclosure, and give the vendor time to fix the issue.

Martin Hall

This post is password protected. To view it please enter your password below:

Password: