Mailing List Archive

We confirm this to be a valid vulnerability for the following reasons.

The access control subsystem is defeated, resulting to arbitrary write
access of any file of choice.

1. You Tube defines which file types are permitted to be uploaded.

2. Exploitation is achieved by circumvention of web-based security controls
(namely http forms, which is a weak security measure). However,
exploitation of the issue results to unrestricted file uploads (any file of
choice ). Remote code execution may be possible either through social
engineering , or by stochastically rewriting an existing file-structure in
the CDN.

3. This directly impacts the integrity of the service since modification of
information occurs by circumvention. Renaming the uploaded files can be
achieved through YouTube's inherent video manager.

4. Denial of Service attacks are feasible since we bypass all security
restrictions. This directly impacts the availability of the service.

5. Malware propagation is possible, if the planted code get's executed
through social engineering or by re-writing a valid file system structure.


6) All uploaded files can be downloaded through Google Take Out, if past
the Content ID filtering algorithm (through file header obfuscation and
encryption).


It is pertinent to note that all publications are made to help mature the
practise and we application security.

Best Regards,
Nicholas Lemonias
Advanced Information Security Corp.

EOF


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

> Look, you keep calling it a "vulnerability" with 0 evidence that it's even
> exploitable. Until you can prove otherwise this is like speculating the
> potential security repercussions of uploading files to EC2 (Which would
> probably have potential to be much more severe than what you're discussing
> here since javascript uploaded to ec2 could actually get executed by
> someones browser)
>
> You keep throwing around keywords like OWASP, OSI, "security best
> practices" as if they actually make a difference here. Truth is there's no
> reason to believe that what you have discovered here is exploitable. This
> mostly seems like a desperate attempt of getting money off of google and
> your name in some publication shitty enough to not do any fact checking
> (eg. softpedia) .
>
>
> 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.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.
>>
>>
>> ---------- 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/
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Are you a Google employee...I wonder?

There is nothing else to be said regarding this. Our research for remote
code execution continues and will let you and Google know once that is
confirmed; through the coordinated security program.

And please OWASP, is recognised worldwide.


Best Regards,
Nicholas Lemonias


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

> Look, you keep calling it a "vulnerability" with 0 evidence that it's even
> exploitable. Until you can prove otherwise this is like speculating the
> potential security repercussions of uploading files to EC2 (Which would
> probably have potential to be much more severe than what you're discussing
> here since javascript uploaded to ec2 could actually get executed by
> someones browser)
>
> You keep throwing around keywords like OWASP, OSI, "security best
> practices" as if they actually make a difference here. Truth is there's no
> reason to believe that what you have discovered here is exploitable. This
> mostly seems like a desperate attempt of getting money off of google and
> your name in some publication shitty enough to not do any fact checking
> (eg. softpedia) .
>
>
> 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.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.
>>
>>
>> ---------- 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/
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Here's my evidence.

Live Proof Of Concept
==================
http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw


{"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"}}

The above proof of concept demonstrates :

1. We have bypassed the security controls in Youtube and uploaded an
unexpected file type.
2. The file is persistent and has not been deleted by YouTube.
3. It can be queried for information since it is assigned a unique
upload_id.
4. It's successfully uploaded to youtube.com As you can see it give out
the total bytes written to the remote network.
5. "content_type":"text/x-sh"}] -------> The file is a shell
script script named 'file'
6. It can be enumerated by a non-authenticated user, remotely.


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

> Are you a Google employee...I wonder?
>
> There is nothing else to be said regarding this. Our research for remote
> code execution continues and will let you and Google know once that is
> confirmed; through the coordinated security program.
>
> And please OWASP, is recognised worldwide.
>
>
> Best Regards,
> Nicholas Lemonias
>
>
> On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> Look, you keep calling it a "vulnerability" with 0 evidence that it's
>> even exploitable. Until you can prove otherwise this is like speculating
>> the potential security repercussions of uploading files to EC2 (Which would
>> probably have potential to be much more severe than what you're discussing
>> here since javascript uploaded to ec2 could actually get executed by
>> someones browser)
>>
>> You keep throwing around keywords like OWASP, OSI, "security best
>> practices" as if they actually make a difference here. Truth is there's no
>> reason to believe that what you have discovered here is exploitable. This
>> mostly seems like a desperate attempt of getting money off of google and
>> your name in some publication shitty enough to not do any fact checking
>> (eg. softpedia) .
>>
>>
>> 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.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.
>>>
>>>
>>> ---------- 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/
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

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/

Zakewski,

Thank you for your e-mail. I welcome all opinions, that are backed up by
evidences.

I am not just a security researcher, I am also an academic in the field and
lecturer.

However, from an academic perspective, when it comes to certain
security designs the mere existence of unvalidated requests is symptomatic
of deeper code problems. Thus, in academia such definitions are vague,
unless they are either backed-up by original, incisive research, or by
existing subject matter literature which is widely accepted.

In terms of what constitutes a security vulnerability, it is a weakness in
a product or service that may allow an attacker to compromise the (C-I-A)
Confidentiality, Integrity and Availability of that same service, and I bet
you 've heard this many times before. Adequate security requirements entail
properties of 1) confidentiality, 2) integrity, 3) availability
but also 4) authorization , 5) non-repudiation and 6) authentication.

Integrity: Integrity refers to the trustworthiness of a resource. An
attacker exploits a weakness in a service to modify it silently and without
authorization means is compromising the integrity of that service.

Example: A weakness that allows an administrator to change the permission
sets on a file , that is not a security vulnerability because an
administrator already has this capability. However if a weakness allowed an
unprivileged user to do the same thing (say to write arbitrary files to a
remote service), that would constitute to a security vulnerability.

Availability*:* Availability refers to the ability to access a resource. An
attacker that exploits a weakness in a service, denying appropriate user
access to it, is thus compromising the availability of that particular
service. In our case a Denial of Service is feasible, because the uploaded
files are persistent and can lead to resource exhaustion.

Example: A weakness that enables an attacker to cause a server to fail
would constitute a vulnerability, since the attacker denies resources
pertinent to that service. Resource exhaustion is possible.

Confidentiality: Confidentiality refers to the disclosure of information,
to unauthorised parties. However this is by no means the only property
required for security. In this case just because we haven't accessed some
files, that does not mean that the service is secure.

Authorization: Refers to the process of determining which 'principals' have
access and to which 'objects'. Access control is a type of authorization,
hence its name. In case of the API upload functionality, a script is loaded
and somewhere a write() function is called. The access control was weak
since it was web-based. We could arbitrary write() any file of choice to
the system as a result, something that only an administrator with full
permission sets should be able to do.

admin.youtube.com is the admin login.


On Fri, Mar 14, 2014 at 4:19 AM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

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

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/

> Zakewski,
>
> Thank you for your e-mail. I welcome all opinions, that are backed up by evidences.
>
> I am not just a security researcher, I am also an academic in the field and lecturer.

All right :-) Thank you for the overview of CIA triad. I don't think
there's a good probability that our thinking about this report will
converge - but if you see demand for the approach you are advocating
(be it in the academia or in the consulting business), I think that's
fair.

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/

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

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

On Thu, Mar 13, 2014 at 10:30 PM, Nicholas Lemonias. <
lem.nikolas@googlemail.com> wrote:

> We confirm this to be a valid vulnerability for the following reasons.
>
> The access control subsystem is defeated, resulting to arbitrary write
> access of any file of choice.
>
> 1. You Tube defines which file types are permitted to be uploaded.
>

And...?


>
> 2. Exploitation is achieved by circumvention of web-based security
> controls (namely http forms, which is a weak security measure). However,
> exploitation of the issue results to unrestricted file uploads (any file of
> choice ). Remote code execution may be possible either through social
> engineering , or by stochastically rewriting an existing file-structure in
> the CDN.
>

So in ohter words, you haven't proven it. The upload in itself is not a
vulnerability (and if you understood that it is, please read again that
OWASP document).


>
> 3. This directly impacts the integrity of the service since modification
> of information occurs by circumvention. Renaming the uploaded files can be
> achieved through YouTube's inherent video manager.
>

How does it impact the integrity? Again, unexpected functionality does not
necessarily equal exploitation.


>
> 4. Denial of Service attacks are feasible since we bypass all security
> restrictions. This directly impacts the availability of the service.
>

Not proven either. At this point I feel you're just making stuff up. All
you did was upload stuff you can't download afterwards.


>
> 5. Malware propagation is possible, if the planted code get's executed
> through social engineering or by re-writing a valid file system structure.
>
>

Again, you need to be able to download the stuff you uploaded, and have it
executed directly. Otherwise you could do the same thing more efficiently
with Google Drive.


>
> 6) All uploaded files can be downloaded through Google Take Out, if past
> the Content ID filtering algorithm (through file header obfuscation and
> encryption).
>

You need to explain how that is an attack vector.


>
>
> Best Regards,
> Nicholas Lemonias
> Advanced Information Security Corp.
>
>
>
>
>
>
> _______________________________________________
> 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.”

You're still missing the attack vector (and the point of the discussion
too, but that's painfully obvious).


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

>
> Here's my evidence.
>
> Live Proof Of Concept
> ==================
>
> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>
>
>
> {"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"}}
>
> The above proof of concept demonstrates :
>
> 1. We have bypassed the security controls in Youtube and uploaded an
> unexpected file type.
> 2. The file is persistent and has not been deleted by YouTube.
> 3. It can be queried for information since it is assigned a unique
> upload_id.
> 4. It's successfully uploaded to youtube.com As you can see it give out
> the total bytes written to the remote network.
> 5. "content_type":"text/x-sh"}] -------> The file is a shell
> script script named 'file'
> 6. It can be enumerated by a non-authenticated user, remotely.
>
>
> On Fri, Mar 14, 2014 at 2:40 AM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Are you a Google employee...I wonder?
>>
>> There is nothing else to be said regarding this. Our research for remote
>> code execution continues and will let you and Google know once that is
>> confirmed; through the coordinated security program.
>>
>> And please OWASP, is recognised worldwide.
>>
>>
>> Best Regards,
>> Nicholas Lemonias
>>
>>
>> On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki <
>> julius.kivimaki@gmail.com> wrote:
>>
>>> Look, you keep calling it a "vulnerability" with 0 evidence that it's
>>> even exploitable. Until you can prove otherwise this is like speculating
>>> the potential security repercussions of uploading files to EC2 (Which would
>>> probably have potential to be much more severe than what you're discussing
>>> here since javascript uploaded to ec2 could actually get executed by
>>> someones browser)
>>>
>>> You keep throwing around keywords like OWASP, OSI, "security best
>>> practices" as if they actually make a difference here. Truth is there's no
>>> reason to believe that what you have discovered here is exploitable. This
>>> mostly seems like a desperate attempt of getting money off of google and
>>> your name in some publication shitty enough to not do any fact checking
>>> (eg. softpedia) .
>>>
>>>
>>> 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. <
>>> lem.nikolas@googlemail.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.
>>>>
>>>>
>>>> ---------- 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/
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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.”

On 13 Mar 2014 14:30, "Nicholas Lemonias." <lem.nikolas@googlemail.com>
wrote:
>
> I suggest you to read on Content Delivery Network Architectures .
>
> YouTube.com populates and distributes stored files to multiple servers
> through a CDN (Content Delivery Architecture), where each video uses more
> than one machine (hosted by a cluster). Less populated video files are
> normally stored in various colocation sites. The YouTube architecture uses
> databases for storing metadata information of all uploaded files.
>
> https://www.owasp.org/index.php/Unrestricted_File_Upload
>

Being a CDN means it is very hard to find out where your file went.

I agree with was said on this thread by other people.

As an external penetration testing consultant, I would put this on a client
report as a low risk finding / possible vulnerability and recommend it to
be fixed.

As an internal vulnerability manager I would push the developers to fix it,
but I would give it a low priority and only real press then once all the
higher priority ones have been fixed.

However in the "real world" it is not a vulnerability, and don't expect
Google to pay you for it.

Regards
Pedro

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

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

Nicholas Lemonias. 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.

LOL you mean 1, maybe 2 hours, you need to write (and test) a
Ruby/Python script.
I don't know your hourly rate, but wouldn't that be like 200$? Is that
really worth?

Also, the point that this 'bug' counts as a valid finding when you do
pentests, well it's a long story.
If you see reports from the big4 companies, you can always notice info
findings as in TRACE enabled
(you can't 'exploit' that through XHR from years anyways), but simply
you wouldn't expect Google to pay you
for such a bug. Same with this bug.

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

--
Cheers
Michele

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.


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

Live Proof Of Concept
==================
http://upload.youtube.com/?authuser=0&upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw


{"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"}}

The above proof of concept demonstrates :

1. We have bypassed the security controls in Youtube and uploaded an
unexpected file type.
2. The file is persistent and has not been deleted by YouTube.
3. It can be queried for information since it is assigned a unique
upload_id.
4. It's successfully uploaded to youtube.com As you can see it give out
the total bytes written to the remote network.
5. "content_type":"text/x-sh"}] -------> The file is a shell
script script named 'file'
6. It can be enumerated by a non-authenticated user, remotely.


So that is a proof that the data are persistent.



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

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

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

LOL, thanks for the undeserved praise! xD


On Fri, Mar 14, 2014 at 2: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/
>>>
>>
>>


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

Mario has years of experience (more than 10 in fact) in exploit writing
and vulnerability assessment. I would consider his position on the subject.

If you don't believe me, Argentina extended me certifications that
proves that I can tell who has vulnerability assesment skills and who
does not.

If you don't believe in Argentina, you should know the ONU accepts it as
a sovereign independent country.

That is the complete certificate chain proving you that Mario is not an
idiot as you inferred.

Best regards,

Alfred


On 03/14/2014 10:50 AM, Sergio 'shadown' Alvarez 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/
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/

Oh and this guy Shadown seems pretty knowledgeable too.

BTW now I have to read what is this about,lets see...

Alright, from TFA:

"That means that a door was open for anyone to upload any file of
choice. Whether this is a security vulnerability or not, I will leave
that to your discretion"

Not even you are sure this is a real vulnerability. It is not.



On 03/14/2014 03:36 PM, Alfredo Ortega wrote:
> Mario has years of experience (more than 10 in fact) in exploit writing
> and vulnerability assessment. I would consider his position on the subject.
>
> If you don't believe me, Argentina extended me certifications that
> proves that I can tell who has vulnerability assesment skills and who
> does not.
>
> If you don't believe in Argentina, you should know the ONU accepts it as
> a sovereign independent country.
>
> That is the complete certificate chain proving you that Mario is not an
> idiot as you inferred.
>
> Best regards,
>
> Alfred
>
>
> On 03/14/2014 10:50 AM, Sergio 'shadown' Alvarez 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..
>>>

_______________________________________________
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 he can change the mime type, then he indeed may have an attack
vector, e.g. he could upload a complete youtube-lookalike site and
snatch credentials. If you can access the fake site via HTTPS with a
youtube cert, it's an obvious vulnerability.



On 03/14/2014 07:05 AM, Mario Vilas wrote:
> You're still missing the attack vector (and the point of the discussion
> too, but that's painfully obvious).
>
>
> On Fri, Mar 14, 2014 at 4:21 AM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>>
>> Here's my evidence.
>>
>> Live Proof Of Concept
>> ==================
>>
>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>
>>
>>
>> {"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"}}
>>
>> The above proof of concept demonstrates :
>>
>> 1. We have bypassed the security controls in Youtube and uploaded an
>> unexpected file type.
>> 2. The file is persistent and has not been deleted by YouTube.
>> 3. It can be queried for information since it is assigned a unique
>> upload_id.
>> 4. It's successfully uploaded to youtube.com As you can see it give out
>> the total bytes written to the remote network.
>> 5. "content_type":"text/x-sh"}] -------> The file is a shell
>> script script named 'file'
>> 6. It can be enumerated by a non-authenticated user, remotely.
>>

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

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

I'm just a lurker on the list, which I have always found valuable.

But for what it's worth, this thread is an awful bore. Who cares
about people's credentials?

I'm not asking for administrative intervention, which I hate, but
rather that the various entrants in the pissing contest empty their
bladders elsewhere. Please!