Security Risks in mojoPortal

This is an open forum for any mojoPortal topics that don't fall into the other categories.

This thread is closed to new posts. You must sign in to post in the forums.
10/31/2011 1:07:42 AM
Gravatar
Total Posts 37

Security Risks in mojoPortal

Hi guys,

We had the opportunity to work with an "ethical hacking" company over the past month to put mojo through its paces for a clients site. Overall, mojoPortal actually performed outstandingly well bar a few minor risks. These are risks that dont offer a specific vulnerability but could cause a hacker to want to "look further" into the compromising your site.

I have a meeting scheduled with this company next week and will post the results here if anyone is interested. The items that have been highlighted as potential risks are

  1. CSRF - Cross site request forgery. I see this is also mentioned on various security sites with the FileHandler module in mojo version up to 2.3.5.1. I cant find any further info as to whether it has been resolved.
  2. Credential harvesting - if you access your forums page (userthreads.aspx) and pass in a user ID you can (in the case where you use LDAP), identify a login username (if the users have not set their full names). I argued this point as a forum is public domain but took the point about usernames with LDAP. As an interim, i added a request.IsAuthenticated to this page as its for use only on the customers intranet site. The issue here is someone could harvest these username and attempt brute force attacks or in their case, call up the IT department, pretend to be an employee giving their username (and email) and request a password change. More of an issue for the IT department and their systems for dealing with password change requests by "remote users", but an interesting issue nonetheless.

If Joe agrees, im happy to post back the results of the meeting and share the finding with the community.

Adrian

 

10/31/2011 8:32:36 AM
Gravatar
Total Posts 18439

Re: Security Risks in mojoPortal

Hi Adrian,

If someone found an actual vulnerability I would want them to contact me privately so that I would have an opportunity to fix the problem before it was known publicly so we could protect our customers. Other than that of course I'm happy to hear of any findings.

1. Was fixed in version 2.3.5.2

2. You are describing a social engineering attack. Most companies use emails or logins that reflect the name of the user so if a hacker knows the names of people in a company he can try these social engineering attacks by calling the IT dept as you have said and if the IT dept is not careful they may help a hacker out. So your concern seems to be that the forums may make it easier to find out names to try in a social engineering attack.

Knowing a userid from mojoPortal does not give access to the login name nor email address and neither the login name nor email address is  displayed in the forums but when we auto create a new user in mojoPortal from LDAP the display name is set the same as the login name since we have no other string to use and we have to put something there for display. I don't really see this as an issue related/limited to the userthreads.aspx page because any forum post shows the display name. However it is possible to disable the userthreads view by setting this to false in Web.config/user.config:

<add key="AllowUserThreadBrowsing" value="false"/>

There are some additional mitigations possible if you are concerned that the display names could be used for social engineering attacks. You can prevent users from changing their display names from Site Settings, there is a setting "Allow Users To Change their Display Name". If you wanted to make sure that mojoPortal users automatically created based on LDAP authentication have a display name different than their login name you could implement a custom UserRegisteredEventHandler where you could implement your own routine for deciding what the display name should be and update the display name. Or you could run a query periodically and update the table directly to change the display name if you find any that match the login name.

You mentioned it being for an Intranet, a true Intranet is a private network usually only available to employees so in that case if you are worried about hacking from internal employees, they probably already know who works in the company so these user names are not giving them additional information. On an Extranet (a public facing Intranet) then I can see where you might be concerned about non employees learning names of employees in order to try a social engineering attack against the IT dept. But again the above mitigations are possible.

Of course there are many other ways a hacker can find out the names of some employees at a company, often it is posted on a web site or publicly known or searching news articles one can find out the names of some people working there and they can guess email addresses and login names based on the employee name, so really it is on the IT dept to have good practices about handling calls requesting credentials or credential changes.

Also note that in terms of a brute force attack trying to login to mojoPortal, the account is going to be temporarily locked for a period of time after a specified number of failed login attempts (Configurable parameters in site settings), so its going to take them a lot of time and persistence.

Best,

Joe

10/31/2011 10:04:37 AM
Gravatar
Total Posts 37

Re: Security Risks in mojoPortal

Thanks Joe, as always a perfect response. I totally agree with your take on the matter and put the same forward to the client during our first meeting. The suggestion you mention for the config files and custom for use in the forums is great, i will amend as per below. The idea of a custom handler to change the display name is great. Ill give it some thought and see what we can come up with that meets security requirements for the client. They might just agree to all employees having a display name of "Company Employee", "Company Employee + Employee Number" or just a nickname

I will of course, as soon as we have had the meeting, provide you with the details of their findings to review and discuss. I will send these to your personal email and share the results after any steps, if even necessary, have been taken to protect other mojoportal customers / users.

I would like to add that there were no critical issues identified in mojoPortal. They provided us initially with a 68 page document describing any and all items investigated and any issues identified. Bar the social engineering attack approach, as Joe describes below, mojoPortal received a near perfect score! Seriously well done Joe!

Adrian

 

10/31/2011 10:50:48 AM
Gravatar
Total Posts 1204
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Security Risks in mojoPortal

Hi guys, just one quick correction. When we made a series of changes to support LDAP fallback authentication for release 2.3.5.8, Joe and I changed the Open LDAP and Active Directory default display names. Users auto-registered via Open LDAP will have a display name that's a concatenation of "givenName" for first name, and "sn" for last name (if those keys are populated). Users auto-registered via Active Directory will have a display name set to their "cn" value.

Hope that helps,
Jamie

You must sign in to post in the forums. This thread is closed to new posts.