Today we will talk about a session management vulnerability affects OpenProject with all its version before 6.1.6 (old Stable) and 7.0.3 (latest stable) and may lead to accounts compromise and perform unauthorized actions via physical access to the logged in user session. but first lets know some general info.
First what is OpenProject?
OpenProject is a web-based project management system for location-independent team collaboration. This open source application is released under the GNU General Public License Version 3 and is continuously developed by an active open source community.
In addition to numerous smaller OpenProject installations there are also some very large installations in global organizations with more than 2,500 projects.
Let’s dive into the vulnerability details:
Vulnerability exploitation scenario:
A lot of users may leave their machines unlocked and this is a very trivial reason but the most important is that users are okay and count on the security settings of OpenProject because they take it for granted, A feature like “Session expiry time after inactivity” may prevent this vulnerability from being happening but it turned to be that some API requests are valid to be sent and perform actions (Commenting, removing comments, etc..) despite of the inactivity expiration period. The only way to prevent this and invalidate the session is to refresh the current page which redirects to “/login” page which is actually invalidating the current session but before all of the API requests are valid.
Vulnerability Type and Classification:
Top 10 2013-A2-Broken Authentication and Session Management
We suggest invalidating the session directly after exceeding the inactivity expiration period set in the administration panel.
OpenProject <= 7.0.3 (latest stable) and 6.1.6 (old stable)
Technical Explanation behind the issue:
OpenProject is a complex Rails monolith with regular Rails controllers for handling most of the application’s requests. They authenticate the user and check the session on each request through before_actions. Previous REST API versions were part of these controllers and thus got the same authentication scheme ‘for free’.
For APIv3, a grape-based API was introduced that required mirroring the authentication schemes, which are implemented in warden. OpenProject is a free application and no-one has yet attempted to merge these schemes into a single authentication flow for both sections of the application.
The issue was caused by the API session-based authentication scheme not properly checking for the optional session TTL setting, exposing the session through the API until a user visited any regular page of the application.
OpenProject team did a 4 files changes with 99 additions and 8 deletions based on the patch commit on their official github repository and you can clearly figure out what are the changes that have been done to the core files which manages the user session.
We released OpenProject 7.0.3. This release contains an import security fix regarding the session expiry that is detailed below.
We strongly recommend the update to the current version if you have activated the session expiry functionality of OpenProject.
OpenProject can be configured to expire sessions after a certain amount of inactivity on the session. The setting and time interval can be configured in the Authentication tab of the system settings.
The session authentication scheme for the APIv3, used in the majority of the angular-driven OpenProject work packages module, did not correctly check this setting and in turn, the setting did not matter for API session-based authentication. Users were able to use session for changes to work packages even past their allotted lifetime as long as the user did not leave the open work package module page. However, requests that and trigger a page refresh (e.g., visiting other modules or refreshing the page manually) cause the session to invalidate properly.
With this malfunction, an adversary hijacking an open session through whatever means could use it indefinitely for requests against the APIv3, as long as the owner of the session did not invalidate it through some page-refreshing request.
This security issue has been discovered by Mohamed A. Baset from Seekurity SAS de C.V and was disclosed to us yesterday evening. Thank you the elaborate report and for disclosing this directly to us. It is very much appreciated.
We take security very seriously at OpenProject. We value any kind of feedback that will keep our community secure. If you happen to come across a security issue we urge you to disclose it to us privately at email@example.com to allow our users and community enough time to upgrade. Security issues will always take precedence over anything else in the pipeline.
OpenProject fixed the vulnerability in a timely manner also released a public update regarding both versions 6.1.6 (old stable) and 7.3.3 (latest stable) and we were so amazed by their response and by the hot-fix been pushed to the public in less than a day, All kudos to their amazing development team who takes security literally very seriously.
A minute if you please!
Building a website, an application or any kind of business? Or already have one? Worried about your security? Think twice before going public and let us protect your business!