Full Disclosure mailing list archives
Re: Fwd: Google vulnerabilities with PoC
From: R D <rd.seclists () gmail com>
Date: Fri, 14 Mar 2014 20:49:49 +0100
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 () 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.seclists () 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 thefile 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 rangeof 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 () 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/
Current thread:
- Re: Fwd: Google vulnerabilities with PoC, (continued)
- Re: Fwd: Google vulnerabilities with PoC Krzysztof Kotowicz (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Michal Zalewski (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Mario Vilas (Mar 15)
- Re: Fwd: Google vulnerabilities with PoC Colette Chamberland (Mar 15)
- Re: Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC David H (Mar 15)
- Re: Fwd: Google vulnerabilities with PoC antisnatchor (Mar 15)
- Re: Fwd: Google vulnerabilities with PoC Mario Vilas (Mar 15)
- Re: Fwd: Google vulnerabilities with PoC R D (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Yvan Janssens (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Colette Chamberland (Mar 15)
- Re: Fwd: Fwd: Google vulnerabilities with PoC Mario Vilas (Mar 14)
- Re: Google vulnerabilities with PoC Mario Vilas (Mar 14)
- Re: Google vulnerabilities with PoC Sergio 'shadown' Alvarez (Mar 14)
- Message not available
- Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Fwd: Google vulnerabilities with PoC Sergio 'shadown' Alvarez (Mar 14)
- Message not available
- Re: Fwd: Google vulnerabilities with PoC Nicholas Lemonias. (Mar 14)
- Re: Google vulnerabilities with PoC Mario Vilas (Mar 14)