Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Full Disclosure>
  3. Full-Disclosure
Fwd: Google vulnerabilities with PoC
lem.nikolas at googlemail
Mar 13, 2014, 12:48 PM
Post #1 of 88 (18600 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 7:16 AM
Post #2 of 88 (18463 views)
Permalink
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 ]
shadown at gmail
Mar 14, 2014, 7:33 AM
Post #3 of 88 (18463 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 7:54 AM
Post #4 of 88 (18432 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 10:44 AM
Post #5 of 88 (18423 views)
Permalink
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 ]
antisnatchor at gmail
Mar 14, 2014, 10:55 AM
Post #6 of 88 (18428 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:00 AM
Post #7 of 88 (18420 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:02 AM
Post #8 of 88 (18449 views)
Permalink
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 ]
antisnatchor at gmail
Mar 14, 2014, 11:03 AM
Post #9 of 88 (18426 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:04 AM
Post #10 of 88 (18442 views)
Permalink
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 ]
ulisses.montenegro at gmail
Mar 14, 2014, 11:04 AM
Post #11 of 88 (18451 views)
Permalink
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 ]
eyeronic.design at gmail
Mar 14, 2014, 11:04 AM
Post #12 of 88 (18442 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:07 AM
Post #13 of 88 (18440 views)
Permalink
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 ]
antisnatchor at gmail
Mar 14, 2014, 11:07 AM
Post #14 of 88 (18432 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:10 AM
Post #15 of 88 (18454 views)
Permalink
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 ]
julius.kivimaki at gmail
Mar 14, 2014, 11:12 AM
Post #16 of 88 (18413 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:13 AM
Post #17 of 88 (18441 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:16 AM
Post #18 of 88 (18459 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:17 AM
Post #19 of 88 (18432 views)
Permalink
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 ]
thomas at tmacuk
Mar 14, 2014, 11:26 AM
Post #20 of 88 (18403 views)
Permalink
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/

Attached Files:

Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 11:26 AM
Post #21 of 88 (18433 views)
Permalink
>
> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:32 AM
Post #22 of 88 (18426 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:40 AM
Post #23 of 88 (18436 views)
Permalink
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 ]
ik at yvanj
Mar 14, 2014, 11:46 AM
Post #24 of 88 (18395 views)
Permalink
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 ]
lem.nikolas at googlemail
Mar 14, 2014, 11:56 AM
Post #25 of 88 (18441 views)
Permalink
Google research not awarded.

http://www.techworm.net/2014/03/security-research-finds-flaws-in.html
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
kkotowicz+fd at gmail
Mar 14, 2014, 12:01 PM
Post #26 of 88 (9510 views)
Permalink
Nicholas, seriously, just stop.

You have found an 'arbitrary file upload' in a file hosting service and
claim it is a serious vulnerability. With no proof that your 'arbitrary
file' is being used anywhere in any context that would lead to code
execution - on server or client side. You cite OWASP documents (which are
unrelated to the case), academia papers from 1975 just to find a reason
it's theoretically serious, not paying any attention to what service you're
actually attacking and what have you really achieved in that (which is
demonstrating a filtering weakness at best, low risk).

Everyone on this list so far explains why you're wrong, but you just won't
stop. So you start throwing out certificates, your academia experience and
your respected company. Then - name calling everyone else. Seriously, it's
just a good laugh for most of us.

Dude, please, just because you did not qualify for a bounty, there's no
point in launching a whole campaign like you are. You're essentially
following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
wall) - he DID find a vuln though. Do you really want that? Go ahead, start
a crowdsourcing campaign!





2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>:

> 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 ]
juniorbsd at gmail
Mar 14, 2014, 12:06 PM
Post #27 of 88 (9522 views)
Permalink
congrats for your discover, get you prize

[image: 24167992.jpg (1024×768)]


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

> Google research not awarded.
>
> http://www.techworm.net/2014/03/security-research-finds-flaws-in.html
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
Grato,

J. Tozo
_
°v°
/(S)\ SLACKWARE
^ ^ Linux
_____________________
because it works
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 12:09 PM
Post #28 of 88 (9535 views)
Permalink
You are wrong, because we do have proof of concepts. If we didn't have
them, then there would be no case.

But if there are video clips, images demonstrating impact - in which case
arbitrary file uploads (which is a write() call ) to a remote network, then
it is a vulnerability. It is not about the bounty, but rather about not
defying academic literature and widely recognised practise.

Attacking the arguer, won't make the bug to go away.

Best,

Nicholas.


On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz
<kkotowicz+fd@gmail.com>wrote:

> Nicholas, seriously, just stop.
>
> You have found an 'arbitrary file upload' in a file hosting service and
> claim it is a serious vulnerability. With no proof that your 'arbitrary
> file' is being used anywhere in any context that would lead to code
> execution - on server or client side. You cite OWASP documents (which are
> unrelated to the case), academia papers from 1975 just to find a reason
> it's theoretically serious, not paying any attention to what service you're
> actually attacking and what have you really achieved in that (which is
> demonstrating a filtering weakness at best, low risk).
>
> Everyone on this list so far explains why you're wrong, but you just won't
> stop. So you start throwing out certificates, your academia experience and
> your respected company. Then - name calling everyone else. Seriously, it's
> just a good laugh for most of us.
>
> Dude, please, just because you did not qualify for a bounty, there's no
> point in launching a whole campaign like you are. You're essentially
> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
> a crowdsourcing campaign!
>
>
>
>
>
> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
>> 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 ]
kkotowicz+fd at gmail
Mar 14, 2014, 12:15 PM
Post #29 of 88 (9534 views)
Permalink
Care to report the same to Dropbox and Pastebin? It's a gold mine, you
know...


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

> You are wrong, because we do have proof of concepts. If we didn't have
> them, then there would be no case.
>
> But if there are video clips, images demonstrating impact - in which case
> arbitrary file uploads (which is a write() call ) to a remote network, then
> it is a vulnerability. It is not about the bounty, but rather about not
> defying academic literature and widely recognised practise.
>
> Attacking the arguer, won't make the bug to go away.
>
> Best,
>
> Nicholas.
>
>
> On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz <
> kkotowicz+fd@gmail.com> wrote:
>
>> Nicholas, seriously, just stop.
>>
>> You have found an 'arbitrary file upload' in a file hosting service and
>> claim it is a serious vulnerability. With no proof that your 'arbitrary
>> file' is being used anywhere in any context that would lead to code
>> execution - on server or client side. You cite OWASP documents (which are
>> unrelated to the case), academia papers from 1975 just to find a reason
>> it's theoretically serious, not paying any attention to what service you're
>> actually attacking and what have you really achieved in that (which is
>> demonstrating a filtering weakness at best, low risk).
>>
>> Everyone on this list so far explains why you're wrong, but you just
>> won't stop. So you start throwing out certificates, your academia
>> experience and your respected company. Then - name calling everyone else.
>> Seriously, it's just a good laugh for most of us.
>>
>> Dude, please, just because you did not qualify for a bounty, there's no
>> point in launching a whole campaign like you are. You're essentially
>> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
>> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
>> a crowdsourcing campaign!
>>
>>
>>
>>
>>
>> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>>> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 12:16 PM
Post #30 of 88 (9541 views)
Permalink
We are not asking for a payment. But at least a thank you for our efforts
would do.

Saying that it is not an issue, to upload remotely any file of choice, that
is ridiculous for the organisation they represent.


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

> You are wrong, because we do have proof of concepts. If we didn't have
> them, then there would be no case.
>
> But if there are video clips, images demonstrating impact - in which case
> arbitrary file uploads (which is a write() call ) to a remote network, then
> it is a vulnerability. It is not about the bounty, but rather about not
> defying academic literature and widely recognised practise.
>
> Attacking the arguer, won't make the bug to go away.
>
> Best,
>
> Nicholas.
>
>
> On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz <
> kkotowicz+fd@gmail.com> wrote:
>
>> Nicholas, seriously, just stop.
>>
>> You have found an 'arbitrary file upload' in a file hosting service and
>> claim it is a serious vulnerability. With no proof that your 'arbitrary
>> file' is being used anywhere in any context that would lead to code
>> execution - on server or client side. You cite OWASP documents (which are
>> unrelated to the case), academia papers from 1975 just to find a reason
>> it's theoretically serious, not paying any attention to what service you're
>> actually attacking and what have you really achieved in that (which is
>> demonstrating a filtering weakness at best, low risk).
>>
>> Everyone on this list so far explains why you're wrong, but you just
>> won't stop. So you start throwing out certificates, your academia
>> experience and your respected company. Then - name calling everyone else.
>> Seriously, it's just a good laugh for most of us.
>>
>> Dude, please, just because you did not qualify for a bounty, there's no
>> point in launching a whole campaign like you are. You're essentially
>> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
>> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
>> a crowdsourcing campaign!
>>
>>
>>
>>
>>
>> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>>> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 12:20 PM
Post #31 of 88 (9519 views)
Permalink
And I am not referring just to Google. But for those people who support
that remote uploads to a trusted network is not an issue. Then that also
means that firewalls and IPS systems are worthless. Why spend so much time
protecting the network layers if a user can send any file of choice to a
remote network...




On Fri, Mar 14, 2014 at 7:15 PM, Krzysztof Kotowicz
<kkotowicz+fd@gmail.com>wrote:

> Care to report the same to Dropbox and Pastebin? It's a gold mine, you
> know...
>
>
> 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> You are wrong, because we do have proof of concepts. If we didn't have
>> them, then there would be no case.
>>
>> But if there are video clips, images demonstrating impact - in which case
>> arbitrary file uploads (which is a write() call ) to a remote network, then
>> it is a vulnerability. It is not about the bounty, but rather about not
>> defying academic literature and widely recognised practise.
>>
>> Attacking the arguer, won't make the bug to go away.
>>
>> Best,
>>
>> Nicholas.
>>
>>
>> On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz <
>> kkotowicz+fd@gmail.com> wrote:
>>
>>> Nicholas, seriously, just stop.
>>>
>>> You have found an 'arbitrary file upload' in a file hosting service and
>>> claim it is a serious vulnerability. With no proof that your 'arbitrary
>>> file' is being used anywhere in any context that would lead to code
>>> execution - on server or client side. You cite OWASP documents (which are
>>> unrelated to the case), academia papers from 1975 just to find a reason
>>> it's theoretically serious, not paying any attention to what service you're
>>> actually attacking and what have you really achieved in that (which is
>>> demonstrating a filtering weakness at best, low risk).
>>>
>>> Everyone on this list so far explains why you're wrong, but you just
>>> won't stop. So you start throwing out certificates, your academia
>>> experience and your respected company. Then - name calling everyone else.
>>> Seriously, it's just a good laugh for most of us.
>>>
>>> Dude, please, just because you did not qualify for a bounty, there's no
>>> point in launching a whole campaign like you are. You're essentially
>>> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
>>> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
>>> a crowdsourcing campaign!
>>>
>>>
>>>
>>>
>>>
>>> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com>:
>>>
>>>> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 12:21 PM
Post #32 of 88 (9531 views)
Permalink
And I am not referring just to Google. But for those people who support
that remote uploads to a trusted network is not an issue. Then that also
means that firewalls and IPS systems are worthless. Why spend so much time
protecting the network layers if a user can send any file of choice to a
remote network through http.


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

> And I am not referring just to Google. But for those people who support
> that remote uploads to a trusted network is not an issue. Then that also
> means that firewalls and IPS systems are worthless. Why spend so much time
> protecting the network layers if a user can send any file of choice to a
> remote network...
>
>
>
>
> On Fri, Mar 14, 2014 at 7:15 PM, Krzysztof Kotowicz <
> kkotowicz+fd@gmail.com> wrote:
>
>> Care to report the same to Dropbox and Pastebin? It's a gold mine, you
>> know...
>>
>>
>> 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> You are wrong, because we do have proof of concepts. If we didn't have
>>> them, then there would be no case.
>>>
>>> But if there are video clips, images demonstrating impact - in which
>>> case arbitrary file uploads (which is a write() call ) to a remote network,
>>> then it is a vulnerability. It is not about the bounty, but rather about
>>> not defying academic literature and widely recognised practise.
>>>
>>> Attacking the arguer, won't make the bug to go away.
>>>
>>> Best,
>>>
>>> Nicholas.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz <
>>> kkotowicz+fd@gmail.com> wrote:
>>>
>>>> Nicholas, seriously, just stop.
>>>>
>>>> You have found an 'arbitrary file upload' in a file hosting service and
>>>> claim it is a serious vulnerability. With no proof that your 'arbitrary
>>>> file' is being used anywhere in any context that would lead to code
>>>> execution - on server or client side. You cite OWASP documents (which are
>>>> unrelated to the case), academia papers from 1975 just to find a reason
>>>> it's theoretically serious, not paying any attention to what service you're
>>>> actually attacking and what have you really achieved in that (which is
>>>> demonstrating a filtering weakness at best, low risk).
>>>>
>>>> Everyone on this list so far explains why you're wrong, but you just
>>>> won't stop. So you start throwing out certificates, your academia
>>>> experience and your respected company. Then - name calling everyone else.
>>>> Seriously, it's just a good laugh for most of us.
>>>>
>>>> Dude, please, just because you did not qualify for a bounty, there's no
>>>> point in launching a whole campaign like you are. You're essentially
>>>> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
>>>> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
>>>> a crowdsourcing campaign!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com>:
>>>>
>>>>> 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 ]
rd.seclists at gmail
Mar 14, 2014, 12:23 PM
Post #33 of 88 (9529 views)
Permalink
I'm going to try to spell it out clearly.

You don't have unrestricted file upload[1]. Keep in mind you're trying to
abuse youtube, which is essentially a video file upload service. So the
fact that you can upload files is not surprising.
Now you're uploading non-video files. Cool. But not earth-shattering.
They are not accessible to anyone but you, as far as I can tell, and I
don't even think you can access the file contents on the remote server, but
please prove me wrong on both points.
You are still, as far as I can tell, bound by the per-file and per-account
quota on disk occupation, so you don't have a DoS by resource exhaustion.
You can't force server-side file path, so you don't have RFI or DoS by
messing with the remote file system. You can't execute the files you
uploaded, so you don't have arbitrary code execution.

But you are right about what your PoC does. You bypassed a security
control, you uploaded crap on youtube servers, and by that you exhausted
their resources by a fraction of the quota they allow you when signing up.
BTW, I don't think they keep invalid video files for an indefinite period
of time in a user account, but I might be wrong.

The burden of proof is still on your side as to whether or not the bug you
found has any impact that was not already accepted by youtube allowing
registered users to upload whatever crap they see fit as long as it is
video. You failed to provide this proof, and please be sure the audience of
fulldisclosure is not "attacking the researcher" but working with you to
have a better understanding of the bug you found, even though you kinda
acted like a fool in this thread.

Please keep on searching and finding vulns, please keep on publishing them,
and use this as a learning experience that not all bugs or control bypasses
are security vulnerabilities.

--Rob'

