Mailing List Archive

Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Nicholas, seriously, just stop.

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

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

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





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

> We have many PoC's including video clips. We may upload for the security
> world to see.
>
> However, this is not the way to treat security vulnerabilities. Attacking
> the researcher and bringing you friends to do aswell, won't mitigate the
> problem.
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
congrats for your discover, get you prize

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


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

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



--
Grato,

J. Tozo
_
°v°
/(S)\ SLACKWARE
^ ^ Linux
_____________________
because it works
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
You are wrong, because we do have proof of concepts. If we didn't have
them, then there would be no case.

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

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

Best,

Nicholas.


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

> Nicholas, seriously, just stop.
>
> You have found an 'arbitrary file upload' in a file hosting service and
> claim it is a serious vulnerability. With no proof that your 'arbitrary
> file' is being used anywhere in any context that would lead to code
> execution - on server or client side. You cite OWASP documents (which are
> unrelated to the case), academia papers from 1975 just to find a reason
> it's theoretically serious, not paying any attention to what service you're
> actually attacking and what have you really achieved in that (which is
> demonstrating a filtering weakness at best, low risk).
>
> Everyone on this list so far explains why you're wrong, but you just won't
> stop. So you start throwing out certificates, your academia experience and
> your respected company. Then - name calling everyone else. Seriously, it's
> just a good laugh for most of us.
>
> Dude, please, just because you did not qualify for a bounty, there's no
> point in launching a whole campaign like you are. You're essentially
> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
> a crowdsourcing campaign!
>
>
>
>
>
> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
>> We have many PoC's including video clips. We may upload for the security
>> world to see.
>>
>> However, this is not the way to treat security vulnerabilities. Attacking
>> the researcher and bringing you friends to do aswell, won't mitigate the
>> problem.
>>
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Care to report the same to Dropbox and Pastebin? It's a gold mine, you
know...


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

> You are wrong, because we do have proof of concepts. If we didn't have
> them, then there would be no case.
>
> But if there are video clips, images demonstrating impact - in which case
> arbitrary file uploads (which is a write() call ) to a remote network, then
> it is a vulnerability. It is not about the bounty, but rather about not
> defying academic literature and widely recognised practise.
>
> Attacking the arguer, won't make the bug to go away.
>
> Best,
>
> Nicholas.
>
>
> On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz <
> kkotowicz+fd@gmail.com> wrote:
>
>> Nicholas, seriously, just stop.
>>
>> You have found an 'arbitrary file upload' in a file hosting service and
>> claim it is a serious vulnerability. With no proof that your 'arbitrary
>> file' is being used anywhere in any context that would lead to code
>> execution - on server or client side. You cite OWASP documents (which are
>> unrelated to the case), academia papers from 1975 just to find a reason
>> it's theoretically serious, not paying any attention to what service you're
>> actually attacking and what have you really achieved in that (which is
>> demonstrating a filtering weakness at best, low risk).
>>
>> Everyone on this list so far explains why you're wrong, but you just
>> won't stop. So you start throwing out certificates, your academia
>> experience and your respected company. Then - name calling everyone else.
>> Seriously, it's just a good laugh for most of us.
>>
>> Dude, please, just because you did not qualify for a bounty, there's no
>> point in launching a whole campaign like you are. You're essentially
>> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
>> wall) - he DID find a vuln though. Do you really want that? Go ahead, start
>> a crowdsourcing campaign!
>>
>>
>>
>>
>>
>> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>>> We have many PoC's including video clips. We may upload for the security
>>> world to see.
>>>
>>> However, this is not the way to treat security vulnerabilities.
>>> Attacking the researcher and bringing you friends to do aswell, won't
>>> mitigate the problem.
>>>
>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
We are not asking for a payment. But at least a thank you for our efforts
would do.

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


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

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




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

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


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

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

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

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

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

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

--Rob'

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

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

Your POC doesn't demonstrate that.

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

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

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


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

> We have many PoC's including video clips. We may upload for the security
> world to see.
>
> However, this is not the way to treat security vulnerabilities. Attacking
> the researcher and bringing you friends to do aswell, won't mitigate the
> problem.
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
Then that also means that firewalls and IPS systems are worthless. Why
spend so much time protecting the network layers if a user can send any
file of choice to a remote network through http...

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

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


Thanks,


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

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


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

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


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

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

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

--Rob'



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

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

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

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

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

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

However...

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

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

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

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

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

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

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

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

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

Hope this helps....

Cheers!
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
http://upload.youtube.com/?authuser=0&upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

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


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

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

Cheers!


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

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


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

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

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

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

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

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

Cheers...



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

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

--Rob


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

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


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

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

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


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

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

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

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


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

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

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

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

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


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

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

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




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

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

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

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

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


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

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

IMHO it is not a security issue. You're uploading a file to some kind of
processing queue that does not validate a file type, but nevertheless only
processes those files as video - there is NO reason to suspect otherwise,
and I'd like to be proven wrong here. Proven as in PoC.
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
[image: Inline image 1]


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

> Quite funnily, most erratic comments originate from a @gmail.com host.
> Does that mean that Google and Co are attacking the researcher ?
>
>
> On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Quite funnily, most erratic comments originate from a @gmail.com host.
>> Does that mean that Google and Co are attacking the researcher ?
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale <eyeronic.design@gmail.com>wrote:
>>
>>> No, you're saying something's a vulnerability without showing any
>>> indication of how it can be abused.
>>>
>>> On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
>>> <lem.nikolas@googlemail.com> wrote:
>>> > The full-disclosure mailing list has really changed. It's full of
>>> lamers
>>> > nowdays aiming high.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
>>> > <lem.nikolas@googlemail.com> wrote:
>>> >>
>>> >> Says the script kiddie... Beg for some publicity. My customers are
>>> FTSE
>>> >> 100.
>>> >>
>>> >> ---------- Forwarded message ----------
>>> >> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> >> Date: Fri, Mar 14, 2014 at 5:58 PM
>>> >> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
>>> >> To: antisnatchor <antisnatchor@gmail.com>
>>> >>
>>> >>
>>> >> Says the script kiddie... Beg for some publicity. My customers are
>>> FTSE
>>> >> 100.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor <antisnatchor@gmail.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>> LOL you're hopeless.
>>> >>> Good luck with your business. Brave customers!
>>> >>>
>>> >>> Cheers
>>> >>> antisnatchor
>>> >>>
>>> >>> Nicholas Lemonias. wrote:
>>> >>>
>>> >>>
>>> >>> People can read the report if they like. Can't you even do basic
>>> things
>>> >>> like reading a vulnerability report?
>>> >>>
>>> >>> Can't you see that the advisory is about writing arbitrary files. If
>>> I
>>> >>> was your boss I would fire you.
>>> >>> ---------- Forwarded message ----------
>>> >>> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
>>> >>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> >>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> >>> To: Mario Vilas <mvilas@gmail.com>
>>> >>>
>>> >>>
>>> >>> People can read the report if they like. Can't you even do basic
>>> things
>>> >>> like reading a vulnerability report?
>>> >>>
>>> >>> Can't you see that the advisory is about writing arbitrary files. If
>>> I
>>> >>> was your boss I would fire you, with a good kick outta the door.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas <mvilas@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>>> >>>> <lem.nikolas@googlemail.com> wrote:
>>> >>>>>
>>> >>>>> Jerome of Mcafee has made a very valid point on revisiting
>>> separation
>>> >>>>> of duties in this security instance.
>>> >>>>>
>>> >>>>> Happy to see more professionals with some skills. Some others have
>>> >>>>> also mentioned the feasibility for Denial of Service attacks.
>>> Remote code
>>> >>>>> execution by Social Engineering is also a prominent scenario.
>>> >>>>
>>> >>>>
>>> >>>> Actually, people have been pointing out exactly the opposite. But
>>> if you
>>> >>>> insist on believing you can DoS an EC2 by uploading files, good
>>> luck to you
>>> >>>> then...
>>> >>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> If you can't tell that that is a vulnerability (probably coming
>>> from a
>>> >>>>> bunch of CEH's), I feel sorry for those consultants.
>>> >>>>
>>> >>>>
>>> >>>> You're the only one throwing around certifications here. I can no
>>> longer
>>> >>>> tell if you're being serious or this is a massive prank.
>>> >>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Nicholas.
>>> >>>>>
>>> >>>>>
>>> >>>>> On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias.
>>> >>>>> <lem.nikolas@googlemail.com> wrote:
>>> >>>>>>
>>> >>>>>> We are on a different level perhaps. We do certainly disagree on
>>> those
>>> >>>>>> points.
>>> >>>>>> I wouldn't hire you as a consultant, if you can't tell if that is
>>> a
>>> >>>>>> valid vulnerability..
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Best Regards,
>>> >>>>>> Nicholas Lemonias.
>>> >>>>>>
>>> >>>>>> On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas <mvilas@gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> But do you have all the required EH certifications? Try this one
>>> from
>>> >>>>>>> the Institute for
>>> >>>>>>> Certified Application Security Specialists:
>>> http://www.asscert.com/
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias.
>>> >>>>>>> <lem.nikolas@googlemail.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Thanks Michal,
>>> >>>>>>>>
>>> >>>>>>>> We are just trying to improve Google's security and contribute
>>> to
>>> >>>>>>>> the research community after all. If you are still on EFNet
>>> give me a shout
>>> >>>>>>>> some time.
>>> >>>>>>>>
>>> >>>>>>>> We have done so and consulted to hundreds of clients including
>>> >>>>>>>> Microsoft, Nokia, Adobe and some of the world's biggest
>>> corporations. We are
>>> >>>>>>>> also strict supporters of the ACM code of conduct.
>>> >>>>>>>>
>>> >>>>>>>> Regards,
>>> >>>>>>>> Nicholas Lemonias.
>>> >>>>>>>> AISec
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias.
>>> >>>>>>>> <lem.nikolas@googlemail.com> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> Hi Jerome,
>>> >>>>>>>>>
>>> >>>>>>>>> Thank you for agreeing on access control, and separation of
>>> duties.
>>> >>>>>>>>>
>>> >>>>>>>>> However successful exploitation permits arbitrary write() of
>>> any
>>> >>>>>>>>> file of choice.
>>> >>>>>>>>>
>>> >>>>>>>>> I could release an exploit code in C Sharp or Python that
>>> permits
>>> >>>>>>>>> multiple file uploads of any file/types, if the Google
>>> security team feels
>>> >>>>>>>>> that this would be necessary. This is unpaid work, so we are
>>> not so keen on
>>> >>>>>>>>> that job.
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias
>>> >>>>>>>>> <athiasjerome@gmail.com> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Hi
>>> >>>>>>>>>>
>>> >>>>>>>>>> I concur that we are mainly discussing a terminology problem.
>>> >>>>>>>>>>
>>> >>>>>>>>>> In the context of a Penetration Test or WAPT, this is a
>>> Finding.
>>> >>>>>>>>>> Reporting this finding makes sense in this context.
>>> >>>>>>>>>>
>>> >>>>>>>>>> As a professional, you would have to explain if/how this
>>> finding
>>> >>>>>>>>>> is a
>>> >>>>>>>>>> Weakness*, a Violation (/Regulations, Compliance, Policies or
>>> >>>>>>>>>> Requirements[1])
>>> >>>>>>>>>> * I would say Weakness + Exposure = Vulnerability.
>>> Vulnerability +
>>> >>>>>>>>>> Exploitability (PoC) = Confirmed Vulnerability that needs
>>> Business
>>> >>>>>>>>>> Impact and Risk Analysis
>>> >>>>>>>>>>
>>> >>>>>>>>>> So I would probably have reported this Finding as a Weakness
>>> (and
>>> >>>>>>>>>> not
>>> >>>>>>>>>> Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it
>>> is
>>> >>>>>>>>>> not
>>> >>>>>>>>>> Best Practice (your OWASP link and Cheat Sheets), and even if
>>> >>>>>>>>>> mitigative/compensative security controls (Ref Orange Book),
>>> >>>>>>>>>> security
>>> >>>>>>>>>> controls like white listing (or at least black listing. see
>>> also
>>> >>>>>>>>>> ESAPI) should be 1) part of the [1]security requirements of a
>>> >>>>>>>>>> proper
>>> >>>>>>>>>> SDLC (Build security in) as per Defense-in-Depth security
>>> >>>>>>>>>> principles
>>> >>>>>>>>>> and 2) used and implemented correctly.
>>> >>>>>>>>>> NB: A simple Threat Model (i.e. list of CAPEC) would be a
>>> solid
>>> >>>>>>>>>> support to your report
>>> >>>>>>>>>> This would help to evaluate/measure the risk (e.g. CVSS).
>>> >>>>>>>>>> Helping the decision/actions around this risk
>>> >>>>>>>>>>
>>> >>>>>>>>>> PS: interestingly, in this case, I'm not sure that the
>>> Separation
>>> >>>>>>>>>> of
>>> >>>>>>>>>> Duties security principle was applied correctly by Google in
>>> term
>>> >>>>>>>>>> of
>>> >>>>>>>>>> Risk Acceptance (which could be another Finding)
>>> >>>>>>>>>>
>>> >>>>>>>>>> So in few words, be careful with the terminology. (don't
>>> always
>>> >>>>>>>>>> say
>>> >>>>>>>>>> vulnerability like the media say hacker, see RFC1392) Use a
>>> CWE ID
>>> >>>>>>>>>> (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)
>>> >>>>>>>>>>
>>> >>>>>>>>>> My 2 bitcents
>>> >>>>>>>>>> Sorry if it is not edible :)
>>> >>>>>>>>>> Happy Hacking!
>>> >>>>>>>>>>
>>> >>>>>>>>>> /JA
>>> >>>>>>>>>> https://github.com/athiasjerome/XORCISM
>>> >>>>>>>>>>
>>> >>>>>>>>>> 2014-03-14 7:19 GMT+03:00 Michal Zalewski <
>>> lcamtuf@coredump.cx>:
>>> >>>>>>>>>> > Nicholas,
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > I remember my early years in the infosec community - and
>>> sadly,
>>> >>>>>>>>>> > so do
>>> >>>>>>>>>> > some of the more seasoned readers of this list :-) Back
>>> then, I
>>> >>>>>>>>>> > thought that the only thing that mattered is the ability to
>>> find
>>> >>>>>>>>>> > bugs.
>>> >>>>>>>>>> > But after some 18 years in the industry, I now know that
>>> there's
>>> >>>>>>>>>> > an
>>> >>>>>>>>>> > even more important and elusive skill.
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > That skill boils down to having a robust mental model of
>>> what
>>> >>>>>>>>>> > constitutes a security flaw - and being able to explain your
>>> >>>>>>>>>> > thinking
>>> >>>>>>>>>> > to others in a precise and internally consistent manner that
>>> >>>>>>>>>> > convinces
>>> >>>>>>>>>> > others to act. We need this because the security of a system
>>> >>>>>>>>>> > can't be
>>> >>>>>>>>>> > usefully described using abstract terms: even the academic
>>> >>>>>>>>>> > definitions
>>> >>>>>>>>>> > ultimately boil down to saying "the system is secure if it
>>> >>>>>>>>>> > doesn't do
>>> >>>>>>>>>> > the things we *really* don't want it to do".
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > In this spirit, the term "vulnerability" is generally
>>> reserved
>>> >>>>>>>>>> > for
>>> >>>>>>>>>> > behaviors that meet all of the following criteria:
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > 1) The behavior must have negative consequences for at
>>> least one
>>> >>>>>>>>>> > of
>>> >>>>>>>>>> > the legitimate stakeholders (users, service owners, etc),
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > 2) The consequences must be widely seen as unexpected and
>>> >>>>>>>>>> > unacceptable,
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > 3) There must be a realistic chance of such a negative
>>> outcome,
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > 4) The behavior must introduce substantial new risks that go
>>> >>>>>>>>>> > beyond
>>> >>>>>>>>>> > the previously accepted trade-offs.
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > If we don't have that, we usually don't have a case, no
>>> matter
>>> >>>>>>>>>> > how
>>> >>>>>>>>>> > clever the bug is.
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > Cheers (and happy hunting!),
>>> >>>>>>>>>> > /mz
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > _______________________________________________
>>> >>>>>>>>>> > Full-Disclosure - We believe in it.
>>> >>>>>>>>>> > Charter:
>>> http://lists.grok.org.uk/full-disclosure-charter.html
>>> >>>>>>>>>> > Hosted and sponsored by Secunia - http://secunia.com/
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> Full-Disclosure - We believe in it.
>>> >>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> >>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> "There's a reason we separate military and the police: one
>>> fights the
>>> >>>>>>> enemy of the state, the other serves and protects the people.
>>> When the
>>> >>>>>>> military becomes both, then the enemies of the state tend to
>>> become the
>>> >>>>>>> people."
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> Full-Disclosure - We believe in it.
>>> >>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> >>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> "There's a reason we separate military and the police: one fights
>>> the
>>> >>>> enemy of the state, the other serves and protects the people. When
>>> the
>>> >>>> military becomes both, then the enemies of the state tend to become
>>> the
>>> >>>> people."
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Full-Disclosure - We believe in it.
>>> >>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> >>> Hosted and sponsored by Secunia - http://secunia.com/
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Cheers
>>> >>> Michele
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Full-Disclosure - We believe in it.
>>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> > Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>>
>>>
>>> --
>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>>>
>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”
Re: Fwd: Google vulnerabilities with PoC [ In reply to ]
So if you can upload a file to Google Drive and trick someone to run it,
you'd call that a vulnerability too?

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

Keep at it man, you're hilarious! xDDD

/me goes grab more popcorn


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

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



--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

1 2 3 4  View All