Message-ID: <CAPMrQTR9j9PczewCOxhHjRLODqOzhuPm2X4Hbn3k0085xfQKhQ@mail.gmail.com>
Date: Fri, 14 Mar 2014 21:32:13 +0200
From: Julius Kivimäki <julius.kivimaki@...il.com>
To: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Fwd: Google vulnerabilities with PoC

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