Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

[Thomas MacKenzie]

You have a Googlemail account. How do we know you don't work for Google too... Inception type stuff going on here. Nicholas Lemonias. 14 March 2014 18:17 Google is a great service, but according to our proof of concepts (images, poc's, codes) presented to Softpedia, and verified by a couple of recognised experts including OWASP - that was a serious vulnerability.   Now you can say whatever you like, and argue about it. You can argue about the impact and whatsoever , but that's not the way to deal with security issues.  _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Nicholas Lemonias. 14 March 2014 18:16 Google is a great service, but according to our proof of concepts (images, poc's, codes) presented to Softpedia, and verified by a couple of recognised experts including OWASP - that was a serious vulnerability.   Now you can say whatever you like, and argue about it. You can argue about the impact and whatsoever , but that's not the way to deal with security issues.      _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Nicholas Lemonias. 14 March 2014 18:13 Security vulnerabilities need to be published and reported. That's the spirit.   Attacking the researcher, won't make it go away. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Mario Vilas 14 March 2014 15:55 On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <lem.niko...@googlemail.com> wrote: Jerome of Mcafee has made a very valid point on revisiting  separation of duties in this security instance.   Happy to see more professionals with some skills.  Some others have also mentioned the feasibility for Denial of Service attacks. Remote code execution by Social Engineering is also a prominent scenario. Actually, people have been pointing out exactly the opposite. But if you insist on believing you can DoS an EC2 by uploading files, good luck to you then...     If you can't tell that that is a vulnerability (probably coming from a bunch of CEH's), I feel sorry for those consultants. You're the only one throwing around certifications here. I can no longer tell if you're being serious or this is a massive prank.     Nicholas. On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias. <lem.niko...@googlemail.com> wrote: We are on a different level perhaps. We do certainly disagree on those points. I wouldn't hire you as a consultant, if you can't tell if that is a valid vulnerability..     Best Regards, Nicholas Lemonias.   On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas <mvi...@gmail.com> wrote: But do you have all the required EH certifications? Try this one from the Institute for  Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. <lem.niko...@googlemail.com> wrote: Thanks Michal,   We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time.    We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct.   Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. <lem.niko...@googlemail.com> wrote: Hi Jerome,   Thank you for agreeing on access control, and separation of duties.   However successful exploitation permits arbitrary write() of any file of choice.   I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job.    On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias <athiasjer...@gmail.com> wrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski <lcam...@coredump.cx>: > Nicholas, > > I remember my early years in the infosec community - and sadly, so do > some of the more seasoned readers of this list :-) Back then, I > thought that the only thing that mattered is the ability to find bugs. > But after some 18 years in the industry, I now know that there's an > even more important and elusive skill. > > That skill boils down to having a robust mental model of what > constitutes a security flaw - and being able to explain your thinking > to others in a precise and internally consistent manner that convinces > others to act. We need this because the security of a system can't be > usefully described using abstract terms: even the academic definitions > ultimately boil down to saying "the system is secure if it doesn't do > the things we *really* don't want it to do". > > In this spirit, the term "vulnerability" is generally reserved for > behaviors that meet all of the following criteria: > > 1) The behavior must have negative consequences for at least one of > the legitimate stakeholders (users, service owners, etc), > > 2) The consequences must be widely seen as unexpected and unacceptable, > > 3) There must be a realistic chance of such a negative outcome, > > 4) The behavior must introduce substantial new risks that go beyond > the previously accepted trade-offs. > > If we don't have that, we usually don't have a case, no matter how > clever the bug is. > > Cheers (and happy hunting!), > /mz > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Nicholas Lemonias. 14 March 2014 11:38 Jerome of Mcafee has made a very valid point on revisiting  separation of duties in this security instance.   Happy to see more professionals with some skills.  Some others have also mentioned the feasibility for Denial of Service attacks. Remote code execution by Social Engineering is also a prominent scenario.   If you can't tell that that is a vulnerability (probably coming from a bunch of CEH's), I feel sorry for those consultants.   Nicholas. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/