Happy trolling...
On Fri, Mar 14, 2014 at 7:49 PM, R D <rd.secli...@gmail.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.niko...@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.secli...@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.niko...@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/ >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