[1] As per OWASP (https://www.owasp.org/index.php/Unrestricted_File_Upload):

>There are really two classes of problems here. The first is with the file
metadata, like the path and file name. These are generally provided by the
transport, such as HTTP multi-part encoding. This data may trick the
application into overwriting a critical file or storing the file in a bad
location. You must validate the metadata extremely carefully before using
it.

Your POC doesn't demonstrate that.

>The other class of problem is with the file size or content. The range of
problems here depends entirely on what the file is used for. See the
examples below for some ideas about how files might be misused. To protect
against this type of attack, you should analyze everything your application
does with files and think carefully about what processing and interpreters
are involved.

Your POC kinda does that, but you didn't provide proof it's possible to
execute what you uploaded, either using social engineering or any other
method.

Also, please don't say "verified by a couple of recognised experts
including OWASP" unless you actually spoke with someone @owasp and she
validated your findings.


On Fri, Mar 14, 2014 at 7:40 PM, 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 12:28 PM
Post #34 of 88 (9540 views)
Permalink
Then that also means that firewalls and IPS systems are worthless. Why
spend so much time protecting the network layers if a user can send any
file of choice to a remote network through http...

As for the uploaded files being persistent, there is evidence of that. For
instance a remote admin could be tricked to execute some of the uploaded
files (Social Engineering).

So our report sent as part of Google's security program, should not be
treated as a non-security issue.


Thanks,


On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:

> I'm going to try to spell it out clearly.
>
> You don't have unrestricted file upload[1]. Keep in mind you're trying to
> abuse youtube, which is essentially a video file upload service. So the
> fact that you can upload files is not surprising.
> Now you're uploading non-video files. Cool. But not earth-shattering.
> They are not accessible to anyone but you, as far as I can tell, and I
> don't even think you can access the file contents on the remote server, but
> please prove me wrong on both points.
> You are still, as far as I can tell, bound by the per-file and per-account
> quota on disk occupation, so you don't have a DoS by resource exhaustion.
> You can't force server-side file path, so you don't have RFI or DoS by
> messing with the remote file system. You can't execute the files you
> uploaded, so you don't have arbitrary code execution.
>
> But you are right about what your PoC does. You bypassed a security
> control, you uploaded crap on youtube servers, and by that you exhausted
> their resources by a fraction of the quota they allow you when signing up.
> BTW, I don't think they keep invalid video files for an indefinite period
> of time in a user account, but I might be wrong.
>
> The burden of proof is still on your side as to whether or not the bug you
> found has any impact that was not already accepted by youtube allowing
> registered users to upload whatever crap they see fit as long as it is
> video. You failed to provide this proof, and please be sure the audience of
> fulldisclosure is not "attacking the researcher" but working with you to
> have a better understanding of the bug you found, even though you kinda
> acted like a fool in this thread.
>
> Please keep on searching and finding vulns, please keep on publishing
> them, and use this as a learning experience that not all bugs or control
> bypasses are security vulnerabilities.
>
> --Rob'
>
> [1] As per OWASP (https://www.owasp.org/index.php/Unrestricted_File_Upload
> ):
>
> >There are really two classes of problems here. The first is with the file
> metadata, like the path and file name. These are generally provided by the
> transport, such as HTTP multi-part encoding. This data may trick the
> application into overwriting a critical file or storing the file in a bad
> location. You must validate the metadata extremely carefully before using
> it.
>
> Your POC doesn't demonstrate that.
>
> >The other class of problem is with the file size or content. The range of
> problems here depends entirely on what the file is used for. See the
> examples below for some ideas about how files might be misused. To protect
> against this type of attack, you should analyze everything your application
> does with files and think carefully about what processing and interpreters
> are involved.
>
> Your POC kinda does that, but you didn't provide proof it's possible to
> execute what you uploaded, either using social engineering or any other
> method.
>
> Also, please don't say "verified by a couple of recognised experts
> including OWASP" unless you actually spoke with someone @owasp and she
> validated your findings.
>
>
> On Fri, Mar 14, 2014 at 7:40 PM, 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 ]
julius.kivimaki at gmail
Mar 14, 2014, 12:32 PM
Post #35 of 88 (9508 views)
Permalink
Wait, so "remote code execution by social engineering" wasn't a troll? I'm
confused.


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

> Then that also means that firewalls and IPS systems are worthless. Why
> spend so much time protecting the network layers if a user can send any
> file of choice to a remote network through http...
>
> As for the uploaded files being persistent, there is evidence of that.
> For instance a remote admin could be tricked to execute some of
> the uploaded files (Social Engineering).
>
> So our report sent as part of Google's security program, should not be
> treated as a non-security issue.
>
>
> Thanks,
>
>
> On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:
>
>> I'm going to try to spell it out clearly.
>>
>> You don't have unrestricted file upload[1]. Keep in mind you're trying to
>> abuse youtube, which is essentially a video file upload service. So the
>> fact that you can upload files is not surprising.
>> Now you're uploading non-video files. Cool. But not earth-shattering.
>> They are not accessible to anyone but you, as far as I can tell, and I
>> don't even think you can access the file contents on the remote server, but
>> please prove me wrong on both points.
>> You are still, as far as I can tell, bound by the per-file and
>> per-account quota on disk occupation, so you don't have a DoS by resource
>> exhaustion.
>> You can't force server-side file path, so you don't have RFI or DoS by
>> messing with the remote file system. You can't execute the files you
>> uploaded, so you don't have arbitrary code execution.
>>
>> But you are right about what your PoC does. You bypassed a security
>> control, you uploaded crap on youtube servers, and by that you exhausted
>> their resources by a fraction of the quota they allow you when signing up.
>> BTW, I don't think they keep invalid video files for an indefinite period
>> of time in a user account, but I might be wrong.
>>
>> The burden of proof is still on your side as to whether or not the bug
>> you found has any impact that was not already accepted by youtube allowing
>> registered users to upload whatever crap they see fit as long as it is
>> video. You failed to provide this proof, and please be sure the audience of
>> fulldisclosure is not "attacking the researcher" but working with you to
>> have a better understanding of the bug you found, even though you kinda
>> acted like a fool in this thread.
>>
>> Please keep on searching and finding vulns, please keep on publishing
>> them, and use this as a learning experience that not all bugs or control
>> bypasses are security vulnerabilities.
>>
>> --Rob'
>>
>> [1] As per OWASP (
>> https://www.owasp.org/index.php/Unrestricted_File_Upload):
>>
>> >There are really two classes of problems here. The first is with the
>> file metadata, like the path and file name. These are generally provided by
>> the transport, such as HTTP multi-part encoding. This data may trick the
>> application into overwriting a critical file or storing the file in a bad
>> location. You must validate the metadata extremely carefully before using
>> it.
>>
>> Your POC doesn't demonstrate that.
>>
>> >The other class of problem is with the file size or content. The range
>> of problems here depends entirely on what the file is used for. See the
>> examples below for some ideas about how files might be misused. To protect
>> against this type of attack, you should analyze everything your application
>> does with files and think carefully about what processing and interpreters
>> are involved.
>>
>> Your POC kinda does that, but you didn't provide proof it's possible to
>> execute what you uploaded, either using social engineering or any other
>> method.
>>
>> Also, please don't say "verified by a couple of recognised experts
>> including OWASP" unless you actually spoke with someone @owasp and she
>> validated your findings.
>>
>>
>> On Fri, Mar 14, 2014 at 7:40 PM, 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/
>>>
>>
>>
>
> _______________________________________________
> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 12:33 PM
Post #36 of 88 (9529 views)
Permalink
It is an example, citing that there has been a security hole on Youtube
that needs patching. End of Story.


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

> Wait, so "remote code execution by social engineering" wasn't a troll? I'm
> confused.
>
>
> 2014-03-14 21:28 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> Then that also means that firewalls and IPS systems are worthless. Why
>> spend so much time protecting the network layers if a user can send any
>> file of choice to a remote network through http...
>>
>> As for the uploaded files being persistent, there is evidence of that.
>> For instance a remote admin could be tricked to execute some of
>> the uploaded files (Social Engineering).
>>
>> So our report sent as part of Google's security program, should not be
>> treated as a non-security issue.
>>
>>
>> Thanks,
>>
>>
>> On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:
>>
>>> I'm going to try to spell it out clearly.
>>>
>>> You don't have unrestricted file upload[1]. Keep in mind you're trying
>>> to abuse youtube, which is essentially a video file upload service. So the
>>> fact that you can upload files is not surprising.
>>> Now you're uploading non-video files. Cool. But not earth-shattering.
>>> They are not accessible to anyone but you, as far as I can tell, and I
>>> don't even think you can access the file contents on the remote server, but
>>> please prove me wrong on both points.
>>> You are still, as far as I can tell, bound by the per-file and
>>> per-account quota on disk occupation, so you don't have a DoS by resource
>>> exhaustion.
>>> You can't force server-side file path, so you don't have RFI or DoS by
>>> messing with the remote file system. You can't execute the files you
>>> uploaded, so you don't have arbitrary code execution.
>>>
>>> But you are right about what your PoC does. You bypassed a security
>>> control, you uploaded crap on youtube servers, and by that you exhausted
>>> their resources by a fraction of the quota they allow you when signing up.
>>> BTW, I don't think they keep invalid video files for an indefinite period
>>> of time in a user account, but I might be wrong.
>>>
>>> The burden of proof is still on your side as to whether or not the bug
>>> you found has any impact that was not already accepted by youtube allowing
>>> registered users to upload whatever crap they see fit as long as it is
>>> video. You failed to provide this proof, and please be sure the audience of
>>> fulldisclosure is not "attacking the researcher" but working with you to
>>> have a better understanding of the bug you found, even though you kinda
>>> acted like a fool in this thread.
>>>
>>> Please keep on searching and finding vulns, please keep on publishing
>>> them, and use this as a learning experience that not all bugs or control
>>> bypasses are security vulnerabilities.
>>>
>>> --Rob'
>>>
>>> [1] As per OWASP (
>>> https://www.owasp.org/index.php/Unrestricted_File_Upload):
>>>
>>> >There are really two classes of problems here. The first is with the
>>> file metadata, like the path and file name. These are generally provided by
>>> the transport, such as HTTP multi-part encoding. This data may trick the
>>> application into overwriting a critical file or storing the file in a bad
>>> location. You must validate the metadata extremely carefully before using
>>> it.
>>>
>>> Your POC doesn't demonstrate that.
>>>
>>> >The other class of problem is with the file size or content. The range
>>> of problems here depends entirely on what the file is used for. See the
>>> examples below for some ideas about how files might be misused. To protect
>>> against this type of attack, you should analyze everything your application
>>> does with files and think carefully about what processing and interpreters
>>> are involved.
>>>
>>> Your POC kinda does that, but you didn't provide proof it's possible to
>>> execute what you uploaded, either using social engineering or any other
>>> method.
>>>
>>> Also, please don't say "verified by a couple of recognised experts
>>> including OWASP" unless you actually spoke with someone @owasp and she
>>> validated your findings.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 7:40 PM, 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/
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 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 ]
rd.seclists at gmail
Mar 14, 2014, 12:49 PM
Post #37 of 88 (9501 views)
Permalink
>Then that also means that firewalls and IPS systems are worthless. Why
spend so much time protecting the network layers if a user can send any
file of choice to a remote network through http...
well, if you are running a file upload system, or any webserver, you really
should block any incoming traffic to port 80, and if you can't of course
your IPS knows what a video file is and can whitelist that /s
That's why server-side controls are in place, and your POC doesn't show you
circumventing them.
>As for the uploaded files being persistent, there is evidence of that.
No. You have evidence they were uploaded. You don't have evidence they will
stay forever. When reporting a vulnerability, please try to not include
hyperbole, the reporters will do that for you.
>For instance a remote admin could be tricked to execute some of
the uploaded files
As I said, your uploaded files are not accessible to any user, unless you
prove me wrong. They are not executable (in the context of the webserver)
for any remote user, unless you can prove me wrong. They are not executable
in the context of an admin browsing the server content, unless the guys at
youtube made a major mistake, and you can't tell if they are, and neither
can I.
> (Social Engineering).
Ohai, youtube admin, could you please copy that file I can't give you the
path of, or even the server where it resides, to your home folder and
please chmod it 777 and then run it? For debugging purposes obviously
http://www.youtube.com/watch?v=oOqJ1F44_-Y

Have a nice day, and may the bug elves fill your socks with awesome
presents,

--Rob'



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

> Then that also means that firewalls and IPS systems are worthless. Why
> spend so much time protecting the network layers if a user can send any
> file of choice to a remote network through http...
>
> As for the uploaded files being persistent, there is evidence of that.
> For instance a remote admin could be tricked to execute some of
> the uploaded files (Social Engineering).
>
> So our report sent as part of Google's security program, should not be
> treated as a non-security issue.
>
>
> Thanks,
>
>
> On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:
>
>> I'm going to try to spell it out clearly.
>>
>> You don't have unrestricted file upload[1]. Keep in mind you're trying to
>> abuse youtube, which is essentially a video file upload service. So the
>> fact that you can upload files is not surprising.
>> Now you're uploading non-video files. Cool. But not earth-shattering.
>> They are not accessible to anyone but you, as far as I can tell, and I
>> don't even think you can access the file contents on the remote server, but
>> please prove me wrong on both points.
>> You are still, as far as I can tell, bound by the per-file and
>> per-account quota on disk occupation, so you don't have a DoS by resource
>> exhaustion.
>> You can't force server-side file path, so you don't have RFI or DoS by
>> messing with the remote file system. You can't execute the files you
>> uploaded, so you don't have arbitrary code execution.
>>
>> But you are right about what your PoC does. You bypassed a security
>> control, you uploaded crap on youtube servers, and by that you exhausted
>> their resources by a fraction of the quota they allow you when signing up.
>> BTW, I don't think they keep invalid video files for an indefinite period
>> of time in a user account, but I might be wrong.
>>
>> The burden of proof is still on your side as to whether or not the bug
>> you found has any impact that was not already accepted by youtube allowing
>> registered users to upload whatever crap they see fit as long as it is
>> video. You failed to provide this proof, and please be sure the audience of
>> fulldisclosure is not "attacking the researcher" but working with you to
>> have a better understanding of the bug you found, even though you kinda
>> acted like a fool in this thread.
>>
>> Please keep on searching and finding vulns, please keep on publishing
>> them, and use this as a learning experience that not all bugs or control
>> bypasses are security vulnerabilities.
>>
>> --Rob'
>>
>> [1] As per OWASP (
>> https://www.owasp.org/index.php/Unrestricted_File_Upload):
>>
>> >There are really two classes of problems here. The first is with the
>> file metadata, like the path and file name. These are generally provided by
>> the transport, such as HTTP multi-part encoding. This data may trick the
>> application into overwriting a critical file or storing the file in a bad
>> location. You must validate the metadata extremely carefully before using
>> it.
>>
>> Your POC doesn't demonstrate that.
>>
>> >The other class of problem is with the file size or content. The range
>> of problems here depends entirely on what the file is used for. See the
>> examples below for some ideas about how files might be misused. To protect
>> against this type of attack, you should analyze everything your application
>> does with files and think carefully about what processing and interpreters
>> are involved.
>>
>> Your POC kinda does that, but you didn't provide proof it's possible to
>> execute what you uploaded, either using social engineering or any other
>> method.
>>
>> Also, please don't say "verified by a couple of recognised experts
>> including OWASP" unless you actually spoke with someone @owasp and she
>> validated your findings.
>>
>>
>> On Fri, Mar 14, 2014 at 7:40 PM, 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 ]
christhom7851 at gmail
Mar 14, 2014, 1:00 PM
Post #38 of 88 (9504 views)
Permalink
Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how it
feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you why
people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a Youtube
whereby it appears (to you) than you can upload an arbitrary file. If you
can indeed do this as you suspect then your points are valid and you "may"
be able to cause various issues associated with it such as DOS etc -
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back (the
JSON response) in your example is simply a response from the API to say the
file you uploaded has been received and saved.

Now, as you no doubt know, when you upload a regular movie to YouTube, once
uploaded it goes away and does some post-processing, converting it to flash
for example. What's to say that there isn't some verification aspect to
this post-processing that checks if the file is intact a valid movie and if
not removes it.

If you could for example demonstrate that the file was indeed persistent,
by being able to retrieve it for example then again, you would have solid
ground to claim an issue however your claims at this point are based on an
assumption.... Let me explain.

1. You have demonstrated than you can send "any" file to an API and the API
returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process them and validate them - we
simply don't know.

3. You have hypothesized that you can retrieve the file by manipulating
tokens etc and you may be right, but you have not demonstrated it as such.

Because of this, you seem to have made a CLAIM that you can upload
arbitrary files to Google however SHOWN that you can simply send files to
an API and an API responds in a certain way.

I am NOT saying you haven't found an issue, what I am saying is that you
need to demonstrate that the issue is real and thus can be abused. If the
Google service simply verifies all uploaded files once they are uploaded
and discards them if invalid, then you haven't really found anything.

If you were to prove that you were able to retrieve this uploaded file then
how could anyone dispute your bug.

Hope this helps....

Cheers!
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 1:04 PM
Post #39 of 88 (9523 views)
Permalink
http://upload.youtube.com/?authuser=0&upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

That information can be queried from the db, where the metadata are saved.
The files are being saved persistently , as per the above example.


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

>
> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>
> That information can be queried from the db, where the metadata are saved.
> The files are being saved persistently , as per the above example.
>
>
> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <christhom7851@gmail.com>wrote:
>
>> Hi Nikolas,
>>
>> Please do read (and understand) my entire email before responding - I
>> understand your frustration trying to get your message across but maybe
>> this will help.
>>
>> Please put aside professional pride for the time being - I know how it
>> feels to be passionate about something yet have others simply not
>> understand.
>>
>> Let me try and bring some sanity to the discussion and explain to you why
>> people maybe not agreeing with you.
>>
>> You (rightly so) highlighted what you believe to be an issue in a Youtube
>> whereby it appears (to you) than you can upload an arbitrary file. If you
>> can indeed do this as you suspect then your points are valid and you "may"
>> be able to cause various issues associated with it such as DOS etc -
>> especially if the uploaded files cannot or are not tracked.
>>
>> However...
>>
>> Consider than you are talking to an API and what you are getting back
>> (the JSON response) in your example is simply a response from the API to
>> say the file you uploaded has been received and saved.
>>
>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>> once uploaded it goes away and does some post-processing, converting it to
>> flash for example. What's to say that there isn't some verification aspect
>> to this post-processing that checks if the file is intact a valid movie and
>> if not removes it.
>>
>> If you could for example demonstrate that the file was indeed persistent,
>> by being able to retrieve it for example then again, you would have solid
>> ground to claim an issue however your claims at this point are based on an
>> assumption.... Let me explain.
>>
>> 1. You have demonstrated than you can send "any" file to an API and the
>> API returned an acknowledgment of receiving (and saving) the file.
>>
>> 2. You / we don't know what Google do with files once they have been
>> received from the API - maybe they process them and validate them - we
>> simply don't know.
>>
>> 3. You have hypothesized that you can retrieve the file by manipulating
>> tokens etc and you may be right, but you have not demonstrated it as such.
>>
>> Because of this, you seem to have made a CLAIM that you can upload
>> arbitrary files to Google however SHOWN that you can simply send files to
>> an API and an API responds in a certain way.
>>
>> I am NOT saying you haven't found an issue, what I am saying is that you
>> need to demonstrate that the issue is real and thus can be abused. If the
>> Google service simply verifies all uploaded files once they are uploaded
>> and discards them if invalid, then you haven't really found anything.
>>
>> If you were to prove that you were able to retrieve this uploaded file
>> then how could anyone dispute your bug.
>>
>> Hope this helps....
>>
>> Cheers!
>>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 1:08 PM
Post #40 of 88 (9514 views)
Permalink
My claim is now verified....

Cheers!


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

> http://upload.youtube.com/?authuser=0&upload_id=
> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>
> That information can be queried from the db, where the metadata are saved.
> The files are being saved persistently , as per the above example.
>
>
> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>>
>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>
>> That information can be queried from the db, where the metadata are
>> saved. The files are being saved persistently , as per the above example.
>>
>>
>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <christhom7851@gmail.com>wrote:
>>
>>> Hi Nikolas,
>>>
>>> Please do read (and understand) my entire email before responding - I
>>> understand your frustration trying to get your message across but maybe
>>> this will help.
>>>
>>> Please put aside professional pride for the time being - I know how it
>>> feels to be passionate about something yet have others simply not
>>> understand.
>>>
>>> Let me try and bring some sanity to the discussion and explain to you
>>> why people maybe not agreeing with you.
>>>
>>> You (rightly so) highlighted what you believe to be an issue in a
>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>> If you can indeed do this as you suspect then your points are valid and you
>>> "may" be able to cause various issues associated with it such as DOS etc -
>>> especially if the uploaded files cannot or are not tracked.
>>>
>>> However...
>>>
>>> Consider than you are talking to an API and what you are getting back
>>> (the JSON response) in your example is simply a response from the API to
>>> say the file you uploaded has been received and saved.
>>>
>>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>>> once uploaded it goes away and does some post-processing, converting it to
>>> flash for example. What's to say that there isn't some verification aspect
>>> to this post-processing that checks if the file is intact a valid movie and
>>> if not removes it.
>>>
>>> If you could for example demonstrate that the file was indeed
>>> persistent, by being able to retrieve it for example then again, you would
>>> have solid ground to claim an issue however your claims at this point are
>>> based on an assumption.... Let me explain.
>>>
>>> 1. You have demonstrated than you can send "any" file to an API and the
>>> API returned an acknowledgment of receiving (and saving) the file.
>>>
>>> 2. You / we don't know what Google do with files once they have been
>>> received from the API - maybe they process them and validate them - we
>>> simply don't know.
>>>
>>> 3. You have hypothesized that you can retrieve the file by manipulating
>>> tokens etc and you may be right, but you have not demonstrated it as such.
>>>
>>> Because of this, you seem to have made a CLAIM that you can upload
>>> arbitrary files to Google however SHOWN that you can simply send files to
>>> an API and an API responds in a certain way.
>>>
>>> I am NOT saying you haven't found an issue, what I am saying is that you
>>> need to demonstrate that the issue is real and thus can be abused. If the
>>> Google service simply verifies all uploaded files once they are uploaded
>>> and discards them if invalid, then you haven't really found anything.
>>>
>>> If you were to prove that you were able to retrieve this uploaded file
>>> then how could anyone dispute your bug.
>>>
>>> Hope this helps....
>>>
>>> Cheers!
>>>
>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 1:16 PM
Post #41 of 88 (9527 views)
Permalink
So you can query a file that I uploaded, and you can see that is uploaded
successfully and saved. That information does not require the user to be
logged in.


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

> My claim is now verified....
>
> Cheers!
>
>
> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> http://upload.youtube.com/?authuser=0&upload_id=
>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>
>> That information can be queried from the db, where the metadata are
>> saved. The files are being saved persistently , as per the above example.
>>
>>
>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>>
>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>
>>> That information can be queried from the db, where the metadata are
>>> saved. The files are being saved persistently , as per the above example.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <christhom7851@gmail.com
>>> > wrote:
>>>
>>>> Hi Nikolas,
>>>>
>>>> Please do read (and understand) my entire email before responding - I
>>>> understand your frustration trying to get your message across but maybe
>>>> this will help.
>>>>
>>>> Please put aside professional pride for the time being - I know how it
>>>> feels to be passionate about something yet have others simply not
>>>> understand.
>>>>
>>>> Let me try and bring some sanity to the discussion and explain to you
>>>> why people maybe not agreeing with you.
>>>>
>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>> If you can indeed do this as you suspect then your points are valid and you
>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>> especially if the uploaded files cannot or are not tracked.
>>>>
>>>> However...
>>>>
>>>> Consider than you are talking to an API and what you are getting back
>>>> (the JSON response) in your example is simply a response from the API to
>>>> say the file you uploaded has been received and saved.
>>>>
>>>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>>>> once uploaded it goes away and does some post-processing, converting it to
>>>> flash for example. What's to say that there isn't some verification aspect
>>>> to this post-processing that checks if the file is intact a valid movie and
>>>> if not removes it.
>>>>
>>>> If you could for example demonstrate that the file was indeed
>>>> persistent, by being able to retrieve it for example then again, you would
>>>> have solid ground to claim an issue however your claims at this point are
>>>> based on an assumption.... Let me explain.
>>>>
>>>> 1. You have demonstrated than you can send "any" file to an API and the
>>>> API returned an acknowledgment of receiving (and saving) the file.
>>>>
>>>> 2. You / we don't know what Google do with files once they have been
>>>> received from the API - maybe they process them and validate them - we
>>>> simply don't know.
>>>>
>>>> 3. You have hypothesized that you can retrieve the file by manipulating
>>>> tokens etc and you may be right, but you have not demonstrated it as such.
>>>>
>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>> an API and an API responds in a certain way.
>>>>
>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>> the Google service simply verifies all uploaded files once they are
>>>> uploaded and discards them if invalid, then you haven't really found
>>>> anything.
>>>>
>>>> If you were to prove that you were able to retrieve this uploaded file
>>>> then how could anyone dispute your bug.
>>>>
>>>> Hope this helps....
>>>>
>>>> Cheers!
>>>>
>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
christhom7851 at gmail
Mar 14, 2014, 1:16 PM
Post #42 of 88 (9505 views)
Permalink
Hi Nicholas,

Again, you hypothesize that you are getting a response from the database,
but you really don't know that. You have no idea when the code is doing
behind the endpoint.

upload.youtube.com is simple an endpoint that you are sending a request to
and getting a response from -

Can you upload a ZIP file for example and then get that same ZIP file from
another machine? If you can do that, then who can question your bug.

Again, i'm not trying to be a dick - just trying to help!

Cheers...



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

> My claim is now verified....
>
> Cheers!
>
>
> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> http://upload.youtube.com/?authuser=0&upload_id=
>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>
>> That information can be queried from the db, where the metadata are
>> saved. The files are being saved persistently , as per the above example.
>>
>>
>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>>
>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>
>>> That information can be queried from the db, where the metadata are
>>> saved. The files are being saved persistently , as per the above example.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <christhom7851@gmail.com
>>> > wrote:
>>>
>>>> Hi Nikolas,
>>>>
>>>> Please do read (and understand) my entire email before responding - I
>>>> understand your frustration trying to get your message across but maybe
>>>> this will help.
>>>>
>>>> Please put aside professional pride for the time being - I know how it
>>>> feels to be passionate about something yet have others simply not
>>>> understand.
>>>>
>>>> Let me try and bring some sanity to the discussion and explain to you
>>>> why people maybe not agreeing with you.
>>>>
>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>> If you can indeed do this as you suspect then your points are valid and you
>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>> especially if the uploaded files cannot or are not tracked.
>>>>
>>>> However...
>>>>
>>>> Consider than you are talking to an API and what you are getting back
>>>> (the JSON response) in your example is simply a response from the API to
>>>> say the file you uploaded has been received and saved.
>>>>
>>>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>>>> once uploaded it goes away and does some post-processing, converting it to
>>>> flash for example. What's to say that there isn't some verification aspect
>>>> to this post-processing that checks if the file is intact a valid movie and
>>>> if not removes it.
>>>>
>>>> If you could for example demonstrate that the file was indeed
>>>> persistent, by being able to retrieve it for example then again, you would
>>>> have solid ground to claim an issue however your claims at this point are
>>>> based on an assumption.... Let me explain.
>>>>
>>>> 1. You have demonstrated than you can send "any" file to an API and the
>>>> API returned an acknowledgment of receiving (and saving) the file.
>>>>
>>>> 2. You / we don't know what Google do with files once they have been
>>>> received from the API - maybe they process them and validate them - we
>>>> simply don't know.
>>>>
>>>> 3. You have hypothesized that you can retrieve the file by manipulating
>>>> tokens etc and you may be right, but you have not demonstrated it as such.
>>>>
>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>> an API and an API responds in a certain way.
>>>>
>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>> the Google service simply verifies all uploaded files once they are
>>>> uploaded and discards them if invalid, then you haven't really found
>>>> anything.
>>>>
>>>> If you were to prove that you were able to retrieve this uploaded file
>>>> then how could anyone dispute your bug.
>>>>
>>>> Hope this helps....
>>>>
>>>> Cheers!
>>>>
>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
rd.seclists at gmail
Mar 14, 2014, 1:20 PM
Post #43 of 88 (9517 views)
Permalink
No it's not. As Chris and I are saying, you don't have proof your file is
accessible to others, only that is was uploaded. Now, you see, when you
upload a video to youtube, you get the adress where it will be viewable in
the response. In your case :
{"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
","cross_domain_url":"
http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
"ok", *"video_id": "KzKDtijwHFI"*
}}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
And what do we get when we browse to https://youtube.com/watch?v=KzKDtijwHFI?
Nothing.
Can you send me a link where I can access the file content of the arbitrary
file you uploaded?
Are you sure this json response, or this file, will be there in a month? Or
in a year? Is the fact that this json response exists a threat to youtube?
Can you quantify how of a threat? How much, in dollars, does it hurt their
business?

--Rob


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

> My claim is now verified....
>
> Cheers!
>
>
> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> http://upload.youtube.com/?authuser=0&upload_id=
>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>
>> That information can be queried from the db, where the metadata are
>> saved. The files are being saved persistently , as per the above example.
>>
>>
>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>>
>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>
>>> That information can be queried from the db, where the metadata are
>>> saved. The files are being saved persistently , as per the above example.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <christhom7851@gmail.com
>>> > wrote:
>>>
>>>> Hi Nikolas,
>>>>
>>>> Please do read (and understand) my entire email before responding - I
>>>> understand your frustration trying to get your message across but maybe
>>>> this will help.
>>>>
>>>> Please put aside professional pride for the time being - I know how it
>>>> feels to be passionate about something yet have others simply not
>>>> understand.
>>>>
>>>> Let me try and bring some sanity to the discussion and explain to you
>>>> why people maybe not agreeing with you.
>>>>
>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>> If you can indeed do this as you suspect then your points are valid and you
>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>> especially if the uploaded files cannot or are not tracked.
>>>>
>>>> However...
>>>>
>>>> Consider than you are talking to an API and what you are getting back
>>>> (the JSON response) in your example is simply a response from the API to
>>>> say the file you uploaded has been received and saved.
>>>>
>>>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>>>> once uploaded it goes away and does some post-processing, converting it to
>>>> flash for example. What's to say that there isn't some verification aspect
>>>> to this post-processing that checks if the file is intact a valid movie and
>>>> if not removes it.
>>>>
>>>> If you could for example demonstrate that the file was indeed
>>>> persistent, by being able to retrieve it for example then again, you would
>>>> have solid ground to claim an issue however your claims at this point are
>>>> based on an assumption.... Let me explain.
>>>>
>>>> 1. You have demonstrated than you can send "any" file to an API and the
>>>> API returned an acknowledgment of receiving (and saving) the file.
>>>>
>>>> 2. You / we don't know what Google do with files once they have been
>>>> received from the API - maybe they process them and validate them - we
>>>> simply don't know.
>>>>
>>>> 3. You have hypothesized that you can retrieve the file by manipulating
>>>> tokens etc and you may be right, but you have not demonstrated it as such.
>>>>
>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>> an API and an API responds in a certain way.
>>>>
>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>> the Google service simply verifies all uploaded files once they are
>>>> uploaded and discards them if invalid, then you haven't really found
>>>> anything.
>>>>
>>>> If you were to prove that you were able to retrieve this uploaded file
>>>> then how could anyone dispute your bug.
>>>>
>>>> Hope this helps....
>>>>
>>>> Cheers!
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 1:22 PM
Post #44 of 88 (9524 views)
Permalink
You are trying to execute an sh script through a video player. That's an
exec() command. So its the wrong way about accessing the file.


On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:

> No it's not. As Chris and I are saying, you don't have proof your file is
> accessible to others, only that is was uploaded. Now, you see, when you
> upload a video to youtube, you get the adress where it will be viewable in
> the response. In your case :
>
> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
> http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
> ","cross_domain_url":"
> http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
> "ok", *"video_id": "KzKDtijwHFI"*
> }}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
> And what do we get when we browse to
> https://youtube.com/watch?v=KzKDtijwHFI ?
> Nothing.
> Can you send me a link where I can access the file content of the
> arbitrary file you uploaded?
> Are you sure this json response, or this file, will be there in a month?
> Or in a year? Is the fact that this json response exists a threat to
> youtube? Can you quantify how of a threat? How much, in dollars, does it
> hurt their business?
>
> --Rob
>
>
> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> My claim is now verified....
>>
>> Cheers!
>>
>>
>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> http://upload.youtube.com/?authuser=0&upload_id=
>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>
>>> That information can be queried from the db, where the metadata are
>>> saved. The files are being saved persistently , as per the above example.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>>
>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>
>>>> That information can be queried from the db, where the metadata are
>>>> saved. The files are being saved persistently , as per the above example.
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>> christhom7851@gmail.com> wrote:
>>>>
>>>>> Hi Nikolas,
>>>>>
>>>>> Please do read (and understand) my entire email before responding - I
>>>>> understand your frustration trying to get your message across but maybe
>>>>> this will help.
>>>>>
>>>>> Please put aside professional pride for the time being - I know how it
>>>>> feels to be passionate about something yet have others simply not
>>>>> understand.
>>>>>
>>>>> Let me try and bring some sanity to the discussion and explain to you
>>>>> why people maybe not agreeing with you.
>>>>>
>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>
>>>>> However...
>>>>>
>>>>> Consider than you are talking to an API and what you are getting back
>>>>> (the JSON response) in your example is simply a response from the API to
>>>>> say the file you uploaded has been received and saved.
>>>>>
>>>>> Now, as you no doubt know, when you upload a regular movie to YouTube,
>>>>> once uploaded it goes away and does some post-processing, converting it to
>>>>> flash for example. What's to say that there isn't some verification aspect
>>>>> to this post-processing that checks if the file is intact a valid movie and
>>>>> if not removes it.
>>>>>
>>>>> If you could for example demonstrate that the file was indeed
>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>> have solid ground to claim an issue however your claims at this point are
>>>>> based on an assumption.... Let me explain.
>>>>>
>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>
>>>>> 2. You / we don't know what Google do with files once they have been
>>>>> received from the API - maybe they process them and validate them - we
>>>>> simply don't know.
>>>>>
>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>> it as such.
>>>>>
>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>> an API and an API responds in a certain way.
>>>>>
>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>> the Google service simply verifies all uploaded files once they are
>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>> anything.
>>>>>
>>>>> If you were to prove that you were able to retrieve this uploaded file
>>>>> then how could anyone dispute your bug.
>>>>>
>>>>> Hope this helps....
>>>>>
>>>>> Cheers!
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 1:23 PM
Post #45 of 88 (9516 views)
Permalink
Are you sure this json response, or this file, will be there in a month? Or
in a year? Is the fact that this json response exists a threat to youtube?
Can you quantify how of a threat? How much, in dollars, does it hurt their
business?

