Finally I've got some free time to update my blog, and post about my latest security seminar: it was in Munich, Germany, on 20th January 2010. It has been a great experience, mainly because some friends from University invited me to speak there, and the beer was so flavored.

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.

Hi to all my readers. 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

Everyone interested in Web Application Security is invited to come to my seminar today, from 11:00 to 13:00 AM, here in Bologna (University, Aula Ercolani E2). My slides can be found here: http://www.cs.unibo.it/babaoglu/courses/security/lucidi/SecureProgrammin... 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've sent some of the bugs I've researched months ago on Bugtraq. 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

Sometimes you've certainly heard about automated vs manual penetration testing, how the latter is better in terms of discovering security issues, and so on.
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 bugs 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 lot of months ago I was researching bugs in the excellent Pentaho Business Intelligence platform (with bundled jboss). I've found the following: 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

I've just finished my seminar Secure Programming and Common Errors at my university (Bologna), on the couse Computer Security lead by professor Babaoglu. 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

After a few hours of research I've found other two XSS (reflected) insertion points. More difficult to find, more satisfaction to have succeeded :) Take a look here please: http://jira.riotfamily.org/browse/RIOT-121. euronymous

The pleaseure to see the speed of bux-fixing by vendors is even much exciting that finding bugs! 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.

After a few months of security research inactivity, due to lack of time, I'm back guys. 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.