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