Message-ID: <CA+CewVCPRXMtoAgu7QeLd6K25gTdZtWD-MVX+zWFj3SosmswFw@mail.gmail.com>
Date: Fri, 14 Mar 2014 14:16:38 +0000
From: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
To: "Sergio 'shadown' Alvarez" <shadown@...il.com>,
 full-disclosure@...ts.grok.org.uk
Subject: Fwd:  Google vulnerabilities with PoC

Go to sleep.
---------- Forwarded message ----------
From: Nicholas Lemonias. <lem.nikolas@...glemail.com>
Date: Fri, Mar 14, 2014 at 2:16 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Sergio 'shadown' Alvarez <shadown@...il.com>


Go to sleep....


On Fri, Mar 14, 2014 at 1:50 PM, Sergio 'shadown' Alvarez <shadown@...il.com
> wrote:

> Dear Nicholas Lemonias,
>
> I don't use to get in these scrapy discussions, but yeah you are in a
> completetly different level if you compare yourself with Mario.
> You are definitely a Web app/metasploit-user guy and pick up a discussion
> with a binary and memory corruption ninja exploit writter like Mario. You
> should know your place and shut up. Period.
>
> Btw, if you dare discussing with a beast like lcamtuf, you are definitely
> out of your mind.
>
> Cheers,
>   Sergio.
> -- Sergio
>
>
> On Mar 14, 2014, "Nicholas Lemonias." <lem.nikolas@...glemail.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 <mvilas@...il.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.nikolas@...glemail.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.nikolas@...glemail.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 <athiasjerome@...il.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 <lcamtuf@...edump.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/
>>>
>>
>>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists