Date: Fri, 14 Mar 2014 11:05:08 +0100
From: Mario Vilas <mvilas@...il.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Google vulnerabilities with PoC

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@...glemail.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@...glemail.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@...il.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@...glemail.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@...glemail.com>
>>>> Date: Thu, Mar 13, 2014 at 7:47 PM
>>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>>> To: Julius Kivimäki <julius.kivimaki@...il.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@...il.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@...glemail.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@...glemail.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@...il.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@...glemail.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@...il.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@...glemail.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@...il.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@...glemail.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.”

Content of type "text/html" skipped

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

Powered by blists - more mailing lists