This file may be here if the admins don't delete it. Now they may do ;@)


So where do you think that information is coming from? The metadata and
tags, and headers are contained in a database.

The files are stored persistently , since they can be quoted. So the API
works both ways. The main thing here is that the files are there, otherwise
there metadata information would be deleted from the db aswell.

http://gdata.youtube.com/demo/index.html?utm_source=
twitterfeed&utm_medium=twitter

Youtube DATA API is unique.. the commands can be send through that
interface... So we do definitely know that that is coming from a database.


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

> You are trying to execute an sh script through a video player. That's an
> exec() command. So its the wrong way about accessing the file.
>
>
> On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:
>
>> No it's not. As Chris and I are saying, you don't have proof your file is
>> accessible to others, only that is was uploaded. Now, you see, when you
>> upload a video to youtube, you get the adress where it will be viewable in
>> the response. In your case :
>>
>> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
>> http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
>> ","cross_domain_url":"
>> http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
>> "ok", *"video_id": "KzKDtijwHFI"*
>> }}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
>> And what do we get when we browse to
>> https://youtube.com/watch?v=KzKDtijwHFI ?
>> Nothing.
>> Can you send me a link where I can access the file content of the
>> arbitrary file you uploaded?
>> Are you sure this json response, or this file, will be there in a month?
>> Or in a year? Is the fact that this json response exists a threat to
>> youtube? Can you quantify how of a threat? How much, in dollars, does it
>> hurt their business?
>>
>> --Rob
>>
>>
>> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> My claim is now verified....
>>>
>>> Cheers!
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>
>>>> That information can be queried from the db, where the metadata are
>>>> saved. The files are being saved persistently , as per the above example.
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>> christhom7851@gmail.com> wrote:
>>>>>
>>>>>> Hi Nikolas,
>>>>>>
>>>>>> Please do read (and understand) my entire email before responding - I
>>>>>> understand your frustration trying to get your message across but maybe
>>>>>> this will help.
>>>>>>
>>>>>> Please put aside professional pride for the time being - I know how
>>>>>> it feels to be passionate about something yet have others simply not
>>>>>> understand.
>>>>>>
>>>>>> Let me try and bring some sanity to the discussion and explain to you
>>>>>> why people maybe not agreeing with you.
>>>>>>
>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>
>>>>>> However...
>>>>>>
>>>>>> Consider than you are talking to an API and what you are getting back
>>>>>> (the JSON response) in your example is simply a response from the API to
>>>>>> say the file you uploaded has been received and saved.
>>>>>>
>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>> intact a valid movie and if not removes it.
>>>>>>
>>>>>> If you could for example demonstrate that the file was indeed
>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>> based on an assumption.... Let me explain.
>>>>>>
>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>
>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>> received from the API - maybe they process them and validate them - we
>>>>>> simply don't know.
>>>>>>
>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>> it as such.
>>>>>>
>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>> an API and an API responds in a certain way.
>>>>>>
>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>> anything.
>>>>>>
>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>> file then how could anyone dispute your bug.
>>>>>>
>>>>>> Hope this helps....
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 1:25 PM
Post #46 of 88 (9515 views)
Permalink
So where do you think that information is coming from? The metadata and
tags, and headers are contained in a database.

The files are stored persistently , since they can be quoted. So the API
works both ways. The main thing here is that the files are there, otherwise
there metadata information would be deleted from the db aswell.

http://gdata.youtube.com/demo/index.html?utm_source=
twitterfeed&utm_medium=twitter

Youtube DATA API is unique.. the commands can be send through that
interface... So we do definitely know that that is coming from a database.
That same video id can be queried through the above link. Having done so, I
confirmed that the information originate from a direct connection to the
db, where the data are stored.


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

> So where do you think that information is coming from? The metadata and
> tags, and headers are contained in a database.
>
> The files are stored persistently , since they can be quoted. So the API
> works both ways. The main thing here is that the files are there, otherwise
> there metadata information would be deleted from the db aswell.
>
>
> http://gdata.youtube.com/demo/index.html?utm_source=twitterfeed&utm_medium=twitter
>
> Youtube DATA API is unique.. the commands can be send through that
> interface... So we do definitely know that that is coming from a database.
>
>
> On Fri, Mar 14, 2014 at 8:16 PM, Chris Thompson <christhom7851@gmail.com>wrote:
>
>> Hi Nicholas,
>>
>> Again, you hypothesize that you are getting a response from the database,
>> but you really don't know that. You have no idea when the code is doing
>> behind the endpoint.
>>
>> upload.youtube.com is simple an endpoint that you are sending a request
>> to and getting a response from -
>>
>> Can you upload a ZIP file for example and then get that same ZIP file
>> from another machine? If you can do that, then who can question your bug.
>>
>> Again, i'm not trying to be a dick - just trying to help!
>>
>> Cheers...
>>
>>
>>
>> On Fri, Mar 14, 2014 at 4:08 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> My claim is now verified....
>>>
>>> Cheers!
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>
>>>> That information can be queried from the db, where the metadata are
>>>> saved. The files are being saved persistently , as per the above example.
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>> christhom7851@gmail.com> wrote:
>>>>>
>>>>>> Hi Nikolas,
>>>>>>
>>>>>> Please do read (and understand) my entire email before responding - I
>>>>>> understand your frustration trying to get your message across but maybe
>>>>>> this will help.
>>>>>>
>>>>>> Please put aside professional pride for the time being - I know how
>>>>>> it feels to be passionate about something yet have others simply not
>>>>>> understand.
>>>>>>
>>>>>> Let me try and bring some sanity to the discussion and explain to you
>>>>>> why people maybe not agreeing with you.
>>>>>>
>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>
>>>>>> However...
>>>>>>
>>>>>> Consider than you are talking to an API and what you are getting back
>>>>>> (the JSON response) in your example is simply a response from the API to
>>>>>> say the file you uploaded has been received and saved.
>>>>>>
>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>> intact a valid movie and if not removes it.
>>>>>>
>>>>>> If you could for example demonstrate that the file was indeed
>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>> based on an assumption.... Let me explain.
>>>>>>
>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>
>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>> received from the API - maybe they process them and validate them - we
>>>>>> simply don't know.
>>>>>>
>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>> it as such.
>>>>>>
>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>> an API and an API responds in a certain way.
>>>>>>
>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>> anything.
>>>>>>
>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>> file then how could anyone dispute your bug.
>>>>>>
>>>>>> Hope this helps....
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 1:27 PM
Post #47 of 88 (9515 views)
Permalink
In my expertise, that is a vulnerability.

Now if Google doesn't want to fix patch that, it's their choice. However I
have already disclosed that to them.




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

> So where do you think that information is coming from? The metadata and
> tags, and headers are contained in a database.
>
> The files are stored persistently , since they can be quoted. So the API
> works both ways. The main thing here is that the files are there, otherwise
> there metadata information would be deleted from the db aswell.
>
> http://gdata.youtube.com/demo/index.html?utm_source=
> twitterfeed&utm_medium=twitter
>
> Youtube DATA API is unique.. the commands can be send through that
> interface... So we do definitely know that that is coming from a database.
> That same video id can be queried through the above link. Having done so, I
> confirmed that the information originate from a direct connection to the
> db, where the data are stored.
>
>
> On Fri, Mar 14, 2014 at 8:20 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> So where do you think that information is coming from? The metadata and
>> tags, and headers are contained in a database.
>>
>> The files are stored persistently , since they can be quoted. So the API
>> works both ways. The main thing here is that the files are there, otherwise
>> there metadata information would be deleted from the db aswell.
>>
>>
>> http://gdata.youtube.com/demo/index.html?utm_source=twitterfeed&utm_medium=twitter
>>
>> Youtube DATA API is unique.. the commands can be send through that
>> interface... So we do definitely know that that is coming from a database.
>>
>>
>> On Fri, Mar 14, 2014 at 8:16 PM, Chris Thompson <christhom7851@gmail.com>wrote:
>>
>>> Hi Nicholas,
>>>
>>> Again, you hypothesize that you are getting a response from the
>>> database, but you really don't know that. You have no idea when the code is
>>> doing behind the endpoint.
>>>
>>> upload.youtube.com is simple an endpoint that you are sending a request
>>> to and getting a response from -
>>>
>>> Can you upload a ZIP file for example and then get that same ZIP file
>>> from another machine? If you can do that, then who can question your bug.
>>>
>>> Again, i'm not trying to be a dick - just trying to help!
>>>
>>> Cheers...
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 4:08 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> My claim is now verified....
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>>> christhom7851@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Nikolas,
>>>>>>>
>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>> this will help.
>>>>>>>
>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>> understand.
>>>>>>>
>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>> you why people maybe not agreeing with you.
>>>>>>>
>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>
>>>>>>> However...
>>>>>>>
>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>
>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>> intact a valid movie and if not removes it.
>>>>>>>
>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>> based on an assumption.... Let me explain.
>>>>>>>
>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>
>>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>>> received from the API - maybe they process them and validate them - we
>>>>>>> simply don't know.
>>>>>>>
>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>> it as such.
>>>>>>>
>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>>> an API and an API responds in a certain way.
>>>>>>>
>>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>>> anything.
>>>>>>>
>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>> file then how could anyone dispute your bug.
>>>>>>>
>>>>>>> Hope this helps....
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
kkotowicz+fd at gmail
Mar 14, 2014, 1:40 PM
Post #48 of 88 (9496 views)
Permalink
2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>:

> Then that also means that firewalls and IPS systems are worthless. Why
> spend so much time protecting the network layers if a user can send any
> file of choice to a remote network through http...
>

No, they are not worthless per se, but of course for an user content
publishing service they need to allow file upload over HTTP/s. How far
those files are inspected and later processed is another question - and
that could lead to a vulnerability that you DIDN'T demonstrate.

You just uploaded a .sh file. There's no harm in that as nowhere did you
prove that that file is being executed. Similarly (and that has been
pointed out in this thread) you could upload a PHP-GIF polyglot file to a
J2EE application - no vulnerability in this. Prove something by overwriting
a crucial file, tricking other user's browser to execute the file as HTML
from an interesting domain (XSS), popping a shell, triggering XXE when the
file is processed as XML, anything. Then that is a vulnerability. So far -
sorry, it is not, and you've been told it repeatedly.


As for the uploaded files being persistent, there is evidence of that. For
> instance a remote admin could be tricked to execute some of the uploaded
> files (Social Engineering).
>

Come on, seriously? Social Engineering can make him download this file from
pastebin just as well. That's a real stretch.

IMHO it is not a security issue. You're uploading a file to some kind of
processing queue that does not validate a file type, but nevertheless only
processes those files as video - there is NO reason to suspect otherwise,
and I'd like to be proven wrong here. Proven as in PoC.
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
mvilas at gmail
Mar 14, 2014, 3:53 PM
Post #49 of 88 (9547 views)
Permalink
[image: Inline image 1]


On Fri, Mar 14, 2014 at 7:07 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: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
>>>
>>
>>
>
> _______________________________________________
> 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 ]
mvilas at gmail
Mar 14, 2014, 3:58 PM
Post #50 of 88 (9513 views)
Permalink
So if you can upload a file to Google Drive and trick someone to run it,
you'd call that a vulnerability too?

Hey, I've got another one. I can upload a video on Youtube telling people
to download and install a virus. I'll claim a prize too!

Keep at it man, you're hilarious! xDDD

/me goes grab more popcorn


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

> Then that also means that firewalls and IPS systems are worthless. Why
> spend so much time protecting the network layers if a user can send any
> file of choice to a remote network through http...
>
> As for the uploaded files being persistent, there is evidence of that.
> For instance a remote admin could be tricked to execute some of
> the uploaded files (Social Engineering).
>
> So our report sent as part of Google's security program, should not be
> treated as a non-security issue.
>
>
> Thanks,
>
>
> On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:
>
>> I'm going to try to spell it out clearly.
>>
>> You don't have unrestricted file upload[1]. Keep in mind you're trying to
>> abuse youtube, which is essentially a video file upload service. So the
>> fact that you can upload files is not surprising.
>> Now you're uploading non-video files. Cool. But not earth-shattering.
>> They are not accessible to anyone but you, as far as I can tell, and I
>> don't even think you can access the file contents on the remote server, but
>> please prove me wrong on both points.
>> You are still, as far as I can tell, bound by the per-file and
>> per-account quota on disk occupation, so you don't have a DoS by resource
>> exhaustion.
>> You can't force server-side file path, so you don't have RFI or DoS by
>> messing with the remote file system. You can't execute the files you
>> uploaded, so you don't have arbitrary code execution.
>>
>> But you are right about what your PoC does. You bypassed a security
>> control, you uploaded crap on youtube servers, and by that you exhausted
>> their resources by a fraction of the quota they allow you when signing up.
>> BTW, I don't think they keep invalid video files for an indefinite period
>> of time in a user account, but I might be wrong.
>>
>> The burden of proof is still on your side as to whether or not the bug
>> you found has any impact that was not already accepted by youtube allowing
>> registered users to upload whatever crap they see fit as long as it is
>> video. You failed to provide this proof, and please be sure the audience of
>> fulldisclosure is not "attacking the researcher" but working with you to
>> have a better understanding of the bug you found, even though you kinda
>> acted like a fool in this thread.
>>
>> Please keep on searching and finding vulns, please keep on publishing
>> them, and use this as a learning experience that not all bugs or control
>> bypasses are security vulnerabilities.
>>
>> --Rob'
>>
>> [1] As per OWASP (
>> https://www.owasp.org/index.php/Unrestricted_File_Upload):
>>
>> >There are really two classes of problems here. The first is with the
>> file metadata, like the path and file name. These are generally provided by
>> the transport, such as HTTP multi-part encoding. This data may trick the
>> application into overwriting a critical file or storing the file in a bad
>> location. You must validate the metadata extremely carefully before using
>> it.
>>
>> Your POC doesn't demonstrate that.
>>
>> >The other class of problem is with the file size or content. The range
>> of problems here depends entirely on what the file is used for. See the
>> examples below for some ideas about how files might be misused. To protect
>> against this type of attack, you should analyze everything your application
>> does with files and think carefully about what processing and interpreters
>> are involved.
>>
>> Your POC kinda does that, but you didn't provide proof it's possible to
>> execute what you uploaded, either using social engineering or any other
>> method.
>>
>> Also, please don't say "verified by a couple of recognised experts
>> including OWASP" unless you actually spoke with someone @owasp and she
>> validated your findings.
>>
>>
>> On Fri, Mar 14, 2014 at 7:40 PM, 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/
>>>
>>
>>
>
> _______________________________________________
> 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 ]
mvilas at gmail
Mar 14, 2014, 4:17 PM
Post #51 of 88 (14119 views)
Permalink
Please provide an attack scenario. Can you do that?



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

> Are you sure this json response, or this file, will be there in a month?
> Or in a year? Is the fact that this json response exists a threat to
> youtube? Can you quantify how of a threat? How much, in dollars, does it
> hurt their business?
>
> This file may be here if the admins don't delete it. Now they may do ;@)
>
>
> So where do you think that information is coming from? The metadata and
> tags, and headers are contained in a database.
>
> The files are stored persistently , since they can be quoted. So the API
> works both ways. The main thing here is that the files are there, otherwise
> there metadata information would be deleted from the db aswell.
>
> http://gdata.youtube.com/demo/index.html?utm_source=
> twitterfeed&utm_medium=twitter
>
> Youtube DATA API is unique.. the commands can be send through that
> interface... So we do definitely know that that is coming from a database.
>
>
> On Fri, Mar 14, 2014 at 8:22 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> You are trying to execute an sh script through a video player. That's an
>> exec() command. So its the wrong way about accessing the file.
>>
>>
>> On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:
>>
>>> No it's not. As Chris and I are saying, you don't have proof your file
>>> is accessible to others, only that is was uploaded. Now, you see, when you
>>> upload a video to youtube, you get the adress where it will be viewable in
>>> the response. In your case :
>>>
>>> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
>>> http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
>>> ","cross_domain_url":"
>>> http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
>>> "ok", *"video_id": "KzKDtijwHFI"*
>>> }}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
>>> And what do we get when we browse to
>>> https://youtube.com/watch?v=KzKDtijwHFI ?
>>> Nothing.
>>> Can you send me a link where I can access the file content of the
>>> arbitrary file you uploaded?
>>> Are you sure this json response, or this file, will be there in a month?
>>> Or in a year? Is the fact that this json response exists a threat to
>>> youtube? Can you quantify how of a threat? How much, in dollars, does it
>>> hurt their business?
>>>
>>> --Rob
>>>
>>>
>>> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> My claim is now verified....
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>>> christhom7851@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Nikolas,
>>>>>>>
>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>> this will help.
>>>>>>>
>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>> understand.
>>>>>>>
>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>> you why people maybe not agreeing with you.
>>>>>>>
>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>
>>>>>>> However...
>>>>>>>
>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>
>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>> intact a valid movie and if not removes it.
>>>>>>>
>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>> based on an assumption.... Let me explain.
>>>>>>>
>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>
>>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>>> received from the API - maybe they process them and validate them - we
>>>>>>> simply don't know.
>>>>>>>
>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>> it as such.
>>>>>>>
>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>>> an API and an API responds in a certain way.
>>>>>>>
>>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>>> anything.
>>>>>>>
>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>> file then how could anyone dispute your bug.
>>>>>>>
>>>>>>> Hope this helps....
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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.”
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
juniorbsd at gmail
Mar 14, 2014, 5:25 PM
Post #52 of 88 (14103 views)
Permalink
Hey dude just give up!

You can convince a lot of journalists without professional skills but if
you cant convince Google or at least the community, so you doing it wrong.
by the way you can upload everything to youtube just tricking the file's
magic number but you cant retrieve it back. so what?

How can you assure that your "proof" isnt just a log for the application?

If you have the expertise you said, i have a challenge to you:

http://upload.youtube.com/?authuser=0&upload_id=AEnB2Uox6eWMN_LyrVQZdsCdQkDezvvNwpthROQn1SRe7idjqRFiez7SKVMd1t-rkCb7_CalkGc2oOJmdrnfxho2FNQt5aIjQw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

Its not a 3gp file, just has the magic number. if you retrieve the contents
of its file and show it to us. i will start agreeing with you that it can
be security issue.
otherwise stop annoyin everyone, get back to your desk and do your job.



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

> In my expertise, that is a vulnerability.
>
> Now if Google doesn't want to fix patch that, it's their choice. However I
> have already disclosed that to them.
>
>
>
>
> On Fri, Mar 14, 2014 at 8:25 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> So where do you think that information is coming from? The metadata and
>> tags, and headers are contained in a database.
>>
>> The files are stored persistently , since they can be quoted. So the API
>> works both ways. The main thing here is that the files are there, otherwise
>> there metadata information would be deleted from the db aswell.
>>
>> http://gdata.youtube.com/demo/index.html?utm_source=
>> twitterfeed&utm_medium=twitter
>>
>> Youtube DATA API is unique.. the commands can be send through that
>> interface... So we do definitely know that that is coming from a database.
>> That same video id can be queried through the above link. Having done so, I
>> confirmed that the information originate from a direct connection to the
>> db, where the data are stored.
>>
>>
>> On Fri, Mar 14, 2014 at 8:20 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> wrote:
>>
>>> So where do you think that information is coming from? The metadata and
>>> tags, and headers are contained in a database.
>>>
>>> The files are stored persistently , since they can be quoted. So the API
>>> works both ways. The main thing here is that the files are there, otherwise
>>> there metadata information would be deleted from the db aswell.
>>>
>>>
>>> http://gdata.youtube.com/demo/index.html?utm_source=twitterfeed&utm_medium=twitter
>>>
>>> Youtube DATA API is unique.. the commands can be send through that
>>> interface... So we do definitely know that that is coming from a database.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:16 PM, Chris Thompson <christhom7851@gmail.com
>>> > wrote:
>>>
>>>> Hi Nicholas,
>>>>
>>>> Again, you hypothesize that you are getting a response from the
>>>> database, but you really don't know that. You have no idea when the code is
>>>> doing behind the endpoint.
>>>>
>>>> upload.youtube.com is simple an endpoint that you are sending a
>>>> request to and getting a response from -
>>>>
>>>> Can you upload a ZIP file for example and then get that same ZIP file
>>>> from another machine? If you can do that, then who can question your bug.
>>>>
>>>> Again, i'm not trying to be a dick - just trying to help!
>>>>
>>>> Cheers...
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 4:08 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> My claim is now verified....
>>>>>
>>>>> Cheers!
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8t
>>>>>> dXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>>
>>>>>>> That information can be queried from the db, where the metadata are
>>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>>>> christhom7851@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Nikolas,
>>>>>>>>
>>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>>> this will help.
>>>>>>>>
>>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>>> understand.
>>>>>>>>
>>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>>> you why people maybe not agreeing with you.
>>>>>>>>
>>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>>
>>>>>>>> However...
>>>>>>>>
>>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>>
>>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>>> intact a valid movie and if not removes it.
>>>>>>>>
>>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>>> based on an assumption.... Let me explain.
>>>>>>>>
>>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>>
>>>>>>>> 2. You / we don't know what Google do with files once they have
>>>>>>>> been received from the API - maybe they process them and validate them - we
>>>>>>>> simply don't know.
>>>>>>>>
>>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>>> it as such.
>>>>>>>>
>>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>>>> an API and an API responds in a certain way.
>>>>>>>>
>>>>>>>> I am NOT saying you haven't found an issue, what I am saying is
>>>>>>>> that you need to demonstrate that the issue is real and thus can be abused.
>>>>>>>> If the Google service simply verifies all uploaded files once they are
>>>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>>>> anything.
>>>>>>>>
>>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>>> file then how could anyone dispute your bug.
>>>>>>>>
>>>>>>>> Hope this helps....
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
Grato,

J. Tozo
_
°v°
/(S)\ SLACKWARE
^ ^ Linux
_____________________
because it works
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
cjchamberland at gmail
Mar 14, 2014, 6:59 PM
Post #53 of 88 (14079 views)
Permalink
Same here... It's like a train wreck, you know you shouldn't watch but it's just so damned entertaining at this point that I can't stop...



Sent from my iPhone

> On Mar 14, 2014, at 2:46 PM, Yvan Janssens <ik@yvanj.me> wrote:
>
> 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/
> _______________________________________________
> 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 ]
lem.nikolas at googlemail
Mar 14, 2014, 7:48 PM
Post #54 of 88 (14113 views)
Permalink
Go to sleep. You have absolutely no understanding of the vulnerability, nor
you have the facts.

If you want a full report ask Softpedia, because we aint releasing them.


On Fri, Mar 14, 2014 at 8:39 PM, R D <rd.seclists@gmail.com> wrote:

> >You are trying to execute an sh script through a video player. That's an
> exec() command.
> No, it's not. That's an HTTP GET. Do you have such a poor understanding of
> how web applications work? Or did you just not read what I said?
>
> >So its the wrong way about accessing the file.
> This way, which is the standard way to access files on youtube, tells me
> the file doesn't exist. You have yet to prove the file you uploaded can be
> accessed or executed by anyone. For that matter, you have still to prove it
> can be discovered by anyone. That URL is hard to guess.
> And you have still to answer all my other questions, and most of the
> questions asked to you on this list.
> The burden of proof is on you, and you are making a fool of yourself by
> answering all the questions here with the same statements, and links to
> your PoC that doesn't proves anything, while everybody asks you for more
> evidence.
> Keep on the (good?) work,
> --Rob'
>
>
> On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> You are trying to execute an sh script through a video player. That's an
>> exec() command. So its the wrong way about accessing the file.
>>
>>
>> On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:
>>
>>> No it's not. As Chris and I are saying, you don't have proof your file
>>> is accessible to others, only that is was uploaded. Now, you see, when you
>>> upload a video to youtube, you get the adress where it will be viewable in
>>> the response. In your case :
>>>
>>> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
>>> http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
>>> ","cross_domain_url":"
>>> http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
>>> "ok", *"video_id": "KzKDtijwHFI"*
>>> }}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
>>> And what do we get when we browse to
>>> https://youtube.com/watch?v=KzKDtijwHFI ?
>>> Nothing.
>>> Can you send me a link where I can access the file content of the
>>> arbitrary file you uploaded?
>>> Are you sure this json response, or this file, will be there in a month?
>>> Or in a year? Is the fact that this json response exists a threat to
>>> youtube? Can you quantify how of a threat? How much, in dollars, does it
>>> hurt their business?
>>>
>>> --Rob
>>>
>>>
>>> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> My claim is now verified....
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>>> christhom7851@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Nikolas,
>>>>>>>
>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>> this will help.
>>>>>>>
>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>> understand.
>>>>>>>
>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>> you why people maybe not agreeing with you.
>>>>>>>
>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>
>>>>>>> However...
>>>>>>>
>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>
>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>> intact a valid movie and if not removes it.
>>>>>>>
>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>> based on an assumption.... Let me explain.
>>>>>>>
>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>
>>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>>> received from the API - maybe they process them and validate them - we
>>>>>>> simply don't know.
>>>>>>>
>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>> it as such.
>>>>>>>
>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>>> an API and an API responds in a certain way.
>>>>>>>
>>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>>> anything.
>>>>>>>
>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>> file then how could anyone dispute your bug.
>>>>>>>
>>>>>>> Hope this helps....
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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 ]
scott at guppylog
Mar 14, 2014, 7:50 PM
Post #55 of 88 (14113 views)
Permalink
It's amazing how much dumber I feel for having read your drivel.
Please for the love of <$diety> stop posting to this list.

--
W. Scott Lockwood III
AMST Tech (SPI)
GWB2009033817
http://www.shadowplayinternational.org/
"There are four boxes to be used in defense of liberty: soap, ballot,
jury, and ammo. Please use in that order." -Ed Howdershelt (Author)


On Fri, Mar 14, 2014 at 9:48 PM, Nicholas Lemonias.
<lem.nikolas@googlemail.com> wrote:
> Go to sleep. You have absolutely no understanding of the vulnerability, nor
> you have the facts.
>
> If you want a full report ask Softpedia, because we aint releasing them.
>
>
> On Fri, Mar 14, 2014 at 8:39 PM, R D <rd.seclists@gmail.com> wrote:
>>
>> >You are trying to execute an sh script through a video player. That's an
>> > exec() command.
>> No, it's not. That's an HTTP GET. Do you have such a poor understanding of
>> how web applications work? Or did you just not read what I said?
>>
>> >So its the wrong way about accessing the file.
>> This way, which is the standard way to access files on youtube, tells me
>> the file doesn't exist. You have yet to prove the file you uploaded can be
>> accessed or executed by anyone. For that matter, you have still to prove it
>> can be discovered by anyone. That URL is hard to guess.
>> And you have still to answer all my other questions, and most of the
>> questions asked to you on this list.
>> The burden of proof is on you, and you are making a fool of yourself by
>> answering all the questions here with the same statements, and links to your
>> PoC that doesn't proves anything, while everybody asks you for more
>> evidence.
>> Keep on the (good?) work,
>> --Rob'
>>
>>
>> On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias.
>> <lem.nikolas@googlemail.com> wrote:
>>>
>>> You are trying to execute an sh script through a video player. That's an
>>> exec() command. So its the wrong way about accessing the file.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:
>>>>
>>>> No it's not. As Chris and I are saying, you don't have proof your file
>>>> is accessible to others, only that is was uploaded. Now, you see, when you
>>>> upload a video to youtube, you get the adress where it will be viewable in
>>>> the response. In your case :
>>>>
>>>> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000","cross_domain_url":"http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
>>>> "ok", "video_id":
>>>> "KzKDtijwHFI"}}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
>>>> And what do we get when we browse to
>>>> https://youtube.com/watch?v=KzKDtijwHFI ?
>>>> Nothing.
>>>> Can you send me a link where I can access the file content of the
>>>> arbitrary file you uploaded?
>>>> Are you sure this json response, or this file, will be there in a month?
>>>> Or in a year? Is the fact that this json response exists a threat to
>>>> youtube? Can you quantify how of a threat? How much, in dollars, does it
>>>> hurt their business?
>>>>
>>>> --Rob
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias.
>>>> <lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>> My claim is now verified....
>>>>>
>>>>> Cheers!
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
>>>>> <lem.nikolas@googlemail.com> wrote:
>>>>>>
>>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
>>>>>> <lem.nikolas@googlemail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>>
>>>>>>> That information can be queried from the db, where the metadata are
>>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
>>>>>>> <christhom7851@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Nikolas,
>>>>>>>>
>>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>>> this will help.
>>>>>>>>
>>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>>> understand.
>>>>>>>>
>>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>>> you why people maybe not agreeing with you.
>>>>>>>>
>>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>>
>>>>>>>> However...
>>>>>>>>
>>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>>
>>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>>> intact a valid movie and if not removes it.
>>>>>>>>
>>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>>> based on an assumption.... Let me explain.
>>>>>>>>
>>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>>
>>>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>>>> received from the API - maybe they process them and validate them - we
>>>>>>>> simply don't know.
>>>>>>>>
>>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>>> it as such.
>>>>>>>>
>>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to an
>>>>>>>> API and an API responds in a certain way.
>>>>>>>>
>>>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>>>> the Google service simply verifies all uploaded files once they are uploaded
>>>>>>>> and discards them if invalid, then you haven't really found anything.
>>>>>>>>
>>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>>> file then how could anyone dispute your bug.
>>>>>>>>
>>>>>>>> Hope this helps....
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/

_______________________________________________
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 ]
pr0ix at yahoo
Mar 14, 2014, 8:17 PM
Post #56 of 88 (14079 views)
Permalink
The thread starter is right about this. It is a vulnerability, and I think Google should start considering this.
 
The JSON service responds to GET requests , and there is a good chance that the service is also vulnerable to JSON Hijacking attacks.
 
As a professional penetration tester , I believe that Google was false not to award this.
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 8:58 PM
Post #57 of 88 (14103 views)
Permalink
Happy trolling...


On Fri, Mar 14, 2014 at 7:49 PM, R D <rd.seclists@gmail.com> wrote:

> >Then that also means that firewalls and IPS systems are worthless. Why
> spend so much time protecting the network layers if a user can send any
> file of choice to a remote network through http...
> well, if you are running a file upload system, or any webserver, you
> really should block any incoming traffic to port 80, and if you can't of
> course your IPS knows what a video file is and can whitelist that /s
> That's why server-side controls are in place, and your POC doesn't show
> you circumventing them.
>
> >As for the uploaded files being persistent, there is evidence of that.
> No. You have evidence they were uploaded. You don't have evidence they
> will stay forever. When reporting a vulnerability, please try to not
> include hyperbole, the reporters will do that for you.
>
> >For instance a remote admin could be tricked to execute some of
> the uploaded files
> As I said, your uploaded files are not accessible to any user, unless you
> prove me wrong. They are not executable (in the context of the webserver)
> for any remote user, unless you can prove me wrong. They are not executable
> in the context of an admin browsing the server content, unless the guys at
> youtube made a major mistake, and you can't tell if they are, and neither
> can I.
> > (Social Engineering).
> Ohai, youtube admin, could you please copy that file I can't give you the
> path of, or even the server where it resides, to your home folder and
> please chmod it 777 and then run it? For debugging purposes obviously
> http://www.youtube.com/watch?v=oOqJ1F44_-Y
>
> Have a nice day, and may the bug elves fill your socks with awesome
> presents,
>
> --Rob'
>
>
>
> On Fri, Mar 14, 2014 at 8:28 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Then that also means that firewalls and IPS systems are worthless. Why
>> spend so much time protecting the network layers if a user can send any
>> file of choice to a remote network through http...
>>
>> As for the uploaded files being persistent, there is evidence of that.
>> For instance a remote admin could be tricked to execute some of
>> the uploaded files (Social Engineering).
>>
>> So our report sent as part of Google's security program, should not be
>> treated as a non-security issue.
>>
>>
>> Thanks,
>>
>>
>> On Fri, Mar 14, 2014 at 7:23 PM, R D <rd.seclists@gmail.com> wrote:
>>
>>> I'm going to try to spell it out clearly.
>>>
>>> You don't have unrestricted file upload[1]. Keep in mind you're trying
>>> to abuse youtube, which is essentially a video file upload service. So the
>>> fact that you can upload files is not surprising.
>>> Now you're uploading non-video files. Cool. But not earth-shattering.
>>> They are not accessible to anyone but you, as far as I can tell, and I
>>> don't even think you can access the file contents on the remote server, but
>>> please prove me wrong on both points.
>>> You are still, as far as I can tell, bound by the per-file and
>>> per-account quota on disk occupation, so you don't have a DoS by resource
>>> exhaustion.
>>> You can't force server-side file path, so you don't have RFI or DoS by
>>> messing with the remote file system. You can't execute the files you
>>> uploaded, so you don't have arbitrary code execution.
>>>
>>> But you are right about what your PoC does. You bypassed a security
>>> control, you uploaded crap on youtube servers, and by that you exhausted
>>> their resources by a fraction of the quota they allow you when signing up.
>>> BTW, I don't think they keep invalid video files for an indefinite period
>>> of time in a user account, but I might be wrong.
>>>
>>> The burden of proof is still on your side as to whether or not the bug
>>> you found has any impact that was not already accepted by youtube allowing
>>> registered users to upload whatever crap they see fit as long as it is
>>> video. You failed to provide this proof, and please be sure the audience of
>>> fulldisclosure is not "attacking the researcher" but working with you to
>>> have a better understanding of the bug you found, even though you kinda
>>> acted like a fool in this thread.
>>>
>>> Please keep on searching and finding vulns, please keep on publishing
>>> them, and use this as a learning experience that not all bugs or control
>>> bypasses are security vulnerabilities.
>>>
>>> --Rob'
>>>
>>> [1] As per OWASP (
>>> https://www.owasp.org/index.php/Unrestricted_File_Upload):
>>>
>>> >There are really two classes of problems here. The first is with the
>>> file metadata, like the path and file name. These are generally provided by
>>> the transport, such as HTTP multi-part encoding. This data may trick the
>>> application into overwriting a critical file or storing the file in a bad
>>> location. You must validate the metadata extremely carefully before using
>>> it.
>>>
>>> Your POC doesn't demonstrate that.
>>>
>>> >The other class of problem is with the file size or content. The range
>>> of problems here depends entirely on what the file is used for. See the
>>> examples below for some ideas about how files might be misused. To protect
>>> against this type of attack, you should analyze everything your application
>>> does with files and think carefully about what processing and interpreters
>>> are involved.
>>>
>>> Your POC kinda does that, but you didn't provide proof it's possible to
>>> execute what you uploaded, either using social engineering or any other
>>> method.
>>>
>>> Also, please don't say "verified by a couple of recognised experts
>>> including OWASP" unless you actually spoke with someone @owasp and she
>>> validated your findings.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 7:40 PM, 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/
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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 ]
lcamtuf at coredump
Mar 14, 2014, 9:05 PM
Post #58 of 88 (14088 views)
Permalink
Oh, wow :-)

To put things in perspective, it probably helps to understand that
virtually all video hosting sites perform batch, queue-based
conversions of uploaded content. There is a good reason for this
design: video conversions are extremely CPU-intensive - and an
orderly, capped-throughput queue gives you much better resilience to
DoS attacks.

Alas, this model is not very user-friendly: it may take good 20
minutes to upload a clip to Vimeo over my lowly DSL connection, and
then another 40 to wait my turn in the conversion queue. If the video
I uploaded turns out to be in an unsupported format (I'm still using
MS-CRAM), I have just wasted an hour of my time. A simple workaround
would be for Vimeo to have a client-side check that flags obvious
problems before sending any data to the server. It's not a security
feature, but it minimizes my pain.

Does it make sense to duplicate this check on the server, too? You
could, but I don't think it adds real value: after all, the converter
will sooner or later perform the same check anyway. And for users who
want to take Vimeo down, uploading tons of cat videos makes more
sense: after all, converting them will cost more than just bailing out
early on an invalid file. As for other attacks you mention: it's
fairly easy to construct valid videos that also work as file archives,
HTML documents, or shell scripts.

Ultimately, sites that deal with user-supplied content often have to
make tough decisions that don't fit in the neat defitions of ISO
standards or academic papers of the old. Mechanisms such as quotas,
various abuse-detection heuristics, rapid scalability - and even user
education and good UX design - go hand-in-hand with more traditional
approaches to minimizing risk.

/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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 9:43 PM
Post #59 of 88 (14096 views)
Permalink
If you wish to talk seriously about the problem, please send me an email
privately. And we can talk about what we have found so far, and perhaps
present some more proof of concepts for this on going research. This is
between the researcher and Google.

People who do not have the facts have been, trying to attack the arguer, on
the basis of their personal beliefs. We are not speaking from experience,
but based on our findings which includes PoC media, images, codes - and
based on academic literature and recognised practise. Please bear in mind
that a lot of research is conducted in academia (those old papers you
say) before finally released to the commercial markets.

Regards,

*Nicholas Lemonias*
*Information Security Expert*
*Advanced Information Security Corp.*


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

> Try learning how to properly send emails before critizicing anyone, pal. ;)
>
>
> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> 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."
>>>
>>
>>
>>
>
>
> --
> "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 ]
cjchamberland at gmail
Mar 14, 2014, 10:06 PM
Post #60 of 88 (14085 views)
Permalink
Omg please for the love of all things human STFU!!!

Sent from my iPhone

> On Mar 15, 2014, at 12:43 AM, "Nicholas Lemonias." <lem.nikolas@googlemail.com> wrote:
>
> If you wish to talk seriously about the problem, please send me an email privately. And we can talk about what we have found so far, and perhaps present some more proof of concepts for this on going research. This is between the researcher and Google.
>
> People who do not have the facts have been, trying to attack the arguer, on the basis of their personal beliefs. We are not speaking from experience, but based on our findings which includes PoC media, images, codes - and based on academic literature and recognised practise. Please bear in mind that a lot of research is conducted in academia (those old papers you say) before finally released to the commercial markets.
>
> Regards,
>
> Nicholas Lemonias
> Information Security Expert
> Advanced Information Security Corp.
>
>
>> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas <mvilas@gmail.com> wrote:
>> Try learning how to properly send emails before critizicing anyone, pal. ;)
>>
>>
>>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <lem.nikolas@googlemail.com> 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.”
>>
>>
>>
>>
>> --
>> “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 ]
lem.nikolas at googlemail
Mar 14, 2014, 10:09 PM
Post #61 of 88 (14100 views)
Permalink
You are too vague. Please keep this to a level.

Thank you.


*Best Regards,*
*Nicholas Lemonias*

*Advanced Information Security Corporation.*


On Sat, Mar 15, 2014 at 5:06 AM, Colette Chamberland <
cjchamberland@gmail.com> wrote:

> Omg please for the love of all things human STFU!!!
>
> Sent from my iPhone
>
> On Mar 15, 2014, at 12:43 AM, "Nicholas Lemonias." <
> lem.nikolas@googlemail.com> wrote:
>
> If you wish to talk seriously about the problem, please send me an email
> privately. And we can talk about what we have found so far, and perhaps
> present some more proof of concepts for this on going research. This is
> between the researcher and Google.
>
> People who do not have the facts have been, trying to attack the arguer,
> on the basis of their personal beliefs. We are not speaking from
> experience, but based on our findings which includes PoC media, images,
> codes - and based on academic literature and recognised practise. Please
> bear in mind that a lot of research is conducted in academia (those old
> papers you say) before finally released to the commercial markets.
>
> Regards,
>
> *Nicholas Lemonias*
> *Information Security Expert*
> *Advanced Information Security Corp.*
>
>
> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas <mvilas@gmail.com> wrote:
>
>> Try learning how to properly send emails before critizicing anyone, pal.
>> ;)
>>
>>
>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> 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."
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> "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 ]
lem.nikolas at googlemail
Mar 14, 2014, 10:11 PM
Post #62 of 88 (14098 views)
Permalink
Correct.

The mime type can be circumvented. We can confirm this to be a valid
vulnerability.

For the PoC's :

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

On Fri, Mar 14, 2014 at 8:40 PM, Krzysztof Kotowicz
<kkotowicz+fd@gmail.com>wrote:

>
> 2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> Then that also means that firewalls and IPS systems are worthless. Why
>> spend so much time protecting the network layers if a user can send any
>> file of choice to a remote network through http...
>>
>
> No, they are not worthless per se, but of course for an user content
> publishing service they need to allow file upload over HTTP/s. How far
> those files are inspected and later processed is another question - and
> that could lead to a vulnerability that you DIDN'T demonstrate.
>
> You just uploaded a .sh file. There's no harm in that as nowhere did you
> prove that that file is being executed. Similarly (and that has been
> pointed out in this thread) you could upload a PHP-GIF polyglot file to a
> J2EE application - no vulnerability in this. Prove something by overwriting
> a crucial file, tricking other user's browser to execute the file as HTML
> from an interesting domain (XSS), popping a shell, triggering XXE when the
> file is processed as XML, anything. Then that is a vulnerability. So far -
> sorry, it is not, and you've been told it repeatedly.
>
>
> As for the uploaded files being persistent, there is evidence of that.
>> For instance a remote admin could be tricked to execute some of
>> the uploaded files (Social Engineering).
>>
>
> Come on, seriously? Social Engineering can make him download this file
> from pastebin just as well. That's a real stretch.
>
> IMHO it is not a security issue. You're uploading a file to some kind of
> processing queue that does not validate a file type, but nevertheless only
> processes those files as video - there is NO reason to suspect otherwise,
> and I'd like to be proven wrong here. Proven as in PoC.
>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lem.nikolas at googlemail
Mar 14, 2014, 11:26 PM
Post #63 of 88 (14095 views)
Permalink
You are so incompetent.. If you want proof why don't you do it yourself?

https://www.youtube.com/watch?v=G4EkgJtjDvU - Here is proof that the file
is saved and processed. If you want to question it come up with your real
name, stop hiding behind fake emails. Are you a Google employee? What's
your motive?

Best


On Fri, Mar 14, 2014 at 8:39 PM, R D <rd.seclists@gmail.com> wrote:

> >You are trying to execute an sh script through a video player. That's an
> exec() command.
> No, it's not. That's an HTTP GET. Do you have such a poor understanding of
> how web applications work? Or did you just not read what I said?
>
> >So its the wrong way about accessing the file.
> This way, which is the standard way to access files on youtube, tells me
> the file doesn't exist. You have yet to prove the file you uploaded can be
> accessed or executed by anyone. For that matter, you have still to prove it
> can be discovered by anyone. That URL is hard to guess.
> And you have still to answer all my other questions, and most of the
> questions asked to you on this list.
> The burden of proof is on you, and you are making a fool of yourself by
> answering all the questions here with the same statements, and links to
> your PoC that doesn't proves anything, while everybody asks you for more
> evidence.
> Keep on the (good?) work,
> --Rob'
>
>
> On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> You are trying to execute an sh script through a video player. That's an
>> exec() command. So its the wrong way about accessing the file.
>>
>>
>> On Fri, Mar 14, 2014 at 8:20 PM, R D <rd.seclists@gmail.com> wrote:
>>
>>> No it's not. As Chris and I are saying, you don't have proof your file
>>> is accessible to others, only that is was uploaded. Now, you see, when you
>>> upload a video to youtube, you get the adress where it will be viewable in
>>> the response. In your case :
>>>
>>> {"sessionStatus":{"state":"FINALIZED","externalFieldTransfers":[{"name":"file","status":"COMPLETED","bytesTransferred":113,"bytesTotal":113,"formPostInfo":{"url":"
>>> http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
>>> ","cross_domain_url":"
>>> http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw"},"content_type":"text/x-sh"}],"additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"SUCCESS","customerSpecificInfo":{"status":
>>> "ok", *"video_id": "KzKDtijwHFI"*
>>> }}}},"upload_id":"AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw"}}
>>> And what do we get when we browse to
>>> https://youtube.com/watch?v=KzKDtijwHFI ?
>>> Nothing.
>>> Can you send me a link where I can access the file content of the
>>> arbitrary file you uploaded?
>>> Are you sure this json response, or this file, will be there in a month?
>>> Or in a year? Is the fact that this json response exists a threat to
>>> youtube? Can you quantify how of a threat? How much, in dollars, does it
>>> hurt their business?
>>>
>>> --Rob
>>>
>>>
>>> On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> My claim is now verified....
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com> wrote:
>>>>
>>>>> http://upload.youtube.com/?authuser=0&upload_id=
>>>>> AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
>>>>> uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
>>>>> CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>
>>>>> That information can be queried from the db, where the metadata are
>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>>>>
>>>>>> That information can be queried from the db, where the metadata are
>>>>>> saved. The files are being saved persistently , as per the above example.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson <
>>>>>> christhom7851@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Nikolas,
>>>>>>>
>>>>>>> Please do read (and understand) my entire email before responding -
>>>>>>> I understand your frustration trying to get your message across but maybe
>>>>>>> this will help.
>>>>>>>
>>>>>>> Please put aside professional pride for the time being - I know how
>>>>>>> it feels to be passionate about something yet have others simply not
>>>>>>> understand.
>>>>>>>
>>>>>>> Let me try and bring some sanity to the discussion and explain to
>>>>>>> you why people maybe not agreeing with you.
>>>>>>>
>>>>>>> You (rightly so) highlighted what you believe to be an issue in a
>>>>>>> Youtube whereby it appears (to you) than you can upload an arbitrary file.
>>>>>>> If you can indeed do this as you suspect then your points are valid and you
>>>>>>> "may" be able to cause various issues associated with it such as DOS etc -
>>>>>>> especially if the uploaded files cannot or are not tracked.
>>>>>>>
>>>>>>> However...
>>>>>>>
>>>>>>> Consider than you are talking to an API and what you are getting
>>>>>>> back (the JSON response) in your example is simply a response from the API
>>>>>>> to say the file you uploaded has been received and saved.
>>>>>>>
>>>>>>> Now, as you no doubt know, when you upload a regular movie to
>>>>>>> YouTube, once uploaded it goes away and does some post-processing,
>>>>>>> converting it to flash for example. What's to say that there isn't some
>>>>>>> verification aspect to this post-processing that checks if the file is
>>>>>>> intact a valid movie and if not removes it.
>>>>>>>
>>>>>>> If you could for example demonstrate that the file was indeed
>>>>>>> persistent, by being able to retrieve it for example then again, you would
>>>>>>> have solid ground to claim an issue however your claims at this point are
>>>>>>> based on an assumption.... Let me explain.
>>>>>>>
>>>>>>> 1. You have demonstrated than you can send "any" file to an API and
>>>>>>> the API returned an acknowledgment of receiving (and saving) the file.
>>>>>>>
>>>>>>> 2. You / we don't know what Google do with files once they have been
>>>>>>> received from the API - maybe they process them and validate them - we
>>>>>>> simply don't know.
>>>>>>>
>>>>>>> 3. You have hypothesized that you can retrieve the file by
>>>>>>> manipulating tokens etc and you may be right, but you have not demonstrated
>>>>>>> it as such.
>>>>>>>
>>>>>>> Because of this, you seem to have made a CLAIM that you can upload
>>>>>>> arbitrary files to Google however SHOWN that you can simply send files to
>>>>>>> an API and an API responds in a certain way.
>>>>>>>
>>>>>>> I am NOT saying you haven't found an issue, what I am saying is that
>>>>>>> you need to demonstrate that the issue is real and thus can be abused. If
>>>>>>> the Google service simply verifies all uploaded files once they are
>>>>>>> uploaded and discards them if invalid, then you haven't really found
>>>>>>> anything.
>>>>>>>
>>>>>>> If you were to prove that you were able to retrieve this uploaded
>>>>>>> file then how could anyone dispute your bug.
>>>>>>>
>>>>>>> Hope this helps....
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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 ]
brian at brianmwaters
Mar 15, 2014, 12:06 AM
Post #64 of 88 (14079 views)
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/15/2014 02:26, Nicholas Lemonias. wrote:
> https://www.youtube.com/watch?v=G4EkgJtjDvU - Here is proof that
> the file is saved and processed.

<disclaimer>
Compared to probably most of the folks on this list, I have absolutely
no idea what I'm doing.
</disclaimer>

However, at the time I accessed your latest URL (around 2:51 AM EST, or
6:51 GMT), I got a message saying "The video is currently being
processed."

So, for all we know, the file is in some queue, waiting for Google to
notice that it's invalid, at which point it will be deleted.

Please get back to us when we are able to download your invalid file,
via YouTube, on our various machines scattered across the globe.

Also, please stop sending so many damn short emails in a row.
Consolidation is nice.

Thank you,

BW

- --
Brian M. Waters
+1 (908) 380-8214
brian@brianmwaters.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBCgAGBQJTI/v3AAoJEEYNFaEjEsGopDwH/R8q9+1wWsKg0j8Wg5zIdZZr
tVNT0IIh9vyjC57WxxQ2SamKoEWsCSt4A8aQ60gup2ImT+XoRpSYMZKWAyKOwz//
yiDjKKI9fsRRdXaBT3r8uWLftWA8WzASrMqrqMhayj06HNXjRXhyonJVdxxgrg/6
h+FaZYGlYdmrGtb02pve5i7in6OoYBQj4m85KVzq+Pnvfowqo6VHzlLwfK3vaD4a
8sEm+i63N02VT6ItO9y7fCcv52pU0sjepGIoYV2aTHkIR3BaNmyxSEVaOZclDY37
6HFSdkWZP0rvkQefNY6QcUvMfBszxFfecQ5cGfIcbScx35iLChXQMYJpH9dmPao=
=Ngjk
-----END PGP SIGNATURE-----

_______________________________________________
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 ]
ispcolohost at gmail
Mar 15, 2014, 2:42 AM
Post #65 of 88 (14083 views)
Permalink
Just curious; what universities have hired you as a lecturer?


On Sat, Mar 15, 2014 at 1:09 AM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> You are too vague. Please keep this to a level.
>
> Thank you.
>
>
> *Best Regards,*
> *Nicholas Lemonias*
>
> *Advanced Information Security Corporation.*
>
>
> On Sat, Mar 15, 2014 at 5:06 AM, Colette Chamberland <
> cjchamberland@gmail.com> wrote:
>
>> Omg please for the love of all things human STFU!!!
>>
>> Sent from my iPhone
>>
>> On Mar 15, 2014, at 12:43 AM, "Nicholas Lemonias." <
>> lem.nikolas@googlemail.com> wrote:
>>
>> If you wish to talk seriously about the problem, please send me an email
>> privately. And we can talk about what we have found so far, and perhaps
>> present some more proof of concepts for this on going research. This is
>> between the researcher and Google.
>>
>> People who do not have the facts have been, trying to attack the arguer,
>> on the basis of their personal beliefs. We are not speaking from
>> experience, but based on our findings which includes PoC media, images,
>> codes - and based on academic literature and recognised practise. Please
>> bear in mind that a lot of research is conducted in academia (those old
>> papers you say) before finally released to the commercial markets.
>>
>> Regards,
>>
>> *Nicholas Lemonias*
>> *Information Security Expert*
>> *Advanced Information Security Corp.*
>>
>>
>> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas <mvilas@gmail.com> wrote:
>>
>>> Try learning how to properly send emails before critizicing anyone, pal.
>>> ;)
>>>
>>>
>>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> 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."
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> "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/
>>
>>
>
> _______________________________________________
> 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 ]
antisnatchor at gmail
Mar 15, 2014, 3:38 AM
Post #66 of 88 (14085 views)
Permalink
Btw, not sure if someone already mentioned it, but you are really
reaching the level
of MustLive. That's actually a big achievement. Congratz.

I'm not sure if you got what lcamtuf is saying (I'm impressed he still
takes time to reply to you),
apparently not. You're still trying to convince us that you're right.

Maybe you can create the next LOIC specifically tailored to DoS Youtube
with this serious bug, ROFL!

Cheers
antisnatchor

Nicholas Lemonias. wrote:
> If you wish to talk seriously about the problem, please send me an email
> privately. And we can talk about what we have found so far, and perhaps
> present some more proof of concepts for this on going research. This is
> between the researcher and Google.
>
> People who do not have the facts have been, trying to attack the arguer, on
> the basis of their personal beliefs. We are not speaking from experience,
> but based on our findings which includes PoC media, images, codes - and
> based on academic literature and recognised practise. Please bear in mind
> that a lot of research is conducted in academia (those old papers you
> say) before finally released to the commercial markets.
>
> Regards,
>
> *Nicholas Lemonias*
> *Information Security Expert*
> *Advanced Information Security Corp.*
>
>
> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas <mvilas@gmail.com> wrote:
>
>> Try learning how to properly send emails before critizicing anyone, pal. ;)
>>
>>
>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
>> lem.nikolas@googlemail.com> 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."
>>>>
>>>
>> --
>> "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 ]
mvilas at gmail
Mar 15, 2014, 4:04 AM
Post #67 of 88 (14076 views)
Permalink
On Sat, Mar 15, 2014 at 5:43 AM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> People who do not have the facts have been, trying to attack the arguer,
> on the basis of their personal beliefs.


Wow. I seriously can't tell if you're trolling or unbelievably narcissistic.

Your work has serious flaws, and have been pointed out with facts over and
over - but you think they're ad-hominem attacks based on the tone of their
replies. Zalewski here is just trying to be nice and patient with you - but
you somehow seem to believe he agrees with you based on the tone of his
replies.

You're either faking it and pulling a massive prank on all of us, or you're
so self absorbed you can't get past your own emotional responses to people
pointing out your mistakes. The actual contents of what they tell you are
irrelevant to you, all that matters is if people praise or criticize you.

I'm beginning to think you may have issues and we should all back off for a
while.

--
“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 ]
mvilas at gmail
Mar 15, 2014, 4:08 AM
Post #68 of 88 (14090 views)
Permalink
That is not what this email says. You can't reply "correct" to criticism
and pretend it's praise.


On Sat, Mar 15, 2014 at 6:11 AM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> Correct.
>
> The mime type can be circumvented. We can confirm this to be a valid
> vulnerability.
>
> For the PoC's :
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> On Fri, Mar 14, 2014 at 8:40 PM, Krzysztof Kotowicz <
> kkotowicz+fd@gmail.com> wrote:
>
>>
>> 2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> Then that also means that firewalls and IPS systems are worthless. Why
>>> spend so much time protecting the network layers if a user can send any
>>> file of choice to a remote network through http...
>>>
>>
>> No, they are not worthless per se, but of course for an user content
>> publishing service they need to allow file upload over HTTP/s. How far
>> those files are inspected and later processed is another question - and
>> that could lead to a vulnerability that you DIDN'T demonstrate.
>>
>> You just uploaded a .sh file. There's no harm in that as nowhere did you
>> prove that that file is being executed. Similarly (and that has been
>> pointed out in this thread) you could upload a PHP-GIF polyglot file to a
>> J2EE application - no vulnerability in this. Prove something by overwriting
>> a crucial file, tricking other user's browser to execute the file as HTML
>> from an interesting domain (XSS), popping a shell, triggering XXE when the
>> file is processed as XML, anything. Then that is a vulnerability. So far -
>> sorry, it is not, and you've been told it repeatedly.
>>
>>
>> As for the uploaded files being persistent, there is evidence of that.
>>> For instance a remote admin could be tricked to execute some of
>>> the uploaded files (Social Engineering).
>>>
>>
>> Come on, seriously? Social Engineering can make him download this file
>> from pastebin just as well. That's a real stretch.
>>
>> IMHO it is not a security issue. You're uploading a file to some kind of
>> processing queue that does not validate a file type, but nevertheless only
>> processes those files as video - there is NO reason to suspect otherwise,
>> and I'd like to be proven wrong here. Proven as in PoC.
>>
>>
>>
>
> _______________________________________________
> 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 ]
BigAl at xtcmail
Mar 15, 2014, 4:17 AM
Post #69 of 88 (14092 views)
Permalink
Some of the replies in this thread are very unfair to the original poster. I have read the news story and have thoroughly read the proof of concepts which in my opinion indicate that this is surely a security vulnerability. I have worked for Lumension as a security consultant for more than a decade. I have never thought that Google would have gone that far. Quite scary if you ask me... Do not be discouraged, as a security researcher I have also been getting that. I can certainly certify that this is a security problem, no doubts about that. Big Al

Get your free email @
http://www.xtcmail.com
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lcamtuf at coredump
Mar 15, 2014, 9:46 AM
Post #70 of 88 (14063 views)
Permalink
> As a professional penetration tester, [...]
> The JSON service responds to GET requests , and there is a good chance that
> the service is also vulnerable to JSON Hijacking attacks.

That's... not how XSSI works.

To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
"ambient" credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.

Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of "{" is overloaded in JS
depending on where it appears in a block of code.

Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.

/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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
TImbrahim at techemail
Mar 15, 2014, 10:53 AM
Post #71 of 88 (14059 views)
Permalink
Hello,

I am a security professional and risk manager in UAE. I support that the remote file upload on YouTube is a vulnerability, and I am sure about this. Not the slightest doubts...

There is a different between a vulnerability and an exploit. The vulnerability here is the lack of any file extension checks, content type verification “$_FILES['uploadedfile']['type']” holds the value of the MIME type. A hacker can easily upload files using a script that allows the sending or tampering of HTTP POST requests.

e.g:

<?php
//Demo1.php
if($_FILES['uploadedfile']['type'] != "image/gif") {
echo "Sorry, we only allow uploading GIF images";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.n";
} else {
echo "File uploading failed.n";
}
?>
Read this for more info if you like: http://resources.infosecinstitute.com/file-upload-vulnerabilities/

if not (rwx) and only (w) to a temporary file even, the spread of malware is real no matter if the file is executed at the time is upload.

For the JSON reply:

A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites.


Sincerely ,
T. Imbrahim


--- lcamtuf@coredump.cx wrote:

From: Michal Zalewski <lcamtuf@coredump.cx>
To: M Kirschbaum <pr0ix@yahoo.co.uk>
Cc: "full-disclosure@lists.grok.org.uk" <full-disclosure@lists.grok.org.uk>
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 09:46:27 -0700

> As a professional penetration tester, [...]
> The JSON service responds to GET requests , and there is a good chance that
> the service is also vulnerable to JSON Hijacking attacks.

That's... not how XSSI works.

To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
"ambient" credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.

Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of "{" is overloaded in JS
depending on where it appears in a block of code.

Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.

/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/




_____________________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lcamtuf at coredump
Mar 15, 2014, 10:59 AM
Post #72 of 88 (14070 views)
Permalink
> A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites.

To be honest, I'm not sure I follow, but I'm fairly confident that my
original point stands. If you believe that well-formed JSON objects
without padding can be read across origins within the browser, I would
love to see more information about that. (In this particular case, it
still wouldn't matter because the response doesn't contain secrets,
but it would certainly break a good chunk of the Internet.) JSONP is a
different animal.

/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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
TImbrahim at techemail
Mar 15, 2014, 11:36 AM
Post #73 of 88 (14067 views)
Permalink
Is this treated with the same way that says that Remote File Inclusion is not a security issue ?

You don't follow? Implying ?

I understand why nobody likes Google. If I 've found a vulnerability and been treated like that for trying to help, I would rather sell it to the black market or to some government.

The NSA maybe is happy to buy a RFI on Google, im sure they could make good use of that. Google is very deceptive in security matters.

--- lcamtuf@coredump.cx wrote:

From: Michal Zalewski <lcamtuf@coredump.cx>
To: TImbrahim@techemail.com
Cc: pr0ix@yahoo.co.uk, full-disclosure <full-disclosure@lists.grok.org.uk>
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 10:59:40 -0700

> A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites.

To be honest, I'm not sure I follow, but I'm fairly confident that my
original point stands. If you believe that well-formed JSON objects
without padding can be read across origins within the browser, I would
love to see more information about that. (In this particular case, it
still wouldn't matter because the response doesn't contain secrets,
but it would certainly break a good chunk of the Internet.) JSONP is a
different animal.

/mz




_____________________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lcamtuf at coredump
Mar 15, 2014, 11:47 AM
Post #74 of 88 (14063 views)
Permalink
> Is this treated with the same way that says that Remote File Inclusion is not a security issue ?

I'm not sure how RFI came into play on this thread - the original
report wasn't about RFI.

I don't have an agenda here; I'm just trying to get to the bottom of
it and make sure that we converge on a common understanding of the
issue. As in any argument, it's fairly likely that one of us is wrong,
and I accept that it could very well be me - I have been wrong quite a
few times in my life, and it's always a valuable learning opportunity.

I think it's unfortunate that the thread has devolved into various
accusations and credential-slinging, because it reduces the likelihood
of such a productive outcome. Please feel free to ping me directly any
time, though - I'm happy to chat.

Cheers,
/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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
TImbrahim at techemail
Mar 15, 2014, 11:59 AM
Post #75 of 88 (14073 views)
Permalink
The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability.

I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily.



--- lcamtuf@coredump.cx wrote:

From: Michal Zalewski <lcamtuf@coredump.cx>
To: TImbrahim@techemail.com
Cc: M Kirschbaum <pr0ix@yahoo.co.uk>, full-disclosure <full-disclosure@lists.grok.org.uk>
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 11:47:19 -0700

> Is this treated with the same way that says that Remote File Inclusion is not a security issue ?

I'm not sure how RFI came into play on this thread - the original
report wasn't about RFI.

I don't have an agenda here; I'm just trying to get to the bottom of
it and make sure that we converge on a common understanding of the
issue. As in any argument, it's fairly likely that one of us is wrong,
and I accept that it could very well be me - I have been wrong quite a
few times in my life, and it's always a valuable learning opportunity.

I think it's unfortunate that the thread has devolved into various
accusations and credential-slinging, because it reduces the likelihood
of such a productive outcome. Please feel free to ping me directly any
time, though - I'm happy to chat.

Cheers,
/mz




_____________________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
lcamtuf at coredump
Mar 15, 2014, 12:27 PM
Post #76 of 88 (9064 views)
Permalink
> The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability.

I don't think this is accurate, at least based on the standard
definition of RFI: a server-side scripting language - usually PHP -
accidentally executing a script fetched from a remote server because
it passed an attacker-controlled string to an API that allows both
local file paths and remote URLs.

The report talks about a different behavior: the ability for users to
upload video and non-video content using legitimate functionality of
the site, without a way to make the server do anything interesting
with the received data. This may or may not be interesting on its own
merit, but I think it's pretty far from RFI.

> I also explained a JSON Hijacking case as a follow up, and you said you didn't follow.

