Bluepage CMS SQL Injection Vulnerabilities CVE-2022-38922, CVE-2022-38923
Affected Software and versions https://www.bluepage-cms.com/ thru v3.9 (Later versions may also be affected)
Discovery
During the course of conducting a security assessment on behalf of one of our customers, It was found that their main company website was managed by the Bluepage CMS (Content Management System). This software was discovered to contain two separate SQL Injection flaws that could be exploited remotely by any unauthenticated attacker.
Bluepage CMS
Bluepage is produced by ISS-Oberlausitz e.K., a Germany-based web application software company. They typically market and sell the software to small-to-medium-sized companies, sports clubs and charities, public bodies and organizations such as local government, transport, education, and healthcare, as well as museums and cultural institutes. In fact, they maintain a published list of customer organizations that use the software on their product website. This poses an increased risk of attack to such organizations that have not yet applied the latest version of the software. Therefore, we highly recommend any organizations that find their name on the list of Bluepage CMS Customers respond accordingly, and either update or replace the vulnerable software if it is still installed on their systems.
Disclosure Timeline
- 30 Aug 2022 - Vendor Informed of the findings and provided recommended actions to fix.
- 01 Sep 2022 - Vendor acknowledged the vulnerability and informed DTS that a patch was available.
- 15 Feb 2023 - CVE Acceptance confirmation received from MITRE.
- 20 Feb 2023 - Vendor informed that details will be made public.
- 21 Feb 2023 - Vendor responded and stated that an update is available to be applied.
- 29 Mar 2023 - CVE-2022-38922 & CVE-2022-38923 Vulnerability Details Published Online.
SQL Inject Attacks & Associated Risks
SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.
In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure or perform a denial-of-service attack.
A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.
SQL injection examples There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:
- Retrieving hidden data, where you can modify a SQL query to return additional results.
- Subverting application logic, where you can change a query to interfere with the application's logic.
- UNION attacks, where you can retrieve data from different database tables.
- Examining the database, where you can extract information about the version and structure of the database.
- Blind SQL injection, where the results of a query you control are not returned in the application's responses.
refs:
- https://portswigger.net/web-security/sql-injection
- https://owasp.org/www-community/attacks/SQL_Injection
Protecting Against SQL Injection
Use Prepared Statements (with Parameterized Queries)
The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
Use Stored Procedures
Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely which is the norm for most stored procedure languages.
They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.
Use Allow-list Input Validation
Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defence. For the names of tables or columns, ideally, those values come from the code, and not from user parameters.
Escaping All User-Supplied Input
This technique should only be used as a last resort when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defences and we cannot guarantee it will prevent all SQL Injections in all situations.
This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost-effective. Applications built from scratch, or applications requiring low-risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.
For more detailed guidance see the source reference link to OWASP below.
refs:
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Simple POC Details
The specific SQL Injection method used in the case of Bluepage CMS, was what is known as a Blind Time-Based attack. This combines two elements of SQL (Structured Query Language) to enable an attacker to bypass certain limitations imposed when attempting to extract data from a vulnerable system.
Blind SQL Injection is a technique of attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection. When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query’s syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.
In the case of Bluepage CMS, no error messages or data query responses could be produced on the web page. So this first technique needed to be combined with a second in order to bypass this limitation.
Time-based blind SQL injection relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic:
If the first letter of the first database’s name is an ‘A’, wait for 10 seconds. If the first letter of the first database’s name is an ‘B’, wait for 10 seconds. etc.
Therefore, on finding the correct first character, an attacker will see that a controllable period of delay can be injected (eg 10 seconds). This means that the request containing the correct character will produce this delay in addition to the average server response time. The attacker can then continue this process for every character in a data string and given enough time, even dump a copy of the entire database.
In the case of the two CVEs we discovered, both used a Time-Based Blind Blind attack technique, but are slighly different and each follow a unique execution chain in server-side code. CVE-2022-38922 requires a part-url-encoded payload injected into the 'users-cookie-settings' Cookie Header, and it produce a 1-to-1 time delay corresponding to the number of seconds injected in the payload. CVE-2022-38923 does not requere to be url-encoded and is injected instead in the User-Agent Header and produces a 1-to-2 time delay corresponding to the number of seconds injected in it's payload.
CVE-2022-38922 - BluePage CMS thru 3.9 processes an insufficiently sanitized HTTP Header Cookie value allowing MySQL Injection in the 'users-cookie-settings' token using a Time-based blind SLEEP payload
CVE-2022-38923 - BluePage CMS thru v3.9 processes an insufficiently sanitized HTTP Header allowing MySQL Injection in the 'User-Agent' field using a Time-based blind SLEEP payload.
Proof of Exploitability
Data exfiltration example using either injection point with the SQLMap (https://sqlmap.org/) Tool:
References & Sources:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38922
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38923
- https://portswigger.net/web-security/sql-injection
- https://owasp.org/www-community/attacks/SQL_Injection
- https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html


