A quick walk thru the 2.1.8 code doesn't show a problem with the read code. It doesn't create any login info, just checks if you are logged in (redirects to login page if not), checks if the logged in user is the from or to user and denies access if you aren't.

The pm sending code checks if you are a logged in user (e.g. not anonymous) and forces you to log in before sending it. The from user will be the currently logged in user.

Not sure where the bug is, if any. [originally posted on jforum.net by monroe]

194.8.75.xxx is the attackers ip, however we assume this might be a poor soul not knowing that he provides some of his bandwidth to contribute to a botnet/spamnet.

thank you in advance for helping us solvings this problem.

kind regards,
user0

[originally posted on jforum.net by user0]

Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424

posted Jun 08, 2009 15:05:30

0

Sorry for the delay... been on vacation with limited i-net access for the last week.

I still can't reproduce this. One thing that I notice from the above logs is that the GET request is using a "sendToUser" action. The standard action for sending PM is "sendTo" and not this.

Since "sendToUser" is not a jForum valid action the default code will re-direct to the PM "list" action, which since the requester is not logged on redirects to the login page. The POST action following this looks like (but I can't be sure) a login response. None of this can send unauthorized messages.

Are you using a modified version of the PrivateMessageAction class with a sendToUser() method added? If so, the security problem is in this code.

You might also check that the modulesMapping.xml files still maps the pm module to the jForum default class. Perhaps someone has replaced with with their own version that allows this.

Are you using SSO or normal jForum security? The second post command could be login information that is getting past your SSO code.

You might find information about this in the JForum_Sessions table. This maps user sessions to the last IP address they logged in from.

Finally, could this be a case of someone being able to access your WebApp server's Session Id information. This is the "magic" number that is returned by the app server to tie requests to a specific session (generally as a session cookie). All webapps have a limited vulnerability via this if someone can find this information.

However, this generally depends on having network snooping hardware between the user and server (or physical access to the DB or server logs). Plus this information is only usable during the lifetime of the user session. (depends on server time out settings).

The "cure" for this is to use SSL connections which can't be easily snooped. But since most networks use switches which mean snooping doesn't work well unless you have access to the switchs and and there for only dangerous if the snooper is inside your or your ISPs physical security, it becomes an issue of "how much security do you really need (and are willing to pay for)".