lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Mar 2014 20:27:14 +0000
From: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
To: Chris Thompson <christhom7851@...il.com>, full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd: Google vulnerabilities with PoC

In my expertise, that is a vulnerability.

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




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

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

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