Message-ID: <CA+CewVB_u2SEH5EPN_6T73w+AK2nJR3kdmhJgKrXdF5bp9Hzcw@mail.gmail.com>
Date: Sat, 15 Mar 2014 03:58:41 +0000
From: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
To: R D <rd.seclists@...il.com>, full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd: Google vulnerabilities with PoC

Happy trolling...


On Fri, Mar 14, 2014 at 7:49 PM, R D <rd.seclists@...il.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...
> 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@...glemail.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@...il.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@...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/
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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