Date: Fri, 14 Mar 2014 20:23:37 +0100
From: R D <rd.seclists@...il.com>
To: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd: Google vulnerabilities with PoC

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@...glemail.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/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists