Authentication Bypass via Improper Session Management

[bhamb]

Dear Team,

Although the session ID is generated and will be invalid during a normal Log in / out activity, still there is a possibility to abuse this Session Management due to a lack of invalidation process.

In case there is no logout and the user only close the browser (and maybe shutdown the computer) and later on he/she will use another browser or computer then a brand new Session ID will be generated during the login activity (which is OK) but the server will terminate the current session ID only during the logout. The user believes that his mailbox access is closed, but the first Session ID still can be used.

Risk.: The lack of the not proper session invalidation could lead an attacker to access all the victim user's emails. The risk is decreased by the fact, that the necessary data (old Session ID ) only can be achieved by the following persons:

• Any network admin who works at the victim's workplace and has access to some network device (esp. SSL proxy)
• Any network admin who works at "ISP"
• Any attacker who already infected the machine being used
• and so on

Mitigations:

1.: It is recommended to terminate / delete all the active sessions which belongs to the logged in user. Of course this solution does not help if the user just close the browser and will not use the mailbox for several hours, and in the meantime the attacker still has access to the mailbox. Furthermore, if concurrent login must be allowed, then a warning message can be sent about the logout to inform the other logged-in instance.

2.: If it is doable, the generated sessions should be bind with an IP address. This mitigation would protect the mailbox from the remote attackers only, and not from the attacker works from the same IP (Enterprise company)

[bhamb]

Correction:
Risk.: The lack of the proper session invalidation process could lead...

Tested versions: 1.4.4-1.4.8

[johndoh]

What exactly/how did you test this?

By default inactive sessions expire after 10 minutes, this can be adjusted using the session_lifetime config option. The client IP address can be used as part of the session authorization by enabling the ip_check config option.

[alecpl]

@bhamb I don't agree with most of what you've said. I mean there's always a risk, but the risk is mitigated as @johndoh explained.

There's one thing we could consider. It's to make sure that the expired sessions aren't used again. Even if GC is enabled (normally it is) it might not remove the expired sessions immediately. We could check if the session is valid when we first try to use it, i.e. in rcube_session_db::read(). Note, this is not needed for memcache/redis sessions (they expire immediately, the cache handles that), I'm not sure about php session driver.

[bhamb]

Hello,

session_lifetime and ip_check :
That is great. Thanks the info.

@alecpl : Yes, it would be great if you could check the re-usage of the expired session - as you mentioned. Because the I could access my own mailbox as I described above. I just had to send the HTTP requests again to the server.

[alecpl]

Fixed.