Security Advisory: Docebo Community Edition <= 4.0.5

Product description

Swascan Offensive Security Team has identified multiple vulnerabilities on Docebo Community Edition 4.0.5, an open source e-learning platform also defined as Learning Management System.

Technical summary

Swascan’s Cyber Security Team discovered important vulnerabilities on Docebo CE <= v.4.0.5

Vulnerability	CVSS 3.1
Docebo CE <= 4.0.5 – SQL Injection (unauthenticated)	8.6 – High [AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L]
Docebo CE <= 4.0.5 – Arbitrary File Upload (Authenticated)	8.8 – High [AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H]

In the following section the technical details about this vulnerability, including evidence and a proof-of-concept. This vulnerability can affect hundred applications.

Exploiting Docebo 4.0.5 Community Edition

Due to an unauthenticated SQL Injection and an authenticated Abitrary File Upload, it’s possible to gain a Remote Command Execution upon Docebo 4.0.5 Community Edition.

Unauthenticated SQL Injection

The application is vulnerable to unauthenticated SQL Injection attacks.

A remote unauthenticated attacker could exploit this vulnerability in order to access to the application DataBase. Once exploited, the attacker can exfiltrate or overwrite all the data within.

However, to exploit this vulnerability, the attacker needs to perform a large amount of HTTP request retrieving one character at a time.

Evidence 1 – Docebo Community Edition 4.0.5 – changelog.txt

The following figures show the evidences of the vulnerability and how it can be exploited. The Time-Based (Blind) technique has been used performing several HTTP requests and comparing the response time deelay.

Payload to verify:

test+AND+(SELECT+1+FROM(SELECT(SLEEP(5)))a)

This specific payload works for MySQL database >= 5.0.12.

Evidence 2 – SQL Injection detection – payload to verify

Evidence 3 – SQL Injection Time Based – 5 seconds delay

The time delay of 5 seconds confirms the vulnerability due to the SQL command injected SLEEEP(5).

The exploitation of this vulnerability doesn’t require any type of authentication.

Performing this attack, it’s possible to exfiltrate the users credentials (hashed) and, if cracked, log into the application.

Remediation

Review the validation logic of the information entered by the user so that a correct control of the input parameters is carried out using one or more of the following programming techniques:

Use of Prepared Statements (parameterized queries);
Use of Stored Procedures;
Validation and escaping of all user inputs that are used as query parameters;

It is also recommended to carry out the same checks in a timely manner on all queries made to the database since the same vulnerability may be present in many other points of the application than those reported.

Authenticated Arbitrary File Upload

After gaining an access to the application, an attacker could upload malicious files which could lead to arbitrary command execution on the remote server. The attacker could also use this vulnerability to upload a large file that may result in a Denial of Service (DoS).

It is shown below how it was possible to take advantage of the features of the application to upload a web shell written in php to the server.

To obtain this result the steps are the following:

Access to the avatar upload function
Append php code inside the field “up_avatar”
URL identification for webshell
Execution of arbitrary commands

The process is described by the following evidences:

Evidence 7 – HTTP Request to upload user avatar and payload injected in the field up_avatar

Evidence 8 – HTTP Response and identification of the URL to access to the webshell

Evidence 9 – Execution of arbitrary commands using the webshell uploaded in the previous step

Remediation

It is recommended to:

• Review the input validation of the file upload function, specifically, it is necessary to allow only the upload of file types functional to the business logic (for example, only images, PDF documents, etc …) through a whitelisting type filter (possibility of uploading only authorized file types);

• Block and notify the system administrator of the loading of the remaining types of files that could be interpreted and executed by the Web Server such as, for example, PHP, ASP, ASPX, JSP, etc …

For more details, refer to the user language and framework documentation and the OWASP SDLC guidelines.