Yup, I am genuinely not familiar with the attack vector that *I think*
you are describing, or why it would matter in this context. My earlier
message in this thread explains my reasoning (in essence, there are
certain conditions that have to be met for a typical XSSI bug, and I
don't think they are met here), but if my understanding is wrong, I'd
really like to learn about the proposed attack.

/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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
pedrib at gmail
Mar 17, 2014, 2:24 AM
Post #77 of 88 (9064 views)
Permalink
On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
>
> The thread read Google vulnerabilities with PoC. From my understanding
it was a RFI vulnerability on YouTube, and I voiced my support that this
is a vulnerability.
>
> I also explained a JSON Hijacking case as a follow up, and you said you
didn't follow. So I am just saying that treating security that way, there
are other parties like NSA who welcome them happily.
>

I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
puppets.

They are all first time posters from unusual free email providers jumping
to defend the OP out of nowhere. If you search Google for their emails you
only find references to this thread.

They present similar (false and /or incorrect) arguments, talk about their
extensive work experience, bash Google and its security team and send
repeated emails with exactly the same text.

This is turning into a madhouse... I hope this guy doesn't have access to a
gun.

Regards
Pedro
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
TImbrahim at techemail
Mar 17, 2014, 3:07 AM
Post #78 of 88 (9067 views)
Permalink
What drugs are you on Pedro Ribeiro I wonder ...? I express my views, if you don't like don't watch them. You responses so far have only been assy speculations so don't tell me Im wrong , and please don't say thing like that. I don't know who the other people is, but what is true in security I support. Why you would Google my name ... ? Is the English language causing you ill effects?
--- pedrib@gmail.com wrote:

From: Pedro Ribeiro <pedrib@gmail.com>
To: TImbrahim@techemail.com
Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski <lcamtuf@coredump.cx>, mvilas@gmail.com, gynvael@coldwind.pl
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Mon, 17 Mar 2014 09:24:08 +0000




On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
>
> The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability.
>
> I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily.
>

I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets.

They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere. If you search Google for their emails you only find references to this thread.

They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text.

This is turning into a madhouse... I hope this guy doesn't have access to a gun.

Regards
Pedro


Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
mvilas at gmail
Mar 17, 2014, 3:59 AM
Post #79 of 88 (9084 views)
Permalink
Please stop changing hats, it's embarrasing.


On Sat, Mar 15, 2014 at 7:36 PM, T Imbrahim <TImbrahim@techemail.com> wrote:

> Is this treated with the same way that says that Remote File Inclusion is
> not a security issue ?
>
> You don't follow? Implying ?
>
> I understand why nobody likes Google. If I 've found a vulnerability and
> been treated like that for trying to help, I would rather sell it to the
> black market or to some government.
>
> The NSA maybe is happy to buy a RFI on Google, im sure they could make
> good use of that. Google is very deceptive in security matters.
>
> --- lcamtuf@coredump.cx wrote:
>
> From: Michal Zalewski <lcamtuf@coredump.cx>
> To: TImbrahim@techemail.com
> Cc: pr0ix@yahoo.co.uk, full-disclosure <full-disclosure@lists.grok.org.uk>
> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
> Date: Sat, 15 Mar 2014 10:59:40 -0700
>
> > A hacker exploits a JSON (javascript) object that has information of
> interest for example holding some values for cookies. A lot of times that
> exploits the same policy origin. The JSON object returned from a server can
> be forged over writing javascript function that create the object. This
> happens because of the same origin policy problem in browsers that cannot
> say if js execution it different for two different sites.
>
> To be honest, I'm not sure I follow, but I'm fairly confident that my
> original point stands. If you believe that well-formed JSON objects
> without padding can be read across origins within the browser, I would
> love to see more information about that. (In this particular case, it
> still wouldn't matter because the response doesn't contain secrets,
> but it would certainly break a good chunk of the Internet.) JSONP is a
> different animal.
>
> /mz
>
>
>
>
> _____________________________________________________________
> Are you a Techie? Get Your Free Tech Email Address Now! Visit
> http://www.TechEmail.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.”
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
mvilas at gmail
Mar 17, 2014, 4:02 AM
Post #80 of 88 (9072 views)
Permalink
ROFL

[image: Inline image 1]


On Mon, Mar 17, 2014 at 11:07 AM, T Imbrahim <TImbrahim@techemail.com>wrote:

> What drugs are you on Pedro Ribeiro I wonder ...?
>
> I express my views, if you don't like don't watch them. You responses so
> far have only been assy speculations so don't tell me Im wrong , and please
> don't say thing like that. I don't know who the other people is, but what
> is true in security I support. Why you would Google my name ... ?
>
> Is the English language causing you ill effects?
>
> --- pedrib@gmail.com wrote:
>
> From: Pedro Ribeiro <pedrib@gmail.com>
> To: TImbrahim@techemail.com
> Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski <
> lcamtuf@coredump.cx>, mvilas@gmail.com, gynvael@coldwind.pl
>
> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
> Date: Mon, 17 Mar 2014 09:24:08 +0000
>
>
> On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
> >
> > The thread read Google vulnerabilities with PoC. From my understanding
> it was a RFI vulnerability on YouTube, and I voiced my support that this
> is a vulnerability.
> >
> > I also explained a JSON Hijacking case as a follow up, and you said you
> didn't follow. So I am just saying that treating security that way, there
> are other parties like NSA who welcome them happily.
> >
>
> I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
> puppets.
>
> They are all first time posters from unusual free email providers jumping
> to defend the OP out of nowhere. If you search Google for their emails you
> only find references to this thread.
>
> They present similar (false and /or incorrect) arguments, talk about their
> extensive work experience, bash Google and its security team and send
> repeated emails with exactly the same text.
>
> This is turning into a madhouse... I hope this guy doesn't have access to
> a gun.
>
> Regards
> Pedro
>
>
> ------------------------------
> Are you a Techie? Get Your Free Tech Email Address Now! Visit
> http://www.TechEmail.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.”

Attached Files:

Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
chuksjonia at gmail
Mar 17, 2014, 4:08 AM
Post #81 of 88 (9073 views)
Permalink
Ooh goodie, where and what happened to N3td3v, he used to crack me up :D :D








On 3/17/14, Mario Vilas <mvilas@gmail.com> wrote:
> ROFL
>
> [image: Inline image 1]
>
>
> On Mon, Mar 17, 2014 at 11:07 AM, T Imbrahim
> <TImbrahim@techemail.com>wrote:
>
>> What drugs are you on Pedro Ribeiro I wonder ...?
>>
>> I express my views, if you don't like don't watch them. You responses so
>> far have only been assy speculations so don't tell me Im wrong , and
>> please
>> don't say thing like that. I don't know who the other people is, but
>> what
>> is true in security I support. Why you would Google my name ... ?
>>
>> Is the English language causing you ill effects?
>>
>> --- pedrib@gmail.com wrote:
>>
>> From: Pedro Ribeiro <pedrib@gmail.com>
>> To: TImbrahim@techemail.com
>> Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski <
>> lcamtuf@coredump.cx>, mvilas@gmail.com, gynvael@coldwind.pl
>>
>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>> Date: Mon, 17 Mar 2014 09:24:08 +0000
>>
>>
>> On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
>> >
>> > The thread read Google vulnerabilities with PoC. From my understanding
>> it was a RFI vulnerability on YouTube, and I voiced my support that this
>> is a vulnerability.
>> >
>> > I also explained a JSON Hijacking case as a follow up, and you said you
>> didn't follow. So I am just saying that treating security that way,
>> there
>> are other parties like NSA who welcome them happily.
>> >
>>
>> I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
>> puppets.
>>
>> They are all first time posters from unusual free email providers jumping
>> to defend the OP out of nowhere. If you search Google for their emails
>> you
>> only find references to this thread.
>>
>> They present similar (false and /or incorrect) arguments, talk about
>> their
>> extensive work experience, bash Google and its security team and send
>> repeated emails with exactly the same text.
>>
>> This is turning into a madhouse... I hope this guy doesn't have access to
>> a gun.
>>
>> Regards
>> Pedro
>>
>>
>> ------------------------------
>> Are you a Techie? Get Your Free Tech Email Address Now! Visit
>> http://www.TechEmail.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."
>


--
--
Gichuki John Ndirangu, C.E.H , C.P.T.P, O.S.C.P
I.T Security Analyst and Penetration Tester
jgichuki at inbox d0t com

{FORUM}http://lists.my.co.ke/pipermail/security/
http://chuksjonia.blogspot.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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
joxeankoret at yahoo
Mar 17, 2014, 4:27 AM
Post #82 of 88 (9057 views)
Permalink
Hi,

The only probable way of exploiting it I can see would be if the servers
at Google where the files are uploaded would perform some specific tasks
with such files that could result in exploiting a vulnerability in any
of the used software (and this is something the "discoverer" failed to
probe). An example: Google malware scans the uploaded file with some AV
engine and the file is actually an exploit targeting one or more AV
products. I don't think this is the case and, even in this case, there
wouldn't be any Google's vulnerability but, rather, a vulnerability in
another product from another company.

So, in short: this conversation is stupid. There is no vulnerability we
can see here and, if there is, it cannot be probed by the discoverer and
he and his buddies attach to either ad hominem arguments or to
statements like "I am XXX with YYY years of experience doing ZZZ"
mistakenly thinking it could back any of their paranoias.

What else do we need to discuss here? I think it's time to stop this
conversation. And, yes, I know that sending an e-mail to ask for
stopping a conversation on FD is stupid too.

Regards,
Joxean Koret

Attached Files:

Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
TImbrahim at techemail
Mar 17, 2014, 6:25 AM
Post #83 of 88 (9060 views)
Permalink
Hey,

At least to me I am security paranoid. Remote File Inclusion of files to a trusted network, seems like a well backed up vulnerability. I think we are talking about Google here not your favourite's pizza website. I personally congratulate to the author for finding it, whether probing it or not. And I have nothing to do with the authors, just supporting what is right.

I definitely would patch my computer if I discovered that somebody could upload files to my computer, even thought if couldn't 'probe' them.



--- joxeankoret@yahoo.es wrote:

From: Joxean Koret <joxeankoret@yahoo.es>
To: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Mon, 17 Mar 2014 12:27:27 +0100

Hi,

The only probable way of exploiting it I can see would be if the servers
at Google where the files are uploaded would perform some specific tasks
with such files that could result in exploiting a vulnerability in any
of the used software (and this is something the "discoverer" failed to
probe). An example: Google malware scans the uploaded file with some AV
engine and the file is actually an exploit targeting one or more AV
products. I don't think this is the case and, even in this case, there
wouldn't be any Google's vulnerability but, rather, a vulnerability in
another product from another company.

So, in short: this conversation is stupid. There is no vulnerability we
can see here and, if there is, it cannot be probed by the discoverer and
he and his buddies attach to either ad hominem arguments or to
statements like "I am XXX with YYY years of experience doing ZZZ"
mistakenly thinking it could back any of their paranoias.

What else do we need to discuss here? I think it's time to stop this
conversation. And, yes, I know that sending an e-mail to ask for
stopping a conversation on FD is stupid too.

Regards,
Joxean Koret



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



_____________________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
gauri at tut
Mar 17, 2014, 6:39 AM
Post #84 of 88 (9057 views)
Permalink
Especially considering that all three use Tor to post on the list. I wonder why.
Other header/content details can be interesting as well...


2014-03-17 10:24 GMT+01:00 Pedro Ribeiro <pedrib@gmail.com>:
>
> On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
>>
>> The thread read Google vulnerabilities with PoC. From my understanding it
>> was a RFI vulnerability on YouTube, and I voiced my support that this is a
>> vulnerability.
>>
>> I also explained a JSON Hijacking case as a follow up, and you said you
>> didn't follow. So I am just saying that treating security that way, there
>> are other parties like NSA who welcome them happily.
>>
>
> I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
> puppets.
>
> They are all first time posters from unusual free email providers jumping to
> defend the OP out of nowhere. If you search Google for their emails you only
> find references to this thread.
>
> They present similar (false and /or incorrect) arguments, talk about their
> extensive work experience, bash Google and its security team and send
> repeated emails with exactly the same text.
>
> This is turning into a madhouse... I hope this guy doesn't have access to a
> gun.
>
> Regards
> Pedro
>
>
> _______________________________________________
> 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/
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
mvilas at gmail
Mar 17, 2014, 6:47 AM
Post #85 of 88 (9066 views)
Permalink
On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim <TImbrahim@techemail.com> wrote:

> I definitely would patch my computer if I discovered that somebody could
> upload files to my computer, even thought if couldn't 'probe' them.


1) I don't think you understood the meaning of the word "probe" in this
context, Nikolas,
2) Does that mean you believe Dropbox is vulnerable to remote file upload
too?


--
“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 ]
pedrib at gmail
Mar 17, 2014, 7:09 AM
Post #86 of 88 (9058 views)
Permalink
On 17 Mar 2014 13:39, "Źmicier Januszkiewicz" <gauri@tut.by> wrote:
>
> Especially considering that all three use Tor to post on the list. I
wonder why.
> Other header/content details can be interesting as well...
>

Good catch, I didn't even remember checking the headers.
Have a look at the comments posted in the softpedia article - I can smell
more dirty socks in there.

And for even more fun read his interview:
http://m.softpedia.com/softpedia-interview-nicholas-lemonias-on-satellite-communication-vulnerabilities-420589.html

He even posted it to this list but no one noticed it:
http://marc.info/?l=full-disclosure&m=139076233105401&w=2

>
> 2014-03-17 10:24 GMT+01:00 Pedro Ribeiro <pedrib@gmail.com>:
> >
> > On 16 Mar 2014 23:36, "T Imbrahim" <TImbrahim@techemail.com> wrote:
> >>
> >> The thread read Google vulnerabilities with PoC. From my understanding
it
> >> was a RFI vulnerability on YouTube, and I voiced my support that this
is a
> >> vulnerability.
> >>
> >> I also explained a JSON Hijacking case as a follow up, and you said you
> >> didn't follow. So I am just saying that treating security that way,
there
> >> are other parties like NSA who welcome them happily.
> >>
> >
> > I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
> > puppets.
> >
> > They are all first time posters from unusual free email providers
jumping to
> > defend the OP out of nowhere. If you search Google for their emails you
only
> > find references to this thread.
> >
> > They present similar (false and /or incorrect) arguments, talk about
their
> > extensive work experience, bash Google and its security team and send
> > repeated emails with exactly the same text.
> >
> > This is turning into a madhouse... I hope this guy doesn't have access
to a
> > gun.
> >
> > Regards
> > Pedro
> >
> >
> > _______________________________________________
> > 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 ]
ulisses.montenegro at gmail
Mar 17, 2014, 7:11 AM
Post #87 of 88 (9061 views)
Permalink
Let's try some scenarios and if those can be pulled out then I'd say it's
safe to assume this is an issue:

1. Upload a webshell (in a war, php, asp[x], jsp or similar file) and have
it executed by YouTube;
2. Upload a malicious file (pdf, swf, jar or similar file which exploits a
known or unknown vulnerability in the respective aps) and have it served by
YouTube;
3. Upload a file which alters the behavior of the YouTube application
(i.e., a configuration file, HTML or Javascript template, even a UI image).

Otherwise you just uploaded a file which went into a bitbucket, but you
have no way of pulling this file out of said bitbucket in a way that can
cause harm to either the application or its users.

Should YouTube restrict file uploads to known valid mime types? Sure, but
that's only how you got the data in there to begin with. It's what happens
after the data is in that will make all the difference.



On Mon, Mar 17, 2014 at 10:47 AM, Mario Vilas <mvilas@gmail.com> wrote:

>
> On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim <TImbrahim@techemail.com>wrote:
>
>> I definitely would patch my computer if I discovered that somebody could
>> upload files to my computer, even thought if couldn't 'probe' them.
>
>
> 1) I don't think you understood the meaning of the word "probe" in this
> context, Nikolas,
> 2) Does that mean you believe Dropbox is vulnerable to remote file upload
> too?
>
>
> --
> “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/
>



--
“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 ]
mvilas at gmail
Mar 17, 2014, 8:25 AM
Post #88 of 88 (9056 views)
Permalink
On Mon, Mar 17, 2014 at 3:11 PM, Ulisses Montenegro <
ulisses.montenegro@gmail.com> wrote:

> Should YouTube restrict file uploads to known valid mime types? Sure, but
> that's only how you got the data in there to begin with. It's what happens
> after the data is in that will make all the difference.


At this point I'm not even sure the data isn't being restricted - it just
may be that the data type is checked again after it gets pulled out of the
queue for processing, and if it's not a video it gets discarded.


--
“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.”

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal