Mailing List Archive

Fwd: Google vulnerabilities with PoC
Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you
may, or may not be qualified to question amazes. But everyone's opinion is
of course respected.

I normally don't provide security lessons via e-mail and full-disclosure,
however you seem not to understand the security report fully and some core
principles. If you can't see what information security best practises, the
OSI/network model and self-automata propagation has anything to do with
arbitrary write permissions to a remote network leveraging from the
application layer, then me and you have nothing to talk about.

As for the exploitability of this vulnerability, you will never know until
you try. And we have tried it , and seem to know better.

I suggest you read the report again.

Thank you.


---------- Forwarded message ----------
From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
Date: Thu, Mar 13, 2014 at 7:47 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Julius Kivimäki <julius.kivimaki@gmail.com>


Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you
may, or may not be qualified to question amazes. But everyone's opinion is
of course respected.

I normally don't provide security lessons via e-mail and full-disclosure,
however you seem not to understand the security report fully and some core
principles. If you can't see what information security best practises, the
OSI/network model and self-automata propagation has anything to do with
arbitrary write permissions to a remote network leveraging from the
application layer, then me and you have nothing to talk about.

As for the exploitability of this vulnerability, you will never know until
you try. And we have tried it , and seem to know better.

I suggest you read the report again.

Thank you.



On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki
<julius.kivimaki@gmail.com>wrote:

> I don't see what OSI model has to do with anything here. Why is arbitrary
> file upload to youtube CDN any worse than to google drive CDN? And how will
> your "self-executing encrypted virus like Cryptolocker" end up getting
> executed anyways? And cryptolocker was definitely not "self-executing", but
> spread via email attachments (excluding the boring USB spread
> functionality).
>
> What you have here is not a vulnerability, just give up. And stop trying
> to get "journalists" like Eduard Kovacs to spread your BS.
>
> 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> Hello Julius,
>>
>> I appreciate your interest to learn more. OWASP is quite credible, and
>> has gained some international recognition. It is a benchmark for many
>> vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
>> uploads of certain file types for security reasons, and let's assume at the
>> application layer. If we manage to get past the security controls, that
>> means we can write unrestrictedly any type of file to the remote network.
>> That also means that we get past their firewall, since the communication is
>> through HTTP (port 80). CDN nodes are deployed to multiple colocation
>> (thousands of nodes and thousands of servers across the world). The files
>> (let's say a self-executing encrypted virus like Cryptolocker? ) are cached
>> deeply in the network across thousands of servers.
>>
>>
>> On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> Hello Julius,
>>>
>>> I appreciate your interest to learn more. OWASP is quite credible, and
>>> has gained some international recognition. It is a benchmark for many
>>> vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
>>> uploads of certain file types for security reasons, and let's assume at the
>>> application layer. If we manage to get past the security controls, that
>>> means we can write unrestrictedly any type of file to the remote network.
>>> That also means that we get past their firewall, since the communication is
>>> through HTTP (port 80). CDN nodes are deployed to multiple colocation
>>> (thousands of nodes and thousands of servers across the world). The files
>>> are cached deep in the network structures to thousands of servers.
>>>
>>>
>>> On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki <
>>> julius.kivimaki@gmail.com> wrote:
>>>
>>>> OWASP is recognized worldwide, so is CEH and a bunch of other morons.
>>>> That doesn't mean their publications are worth anything. Now tell me, why
>>>> would arbitrary file upload on a CDN lead to code execution (Besides for
>>>> HTML, which you have been unable to confirm)?
>>>>
>>>>
>>>> 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com>:
>>>>
>>>> *You are wrong about accessing the files. What has not been confirmed
>>>>> is remote code execution. We are working on it.*
>>>>> *And please, OWASP is recognised worldwide... *
>>>>>
>>>>> *Files can be accessed through Google Take out with a little bit of
>>>>> skills.*
>>>>>
>>>>> *https://www.google.com/settings/takeout
>>>>> <https://www.google.com/settings/takeout> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki <
>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>
>>>>>> Did you even read that article? (Not that OWASP has any sort of
>>>>>> credibility anyways). From what I saw in your previous post you are both
>>>>>> unable to execute the files or even access them and thus unable to
>>>>>> manipulate the content-type the files are returned with, therefore there is
>>>>>> no vulnerability (According to the article you linked.).
>>>>>>
>>>>>> BTW, you should look for more cool vulnerabilities in amazons EC2,
>>>>>> I'm sure you will find some "Unrestricted File Upload" holes.
>>>>>>
>>>>>>
>>>>>> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <
>>>>>> lem.nikolas@googlemail.com>:
>>>>>>
>>>>>> Here is your answer.
>>>>>>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>>>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>>>
>>>>>>>> When did the ability to upload files of arbitrary types become a
>>>>>>>> security issue? If the file doesn't get executed, it's really not a
>>>>>>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>>>>>>> lem.nikolas@googlemail.com>:
>>>>>>>>
>>>>>>>>> Google vulnerabilities uncovered...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Fwd: Google vulnerabilities with PoC [ In reply to ]
Go to sleep.
---------- Forwarded message ----------
From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
Date: Fri, Mar 14, 2014 at 2:16 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Sergio 'shadown' Alvarez <shadown@gmail.com>


Go to sleep....


On Fri, Mar 14, 2014 at 1:50 PM, Sergio 'shadown' Alvarez <shadown@gmail.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@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 <mvilas@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.nikolas@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.nikolas@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 <athiasjerome@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 <lcamtuf@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/
>>>
>>
>>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
I will, it's late here, but I'm enjoying the show way too much. xD

Instead of discussing why don't you show a client side attack with that thing that you call a vulnerability and make every one shut up?, oh wait...because you can't! ;-)

"A fail has thousand excuses, but success doesn't require any explaination".

In this context a working client side exploit or a Server Shell proof is a success, any other thing is crap.

Talking, complaining and showing certification don't work against a computer, a working exploit that gives you a shell does.

Cheers,
-- Sergio

On Mar 14, 2014, "Nicholas Lemonias." <lem.nikolas@googlemail.com> wrote:
>Go to sleep.
>---------- Forwarded message ----------
>From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>Date: Fri, Mar 14, 2014 at 2:16 PM
>Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>To: Sergio 'shadown' Alvarez <shadown@gmail.com>
>
>
>Go to sleep....
>
>
>On Fri, Mar 14, 2014 at 1:50 PM, Sergio 'shadown' Alvarez
><shadown@gmail.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@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 <mvilas@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.nikolas@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.nikolas@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
><athiasjerome@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 <lcamtuf@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/
>>>>
>>>
>>>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Enough with this thread.


On Fri, Mar 14, 2014 at 2:37 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> I am too buy researching satellite security. Been doing that since the
> times of TESO, probably before you were born.
>
> Have a good night's sleep.
>
>
> On Fri, Mar 14, 2014 at 2:33 PM, Sergio 'shadown' Alvarez <
> shadown@gmail.com> wrote:
>
>> I will, it's late here, but I'm enjoying the show way too much. xD
>>
>> Instead of discussing why don't you show a client side attack with that
>> thing that you call a vulnerability and make every one shut up?, oh
>> wait...because you can't! ;-)
>>
>> "A fail has thousand excuses, but success doesn't require any
>> explaination".
>>
>> In this context a working client side exploit or a Server Shell proof is
>> a success, any other thing is crap.
>>
>> Talking, complaining and showing certification don't work against a
>> computer, a working exploit that gives you a shell does.
>>
>> Cheers,
>>
>> -- Sergio
>>
>> On Mar 14, 2014, "Nicholas Lemonias." <lem.nikolas@googlemail.com> wrote:
>>>
>>>
>>> Go to sleep.
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 2:16 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Sergio 'shadown' Alvarez <shadown@gmail.com>
>>>
>>>
>>> Go to sleep....
>>>
>>>
>>> On Fri, Mar 14, 2014 at 1:50 PM, Sergio 'shadown' Alvarez <
>>> shadown@gmail.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@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Fwd: Google vulnerabilities with PoC [ In reply to ]
People can read the report if they like. Can't you even do basic things
like reading a vulnerability report?

Can't you see that the advisory is about writing arbitrary files. If I was
your boss I would fire you.
---------- Forwarded message ----------
From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
Date: Fri, Mar 14, 2014 at 5:43 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Mario Vilas <mvilas@gmail.com>


People can read the report if they like. Can't you even do basic things
like reading a vulnerability report?

Can't you see that the advisory is about writing arbitrary files. If I was
your boss I would fire you, with a good kick outta the door.






On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:

> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>> athiasjerome@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 <lcamtuf@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."
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
LOL you're hopeless.
Good luck with your business. Brave customers!

Cheers
antisnatchor

Nicholas Lemonias. wrote:
>
> People can read the report if they like. Can't you even do basic
> things like reading a vulnerability report?
>
> Can't you see that the advisory is about writing arbitrary files. If I
> was your boss I would fire you.
> ---------- Forwarded message ----------
> From: *Nicholas Lemonias.* <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>>
> Date: Fri, Mar 14, 2014 at 5:43 PM
> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
> To: Mario Vilas <mvilas@gmail.com <mailto:mvilas@gmail.com>>
>
>
> People can read the report if they like. Can't you even do basic
> things like reading a vulnerability report?
>
> Can't you see that the advisory is about writing arbitrary files. If I
> was your boss I would fire you, with a good kick outta the door.
>
>
>
>
>
>
> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com
> <mailto:mvilas@gmail.com>> wrote:
>
> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com <mailto:lem.nikolas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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
> <mvilas@gmail.com <mailto:mvilas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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
> <athiasjerome@gmail.com
> <mailto:athiasjerome@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
> <lcamtuf@coredump.cx
> <mailto:lcamtuf@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/

--
Cheers
Michele
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
The full-disclosure mailing list has really changed. It's full of lamers
nowdays aiming high.





On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> Says the script kiddie... Beg for some publicity. My customers are FTSE
> 100.
>
> ---------- Forwarded message ----------
> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
> Date: Fri, Mar 14, 2014 at 5:58 PM
> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
> To: antisnatchor <antisnatchor@gmail.com>
>
>
> Says the script kiddie... Beg for some publicity. My customers are FTSE
> 100.
>
>
>
>
> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>
>> LOL you're hopeless.
>> Good luck with your business. Brave customers!
>>
>> Cheers
>> antisnatchor
>>
>> Nicholas Lemonias. wrote:
>>
>>
>> People can read the report if they like. Can't you even do basic things
>> like reading a vulnerability report?
>>
>> Can't you see that the advisory is about writing arbitrary files. If I
>> was your boss I would fire you.
>> ---------- Forwarded message ----------
>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> Date: Fri, Mar 14, 2014 at 5:43 PM
>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>> To: Mario Vilas <mvilas@gmail.com>
>>
>>
>> People can read the report if they like. Can't you even do basic things
>> like reading a vulnerability report?
>>
>> Can't you see that the advisory is about writing arbitrary files. If I
>> was your boss I would fire you, with a good kick outta the door.
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>
>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>
>>
>> --
>> Cheers
>> Michele
>>
>>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
You can't even find a cross site scripting on google.

Find a vuln on Google seems like a dream to some script kiddies.


On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> The full-disclosure mailing list has really changed. It's full of lamers
> nowdays aiming high.
>
>
>
>
>
> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>> ---------- Forwarded message ----------
>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> Date: Fri, Mar 14, 2014 at 5:58 PM
>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>> To: antisnatchor <antisnatchor@gmail.com>
>>
>>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>
>>> LOL you're hopeless.
>>> Good luck with your business. Brave customers!
>>>
>>> Cheers
>>> antisnatchor
>>>
>>> Nicholas Lemonias. wrote:
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you.
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas <mvilas@gmail.com>
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you, with a good kick outta the door.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>
>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>
>>>
>>> --
>>> Cheers
>>> Michele
>>>
>>>
>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Ahah, I don't want to loose my time with public bug bounties, it's not
even cost-effective.

Sei proprio un nabbo

Nicholas Lemonias. wrote:
> You can't even find a cross site scripting on google.
>
> Find a vuln on Google seems like a dream to some script kiddies.
>
>
> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com <mailto:lem.nikolas@googlemail.com>> wrote:
>
> The full-disclosure mailing list has really changed. It's full of
> lamers nowdays aiming high.
>
>
>
>
>
> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com <mailto:lem.nikolas@googlemail.com>>
> wrote:
>
> Says the script kiddie... Beg for some publicity. My customers
> are FTSE 100.
>
> ---------- Forwarded message ----------
> From: *Nicholas Lemonias.* <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>>
> Date: Fri, Mar 14, 2014 at 5:58 PM
> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities
> with PoC
> To: antisnatchor <antisnatchor@gmail.com
> <mailto:antisnatchor@gmail.com>>
>
>
> Says the script kiddie... Beg for some publicity. My customers
> are FTSE 100.
>
>
>
>
> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor
> <antisnatchor@gmail.com <mailto:antisnatchor@gmail.com>> wrote:
>
> LOL you're hopeless.
> Good luck with your business. Brave customers!
>
> Cheers
> antisnatchor
>
> Nicholas Lemonias. wrote:
>>
>> People can read the report if they like. Can't you even
>> do basic things like reading a vulnerability report?
>>
>> Can't you see that the advisory is about writing
>> arbitrary files. If I was your boss I would fire you.
>> ---------- Forwarded message ----------
>> From: *Nicholas Lemonias.* <lem.nikolas@googlemail.com
>> <mailto:lem.nikolas@googlemail.com>>
>> Date: Fri, Mar 14, 2014 at 5:43 PM
>> Subject: Re: [Full-disclosure] Google vulnerabilities
>> with PoC
>> To: Mario Vilas <mvilas@gmail.com <mailto:mvilas@gmail.com>>
>>
>>
>> People can read the report if they like. Can't you even
>> do basic things like reading a vulnerability report?
>>
>> Can't you see that the advisory is about writing
>> arbitrary files. If I was your boss I would fire you,
>> with a good kick outta the door.
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas
>> <mvilas@gmail.com <mailto:mvilas@gmail.com>> wrote:
>>
>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>> <lem.nikolas@googlemail.com
>> <mailto:lem.nikolas@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.nikolas@googlemail.com
>> <mailto:lem.nikolas@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
>> <mvilas@gmail.com <mailto:mvilas@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.nikolas@googlemail.com
>> <mailto:lem.nikolas@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.nikolas@googlemail.com
>> <mailto:lem.nikolas@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
>> <athiasjerome@gmail.com
>> <mailto:athiasjerome@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
>> <lcamtuf@coredump.cx
>> <mailto:lcamtuf@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/
>
> --
> Cheers
> Michele
>
>
>
>
>

--
Cheers
Michele
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Too bad the findings were manual.. no tools used. raw http communication.

Took me less than 2 minutes to find, following an initial conv I had with
Google Sec Team.


On Fri, Mar 14, 2014 at 6:02 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> You can't even find a cross site scripting on google.
>
> Find a vuln on Google seems like a dream to some script kiddies.
>
>
> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> The full-disclosure mailing list has really changed. It's full of lamers
>> nowdays aiming high.
>>
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>> 100.
>>>
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 5:58 PM
>>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>> To: antisnatchor <antisnatchor@gmail.com>
>>>
>>>
>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>> 100.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>>
>>>> LOL you're hopeless.
>>>> Good luck with your business. Brave customers!
>>>>
>>>> Cheers
>>>> antisnatchor
>>>>
>>>> Nicholas Lemonias. wrote:
>>>>
>>>>
>>>> People can read the report if they like. Can't you even do basic things
>>>> like reading a vulnerability report?
>>>>
>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>> was your boss I would fire you.
>>>> ---------- Forwarded message ----------
>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>> To: Mario Vilas <mvilas@gmail.com>
>>>>
>>>>
>>>> People can read the report if they like. Can't you even do basic things
>>>> like reading a vulnerability report?
>>>>
>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>> was your boss I would fire you, with a good kick outta the door.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>>
>>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>>
>>>>
>>>> --
>>>> Cheers
>>>> Michele
>>>>
>>>>
>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
This is one of the most fun threads I've read in fd, and that's no small
feat. Thanks for the laughs.


On Fri, Mar 14, 2014 at 3:00 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> The full-disclosure mailing list has really changed. It's full of lamers
> nowdays aiming high.
>
>
>
>
>
> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>> ---------- Forwarded message ----------
>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> Date: Fri, Mar 14, 2014 at 5:58 PM
>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>> To: antisnatchor <antisnatchor@gmail.com>
>>
>>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>
>>> LOL you're hopeless.
>>> Good luck with your business. Brave customers!
>>>
>>> Cheers
>>> antisnatchor
>>>
>>> Nicholas Lemonias. wrote:
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you.
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas <mvilas@gmail.com>
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you, with a good kick outta the door.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>
>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>
>>>
>>> --
>>> Cheers
>>> Michele
>>>
>>>
>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
“If debugging is the process of removing software bugs, then programming
must be the process of putting them in.” - *Edsger Dijkstra*
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
No, you're saying something's a vulnerability without showing any
indication of how it can be abused.

On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
<lem.nikolas@googlemail.com> wrote:
> The full-disclosure mailing list has really changed. It's full of lamers
> nowdays aiming high.
>
>
>
>
>
> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com> wrote:
>>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>> ---------- Forwarded message ----------
>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> Date: Fri, Mar 14, 2014 at 5:58 PM
>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>> To: antisnatchor <antisnatchor@gmail.com>
>>
>>
>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> 100.
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>
>> wrote:
>>>
>>> LOL you're hopeless.
>>> Good luck with your business. Brave customers!
>>>
>>> Cheers
>>> antisnatchor
>>>
>>> Nicholas Lemonias. wrote:
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you.
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas <mvilas@gmail.com>
>>>
>>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you, with a good kick outta the door.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>>
>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>>>> <lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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
>>>>>>>>> <athiasjerome@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 <lcamtuf@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/
>>>
>>>
>>> --
>>> Cheers
>>> Michele
>>>
>>
>>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/



--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Quite funnily, most erratic comments originate from a @gmail.com host. Does
that mean that Google and Co are attacking the researcher ?


On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> Quite funnily, most erratic comments originate from a @gmail.com host.
> Does that mean that Google and Co are attacking the researcher ?
>
>
>
>
> On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale <eyeronic.design@gmail.com>wrote:
>
>> No, you're saying something's a vulnerability without showing any
>> indication of how it can be abused.
>>
>> On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
>> <lem.nikolas@googlemail.com> wrote:
>> > The full-disclosure mailing list has really changed. It's full of lamers
>> > nowdays aiming high.
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
>> > <lem.nikolas@googlemail.com> wrote:
>> >>
>> >> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> >> 100.
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> >> Date: Fri, Mar 14, 2014 at 5:58 PM
>> >> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>> >> To: antisnatchor <antisnatchor@gmail.com>
>> >>
>> >>
>> >> Says the script kiddie... Beg for some publicity. My customers are FTSE
>> >> 100.
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>
>> >> wrote:
>> >>>
>> >>> LOL you're hopeless.
>> >>> Good luck with your business. Brave customers!
>> >>>
>> >>> Cheers
>> >>> antisnatchor
>> >>>
>> >>> Nicholas Lemonias. wrote:
>> >>>
>> >>>
>> >>> People can read the report if they like. Can't you even do basic
>> things
>> >>> like reading a vulnerability report?
>> >>>
>> >>> Can't you see that the advisory is about writing arbitrary files. If I
>> >>> was your boss I would fire you.
>> >>> ---------- Forwarded message ----------
>> >>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> >>> Date: Fri, Mar 14, 2014 at 5:43 PM
>> >>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>> >>> To: Mario Vilas <mvilas@gmail.com>
>> >>>
>> >>>
>> >>> People can read the report if they like. Can't you even do basic
>> things
>> >>> like reading a vulnerability report?
>> >>>
>> >>> Can't you see that the advisory is about writing arbitrary files. If I
>> >>> was your boss I would fire you, with a good kick outta the door.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com>
>> wrote:
>> >>>>
>> >>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>> >>>> <lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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
>> >>>>>>>>> <athiasjerome@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 <lcamtuf@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/
>> >>>
>> >>>
>> >>> --
>> >>> Cheers
>> >>> Michele
>> >>>
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>>
>> --
>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
LOL I don't work for Google and you can easily verify that.

Also, your XSS PoCs suck, they don't even trigger automatically but the
victim needs to
go with the mouse over the element LOL:
http://packetstormsecurity.com/files/125135/Visa-Europe-Cross-Site-Scripting.html

Lame

Nicholas Lemonias. wrote:
> Quite funnily, most erratic comments originate from a @gmail.com
> <http://gmail.com/> host. Does that mean that Google and Co are
> attacking the researcher ?
>
>
> On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com <mailto:lem.nikolas@googlemail.com>> wrote:
>
> Quite funnily, most erratic comments originate from a @gmail.com
> <http://gmail.com> host. Does that mean that Google and Co are
> attacking the researcher ?
>
>
>
>
> On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale
> <eyeronic.design@gmail.com <mailto:eyeronic.design@gmail.com>> wrote:
>
> No, you're saying something's a vulnerability without showing any
> indication of how it can be abused.
>
> On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>> wrote:
> > The full-disclosure mailing list has really changed. It's
> full of lamers
> > nowdays aiming high.
> >
> >
> >
> >
> >
> > On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
> > <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>> wrote:
> >>
> >> Says the script kiddie... Beg for some publicity. My
> customers are FTSE
> >> 100.
> >>
> >> ---------- Forwarded message ----------
> >> From: Nicholas Lemonias. <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>>
> >> Date: Fri, Mar 14, 2014 at 5:58 PM
> >> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities
> with PoC
> >> To: antisnatchor <antisnatchor@gmail.com
> <mailto:antisnatchor@gmail.com>>
> >>
> >>
> >> Says the script kiddie... Beg for some publicity. My
> customers are FTSE
> >> 100.
> >>
> >>
> >>
> >>
> >> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor
> <antisnatchor@gmail.com <mailto:antisnatchor@gmail.com>>
> >> wrote:
> >>>
> >>> LOL you're hopeless.
> >>> Good luck with your business. Brave customers!
> >>>
> >>> Cheers
> >>> antisnatchor
> >>>
> >>> Nicholas Lemonias. wrote:
> >>>
> >>>
> >>> People can read the report if they like. Can't you even do
> basic things
> >>> like reading a vulnerability report?
> >>>
> >>> Can't you see that the advisory is about writing arbitrary
> files. If I
> >>> was your boss I would fire you.
> >>> ---------- Forwarded message ----------
> >>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@googlemail.com>>
> >>> Date: Fri, Mar 14, 2014 at 5:43 PM
> >>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
> >>> To: Mario Vilas <mvilas@gmail.com <mailto:mvilas@gmail.com>>
> >>>
> >>>
> >>> People can read the report if they like. Can't you even do
> basic things
> >>> like reading a vulnerability report?
> >>>
> >>> Can't you see that the advisory is about writing arbitrary
> files. If I
> >>> was your boss I would fire you, with a good kick outta the
> door.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas
> <mvilas@gmail.com <mailto:mvilas@gmail.com>> wrote:
> >>>>
> >>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
> >>>> <lem.nikolas@googlemail.com
> <mailto:lem.nikolas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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
> <mvilas@gmail.com <mailto:mvilas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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
> >>>>>>>>> <athiasjerome@gmail.com
> <mailto:athiasjerome@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
> <lcamtuf@coredump.cx <mailto:lcamtuf@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/
> >>>
> >>>
> >>> --
> >>> Cheers
> >>> Michele
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>
>
>

--
Cheers
Michele
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
That's why its called proof of concept, you lamer. Google and Co on the
counter attack. hahaha


On Fri, Mar 14, 2014 at 6:07 PM, antisnatchor <antisnatchor@gmail.com>wrote:

> LOL I don't work for Google and you can easily verify that.
>
> Also, your XSS PoCs suck, they don't even trigger automatically but the
> victim needs to
> go with the mouse over the element LOL:
>
> http://packetstormsecurity.com/files/125135/Visa-Europe-Cross-Site-Scripting.html
>
> Lame
>
>
> Nicholas Lemonias. wrote:
>
> Quite funnily, most erratic comments originate from a @gmail.com host.
> Does that mean that Google and Co are attacking the researcher ?
>
>
> On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Quite funnily, most erratic comments originate from a @gmail.com host.
>> Does that mean that Google and Co are attacking the researcher ?
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale <eyeronic.design@gmail.com>wrote:
>>
>>> No, you're saying something's a vulnerability without showing any
>>> indication of how it can be abused.
>>>
>>> On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
>>> <lem.nikolas@googlemail.com> wrote:
>>> > The full-disclosure mailing list has really changed. It's full of
>>> lamers
>>> > nowdays aiming high.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
>>> > <lem.nikolas@googlemail.com> wrote:
>>> >>
>>> >> Says the script kiddie... Beg for some publicity. My customers are
>>> FTSE
>>> >> 100.
>>> >>
>>> >> ---------- Forwarded message ----------
>>> >> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> >> Date: Fri, Mar 14, 2014 at 5:58 PM
>>> >> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>> >> To: antisnatchor <antisnatchor@gmail.com>
>>> >>
>>> >>
>>> >> Says the script kiddie... Beg for some publicity. My customers are
>>> FTSE
>>> >> 100.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>> LOL you're hopeless.
>>> >>> Good luck with your business. Brave customers!
>>> >>>
>>> >>> Cheers
>>> >>> antisnatchor
>>> >>>
>>> >>> Nicholas Lemonias. wrote:
>>> >>>
>>> >>>
>>> >>> People can read the report if they like. Can't you even do basic
>>> things
>>> >>> like reading a vulnerability report?
>>> >>>
>>> >>> Can't you see that the advisory is about writing arbitrary files. If
>>> I
>>> >>> was your boss I would fire you.
>>> >>> ---------- Forwarded message ----------
>>> >>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> >>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> >>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> >>> To: Mario Vilas <mvilas@gmail.com>
>>> >>>
>>> >>>
>>> >>> People can read the report if they like. Can't you even do basic
>>> things
>>> >>> like reading a vulnerability report?
>>> >>>
>>> >>> Can't you see that the advisory is about writing arbitrary files. If
>>> I
>>> >>> was your boss I would fire you, with a good kick outta the door.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>>> >>>> <lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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
>>> >>>>>>>>> <athiasjerome@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 <
>>> lcamtuf@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/
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Cheers
>>> >>> Michele
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Full-Disclosure - We believe in it.
>>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> > Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>>
>>>
>>> --
>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>>>
>>
>>
>
> --
> Cheers
> Michele
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Dude, seriously. Just stop.


2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>:

> You can't even find a cross site scripting on google.
>
> Find a vuln on Google seems like a dream to some script kiddies.
>
>
> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> The full-disclosure mailing list has really changed. It's full of lamers
>> nowdays aiming high.
>>
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>> 100.
>>>
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> Date: Fri, Mar 14, 2014 at 5:58 PM
>>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>> To: antisnatchor <antisnatchor@gmail.com>
>>>
>>>
>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>> 100.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>>
>>>> LOL you're hopeless.
>>>> Good luck with your business. Brave customers!
>>>>
>>>> Cheers
>>>> antisnatchor
>>>>
>>>> Nicholas Lemonias. wrote:
>>>>
>>>>
>>>> People can read the report if they like. Can't you even do basic things
>>>> like reading a vulnerability report?
>>>>
>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>> was your boss I would fire you.
>>>> ---------- Forwarded message ----------
>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>> To: Mario Vilas <mvilas@gmail.com>
>>>>
>>>>
>>>> People can read the report if they like. Can't you even do basic things
>>>> like reading a vulnerability report?
>>>>
>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>> was your boss I would fire you, with a good kick outta the door.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>>
>>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>>
>>>>
>>>> --
>>>> Cheers
>>>> Michele
>>>>
>>>>
>>>
>>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Security vulnerabilities need to be published and reported. That's the
spirit.

Attacking the researcher, won't make it go away.


On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki
<julius.kivimaki@gmail.com>wrote:

> Dude, seriously. Just stop.
>
>
> 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> You can't even find a cross site scripting on google.
>>
>> Find a vuln on Google seems like a dream to some script kiddies.
>>
>>
>> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> The full-disclosure mailing list has really changed. It's full of lamers
>>> nowdays aiming high.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>>> 100.
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>> Date: Fri, Mar 14, 2014 at 5:58 PM
>>>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>>> To: antisnatchor <antisnatchor@gmail.com>
>>>>
>>>>
>>>> Says the script kiddie... Beg for some publicity. My customers are FTSE
>>>> 100.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>>>
>>>>> LOL you're hopeless.
>>>>> Good luck with your business. Brave customers!
>>>>>
>>>>> Cheers
>>>>> antisnatchor
>>>>>
>>>>> Nicholas Lemonias. wrote:
>>>>>
>>>>>
>>>>> People can read the report if they like. Can't you even do basic
>>>>> things like reading a vulnerability report?
>>>>>
>>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>>> was your boss I would fire you.
>>>>> ---------- Forwarded message ----------
>>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>>> To: Mario Vilas <mvilas@gmail.com>
>>>>>
>>>>>
>>>>> People can read the report if they like. Can't you even do basic
>>>>> things like reading a vulnerability report?
>>>>>
>>>>> Can't you see that the advisory is about writing arbitrary files. If I
>>>>> was your boss I would fire you, with a good kick outta the door.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>>>>
>>>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>>>
>>>>>
>>>>> --
>>>>> Cheers
>>>>> Michele
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
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.




On Fri, Mar 14, 2014 at 6:13 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> Security vulnerabilities need to be published and reported. That's the
> spirit.
>
> Attacking the researcher, won't make it go away.
>
>
> On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> Dude, seriously. Just stop.
>>
>>
>> 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> You can't even find a cross site scripting on google.
>>>
>>> Find a vuln on Google seems like a dream to some script kiddies.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> The full-disclosure mailing list has really changed. It's full of
>>>> lamers nowdays aiming high.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> Says the script kiddie... Beg for some publicity. My customers are
>>>>> FTSE 100.
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>>> Date: Fri, Mar 14, 2014 at 5:58 PM
>>>>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>>>> To: antisnatchor <antisnatchor@gmail.com>
>>>>>
>>>>>
>>>>> Says the script kiddie... Beg for some publicity. My customers are
>>>>> FTSE 100.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com>wrote:
>>>>>
>>>>>> LOL you're hopeless.
>>>>>> Good luck with your business. Brave customers!
>>>>>>
>>>>>> Cheers
>>>>>> antisnatchor
>>>>>>
>>>>>> Nicholas Lemonias. wrote:
>>>>>>
>>>>>>
>>>>>> People can read the report if they like. Can't you even do basic
>>>>>> things like reading a vulnerability report?
>>>>>>
>>>>>> Can't you see that the advisory is about writing arbitrary files. If
>>>>>> I was your boss I would fire you.
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>>>> To: Mario Vilas <mvilas@gmail.com>
>>>>>>
>>>>>>
>>>>>> People can read the report if they like. Can't you even do basic
>>>>>> things like reading a vulnerability report?
>>>>>>
>>>>>> Can't you see that the advisory is about writing arbitrary files. If
>>>>>> I was your boss I would fire you, with a good kick outta the door.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com>wrote:
>>>>>>
>>>>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>>>>> athiasjerome@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 <lcamtuf@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/
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers
>>>>>> Michele
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
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.


On Fri, Mar 14, 2014 at 6:16 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> 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.
>
>
>
>
> On Fri, Mar 14, 2014 at 6:13 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Security vulnerabilities need to be published and reported. That's the
>> spirit.
>>
>> Attacking the researcher, won't make it go away.
>>
>>
>> On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki <
>> julius.kivimaki@gmail.com> wrote:
>>
>>> Dude, seriously. Just stop.
>>>
>>>
>>> 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com>:
>>>
>>> You can't even find a cross site scripting on google.
>>>>
>>>> Find a vuln on Google seems like a dream to some script kiddies.
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> The full-disclosure mailing list has really changed. It's full of
>>>>> lamers nowdays aiming high.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>> Says the script kiddie... Beg for some publicity. My customers are
>>>>>> FTSE 100.
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>>>> Date: Fri, Mar 14, 2014 at 5:58 PM
>>>>>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>>>>> To: antisnatchor <antisnatchor@gmail.com>
>>>>>>
>>>>>>
>>>>>> Says the script kiddie... Beg for some publicity. My customers are
>>>>>> FTSE 100.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> LOL you're hopeless.
>>>>>>> Good luck with your business. Brave customers!
>>>>>>>
>>>>>>> Cheers
>>>>>>> antisnatchor
>>>>>>>
>>>>>>> Nicholas Lemonias. wrote:
>>>>>>>
>>>>>>>
>>>>>>> People can read the report if they like. Can't you even do basic
>>>>>>> things like reading a vulnerability report?
>>>>>>>
>>>>>>> Can't you see that the advisory is about writing arbitrary files. If
>>>>>>> I was your boss I would fire you.
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>>>>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>>>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>>>>> To: Mario Vilas <mvilas@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>> People can read the report if they like. Can't you even do basic
>>>>>>> things like reading a vulnerability report?
>>>>>>>
>>>>>>> Can't you see that the advisory is about writing arbitrary files. If
>>>>>>> I was your boss I would fire you, with a good kick outta the door.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com>wrote:
>>>>>>>
>>>>>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>>>>>>>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>>>>>>>> athiasjerome@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 <
>>>>>>>>>>>>>> lcamtuf@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/
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers
>>>>>>> Michele
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>
>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
You have a Googlemail account. How do we know you don't work for Google
too...

Inception type stuff going on here.
> Nicholas Lemonias. <mailto:lem.nikolas@googlemail.com>
> 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. <mailto:lem.nikolas@googlemail.com>
> 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. <mailto:lem.nikolas@googlemail.com>
> 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 <mailto:mvilas@gmail.com>
> 14 March 2014 15:55
> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
> <lem.nikolas@googlemail.com <mailto:lem.nikolas@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.nikolas@googlemail.com <mailto:lem.nikolas@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
> <mvilas@gmail.com <mailto:mvilas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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.nikolas@googlemail.com
> <mailto:lem.nikolas@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
> <athiasjerome@gmail.com
> <mailto:athiasjerome@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
> <lcamtuf@coredump.cx
> <mailto:lcamtuf@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. <mailto:lem.nikolas@googlemail.com>
> 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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
>
> Laughing at the incompetency of some people, who wish to discredit
>>>> OWASP and their reports. Say that to any serious professional, and they
>>>> will laugh at you. Writing arbitrary files to a remote network is a serious
>>>> risk, irrelevantly of how good and reputable that service is.
>>>>
>>>
Best,
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Jerome of MacAfee has made a very valid point on revisiting separation of
duties in this security instance.

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, whether employed by
Google or other companies. It's usual for incompetent consultants to cover
up each others asses - speaking from experience.





On Fri, Mar 14, 2014 at 6:30 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> Jerome of Mcafee has made a very valid point on revisiting separation of
> duties in this security instance.
>
> 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, whether employed by
> Google or other companies.
>
> Nicholas.
>
>
> On Fri, Mar 14, 2014 at 6:26 PM, Thomas MacKenzie <thomas@tmacuk.co.uk>wrote:
>
>>
>> You have a Googlemail account. How do we know you don't work for Google
>> too...
>>
>> Inception type stuff going on here.
>>
>> Nicholas Lemonias. <lem.nikolas@googlemail.com>
>> 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. <lem.nikolas@googlemail.com>
>> 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. <lem.nikolas@googlemail.com>
>> 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 <mvilas@gmail.com>
>> 14 March 2014 15:55
>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
>> lem.nikolas@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.nikolas@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 <mvilas@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.nikolas@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.nikolas@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 <
>>>>>>> athiasjerome@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 <lcamtuf@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. <lem.nikolas@googlemail.com>
>> 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/
>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
We have many PoC's including video clips. We may upload for the security
world to see.

However, this is not the way to treat security vulnerabilities. Attacking
the researcher and bringing you friends to do aswell, won't mitigate the
problem.
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Does anybody still have some popcorn left?

They ran out of it in the tax free zone in here due to this thread...

Kind regards,

Yvan Janssens

Sent from my PDA - excuse me for my brevity

> On 14 Mar 2014, at 18:40, "Nicholas Lemonias." <lem.nikolas@googlemail.com> wrote:
>
> We have many PoC's including video clips. We may upload for the security world to see.
>
> However, this is not the way to treat security vulnerabilities. Attacking the researcher and bringing you friends to do aswell, won't mitigate the problem.
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]

1 2 3 4  View All