tag:blogger.com,1999:blog-13756280.post4711866998525574905..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Full-Disclosure, Our TurnJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-13756280.post-60368563918500435552010-07-12T11:18:17.464-07:002010-07-12T11:18:17.464-07:00In response to TestManager for this: >> Anyo...In response to TestManager for this: >> Anyone disclosing issues to ....<br /><br />What you're doing will definitely trigger you a trouble. You'll never end up saving the vulnerable sites with your effort alone. They're being created daily. Whether they have vulnerabilities or not is not your matter. Whether they listen to your reported things is not your matter. <br />I'm glad you have such good mind to tell them. Think again. Save your time and learn by doing legal pentests.l444t43http://yehg.netnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-76865007198856521092010-07-05T06:59:13.724-07:002010-07-05T06:59:13.724-07:00@Alex: Yes perhaps it was illegal under the UK law...@Alex: Yes perhaps it was illegal under the UK law, but I also believe the law would be wrong, totally counter productive, and want no part of it. Remember Daniel Cuthbert? That law was applied to him and was completely uncalled, but beyond that had a chilling affect on the rest of the industry. No thanks.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-34630660760506657642010-07-05T01:13:43.472-07:002010-07-05T01:13:43.472-07:00You take a benign attitude to the actions of TheTe...You take a benign attitude to the actions of TheTestManager. However, you could certainly argue, that if (s)he had done the same thing in the UK, he would be in breach of the UK Computer Misuse Act*. He could then be looking at two years "doing porridge" as we say in the old world. <br /><br /><br />*http://p10.hostingprod.com/@spyblog.org.uk/blog/2008/09/computer-misuse-act-amendments-come-into-force-on-1st-october-2008.htmlAlexisnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-36565604387268909542010-07-01T14:59:18.716-07:002010-07-01T14:59:18.716-07:00I'd like to once again say thank you very much...I'd like to once again say thank you very much to everyone for the overwhelmingly positive response. We really didn't know what the reaction would be to the foible. It's extremely encouraging to know the security industry truly values and respects honest and transparency.<br /><br />@shiflett: Nice, honest post from @jeremiahg showing how XSS can get you, even if you know all about it: http://j.mp/whitehatxss<br /><br />@mkoelm: RT @seccubus: RT @security4all: "Full-Disclosure, Our Turn" - http://is.gd/d96rl (via @jeremiahg) -> respect for being honest!! <- hear hear<br /><br />@fabriciobraz: Very nice way to face any fault, including security RT @jeremiahg: "Full-Disclosure, Our Turn" - http://is.gd/d96rlJeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-58590427069513456482010-06-30T11:35:53.537-07:002010-06-30T11:35:53.537-07:00What I liked best was your very thorough root caus...What I liked best was your very thorough root cause analysis. I think that piece is the most overlooked part of vulnerability response in the industry. Bravo!dunsanyhttp://www.planetheidi.comnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-54602932877466154592010-06-30T06:14:57.950-07:002010-06-30T06:14:57.950-07:00@Adam, not at all, these are the right questions t...@Adam, not at all, these are the right questions to ask, we're doing the same internally. <br /><br />Since there were "no web applications," there was little need for a WAF. Even still given this was a DOM-based XSS, its not guaranteed it would have detected/stopped it anyway. One of the things I'm needing to double-check on. <br /><br />With respect to log management, we have that in place as other monitoring tools. However, we get attacked with ruthless regularity. The bad guys, researchers, partners, competitors, customers, us... are constantly probing our systems. In the case of XSS for example, its very difficult to know when one of the thousands of "tests" per day was actually successful.<br /><br /><br />@Anonymous3 not sure, is this in context to the current blog post? We do scan the website with a web application scanner every day, but for reasons I explained in the post, it wasn't found.<br /><br />@TheTestManager, I said it in the post! And we thought the site WAS static, well it is static! Sort of . :) Thanks for the kind words. It was disappointing to think that this was something that we should have, could have, found. It does serve as a good reminder that we, especially us, need to be ever vigilant.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-77726220550404840292010-06-30T04:02:55.767-07:002010-06-30T04:02:55.767-07:00what Jeremiah hasn't said is that the speed in...what Jeremiah hasn't said is that the speed in which the issue was fixed was quite amazing about 15-20 minutes maximum. <br /><br />I actually found the issue a few days before posting it when Jeremiah had retweeted about some other security firms having xss issues.<br /><br />Like I said in my original post, it was not meant as poke at either Jerrmiah or WhitehatSec whom along with a few other select security researchers I really look upto, and always look forward to reading their work.<br /><br />I would normally have disclosed in private manner as I do virtually every day with numerous issues found in multiple different places. <br />Any disclosure may open you to legal action, if you have tampered with either the URL or the rendering of the page in anyway, so disclosing either privately or publicly is always walking a tightrope<br />Looking back on it now I wish that I had done it in a private and therefore more responsible way. However what is done is done. <br /><br />Anyone disclosing issues to companies will know by experience that usually you are either ignored and the issue is left outstanding, or you are still ignored and the issue is fixed in quiet fashion without you ever being informed. <br />Rarely you are thanked or even acknowledged, only the rare 5%-10% or so of businesses will want to discuss the issue further. <br /><br />Some people think that Cross Site scripting or other security based issues existing on a security site is a crime, <br /><br />However in the case of XSS, it exists in virtually every site, unless your using flat static content. The escaping out of tags is childs play and the actual bypassing of many XSS blockers or Anti XSS whitelists is again just a matter of trial and error. <br /><br />The main point of the post is that I wanted to state throughout the whole process from Jeremiah reading my tweet disclosing the issue to this blog post he has been nothing but open, and I think that should be commended. <br />We could do with more vendors like thisTheTestManagerhttp://www.thetestmanager.comnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-87975137442342200832010-06-30T01:57:05.534-07:002010-06-30T01:57:05.534-07:00I'm wondering why the session fixation is more...I'm wondering why the session fixation is more important than a XSS for the most of companies which are not even using HTTPOnly flags! :D<br />---------<br />PS: Why don't you use a web application scanner to scan your website each month? At least you can find the obvious vulnerabilities with it ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-41823091697575876732010-06-29T22:31:01.542-07:002010-06-29T22:31:01.542-07:00This is not meant to be a poke, but where is the W...This is not meant to be a poke, but where is the WAF in all of this or the log monitoring that may have identified this before it went to a full disclosure situation? If one simply relies on assessments and disclosure for protection isn't there a large gap in there?Adam Baldwinhttp://ngenuity-is.comnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-61575237862686749462010-06-29T17:32:04.304-07:002010-06-29T17:32:04.304-07:00@Mephisto, thank you for the kind words. For our p...@Mephisto, thank you for the kind words. For our part, whether or not the disclosure process was appropriate, @testmanager didn't introduce the XSS vulnerability, we did. Fix it, learn from it, and figure out how to do better. We tell our customers to do the same, and they expect nothing less from us.<br /><br />@Anonymous1, if only that were the case. :)<br /><br />@Question, that certainly fits within the requirements of our policy. Some website however have a business requirement to be vulnerable, persistent XSS. LOL.<br /><br /><br />@Anonymous2, good catch, I should have been more clear with "web-form log-in", which is what I had in mind. The partner portal is essentially a dropbox for a variety marketing literature (pdf, docs, xls, ppts) we make available to our resellers. While nothing in it is really "sensitive", we prefer it wasn't openly indexed by the search engines. We didn't need anything stronger than basic-auth over plain HTTP, such as more Web app code to look after potentially reducing our security posture, to protect such data.<br /><br />Secondly, as you've noticed, there are a few minor issues around that should be cleaned up. We've been in the process of doing exactly that. This experience was a subtle reminder of not to be comfortable for even a moment.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-91205078267109908462010-06-29T16:48:14.413-07:002010-06-29T16:48:14.413-07:00No login page? What's this I see? A login pag...No login page? What's this I see? A login page protected by Basic Authentication over HTTP? ServerTokens Full?<br /><br />I see a lot more wrong with this picture than just a simple "process oversight".<br /><br />$ curl -i http://www.whitehatsec.com/home/partnerportal/index.html<br />HTTP/1.1 401 Authorization Required<br />Server: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g<br />WWW-Authenticate: Basic realm="Partner Portal"Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-43494850093990934382010-06-29T16:20:57.640-07:002010-06-29T16:20:57.640-07:00@Anonymous cookie/credential theft is not the only...@Anonymous cookie/credential theft is not the only thing you can do with XSS. Think about defacement and/or redirection to malicious sites serving malware or fake AV.<br /><br />All XSS should be fixed on any site, regardless of the original content, function, intent, etc of the original site.Unknownhttps://www.blogger.com/profile/00871987829443702456noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-74059171837146791612010-06-29T15:33:16.767-07:002010-06-29T15:33:16.767-07:00Surely XSS is no threat in a site that doesn't...Surely XSS is no threat in a site that doesn't have a login system.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-22121809498386638482010-06-29T15:09:53.870-07:002010-06-29T15:09:53.870-07:00If only all companies were as open and honest abou...If only all companies were as open and honest about their issues. You're completely right, no company is perfect and try as we might to prevent these types of attacks business requirements can, and obviously do, occasionally open us up to attack. I agree private disclosure would have been more appropriate, but as you said, at least @testmanager brought it out in the open so it could be addressed and remediated in a timely manner.S3Jensenhttps://www.blogger.com/profile/06169833355986909704noreply@blogger.com